Date   

Re: useless-rpaths : How to solve it/Know if it should be solved ?

Vitor Crestani Goergen
 

This is the git branch from which I am taking my Kernel source:
Attached is a folder with the recipe source code and bbfile. The bbfile has the INSANE SKIP because I didn't change it.

Thanks for your help,

Vitor



On Fri, 25 Sep 2020 at 14:30, Alexander Kanavin <alex.kanavin@...> wrote:
It helps if you can show the recipe, and the git repo of the library.

Alex

On Wed, 23 Sep 2020 at 13:30, Vitor Crestani Goergen <crestanivitor@...> wrote:
Hello,

I have been dealing with Yocto for about a month, so I am still a beginner.

I am usign a NXP Sabresd board with an iMX6 processor. I have the recipes from oe, bsp, freescale etc downloaded from the NXP website, although I replaced the kernel with the EVL core project kernel. I did this in a workspace using devtool.

I was able to bitbake and build this new kernel without a problem. After that, I set on to install some libraries, specifically libevl, which is the library from the EVL project. This source code comes with several makefiles. I don't understand most of the codes in these makefiles but I am currently working on that. 

I created a new layer and a recipe for this library. Initially I had an error of "files shipped but not installed" but that was fixed by adding some more information to FILES_${PN}. Now, I am stuck with the following error message when trying to build:

Error: QA issue: libevl: /work/{machine}/libevl/0.1-r0/packages-split/libevl/usr/lib/libevl-0.so.0 contains probably redundant RPATH /usr/lib 

I am aware that a "solution" exists using INSANE_SKIP. I did that and everything worked. However, I would not like to put more things than I should just to take up space on the board.

What I tried so far was to add somefiles to FILES_${PN}-dev, telling Make to ignore RPATH (Using the variable CMAKE_IGNORE_RPATH) but none of these worked.

I've also seen in some discussions that maybe this should probably stay as it is. How can I determine if this is normal behaviour and I should just use INSANE_SKIP?

Thanks in advance,

Vitor




Re: useless-rpaths : How to solve it/Know if it should be solved ?

Alexander Kanavin
 

It helps if you can show the recipe, and the git repo of the library.

Alex


On Wed, 23 Sep 2020 at 13:30, Vitor Crestani Goergen <crestanivitor@...> wrote:
Hello,

I have been dealing with Yocto for about a month, so I am still a beginner.

I am usign a NXP Sabresd board with an iMX6 processor. I have the recipes from oe, bsp, freescale etc downloaded from the NXP website, although I replaced the kernel with the EVL core project kernel. I did this in a workspace using devtool.

I was able to bitbake and build this new kernel without a problem. After that, I set on to install some libraries, specifically libevl, which is the library from the EVL project. This source code comes with several makefiles. I don't understand most of the codes in these makefiles but I am currently working on that. 

I created a new layer and a recipe for this library. Initially I had an error of "files shipped but not installed" but that was fixed by adding some more information to FILES_${PN}. Now, I am stuck with the following error message when trying to build:

Error: QA issue: libevl: /work/{machine}/libevl/0.1-r0/packages-split/libevl/usr/lib/libevl-0.so.0 contains probably redundant RPATH /usr/lib 

I am aware that a "solution" exists using INSANE_SKIP. I did that and everything worked. However, I would not like to put more things than I should just to take up space on the board.

What I tried so far was to add somefiles to FILES_${PN}-dev, telling Make to ignore RPATH (Using the variable CMAKE_IGNORE_RPATH) but none of these worked.

I've also seen in some discussions that maybe this should probably stay as it is. How can I determine if this is normal behaviour and I should just use INSANE_SKIP?

Thanks in advance,

Vitor




Re: SIGINT Issues with Zeus Migration

Aashik Aswin
 

Hi Leon, Zoran

I am using Ctrl+C to kill the Ping command.


Thanks.

On Fri, Sep 25, 2020 at 3:56 PM Zoran Stojsavljevic <zoran.stojsavljevic@...> wrote:
Hello Leon,

> Aashik, how are you sending the signal? Using CTRL-C or
> using the "kill" command?

This is a good suggestion for the test. To open another terminal and
issue: kill -SIGINT <ping PID>.

I should add that this MUST work: kill -SIGKILL <ping PID>, since
SIGKILL handler is un-preemptable.

If it does not, something is very wrong... I suggest, Aashik, you
write YOCTO bugzilla for Zeus.

> Zoran, are you suggesting that the program will change the signal
> handler to default even after it has exited, and for the subsequent
> ping command?

Yes, I do. Then, the ping command should be issued again, and my best
guess is, it should terminate the ping process.

Leon, you should try to write another C f-n and to install other
SIGINT handler (replacing SIG_DFL), then test it with my original C:

void  myhandler(int signum) {
        if (SIGINT == signum)
                printf("\nHey, I got SIGINT: %d\n\n",signum);
}

Zoran
_______

On Fri, Sep 25, 2020 at 10:54 AM Leon Woestenberg <leon@...> wrote:
>
> Hi Aashik, Zoran,
>
>
> On Fri, Sep 25, 2020 at 10:02 AM Zoran <zoran.stojsavljevic@...> wrote:
> >
> > > ...that I am not able to send SIGINT to commands such as Ping, tail etc.\
>
> Aashik, how are you sending the signal? Using CTRL-C or using the
> "kill" command?
>
> >
> > Please, do the following: issue in zeus xterm the command: man signal
> > and read it.
> >
> That reads to use sigaction() instead of signal() I would assume.
>
> > Then execute the following code (ad-hoc from the top of my head):
> > <...>
> > This program serves the double purpose:
> > [1] Gives you the address of the old SIGINT handler which was executed
> > prior execution of this code;
> > [2] After execution, repeat the routine (ping) and see if <ctrl c>
> > terminates the ping process.
> >
>
> Zoran, are you suggesting that program will change the signal handler
> to default even after it has exited, and for the subsequent ping
> command?
>
> Regards,
>
> Leon.


Re: SIGINT Issues with Zeus Migration

Zoran
 

Hello Leon,

Aashik, how are you sending the signal? Using CTRL-C or
using the "kill" command?
This is a good suggestion for the test. To open another terminal and
issue: kill -SIGINT <ping PID>.

I should add that this MUST work: kill -SIGKILL <ping PID>, since
SIGKILL handler is un-preemptable.

If it does not, something is very wrong... I suggest, Aashik, you
write YOCTO bugzilla for Zeus.

Zoran, are you suggesting that the program will change the signal
handler to default even after it has exited, and for the subsequent
ping command?
Yes, I do. Then, the ping command should be issued again, and my best
guess is, it should terminate the ping process.

Leon, you should try to write another C f-n and to install other
SIGINT handler (replacing SIG_DFL), then test it with my original C:

void myhandler(int signum) {
if (SIGINT == signum)
printf("\nHey, I got SIGINT: %d\n\n",signum);
}

Zoran
_______

On Fri, Sep 25, 2020 at 10:54 AM Leon Woestenberg <leon@sidebranch.com> wrote:

Hi Aashik, Zoran,


On Fri, Sep 25, 2020 at 10:02 AM Zoran <zoran.stojsavljevic@gmail.com> wrote:

...that I am not able to send SIGINT to commands such as Ping, tail etc.\
Aashik, how are you sending the signal? Using CTRL-C or using the
"kill" command?


Please, do the following: issue in zeus xterm the command: man signal
and read it.
That reads to use sigaction() instead of signal() I would assume.

Then execute the following code (ad-hoc from the top of my head):
<...>
This program serves the double purpose:
[1] Gives you the address of the old SIGINT handler which was executed
prior execution of this code;
[2] After execution, repeat the routine (ping) and see if <ctrl c>
terminates the ping process.
Zoran, are you suggesting that program will change the signal handler
to default even after it has exited, and for the subsequent ping
command?

Regards,

Leon.


Re: sd-bus.h not found when compiling #yocto

Quentin Schulz
 

Hi Talel,

On Fri, Sep 25, 2020 at 02:08:17AM -0700, Bel Hadj Salem Talel wrote:
Hi All,
I'm trying to create a recipe for wirepas_gateway , it is a python project, but it uses systemd dbus , and there is a .c file that includes  #include <systemd/sd-bus.h>
I tried to add "systemd" and "libsystemd" to RDPENDS, but same error keeps showing :
RDEPENDS is for runtime dependencies, DEPENDS is for build time, so you
want to use DEPENDS here.

Cheers,
Quentin


sd-bus.h not found when compiling #yocto

Bel Hadj Salem Talel
 

Hi All,
I'm trying to create a recipe for wirepas_gateway , it is a python project, but it uses systemd dbus , and there is a .c file that includes  #include <systemd/sd-bus.h>
I tried to add "systemd" and "libsystemd" to RDPENDS, but same error keeps showing :
dbus_c.c:9:10: fatal error: systemd/sd-bus.h: No such file or directory|     9 | #include <systemd/sd-bus.h>
Here is my recipe:
SUMMARY = "Wirepas gateway transport service that connects the local dbus to a remote MQTT broker."
HOMEPAGE = "https://github.com/wirepas/gateway"
LICENSE = "Apache"
LIC_FILES_CHKSUM = "file://LICENSE;md5=cb6bb17b0d0cca188339074207e9f4d8"
SRC_URI = "file:///home/talel/Desktop/wirepas_gateway-${PV}/wp-gateway.zip"
inherit setuptools3
RDEPENDS_${PN} += "libsystemd python3-pyyaml python3-grpcio python3-paho-mqtt python3-pydbus python3-wirepas_messaging"
RDEPENDS_${PN} += "python3-core python3-datetime python3-io python3-json python3-logging python3-netclient python3-paho-mqtt python3-pygobject python3-pyyaml python3-threading"

How can I solve the issue ?

Thanks, Talel


Re: SIGINT Issues with Zeus Migration

Leon Woestenberg
 

Hi Aashik, Zoran,


On Fri, Sep 25, 2020 at 10:02 AM Zoran <zoran.stojsavljevic@gmail.com> wrote:

...that I am not able to send SIGINT to commands such as Ping, tail etc.\
Aashik, how are you sending the signal? Using CTRL-C or using the
"kill" command?


Please, do the following: issue in zeus xterm the command: man signal
and read it.
That reads to use sigaction() instead of signal() I would assume.

Then execute the following code (ad-hoc from the top of my head):
<...>
This program serves the double purpose:
[1] Gives you the address of the old SIGINT handler which was executed
prior execution of this code;
[2] After execution, repeat the routine (ping) and see if <ctrl c>
terminates the ping process.
Zoran, are you suggesting that program will change the signal handler
to default even after it has exited, and for the subsequent ping
command?

Regards,

Leon.


Re: SIGINT Issues with Zeus Migration

Zoran
 

...that I am not able to send SIGINT to commands such as Ping, tail etc.
Please, do the following: issue in zeus xterm the command: man signal
and read it.

Then execute the following code (ad-hoc from the top of my head):

#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

typedef void (*sighandler_t)(int);
sighandler_t signal_handler;
sighandler_t signal(int signum, sighandler_t handler);

int main() {
signal_handler = signal(SIGINT, SIG_DFL);
printf ("Old signal handler is 0x%x\n", signal_handler);
}

Where the following is also known:
#define SIG_ERR ((__sighandler_t) -1) /* Error return. */
#define SIG_DFL ((__sighandler_t) 0) /* Default action. */
#define SIG_IGN ((__sighandler_t) 1) /* Ignore signal. */

This program serves the double purpose:
[1] Gives you the address of the old SIGINT handler which was executed
prior execution of this code;
[2] After execution, repeat the routine (ping) and see if <ctrl c>
terminates the ping process.

All other comments are obvious (testing the Zeus SIGINT signal, yada
yada yada... ;-)

Zoran
_______

On Fri, Sep 25, 2020 at 6:48 AM Aashik Aswin <thisisaash9698@gmail.com> wrote:

Hello Developers,

I recently migrated all my platform Recipes from Thud (Linux 4.19) to Zeus (5.4). I understand there might be compatibility issues and was able to fix most of them.

However one issue I am facing is that in the newly migrated Zeus Image is that I am not able to send SIGINT to commands such as Ping, tail etc. I am only able to run them in non-interactive mode. I have to reboot the box if I executed those above commands in interactive mode.

Can anyone suggest which recipe/config can be a good starting point?

Please let me know your suggestions.

Thanks,
Aashik



Per recipe licenses with dependencies

Daniel Ammann
 

Hi

Is there a tool or an simple way to create a list of licenses used by a recipe
(in contrast to an image)? It should include all of the dependencies as well.

Thanks, Daniel

--
bytes at work
Technoparkstrasse 7
CH-8406 Winterthur
Switzerland

phone: +41 52 550 50 67


SIGINT Issues with Zeus Migration

Aashik Aswin
 

Hello Developers,

I recently migrated all my platform Recipes from Thud (Linux 4.19) to Zeus (5.4). I understand there might be compatibility issues and was able to fix most of them.

However one issue I am facing is that in the newly migrated Zeus Image is that I am not able to send SIGINT to commands such as Ping, tail etc. I am only able to run them in non-interactive mode. I have to reboot the box if I executed those above commands in interactive mode. 

Can anyone suggest which recipe/config can be a good starting point?

Please let me know your suggestions.

Thanks,
Aashik


Yocto Technical Team Minutes, Engineering Sync, for September 22, 2020

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for September 22, 2020
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Armin Kuster, Stephen Jolly, Martin Jansa (JaMa), Richard
Purdie, Joshua Watt (JPEW), Steve Sakoman (SS), Mark Morton, Michael
Halstead, David Reyna, Saul Wold, Paul Barker, Scott Murray, Jon Mason,
Randy MacLeod, Bruce Ashfield, Alejandro H, Tim Orling (Timo)

== notes ==
- m3-rc1 build and ran, qa found issues (beaglebone fails to boot) therefore
an -rc2 will be built
- 3.1.3 will be built soon
- sphinx transition has merged (docs.yoctoproject.org)
- one of the AB timeout issues identified and patch sent
- other AB issues to work on

== general ==
RP: beaglebone issues, ptest issues, please take a look

RP: believe we found why there are stalls on I/O (journal writing), tweaks
made, hope they help (thanks Michael)
RP: but there are still other AB issues (e.g. --x bit not set, caused by sudo
re-used inodes)
RP: this is blocking next build, not sure if they’re caused by master-next


RP: sphinx updates merged, it’s just the start, there are lots of URL issues
and lots of out-dated content that could use an update
Randy: is this documented somewhere (the workflow)?
RP: the README has been updated
RP: ignore the xml files, make changes to the rst files

RP: (to Michael) how close are we to getting auto-updates to the website
Michael: very close, just need an update to the new process
RP: would be great to not need manual intervention to update the docs
Michael: who would need to know of any failures other than me?
RP: the docs email list

PaulB: follow-up on last week’s rust discussion
PaulB: the license stuff looks good, what’s in meta-rust looks good, it
provides a fetcher (i.e. crates) that feeds that to bitbake. lots of stuff
that works (e.g. BB_NO_NETWORK).
PaulB: one limitation is that licenses of fetched dependencies are not fetched
PaulB: the crate-fetcher should be moved into bitbake itself, it just uses https as expected, so shouldn’t be too hard
RP: sounds good!
PaulB: after seeing npm nightmares, rust looks good!
PaulB: we need a story for handling licenses of dependencies
Randy: can we not just list all the licences for each one?
PaulB: the cargo-bitbake tool should be able to simply recurse through the
dependencies
PaulB: the cargo-bitbake tool is written in rust (as opposed to python3)

RP: on the licensing email list there was a question about licensing. there
are packages with sprawling dependencies and although the top-level
license is listed the licenses of the dependencies are not
PaulB: there is a tool (scancode-tk class in meta-spdxscanner) that can go
through a repository to look for license text (and itemize them). it’s a
very time-consuming process; core-image-minimal adds 23 hours to a 1 hour
build
RP: when we scan for debug symbols it tells us what’s included in the binary
PaulB: scancode-tk uses the fetching and patching to examine, examining only
the debug symbols would cut down the time
RP: in any case the question on the licensing mailing list needs a reply. do
we add to do_license?
PaulB: i don’t think it can ever be “complete”
RP: true, but maybe there are holes that can be easily filled
Armin: would ptest-check come into play too?
RP: those can be under a different license
Armin: what i mean is, sometimes enabling ptests causes other things to be
downloaded and used, would those be included? would those be considered
part of the package license compliance list
RP: since it’s downloaded but not shipped, i don’t think so, i think it
should be a runtime issue
(various): qt5, chromium, wayland, etc
RP: sounds like there’s work here to do and things to investigate

RP: are we going to get the rust fetcher into bitbake?
Randy: working on other stuff at the moment, but was going to get “hello
world” working, then focus on packaging, then later a “hello
crazy-world” (i.e. a larger rust program)
RP: makes sense to break it up into logical chunks. sounds like working on the
fetcher and having fetcher tests would be nice
Randy: PaulB does that sound good?
RP: I need to poke the meta-rust maintainers and see what they think/involve
them
Randy: they didn’t seem super interested in participating when i poked them
a while back
PaulB: but yes, working on the fetcher sounds like a good area to work on.
it’s fairly self-contained. needs test cases. should be able to pull it
in without the rest of meta-rust
Randy: does it make sense to do the toolchain alone then librsvg
PaulB: where is librsvg? (librsvg needs rust to build now)
Randy: oe-core
Armin: in meta-security there is a newer package that i haven’t brought in
because it needs rust, so it could be a good test case
PaulB: rust has really fast releases, how do we want to handle that amongst
the various branches?
PaulB: with python it makes sense to write a recipe for each and every
library/dependency that is used, but rust works differently, it doesn’t
work in the way of needing to build dependencies then building the main
app itself. in rust we just need a recipe for the app, and the rest gets
handled
Randy: (divides work up between himself and PaulB, going forward)

Stephen: there will be a new invite to this meeting and the bug triage meeting
on the mailing list, the new links will have an embedded password

RP: anything on stable front that we need to talk about
SS: not really. when we do the latest pull we’ll need to start a new build
RP: centos 7 perf?

RP: Bruce: x86 backtrace?
Bruce: had a quick look, no ideas yet, will look at it later today
RP: it’s a weird one and it worries me: a corrupt return pointer? maybe a
tool issue
Bruce: we can’t blame system load on this one
RP: it looks like corruption


Re: QA notification for completed autobuilder build (yocto-3.2_M3.rc2)

Richard Purdie
 

On Thu, 2020-09-24 at 08:33 +0100, Richard Purdie via
lists.yoctoproject.org wrote:
On Thu, 2020-09-24 at 03:22 +0000, Pokybuild User wrote:
A build flagged for QA (yocto-3.2_M3.rc2) was completed on the
autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.2_M3.rc2


Build hash information:

bitbake: 27b53186fa67d281d29b2f8e15bcff8dc2557b8a
meta-arm: c7a1a5f9fd415e3ae1078c2a1d6af9c25e9e6498
meta-gplv2: a8da8eb127a56561bf633ab53bec57fb5dbba537
meta-intel: 254e3a79b3a37045f829848e0a5e04801bec1439
meta-kernel: cb7f0dc5bb1ea0998c8d4fcb486148d4cab575f4
meta-mingw: f1e1d5a803a48ed70f2b0eaf0ef15ade70479fce
oecore: e68df923e1bf9e82662ee2619ac9e2f239e8f7be
poky: 0a243cd21263f498b6eca7c0b168e655dd823e22



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@linuxfoundation.org
There were two failures in this build. One was a single selftest
failure which I'll look into. The other was a qemumips altcfg image
loss of networking. I know Saul is working on better debug for that
and we have open bugs for it.
Much to my surprise, I figured out the issue and there is a patch for
the selftest failure on the bitbake list. It won't stop the release or
QA.

Cheers,

Richard


Re: QA notification for completed autobuilder build (yocto-3.2_M3.rc2)

Sangeeta Jain
 

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.2_M3.rc2.
We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. Beaglebone

ETA for completion is next Monday, September 28.

Thanks,
Sangeeta

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On Behalf
Of Pokybuild User
Sent: Thursday, 24 September, 2020 11:23 AM
To: yocto@lists.yoctoproject.org
Cc: otavio@ossystems.com.br; yi.zhao@windriver.com; Sangal, Apoorv
<apoorv.sangal@intel.com>; Yeoh, Ee Peng <ee.peng.yeoh@intel.com>; Chan,
Aaron Chun Yew <aaron.chun.yew.chan@intel.com>;
richard.purdie@linuxfoundation.org; akuster808@gmail.com;
sjolley.yp.pm@gmail.com; Jain, Sangeeta <sangeeta.jain@intel.com>
Subject: [yocto] QA notification for completed autobuilder build (yocto-
3.2_M3.rc2)


A build flagged for QA (yocto-3.2_M3.rc2) was completed on the autobuilder
and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.2_M3.rc2


Build hash information:

bitbake: 27b53186fa67d281d29b2f8e15bcff8dc2557b8a
meta-arm: c7a1a5f9fd415e3ae1078c2a1d6af9c25e9e6498
meta-gplv2: a8da8eb127a56561bf633ab53bec57fb5dbba537
meta-intel: 254e3a79b3a37045f829848e0a5e04801bec1439
meta-kernel: cb7f0dc5bb1ea0998c8d4fcb486148d4cab575f4
meta-mingw: f1e1d5a803a48ed70f2b0eaf0ef15ade70479fce
oecore: e68df923e1bf9e82662ee2619ac9e2f239e8f7be
poky: 0a243cd21263f498b6eca7c0b168e655dd823e22



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@linuxfoundation.org



Re: [meta-cgl][PATCH] pacemaker: Fix build with -fno-common

Yu, Mingli
 

Ping.

Thanks,

On 9/3/20 1:59 PM, Yu, Mingli wrote:
From: Mingli Yu <mingli.yu@windriver.com>
Starting with GCC >= 10.x, -fno-common is used as default
instead of -fcommon.
Make the function definiton extern to fix the build failure.
Set the default OCF_ROOT_DIR to $libdir/ocf to make the
resource agents components more compatible.
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
---
.../0001-Mark-declaration-with-extern.patch | 46 +++++++++++++++++++
...maker-set-OCF_ROOT_DIR-to-libdir-ocf.patch | 32 +++++++++++++
.../recipes-cgl/pacemaker/pacemaker_2.0.3.bb | 2 +
3 files changed, 80 insertions(+)
create mode 100644 meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Mark-declaration-with-extern.patch
create mode 100644 meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-set-OCF_ROOT_DIR-to-libdir-ocf.patch
diff --git a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Mark-declaration-with-extern.patch b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Mark-declaration-with-extern.patch
new file mode 100644
index 0000000..5729447
--- /dev/null
+++ b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Mark-declaration-with-extern.patch
@@ -0,0 +1,46 @@
+From e1abd3b7c7a0122813e4d0abdb079df10104882c Mon Sep 17 00:00:00 2001
+From: Mingli Yu <mingli.yu@windriver.com>
+Date: Thu, 3 Sep 2020 04:44:09 +0000
+Subject: [PATCH] Mark declaration with extern
+
+Fixes build with gcc 10+
+
+Upstream-Status: Pending
+
+Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
+---
+ daemons/attrd/pacemaker-attrd.h | 4 ++--
+ daemons/execd/pacemaker-execd.h | 2 +-
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/daemons/attrd/pacemaker-attrd.h b/daemons/attrd/pacemaker-attrd.h
+index cc8e29ee1..76778915e 100644
+--- a/daemons/attrd/pacemaker-attrd.h
++++ b/daemons/attrd/pacemaker-attrd.h
+@@ -106,8 +106,8 @@ typedef struct attribute_value_s {
+ gboolean seen;
+ } attribute_value_t;
+
+-crm_cluster_t *attrd_cluster;
+-GHashTable *attributes;
++extern crm_cluster_t *attrd_cluster;
++extern GHashTable *attributes;
+
+ #define attrd_send_ack(client, id, flags) \
+ crm_ipcs_send_ack((client), (id), (flags), "ack", __FUNCTION__, __LINE__)
+diff --git a/daemons/execd/pacemaker-execd.h b/daemons/execd/pacemaker-execd.h
+index 4a52d9183..dab3ccdbe 100644
+--- a/daemons/execd/pacemaker-execd.h
++++ b/daemons/execd/pacemaker-execd.h
+@@ -20,7 +20,7 @@
+ # include <gnutls/gnutls.h>
+ # endif
+
+-GHashTable *rsc_list;
++extern GHashTable *rsc_list;
+
+ typedef struct lrmd_rsc_s {
+ char *rsc_id;
+--
+2.26.2
+
diff --git a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-set-OCF_ROOT_DIR-to-libdir-ocf.patch b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-set-OCF_ROOT_DIR-to-libdir-ocf.patch
new file mode 100644
index 0000000..1ff9c7d
--- /dev/null
+++ b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-set-OCF_ROOT_DIR-to-libdir-ocf.patch
@@ -0,0 +1,32 @@
+From 3ca78a6441eefc26f18211375b18205ed6fc28c6 Mon Sep 17 00:00:00 2001
+From: Mingli Yu <mingli.yu@windriver.com>
+Date: Thu, 3 Sep 2020 05:26:36 +0000
+Subject: [PATCH] pacemaker: set OCF_ROOT_DIR to $libdir/ocf
+
+* Set the default OCF_ROOT_DIR to $libdir/ocf
+ to make the resource agents components more
+ compatible
+
+Upstream-Status: Pending
+
+Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
+---
+ configure.ac | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index 58d39cdc0..eb4275560 100644
+--- a/configure.ac
++++ b/configure.ac
+@@ -315,7 +315,7 @@ dnl This defaults to /usr/lib rather than libdir because it's determined by the
+ dnl OCF project and not pacemaker. Even if a user wants to install pacemaker to
+ dnl /usr/local or such, the OCF agents will be expected in their usual
+ dnl location. However, we do give the user the option to override it.
+-OCF_ROOT_DIR="/usr/lib/ocf"
++OCF_ROOT_DIR="$libdir/ocf"
+ AC_ARG_WITH([ocfdir],
+ [AS_HELP_STRING([--with-ocfdir=DIR],
+ [OCF resource agent root directory (advanced option: changing this may break other cluster components unless similarly configured) @<:@/usr/lib/ocf@:>@])],
+--
+2.26.2
+
diff --git a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.3.bb b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.3.bb
index 9b63acd..56f3bc4 100644
--- a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.3.bb
+++ b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.3.bb
@@ -16,6 +16,8 @@ DEPENDS = "corosync libxslt libxml2 gnutls resource-agents libqb python3-native"
SRC_URI = "git://github.com/ClusterLabs/${BPN}.git \
file://0006-Fix-tools-Fix-definition-of-curses_indented_printf.patch \
file://0001-Fix-python3-usage.patch \
+ file://0001-Mark-declaration-with-extern.patch \
+ file://0001-pacemaker-set-OCF_ROOT_DIR-to-libdir-ocf.patch \
file://volatiles \
file://tmpfiles \
"


[meta-cgl][PATCH] pacemaker: improve reproducibility

Yu, Mingli
 

From: Mingli Yu <mingli.yu@windriver.com>

Remove the build path info from the files such as crm_master,
crm_report and etc to improve reproducibility.

Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
---
.../recipes-cgl/pacemaker/pacemaker_2.0.3.bb | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)

diff --git a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.3.bb b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.3.bb
index 56f3bc4..8576f18 100644
--- a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.3.bb
+++ b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.3.bb
@@ -51,6 +51,18 @@ EXTRA_OECONF += "STAGING_INCDIR=${STAGING_INCDIR} \
CACHED_CONFIGUREVARS += " \
ac_cv_path_BASH_PATH=/bin/bash \
"
+do_configure_prepend() {
+ # remove buildpath
+ placeh="abs_top_builddir abs_top_srcdir"
+ for ph in $placeh
+ do
+ srcdirs=$(grep -Rn $ph ${S}/* | awk -F: '{print $1}' | uniq)
+ for srcdir in $srcdirs
+ do
+ sed -i "s/${ph}/${ph}_placeholder/g" $srcdir
+ done
+ done
+}

do_install_append() {
install -d ${D}${sysconfdir}/default
@@ -66,6 +78,13 @@ do_install_append() {

rm -rf ${D}${localstatedir}/lib/heartbeat
rm -rf ${D}${localstatedir}/run
+
+ # remove buildpath
+ tempdirs=$(grep -Rn ${RECIPE_SYSROOT_NATIVE} ${D}/* | awk -F: '{print $1}' | uniq)
+ for temdir in $tempdirs
+ do
+ sed -i "s:${RECIPE_SYSROOT_NATIVE}::g" $temdir
+ done
}

PACKAGES_prepend = "${PN}-cli-utils ${PN}-libs ${PN}-cluster-libs ${PN}-remote "
--
2.26.2


Re: QA notification for completed autobuilder build (yocto-3.2_M3.rc2)

Sangeeta Jain
 

-----Original Message-----
From: Richard Purdie <richard.purdie@linuxfoundation.org>
Sent: Thursday, 24 September, 2020 3:34 PM
To: Pokybuild User <pokybuild@ubuntu2004-ty-2.yocto.io>;
yocto@lists.yoctoproject.org; Saul Wold <Saul.Wold@windriver.com>
Cc: otavio@ossystems.com.br; yi.zhao@windriver.com; Sangal, Apoorv
<apoorv.sangal@intel.com>; Yeoh, Ee Peng <ee.peng.yeoh@intel.com>; Chan,
Aaron Chun Yew <aaron.chun.yew.chan@intel.com>; akuster808@gmail.com;
sjolley.yp.pm@gmail.com; Jain, Sangeeta <sangeeta.jain@intel.com>
Subject: Re: [yocto] QA notification for completed autobuilder build (yocto-
3.2_M3.rc2)

On Thu, 2020-09-24 at 03:22 +0000, Pokybuild User wrote:
A build flagged for QA (yocto-3.2_M3.rc2) was completed on the
autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.2_M3.rc2


Build hash information:

bitbake: 27b53186fa67d281d29b2f8e15bcff8dc2557b8a
meta-arm: c7a1a5f9fd415e3ae1078c2a1d6af9c25e9e6498
meta-gplv2: a8da8eb127a56561bf633ab53bec57fb5dbba537
meta-intel: 254e3a79b3a37045f829848e0a5e04801bec1439
meta-kernel: cb7f0dc5bb1ea0998c8d4fcb486148d4cab575f4
meta-mingw: f1e1d5a803a48ed70f2b0eaf0ef15ade70479fce
oecore: e68df923e1bf9e82662ee2619ac9e2f239e8f7be
poky: 0a243cd21263f498b6eca7c0b168e655dd823e22



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@linuxfoundation.org
There were two failures in this build. One was a single selftest failure which I'll
look into. The other was a qemumips altcfg image loss of networking. I know
Saul is working on better debug for that and we have open bugs for it.

I don't believe either should stop QA.

The 3.1.3 build should also be arriving shortly. Sorry about the 'queue',
everything was finally ready for that release so I thought we should get it built.
We should handle 3.2 M3 first, then 3.1.3.
Thanks for sharing this.
QA has been started for 3.2 M3 RC2. Will star QA for 3.1.3 after this one is complete.

Cheers,

Richard
Thanks,
Sangeeta


Re: QA notification for completed autobuilder build (yocto-3.2_M3.rc2)

Richard Purdie
 

On Thu, 2020-09-24 at 03:22 +0000, Pokybuild User wrote:
A build flagged for QA (yocto-3.2_M3.rc2) was completed on the
autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.2_M3.rc2


Build hash information:

bitbake: 27b53186fa67d281d29b2f8e15bcff8dc2557b8a
meta-arm: c7a1a5f9fd415e3ae1078c2a1d6af9c25e9e6498
meta-gplv2: a8da8eb127a56561bf633ab53bec57fb5dbba537
meta-intel: 254e3a79b3a37045f829848e0a5e04801bec1439
meta-kernel: cb7f0dc5bb1ea0998c8d4fcb486148d4cab575f4
meta-mingw: f1e1d5a803a48ed70f2b0eaf0ef15ade70479fce
oecore: e68df923e1bf9e82662ee2619ac9e2f239e8f7be
poky: 0a243cd21263f498b6eca7c0b168e655dd823e22



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@linuxfoundation.org
There were two failures in this build. One was a single selftest
failure which I'll look into. The other was a qemumips altcfg image
loss of networking. I know Saul is working on better debug for that and
we have open bugs for it.

I don't believe either should stop QA.

The 3.1.3 build should also be arriving shortly. Sorry about the
'queue', everything was finally ready for that release so I thought we
should get it built. We should handle 3.2 M3 first, then 3.1.3.

Cheers,

Richard


Re: [meta-anaconda][PATCH] libgnomekbd: add recipe which was removed from meta-openembedded

kai
 

On 9/24/20 2:44 PM, Chen Qi wrote:
Add this recipe as python3-anaconda recipe still needs it.

Merged. Thanks.

Kai


Signed-off-by: Chen Qi <Qi.Chen@...>
---
 recipes-gnome/libgnome/libgnomekbd_3.26.1.bb | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
 create mode 100644 recipes-gnome/libgnome/libgnomekbd_3.26.1.bb

diff --git a/recipes-gnome/libgnome/libgnomekbd_3.26.1.bb b/recipes-gnome/libgnome/libgnomekbd_3.26.1.bb
new file mode 100644
index 0000000..2a2db9c
--- /dev/null
+++ b/recipes-gnome/libgnome/libgnomekbd_3.26.1.bb
@@ -0,0 +1,14 @@
+SUMMARY = "GNOME keyboard library"
+LICENSE = "LGPLv2"
+LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=6e29c688d912da12b66b73e32b03d812"
+
+SECTION = "x11/gnome/libs"
+
+DEPENDS = "glib-2.0 gtk+3 libxklavier"
+
+inherit features_check gnomebase gobject-introspection gsettings gettext
+
+REQUIRED_DISTRO_FEATURES = "x11"
+
+SRC_URI[archive.md5sum] = "98040022484406e7ebe25f82cef93344"
+SRC_URI[archive.sha256sum] = "f7ca02631576e9b88aee1b1bae37ac1488b80ee7975f20a97f29e761a7172679"




-- 
Kai Kang
Wind River Linux


[meta-anaconda][PATCH] libgnomekbd: add recipe which was removed from meta-openembedded

Chen Qi
 

Add this recipe as python3-anaconda recipe still needs it.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
---
recipes-gnome/libgnome/libgnomekbd_3.26.1.bb | 14 ++++++++++++++
1 file changed, 14 insertions(+)
create mode 100644 recipes-gnome/libgnome/libgnomekbd_3.26.1.bb

diff --git a/recipes-gnome/libgnome/libgnomekbd_3.26.1.bb b/recipes-gnome/libgnome/libgnomekbd_3.26.1.bb
new file mode 100644
index 0000000..2a2db9c
--- /dev/null
+++ b/recipes-gnome/libgnome/libgnomekbd_3.26.1.bb
@@ -0,0 +1,14 @@
+SUMMARY = "GNOME keyboard library"
+LICENSE = "LGPLv2"
+LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=6e29c688d912da12b66b73e32b03d812"
+
+SECTION = "x11/gnome/libs"
+
+DEPENDS = "glib-2.0 gtk+3 libxklavier"
+
+inherit features_check gnomebase gobject-introspection gsettings gettext
+
+REQUIRED_DISTRO_FEATURES = "x11"
+
+SRC_URI[archive.md5sum] = "98040022484406e7ebe25f82cef93344"
+SRC_URI[archive.sha256sum] = "f7ca02631576e9b88aee1b1bae37ac1488b80ee7975f20a97f29e761a7172679"
--
2.17.1


[meta-cgl][PATCH V3] ucarp: fix build error with gcc-10

Chen Qi
 

Add a patch to use __attribute__((packed)) to replace __packed to
avoid multiple definition build error with gcc10.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
---
...attribute__-packed-instead-of-__pack.patch | 30 +++++++++++++++++++
.../recipes-cgl/ucarp/ucarp_1.5.2.bb | 1 +
2 files changed, 31 insertions(+)
create mode 100644 meta-cgl-common/recipes-cgl/ucarp/ucarp/0001-ip_carp.h-use-__attribute__-packed-instead-of-__pack.patch

diff --git a/meta-cgl-common/recipes-cgl/ucarp/ucarp/0001-ip_carp.h-use-__attribute__-packed-instead-of-__pack.patch b/meta-cgl-common/recipes-cgl/ucarp/ucarp/0001-ip_carp.h-use-__attribute__-packed-instead-of-__pack.patch
new file mode 100644
index 0000000..918fa9b
--- /dev/null
+++ b/meta-cgl-common/recipes-cgl/ucarp/ucarp/0001-ip_carp.h-use-__attribute__-packed-instead-of-__pack.patch
@@ -0,0 +1,30 @@
+From a1c83bc4676dbeaff0e1c540aeeb7c31e17aae74 Mon Sep 17 00:00:00 2001
+From: Chen Qi <Qi.Chen@windriver.com>
+Date: Thu, 24 Sep 2020 14:20:58 +0800
+Subject: [PATCH] ip_carp.h: use __attribute__((packed)) instead of __packed
+
+Fix gcc10 build error about multiple definition of __packed.
+
+Upstream-Status: Pending
+
+Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
+---
+ src/ip_carp.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/ip_carp.h b/src/ip_carp.h
+index 9504a8e..d1e3368 100644
+--- a/src/ip_carp.h
++++ b/src/ip_carp.h
+@@ -70,7 +70,7 @@ struct carp_header {
+ u_int16_t carp_cksum;
+ u_int32_t carp_counter[2];
+ unsigned char carp_md[20]; /* SHA1 HMAC */
+-} __packed;
++} __attribute__((packed));
+
+ #define CARP_DFLTTL 255
+
+--
+2.17.1
+
diff --git a/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb b/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb
index d17baa0..62ccd11 100644
--- a/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb
+++ b/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb
@@ -17,6 +17,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=278a886e91f2f6c983ffdf040130cdc6"
SRC_URI = "http://download.pureftpd.org/pub/ucarp/${BPN}-${PV}.tar.gz \
file://ucarp-configure-sha1.patch \
file://ucarp-configure-snprintf.patch \
+ file://0001-ip_carp.h-use-__attribute__-packed-instead-of-__pack.patch \
file://ucarp.init \
file://vip-001.conf.example \
file://vip-common.conf \
--
2.17.1

1241 - 1260 of 52041