|
sd-bus.h not found when compiling
#yocto
Bel Hadj Salem Talel <bhstalel@...>
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@...> wrote: Aashik, how are you sending the signal? Using CTRL-C or using the...that I am not able to send SIGINT to commands such as Ping, tail etc.\ "kill" command? That reads to use sigaction() instead of signal() I would assume. Then execute the following code (ad-hoc from the top of my head):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@...> wrote:
|
|
|
|
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:Much to my surprise, I figured out the issue and there is a patch forA build flagged for QA (yocto-3.2_M3.rc2) was completed on theThere were two failures in this build. One was a single selftest 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,
toggle quoted messageShow quoted text
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-----
|
|
|
|
Re: [meta-cgl][PATCH] pacemaker: Fix build with -fno-common
Yu, Mingli
Ping.
toggle quoted messageShow quoted text
Thanks,
On 9/3/20 1:59 PM, Yu, Mingli wrote:
From: Mingli Yu <mingli.yu@...>
|
|
|
|
[meta-cgl][PATCH] pacemaker: improve reproducibility
Yu, Mingli
From: Mingli Yu <mingli.yu@...>
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@...> --- .../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
toggle quoted messageShow quoted text
-----Original Message-----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. 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 theThere 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@...> --- 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@...> --- ...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@...> +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@...> +--- + 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
|
|
|
|
Re: [meta-cgl][PATCH V2] ucarp: fix build error with gcc-10
Chen Qi
On 09/24/2020 02:13 PM, Khem Raj wrote:
On Wed, Sep 23, 2020 at 11:08 PM ChenQi <Qi.Chen@...> wrote:Thanks for this info.On 09/24/2020 01:43 PM, Khem Raj wrote:certain compilers do allow __packed keyword and it might beOn Wed, Sep 23, 2020 at 8:38 PM Chen Qi <Qi.Chen@...> wrote:It's possible, but I didn't look at the logic and I don't want to.Add a patch to remove the useless '__packed' variable to avoidI wonder if the intention is to mark this structure as packed struct I'll send out V3 to use '__attribute__((packed))__'. Best Regards, Chen Qi Unfortunately, the codes are really old, and I cannot find a place to
|
|
|
|
Re: [meta-cgl][PATCH V2] ucarp: fix build error with gcc-10
Chen Qi
On 09/24/2020 02:14 PM, Chen Qi wrote:
On 09/24/2020 01:43 PM, Khem Raj wrote: Forgot to mention, I also tested with '__attribute__((packed))', the build succeeded. Adrian, Alexandru and Joe, I'll send out V3 with this change. You can choose V2 or V3 as you like. Regards, Chen Qi It's possible, but I didn't look at the logic and I don't want to. Anyway, the variable never had any effect. So I figure it's safe to remove it, and this will not change any behavior.
|
|
|
|
Re: [meta-cgl][PATCH V2] ucarp: fix build error with gcc-10
On Wed, Sep 23, 2020 at 11:08 PM ChenQi <Qi.Chen@...> wrote:
certain compilers do allow __packed keyword and it might be intentional too. If its removed then the bug will become even more subtler, therefore. if we want to change the code then its perhaps better to confirm it with upstream before applying patch. Otherwise apply usual -fcommon workaround. Unfortunately, the codes are really old, and I cannot find a place to
|
|
|
|
Re: [meta-cgl][PATCH V2] ucarp: fix build error with gcc-10
Chen Qi
On 09/24/2020 01:43 PM, Khem Raj wrote:
On Wed, Sep 23, 2020 at 8:38 PM Chen Qi <Qi.Chen@...> wrote:It's possible, but I didn't look at the logic and I don't want to. Anyway, the variable never had any effect. So I figure it's safe to remove it, and this will not change any behavior.Add a patch to remove the useless '__packed' variable to avoidI wonder if the intention is to mark this structure as packed struct Unfortunately, the codes are really old, and I cannot find a place to send the patch, not to mention to confirm this with its author :( Regards, Chen Qi Signed-off-by: Chen Qi <Qi.Chen@...>
|
|
|
|
Re: [meta-cgl][PATCH V2] ucarp: fix build error with gcc-10
On Wed, Sep 23, 2020 at 8:38 PM Chen Qi <Qi.Chen@...> wrote:
I wonder if the intention is to mark this structure as packed struct then it should be replaced with __attribute__((packed)) Signed-off-by: Chen Qi <Qi.Chen@...>
|
|
|