Date   

[PATCH] cluster-glue: improve reproducibility

Yu, Mingli
 

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

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

Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
---
.../recipes-cgl/cluster-glue/cluster-glue_1.0.12.bb | 7 +++++++
1 file changed, 7 insertions(+)

diff --git a/meta-cgl-common/recipes-cgl/cluster-glue/cluster-glue_1.0.12.bb b/meta-cgl-common/recipes-cgl/cluster-glue/cluster-glue_1.0.12.bb
index d9df83b..1e4529d 100644
--- a/meta-cgl-common/recipes-cgl/cluster-glue/cluster-glue_1.0.12.bb
+++ b/meta-cgl-common/recipes-cgl/cluster-glue/cluster-glue_1.0.12.bb
@@ -62,6 +62,13 @@ do_install_append() {
install -d ${D}${sysconfdir}/tmpfiles.d
install -m 0644 ${WORKDIR}/tmpfiles ${D}${sysconfdir}/tmpfiles.d/${PN}.conf

+ # remove buildpath
+ tempdirs=$(grep -Rn ${HOSTTOOLS_DIR} ${D}/* | awk -F: '{print $1}' | uniq)
+ for temdir in $tempdirs
+ do
+ sed -i "s:${HOSTTOOLS_DIR}/::g" $temdir
+ done
+
oe_multilib_header heartbeat/glue_config.h
}

--
2.26.2


Re: sd-bus.h not found even with DEPENDS += "systemd"

Bel Hadj Salem Talel
 

HI Again,

The systemd issue is solved by installing the libsystemd in my native host, but I got another problem linking the lib with "ld" :

| /media/talel/data/menzu-zeus/menzu/tmp/work/aarch64-poky-linux/wirepas-sink-tool/1.0-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/../../libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/ld: c-mesh-api/lib/build/mesh_api_lib.a(logger.o): Relocations in generic ELF (EM: 62)
| /media/talel/data/menzu-zeus/menzu/tmp/work/aarch64-poky-linux/wirepas-sink-tool/1.0-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/../../libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/ld: c-mesh-api/lib/build/mesh_api_lib.a(logger.o): Relocations in generic ELF (EM: 62)
| /media/talel/data/menzu-zeus/menzu/tmp/work/aarch64-poky-linux/wirepas-sink-tool/1.0-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/../../libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/ld: c-mesh-api/lib/build/mesh_api_lib.a: error adding symbols: file in wrong format
| collect2: error: ld returned 1 exit status
| makefile:102: recipe for target 'build/sinkService' failed

Here is the Makefile:

---------------------------

# Makefile for Wirepas Dbus Sink module

# Toolchain
CC  ?= gcc
AS  ?= as
LD  ?= ld
AR  ?= ar

# Paths, including trailing path separator
SOURCEPREFIX   := source/
BUILDPREFIX    := build/

# This example needs the mesh lib
MESH_LIB_FOLDER := c-mesh-api/lib/
MESH_LIB := $(MESH_LIB_FOLDER)build/mesh_api_lib.a

# General compiler flags
CFLAGS  := -std=gnu99 -Wall -Werror -O

# Targets definition
MAIN_APP := sinkService

TARGET_APP := $(BUILDPREFIX)$(MAIN_APP)

# Add Api header (including logger files)
CFLAGS  += -I$(MESH_LIB_FOLDER)api
# Add pthtread lib as needed by Mesh Lib
LDFLAGS += -pthread
# Add Reentrant flag as using pthread
CFLAGS  += -D_REENTRANT

# Add systemd lib as needed for sd-bus
LDFLAGS += -lsystemd

# Add current directory for headers
CFLAGS  += -I$(SOURCEPREFIX)

# Specific sources for this application
SOURCES := $(SOURCEPREFIX)main.c
SOURCES += $(SOURCEPREFIX)config.c
SOURCES += $(SOURCEPREFIX)data.c
SOURCES += $(SOURCEPREFIX)otap.c

OBJECTS := $(patsubst $(SOURCEPREFIX)%,                     \
                  $(BUILDPREFIX)%,                          \
                  $(SOURCES:.c=.o))

# Functions

# Also create the target directory if it does not exist
define COMPILE
    echo "  CC $(2)"
    mkdir -p $(dir $(1))
    $(CC) $(CFLAGS) -c -o $(1) $(2)
endef

define LINK
    echo "  Linking $(1)"
    $(CC) $(CFLAGS) -o $(1) $(2) $(MESH_LIB) $(LDFLAGS)
endef

define CLEAN
    echo "  Cleaning up"
    $(RM) -r $(BUILDPREFIX)
    make -C $(MESH_LIB_FOLDER) clean
endef

# Target rules

# Use dependency files automatically generated by GCC.
# First collect all C source files
AUTODEPS := $(patsubst $(SOURCEPREFIX)%.c, $(BUILDPREFIX)%.d, $(SOURCES))

ifeq ($(V),1)
# "V=1" on command line, print commands.
else
# Default, do not print commands.
.SILENT:
endif

.PHONY: all
all: app

app: $(TARGET_APP)

.PHONY: clean
clean:
    $(call CLEAN)

$(MESH_LIB_FOLDER):
    $(error Please add the c-mesh-api library under c-mesh-api folder.\
            It is needed to handle dualmcu protocol)

.PHONY: $(MESH_LIB)
$(MESH_LIB): $(MESH_LIB_FOLDER)
    make -C $(MESH_LIB_FOLDER)

$(BUILDPREFIX)%.o: $(SOURCEPREFIX)%.c
    $(call COMPILE,$@,$<)

$(BUILDPREFIX)$(MAIN_APP): $(OBJECTS) $(MESH_LIB)
    $(call LINK,$@,$^)

---------------------------

What is wrong ?

Thanks ,Talel


sd-bus.h not found even with DEPENDS += "systemd"

Bel Hadj Salem Talel
 

Hi Community,

I'm trying to make a recipe for source files with a Makefile , files are under : https://github.com/wirepas/gateway/tree/master/sink_service

I can't add the recipe directly from the URL, so I cloned the repo and zipped only the sink_service file.

When I added the zip file with devtool it added DEPEND = "systemd" in the recipe file. But when compiling :
fatal error: systemd/sd-bus.h: No such file or directory
The Makefile just needs "make" and it worked on my native host. Here is the recipe:
LICENSE = "Unknown"
LIC_FILES_CHKSUM = "file://c-mesh-api/LICENSE;md5=b8b4f77337154d1f64ebe68dcd93fab6"
SRC_URI = "file:///media/talel/data/multigate/multigate/meta-wirepas/recipes-wirepas/wirepas-sink-tool/files/sink_service.zip"
DEPENDS = "systemd"
do_configure () {
# Specify any needed configure commands here
:
}

do_compile () {
# You will almost certainly need to add additional arguments here
oe_runmake
}

do_install () {
# NOTE: unable to determine what to put here - there is a Makefile but no
# target named "install", so you will need to define this yourself
:
}

The only problem is in do_compile , I need to fix it and then I can manage the install part.
How can I specify the libsystemd in BUILD time , do I need EXTRA_OEMAKE ?

Thanks, Talel



Re: setup.py no such file or directory

Bel Hadj Salem Talel
 

Hi Again,
I solved the issue,
The problem was that when yocto unpacks the source files it unpacks it not in tmp/work/.../python3-wirepas-messaging/python3-wirepas-messaging-1.0 which is the work directory, so that is why setuptools cannot find setup.py ,
So I modified the source files folder to the same recipes name with ${PV} so it can match the same recipe's workdir. And now files are extracted in the good location and get compiled correctly.
devtool uses externalsrc to locate the source files directly, that is why it finds setup.py.
Thanks for the support again, Talel


Re: setup.py no such file or directory

Bel Hadj Salem Talel
 

Hi again,
When I add the recipe with devtool and I disable the .bbappend that adds externalsrc the same error appears.
Should I add it to final recipe as well ?
Can anyone explain this for me ?
Thanks.


Re: [OE-core] [PATCH] pseudo: do not expand symlinks in /proc

Richard Purdie
 

On Fri, 2020-09-25 at 14:47 -0400, Randy MacLeod wrote:
pseduo patches are usually sent to the yocto list so
I've added that list and only BCCed oe-core here so
people know where to look for follow-up.
In Sakib's defence, did you read the README in pseudo? :)

"Discussions and patches should be directed at the openembedded-core
mailing list at openembedded-core at lists.openembedded.org."

Whether that is right or not, less sure but it is what it says!

Cheers,

Richard


Re: setup.py no such file or directory

Bel Hadj Salem Talel
 

HI,

I'm trying to make a recipe for wirepas-gateway and wirepas-messaging, let's take wirepas-messaging for an example , it is so easy :
I'm downloading the https://github.com/wirepas/backend-apis/tree/master/wrappers/python , because https://github.com/wirepas/backend-apis does not contain the wirepas-messaging package sources directly .
So I'm zipping the sources of https://github.com/wirepas/backend-apis/tree/master/wrappers/python and adding it with devtool
After that when I build the recipe it build successfully after fixing the do_package with adding FILES_${PN} = "/usr/share/*"
So I checked the tmp/work/.../image and the package is correctly installed into the image destination.
Now when I do devtool finish , it copy paste the same recipe .bb file with the same SRC_URI, now when I try to build it I get the error of :
/media/talel/data/menzu-zeus/menzu/tmp/work/aarch64-poky-linux/python3-wirepas-messaging/1.0-r0/recipe-sysroot-native/usr/bin/python3-native/python3: can't open file 'setup.py': [Errno 2] No such file or directory

The same SRC_URI:
SRC_URI = "file:///home/talel/Desktop/backend-apis/wrappers/python/wirepas-messaging.zip"
What is the differnece ? I can't understand.

Thanks, Talel


On Fri, Sep 25, 2020 at 5:00 PM Quentin Schulz <quentin.schulz@...> wrote:
On Fri, Sep 25, 2020 at 08:12:11AM -0700, Bel Hadj Salem Talel wrote:
> Hi Community,
>
> I have a python module which I downloaded from github containing a setup.py as all python modules.
> When I create a recipe with devtool it compiles correctly with no problem, but when I copy paste the same recipe source from workspace recipes to an official meta recipe I got this error :
> >
> >
> > /media/talel/data/menzu-zeus/menzu/tmp/work/aarch64-poky-linux/python3-wirepas_messaging/1.4.0-r0/recipe-sysroot-native/usr/bin/python3-native/python3:
> > can't open file 'setup.py': [Errno 2] No such file or directory
>
> Here is the recipe by devtool:
>
> ##############
>
> 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:///media/talel/data/multigate/multigate/meta-wirepas/recipes-wirepas/wirepas-gateway/files/wirepas_gateway-${PV}/wp-gateway.zip"

If your recipe is in:
/media/talel/data/multigate/multigate/meta-wirepas/recipes-wirepas/wirepas-gateway/
and wp-gateway.zip is in:
/media/talel/data/multigate/multigate/meta-wirepas/recipes-wirepas/wirepas-gateway/files/wirepas_gateway-1.4.0
just put:
SRC_URI = "file://wirepas_gateway-${PN}/wp-gateway.zip"

I'd suggest putting your .zip file in:
/media/talel/data/multigate/multigate/meta-wirepas/recipes-wirepas/wirepas-gateway/wirepas_gateway-1.4.0
(note the missing files directory), in which case, your SRC_URI would
be:
SRC_URI = "file://wp-gateway.zip"

Also... This looks like you're taking code from
https://github.com/wirepas/gateway ? Have you thought of using the git
repo directly? e.g. devtool add python3-wirepas-gateway
https://github.com/wirepas/gateway.git?

It'll use the latest commit in master but it's changeable, and it is way
more maintainable IMO compared to a tarball you manually download every
now and then.

Please do NOT use _ in your recipe filename, so rename your recipe to
python3-wirepas-messaging.

Please answer to all when you're answering back to me or anyone in this
community, so people could benefit from the solution or discussion
around the issue,
Quentin


Re: [OE-core] [PATCH] pseudo: do not expand symlinks in /proc

Randy MacLeod
 

pseduo patches are usually sent to the yocto list so
I've added that list and only BCCed oe-core here so
people know where to look for follow-up.


On 2020-09-25 1:05 p.m., Sakib Sajal wrote:
From: Matt Cowell <matt.cowell@...>

Some symlinks in /proc, such as those under /proc/[pid]/fd,
/proc/[pid]/cwd, and /proc/[pid]/exe that are not real and should not
have readlink called on them.  These look like symlinks, but behave like
hardlinks.  Readlink does not return actual paths.  Previously
pseudo_fix_path would expand files such as /dev/stdin to paths such as
/proc/6680/fd/pipe:[1270830076] which do not exist.

This issue affects:
- deleted files
- deleted directories
- fifos
- sockets
- anon_inodes (epoll, eventfd, inotify, signalfd, timerfd, etc)

Testing:
timed builds before and after applying patch, without significant
measurable difference.
$ bitbake -c compile <image>; time bitbake <image>

installed pseudo on an image and was unable to reproduce the test
on bug report after applying the patch.

There might be a better test so please let Sakib know if so.

Sakib,
  If there's a v2 or in future work, please give the actual results
such as:

  5 trials with an average time of 18m:14s and a range of 22 seconds
  on a build host that no one else was using.

This will help people to understand what you mean by
   "without significant measurable difference.

Thanks for testing and sending this change.

../Randy


FIXES: Bug 13288

Signed-off-by: Sakib Sajal <sakib.sajal@...>
---
 pseudo_util.c | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/pseudo_util.c b/pseudo_util.c
index c867ed6..bce4d1e 100644
--- a/pseudo_util.c
+++ b/pseudo_util.c
@@ -21,6 +21,8 @@
 #include <sys/time.h>
 #include <unistd.h>
 #include <limits.h>
+#include <sys/vfs.h>
+#include <linux/magic.h>
 
 /* see the comments below about (*real_regcomp)() */
 #include <dlfcn.h>
@@ -29,6 +31,11 @@
 #include "pseudo_ipc.h"
 #include "pseudo_db.h"
 
+/* O_PATH is defined in glibc 2.16 and later only */
+#ifndef O_PATH
+#define O_PATH          010000000
+#endif
+
 struct pseudo_variables {
 	char *key;
 	size_t key_len;
@@ -677,6 +684,26 @@ pseudo_append_element(char *newpath, char *root, size_t allocated, char **pcurre
 	 */
 	if (!leave_this && is_dir) {
 		int is_link = S_ISLNK(buf->st_mode);
+
+		/* do not expand symlinks in the proc filesystem, since they may not be real */
+		if (is_link) {
+			struct statfs sfs;
+			int fd;
+
+			/* statfs follows symlinks, so use fstatfs */
+			fd = open(newpath, O_CLOEXEC | O_PATH | O_NOFOLLOW);
+			if (-1 != fd) {
+				if (0 == fstatfs(fd, &sfs) && sfs.f_type == PROC_SUPER_MAGIC) {
+					pseudo_debug(PDBGF_PATH | PDBGF_VERBOSE,
+						"pae: '%s' is procfs symlink, not expanding\n",
+						newpath);
+					is_link = 0;
+				}
+
+				close(fd);
+			}
+		}
+
 		if (link_recursion >= PSEUDO_MAX_LINK_RECURSION && is_link) {
 			pseudo_diag("link recursion too deep, not expanding path '%s'.\n", newpath);
 			is_link = 0;




-- 
# Randy MacLeod
# Wind River Linux


Re: setup.py no such file or directory

Quentin Schulz
 

On Fri, Sep 25, 2020 at 08:12:11AM -0700, Bel Hadj Salem Talel wrote:
Hi Community,

I have a python module which I downloaded from github containing a setup.py as all python modules.
When I create a recipe with devtool it compiles correctly with no problem, but when I copy paste the same recipe source from workspace recipes to an official meta recipe I got this error :


/media/talel/data/menzu-zeus/menzu/tmp/work/aarch64-poky-linux/python3-wirepas_messaging/1.4.0-r0/recipe-sysroot-native/usr/bin/python3-native/python3:
can't open file 'setup.py': [Errno 2] No such file or directory
Here is the recipe by devtool:

##############

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:///media/talel/data/multigate/multigate/meta-wirepas/recipes-wirepas/wirepas-gateway/files/wirepas_gateway-${PV}/wp-gateway.zip"
If your recipe is in:
/media/talel/data/multigate/multigate/meta-wirepas/recipes-wirepas/wirepas-gateway/
and wp-gateway.zip is in:
/media/talel/data/multigate/multigate/meta-wirepas/recipes-wirepas/wirepas-gateway/files/wirepas_gateway-1.4.0
just put:
SRC_URI = "file://wirepas_gateway-${PN}/wp-gateway.zip"

I'd suggest putting your .zip file in:
/media/talel/data/multigate/multigate/meta-wirepas/recipes-wirepas/wirepas-gateway/wirepas_gateway-1.4.0
(note the missing files directory), in which case, your SRC_URI would
be:
SRC_URI = "file://wp-gateway.zip"

Also... This looks like you're taking code from
https://github.com/wirepas/gateway ? Have you thought of using the git
repo directly? e.g. devtool add python3-wirepas-gateway
https://github.com/wirepas/gateway.git?

It'll use the latest commit in master but it's changeable, and it is way
more maintainable IMO compared to a tarball you manually download every
now and then.

Please do NOT use _ in your recipe filename, so rename your recipe to
python3-wirepas-messaging.

Please answer to all when you're answering back to me or anyone in this
community, so people could benefit from the solution or discussion
around the issue,
Quentin


Re: SIGINT Issues with Zeus Migration

Leon Woestenberg
 

Hello Aashik,

I recognize the issue that CTRL-C does not pass from the console, but only with *very* minimal configurations.

How does your local.conf look like, or better yet how can we reproduce your case?

Regards, Leon

On Fri, 25 Sep 2020 at 12:46, Aashik Aswin <thisisaash9698@...> wrote:
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.




--
-- 
Leon Woestenberg
leon@...
T: +31 40 711 42 76
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com


Re: setup.py no such file or directory

Quentin Schulz
 

Hi Talel,

On Fri, Sep 25, 2020 at 08:12:11AM -0700, Bel Hadj Salem Talel wrote:
Hi Community,

I have a python module which I downloaded from github containing a setup.py as all python modules.
When I create a recipe with devtool it compiles correctly with no problem, but when I copy paste the same recipe source from workspace recipes to an official meta recipe I got this error :


/media/talel/data/menzu-zeus/menzu/tmp/work/aarch64-poky-linux/python3-wirepas_messaging/1.4.0-r0/recipe-sysroot-native/usr/bin/python3-native/python3:
can't open file 'setup.py': [Errno 2] No such file or directory
Use devtool finish when you're done with a recipe you started with
devtool add, that should do it.

Quentin


setup.py no such file or directory

Bel Hadj Salem Talel
 

Hi Community,

I have a python module which I downloaded from github containing a setup.py as all python modules.
When I create a recipe with devtool it compiles correctly with no problem, but when I copy paste the same recipe source from workspace recipes to an official meta recipe I got this error :
/media/talel/data/menzu-zeus/menzu/tmp/work/aarch64-poky-linux/python3-wirepas_messaging/1.4.0-r0/recipe-sysroot-native/usr/bin/python3-native/python3: can't open file 'setup.py': [Errno 2] No such file or directory
Here is the recipe by devtool:

##############

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:///media/talel/data/multigate/multigate/meta-wirepas/recipes-wirepas/wirepas-gateway/files/wirepas_gateway-${PV}/wp-gateway.zip"
inherit setuptools3
RDEPENDS_${PN} += "python3-pyyaml python3-grpcio python3-paho-mqtt python3-pydbus"
RDEPENDS_${PN} += "python3-core python3-datetime python3-io python3-json python3-logging python3-netclient python3-paho-mqtt python3-pydbus python3-pygobject python3-pyyaml python3-threading"
DEPENDS += "systemd"

##############

I copy paste the same recipe source to a recipe under meta-wirepas/recipes-wirepas of mine, and copied the SRC_URI = "file:///media/talel/data/multigate/multigate/meta-wirepas/recipes-wirepas/wirepas-gateway/files/wirepas_gateway-${PV}/wp-gateway.zip" zip file under "files", and I got the error.

I don't know what is the difference, I think devtool created the recipe with .bbappend containing :

inherit externalsrc
EXTERNALSRC = "/media/talel/data/menzu-zeus/menzu/workspace/sources/wirepas-gateway"
EXTERNALSRC_BUILD = "/media/talel/data/menzu-zeus/menzu/workspace/sources/wirepas-gateway"

######

Is it the source of the problem, or how can I fix the issue ?

Thanks, Talel




Build and integration engineer for Yocto Project

Nicolas Dechesne
 

hi there,

The The Yocto Project is looking to hire a build and integration
engineer to join our developers community and assist the Yocto Project
Architect in a wide array of tasks. We expect to build a long term
relationship with an engineer, and estimate that the workload for a
senior engineer should be no more than 50%.

To learn more about this RFQ, please check this:
https://www.yoctoproject.org/yocto-project-build-integration-engineer-request-for-quote/

Any questions, feel free to contact me.

cheers
nico


QA notification for completed autobuilder build (yocto-3.1.3.rc1)

Richard Purdie
 

[the original email bounced for some reason, resending to the list]

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


https://autobuilder.yocto.io/pub/releases/yocto-3.1.3.rc1


Build hash information:

bitbake: 18e1957337fd9f06bc673d28dd4f8277321d07bc
meta-arm: c7a1a5f9fd415e3ae1078c2a1d6af9c25e9e6498
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: d7134e86574172784f90117c03a012e0048d8bcb
meta-kernel: cb7f0dc5bb1ea0998c8d4fcb486148d4cab575f4
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
oecore: b39bda4cc62db12c0edfbe489d5a7f5988ede6a9
poky: 012ad10a89a889c21e67c27dc37d22520212548f



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


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

1261 - 1280 of 52075