Date   

[meta-security][PATCH 2/2] packagegroup-core-security: add softHSM

akuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-core/packagegroup/packagegroup-core-security.bb | 1 +
1 file changed, 1 insertion(+)

diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb b/recipes-core/packagegroup/packagegroup-core-security.bb
index 1d01800..4d98631 100644
--- a/recipes-core/packagegroup/packagegroup-core-security.bb
+++ b/recipes-core/packagegroup/packagegroup-core-security.bb
@@ -36,6 +36,7 @@ RDEPENDS_packagegroup-security-utils = "\
python3-privacyidea \
python3-fail2ban \
python3-scapy \
+ softhsm \
${@bb.utils.contains_any("TUNE_FEATURES", "riscv32 ", "", " libseccomp",d)} \
${@bb.utils.contains("DISTRO_FEATURES", "pam", "sssd google-authenticator-libpam", "",d)} \
${@bb.utils.contains("DISTRO_FEATURES", "pax", "pax-utils packctl", "",d)} \
--
2.17.1


[meta-security][PATCH 1/2] softHSM: add pkg

akuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-security/softHSM/softhsm_2.6.1.bb | 30 +++++++++++++++++++++++
1 file changed, 30 insertions(+)
create mode 100644 recipes-security/softHSM/softhsm_2.6.1.bb

diff --git a/recipes-security/softHSM/softhsm_2.6.1.bb b/recipes-security/softHSM/softhsm_2.6.1.bb
new file mode 100644
index 0000000..74e837a
--- /dev/null
+++ b/recipes-security/softHSM/softhsm_2.6.1.bb
@@ -0,0 +1,30 @@
+SUMMARY = "SoftHSM is an implementation of a cryptographic store accessible through a PKCS #11 interface."
+HOMEPAGE = "www.opendnssec.org"
+
+LICENSE = "BSD"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=ef3f77a3507c3d91e75b9f2bdaee4210"
+
+DEPENDS = "sqlite3"
+
+SRC_URI = "https://dist.opendnssec.org/source/softhsm-2.6.1.tar.gz";
+SRC_URI[sha256sum] = "61249473054bcd1811519ef9a989a880a7bdcc36d317c9c25457fc614df475f2"
+
+inherit autotools pkgconfig siteinfo
+
+EXTRA_OECONF += " --with-sqlite3=${STAGING_DIR_HOST}/usr"
+EXTRA_OECONF += "${@oe.utils.conditional('SITEINFO_BITS', '64', ' --enable-64bit', '', d)}"
+
+PACKAGECONFIG ?= "pk11 openssl"
+
+PACKAGECONFIG[npm] = ",--disable-non-paged-memory"
+PACKAGECONFIG[ecc] = "--enable-ecc,--disable-ecc"
+PACKAGECONFIG[gost] = "--enable-gost,--disable-gost"
+PACKAGECONFIG[eddsa] = "--enable-eddsa, --disable-eddsa"
+PACKAGECONFIG[fips] = "--enable-fips, --disable-fips"
+PACKAGECONFIG[notvisable] = "--disable-visibility"
+PACKAGECONFIG[openssl] = "--with-openssl=${STAGING_DIR_HOST}/usr --with-crypto-backend=openssl, --without-openssl, openssl, openssl"
+PACKAGECONFIG[botan] = "--with-botan=${STAGING_DIR_HOST}/usr --with-crypto-backend=botan, --without-botan, botan"
+PACKAGECONFIG[migrate] = "--with-migrate"
+PACKAGECONFIG[pk11] = "--enable-p11-kit --with-p11-kit==${STAGING_DIR_HOST}/usr, --without-p11-kit, p11-kit, p11-kit"
+
+RDEPENDS_${PN} = "sqlite3"
--
2.17.1


poky-dunfell-23.0.2: WARNING: Your host glibc verson (2.32) is newer than that in uninative (2.31). Disabling uninative so that sstate is not corrupted.

Robert
 

Hello list,

The warning in the subject has turned into an error.

I'm building a Yocto project based on poky-dunfell-23.0.2

I get this error:
ERROR: dpkg-native-1.19.7-r0 do_compile: oe_runmake failed

| ../../../dpkg-1.19.7/lib/compat/strsignal.c: In function ‘test_strsignal’:
| ../../../dpkg-1.19.7/lib/compat/strsignal.c:71:10: error: ‘sys_siglist’ undeclared (first use in this function)
|    71 |   return sys_siglist[s];

I found the reason for this error:
Release notes of glibc 2.32:
https://sourceware.org/pipermail/libc-announce/2020/000029.html

* The deprecated arrays sys_siglist, _sys_siglist, and sys_sigabbrev
  are no longer available to newly linked binaries, and their declarations
  have been removed from <string.h>.  They are exported solely as
  compatibility symbols to support old binaries.  All programs should use
  strsignal instead.


To solve it I could downgrade the glibc library version of my system (general consensus on forums is that, that is a bad idea).
Other option:
In the master branch I find a recipe for dpkg 1.20.5, can I simply upgrade the dpkg version (1.19.7) in the dunfell release with the master branch version (1.20.5)?
Could it break anything and how do I know it will solve my problem? Other then try it.
Or is there another solution?

uname -rmo
Linux 5.4.64-1-MANJARO  x86_64 GNU/Linux

Thanks,
Robert.


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

Bel Hadj Salem Talel
 

Hi,

A response came only to me :

Hey Bel,
 
Please remove the libsystemd from your host. It will cause host contamination.
 
You need to tell in your makefile where make can find include path and lib path
 
Normally it should work
 
Include: -I${STAging_incdir}
-L for ld path
 
 
Cheers
So I added

EXTRA_OEMAKE += "-I${STAGING_INCDIR}
to fix the systemd include error.

But I still get the error of :

 /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

I don't know what is the problem.
Help me on this please.

Thanks for your support.



Re: #yocto systemd not able to start sshd after a reboot #yocto

Zoran
 

Maybe this should be added to sshd.service [unit] part
(to have added dependency) to solve this problem:

> The sshd.service file is as follows:
> [Unit]
> Description=OpenSSH server daemon
> Documentation=man:sshd(8) man:sshd_config(5)
> After=sshdgenkeys.service
> Wants=sshdgenkeys.service
Requires=sshd.socket

Zoran
_______

On Fri, Sep 18, 2020 at 5:29 PM <srijan.nandi@...> wrote:
>
> I am facing a peculiar problem with openssh. I have built openssh_8.0p1on zeus.
>
> The sshd.service file is as follows:
> [Unit]
> Description=OpenSSH server daemon
> Documentation=man:sshd(8) man:sshd_config(5)
> After=sshdgenkeys.service
> Wants=sshdgenkeys.service
>  
> [Service]
> Type=simple
> PIDFile=/var/run/sshd.pid
> EnvironmentFile=-/etc/default/sshd
> ExecStart=/usr/sbin/sshd -D $OPTIONS
> ExecReload=/bin/kill -HUP $MAINPID
> ExecStop=/bin/kill $MAINPID
> PermissionsStartOnly=true
> KillMode=process
> Restart=on-failure
> StandardError=syslog
>  
> [Install]
> WantedBy=multi-user.target
>
> It starts without issues, if i do a systemctl start sshd.service. If I do a test of the config file it does not come up with any errors:
>
> genericx86-64:~$ sudo /usr/sbin/sshd -t
> genericx86-64:~$
>
> Problem:
> If I reboot the server, sshd does not start. There is no error on syslog. I have enabled debug logging, still no logs in syslog.
>
> # Logging
> SyslogFacility DAEMON
> LogLevel DEBUG3
>
> Even systemctl is-enabled sshd shows as enabled.
>
> After a reboot, if I do a systemctl status sshd it shows:
> Loaded: loaded  (/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
> Active: inactive (dead)
>
> If I manually run systemctl start sshd.service, everything works perfectly well without issues. sshd start on 0.0.0.0:2224 and I am able to ssh in as well.
>
> It's just that systemctl is not able to start sshd after a reboot and there is no error that i can find or debug. Absolutely run out of ideas to resolve this. Any help will be greatly appreciated.
>
> Thanks and Regards,
> -=Srijan Nandi
>
>
>


[meta-cgl][ 2/3] ocfs2-tools: remove lsbinitscripts from RDEPENDS

kai
 

From: Robert Yang <liezhi.yang@windriver.com>

The LSB support had been removed from oe-core by:

https://git.openembedded.org/openembedded-core/commit/?id=fb06435

And it works well to start o2cb/ocfs2 services without lsbinitscripts.
So drop LSB support for ocfs2-tools too.

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Kai Kang <kai.kang@windriver.com>
---
...move-unneeded-lib-lsb-init-functions.patch | 32 +++++++++++++++++++
.../ocfs2-tools/ocfs2-tools_1.8.6.bb | 5 +--
2 files changed, 35 insertions(+), 2 deletions(-)
create mode 100644 meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/0001-o2cb.init.sh-Remove-unneeded-lib-lsb-init-functions.patch

diff --git a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/0001-o2cb.init.sh-Remove-unneeded-lib-lsb-init-functions.patch b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/0001-o2cb.init.sh-Remove-unneeded-lib-lsb-init-functions.patch
new file mode 100644
index 0000000..5609b4b
--- /dev/null
+++ b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/0001-o2cb.init.sh-Remove-unneeded-lib-lsb-init-functions.patch
@@ -0,0 +1,32 @@
+From b7913a62e2d78fa98ae2c475de4cc697519181e2 Mon Sep 17 00:00:00 2001
+From: Robert Yang <liezhi.yang@windriver.com>
+Date: Tue, 10 Sep 2019 19:29:16 -0700
+Subject: [PATCH] o2cb.init.sh: Remove unneeded /lib/lsb/init-functions
+
+The "systemctl start o2cb/ocfs2" works well when systemd (no
+/etc/init.d/functions, either), so remove the unneeded line.
+
+Upstream-Status: Pending
+
+Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
+---
+ vendor/common/o2cb.init.sh | 3 ---
+ 1 file changed, 3 deletions(-)
+
+diff --git a/vendor/common/o2cb.init.sh b/vendor/common/o2cb.init.sh
+index 8b0dbf09..49eb9a4c 100755
+--- a/vendor/common/o2cb.init.sh
++++ b/vendor/common/o2cb.init.sh
+@@ -25,9 +25,6 @@ then
+ start_daemon () {
+ daemon $*
+ }
+-else
+-# Let's try to use the LSB functions
+-. /lib/lsb/init-functions
+ fi
+
+ if [ $? != 0 ]
+--
+2.21.0
+
diff --git a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.6.bb b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.6.bb
index bc0551b..81e6c2e 100644
--- a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.6.bb
+++ b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.6.bb
@@ -19,6 +19,7 @@ SRC_URI = "git://github.com/markfasheh/ocfs2-tools \
file://o2cb.service \
file://ocfs2.service \
file://0001-Fix-build-with-glibc-2.28.patch \
+ file://0001-o2cb.init.sh-Remove-unneeded-lib-lsb-init-functions.patch \
"
SRCREV = "4d76ceb4aa7aaa1fd595368089e99575d708f719"
S = "${WORKDIR}/git"
@@ -30,11 +31,11 @@ DEPENDS = "corosync pacemaker \
e2fsprogs e2fsprogs-native \
"

+
# lsbinitscripts are needed to replace /etc/init.d/functions supplied by initscripts (systemv)
# They are not the same code!
#
-RDEPENDS_${PN} = "bash coreutils net-tools module-init-tools e2fsprogs glib-2.0 \
- ${@bb.utils.contains('DISTRO_FEATURES','systemd','lsbinitscripts','',d)}"
+RDEPENDS_${PN} = "bash coreutils net-tools module-init-tools e2fsprogs glib-2.0"

ASNEEDED_pn-${PN} = ""
PARALLEL_MAKE = ""
--
2.17.1


[meta-cgl][ 3/3] ucarp: add initscripts-functions as runtime dependency when using systemd

kai
 

From: Yi Zhao <yi.zhao@windriver.com>

The ucarp.service invokes script /usr/libexec/ucarp to start/stop the
ucarp service. But the /etc/init.d/functions file which is required by
the script is not installed by default when using systemd. Explicitly
set the initscripts-functions package as the runtime dependency when
using systemd.

Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Kai Kang <kai.kang@windriver.com>
---
meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb | 1 +
1 file changed, 1 insertion(+)

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..5ba236d 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
@@ -31,6 +31,7 @@ SRC_URI[sha256sum] = "f3cc77e28481fd04f62bb3d4bc03104a97dd316c80c0ed04ad7be24b54
inherit autotools gettext systemd

DEPENDS = "libpcap"
+RDEPENDS_${PN} = "${@bb.utils.contains('DISTRO_FEATURES','systemd','initscripts-functions','',d)}"

SYSTEMD_SERVICE_${PN} = "ucarp.service"
SYSTEMD_AUTO_ENABLE = "disable"
--
2.17.1


[meta-cgl][ 1/3] kernel: Remove non-existing kernel option

kai
 

From: He Zhe <zhe.he@windriver.com>

CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE has been removed from mainline kernel
by commit be6ec88f41ba ("selinux: Remove SECURITY_SELINUX_BOOTPARAM_VALUE").

Ref:
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?id=be6ec88

Signed-off-by: He Zhe <zhe.he@windriver.com>
Signed-off-by: Kai Kang <kai.kang@windriver.com>
---
meta-cgl-common/recipes-kernel/linux/files/cfg/00014-selinux.cfg | 1 -
1 file changed, 1 deletion(-)

diff --git a/meta-cgl-common/recipes-kernel/linux/files/cfg/00014-selinux.cfg b/meta-cgl-common/recipes-kernel/linux/files/cfg/00014-selinux.cfg
index 1efd63e..b10b839 100644
--- a/meta-cgl-common/recipes-kernel/linux/files/cfg/00014-selinux.cfg
+++ b/meta-cgl-common/recipes-kernel/linux/files/cfg/00014-selinux.cfg
@@ -19,7 +19,6 @@ CONFIG_REISERFS_FS_SECURITY=y
CONFIG_JFFS2_FS_SECURITY=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
-CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
--
2.17.1


[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



1721 - 1740 of 52543