Date   

Introduction #yocto #python #linux

idadelm@...
 

Hello, I'm Ida Delphine and I'm new to the Yocto Project. Excited to contribute to the Yocto project and hopefully become an outreachy intern.


Re: NPM package recipe, npm not found

Bel Hadj Salem Talel <bhstalel@...>
 

You are right, it needs nodejs-native in DEPENDS. Now it is working
Thanks a lot.


Re: NPM package recipe, npm not found

Quentin Schulz
 

Hi Talel,

On Wed, Oct 07, 2020 at 07:51:58AM -0700, Bel Hadj Salem Talel wrote:
Hi,

I'm trying to make a recipe for an NPM package.
The source files are local.
Here is my recipe:

LICENSE="CLOSED"
SRC_URI+="file://sense-web_${PV].zip"
S=${WORKDIR}
DEPENDS+="nodejs"
Just guessing but probably nodejs-native here?

Although, you might want to have a look at the npm.bbclass and try to
inherit it. Considering how complex the class looks like, it might be
easier to get started with the class and fix what needs to be fixed.

Quentin


NPM package recipe, npm not found

Bel Hadj Salem Talel <bhstalel@...>
 

Hi,

I'm trying to make a recipe for an NPM package.
The source files are local.
Here is my recipe:

LICENSE="CLOSED"
SRC_URI+="file://sense-web_${PV].zip"
S=${WORKDIR}
DEPENDS+="nodejs"
do_compile(){
  export HOME=${S}
  npm install
  npm run-script build
}

The following error appears:

Log data follows:
| DEBUG: Executing shell function do_compile
| /media/talel/data/menzu-zeus/menzu/tmp/work/aarch64-poky-linux/sense-web/1.0-r0/temp/run.do_compile.11622: 107: /media/talel/data/menzu-zeus/menzu/tmp/work/aarch64-poky-linux/sense-web/1.0-r0/temp/run.do_compile.11622: npm: not found
| WARNING: exit code 127 from a shell command.
| ERROR: Execution of '/media/talel/data/menzu-zeus/menzu/tmp/work/aarch64-poky-linux/sense-web/1.0-r0/temp/run.do_compile.11622' failed with exit code 127:
| /media/talel/data/menzu-zeus/menzu/tmp/work/aarch64-poky-linux/sense-web/1.0-r0/temp/run.do_compile.11622: 107: /media/talel/data/menzu-zeus/menzu/tmp/work/aarch64-poky-linux/sense-web/1.0-r0/temp/run.do_compile.11622: npm: not found
| WARNING: exit code 127 from a shell command.
|

I did the same steps in devshell of nodejs and everything is correct.
I tried to add the recipe with devtool , devtool add sense-web_1.0.zip but it failed.

Any ideas?
Thanks, Talel


Re: Only index.html is cloned in private repo clone recipe #yocto

Bel Hadj Salem Talel <bhstalel@...>
 

Hi,
Thanks for the quick reply ,
Actually I was wrong about https, I changed it to http and added: SRCURL = "git://gitlab.tools.comp.local/comp/sense/sense_frontend"
instead of SRCURL = "http://gitlab.tools.comp.local/comp/sense/sense_frontend"

Now when I do_fetch:

############
ERROR: sense-web-1.0-r0 do_fetch:
Fetcher failure for URL: 'git://gitlab.tools.comp.local/comp/sense/sense_frontend;protocol=http;branch=master'.
Please set a valid SRCREV for url ['SRCREV_default_pn-sense-web', 'SRCREV_default', 'SRCREV_pn-sense-web', 'SRCREV']
(possible key names are git://gitlab.tools.comp.local/comp/sense/sense_frontend;protocol=http;branch=master, or use a ;rev=X URL parameter)
############

I'm trying to understand the issue for my Yocto knowledge.
Can you help me understand this or fix the issue ?

Thanks alot for the help.


Re: Only index.html is cloned in private repo clone recipe #yocto

 

On Wed, 7 Oct 2020 at 09:29, Bel Hadj Salem Talel <bhstalel@...> wrote:

Hello All,

I have a private git repo which is in a local gitlab server.
Here is the local repo domain: http://gitlab.tools.comp.local/comp/sense/sense_frontend
I already saved the git credentials (username and password) , and I created this recipe:

LICENSE = "CLOSED"
SRCURL = "http://gitlab.tools.comp.local/comp/sense/sense_frontend"
SRCBRANCH = "master"
SRCPROTO = "https"
# Define the source for this recipe
SRC_URI += "${SRCURL};protocol=${SRCPROTO};branch=${SRCBRANCH}"
SRC_URI[md5sum] = "1becf51a6312d09f0c1c22120efd499c"
SRC_URI[sha256sum] = "142e3af77b6851b614d07012abce145ce2526b8d0d95e7a94cff62f0e6432d26"

When I do do_fetch and do_unpack I only see the index.html file of the repo is downloaded.
What is the problem ?
How can I solve this?
SRC_URI should start with "git://" to do a git clone. The "protocol"
field can then be set to http, https or ssh if needed, I see you've
already got that set to https after expansion so you should just need
to change your SRCURL value.

Thanks,

--
Paul Barker
Konsulko Group


Only index.html is cloned in private repo clone recipe #yocto

Bel Hadj Salem Talel <bhstalel@...>
 

Hello All,

I have a private git repo which is in a local gitlab server.
Here is the local repo domain: http://gitlab.tools.comp.local/comp/sense/sense_frontend
I already saved the git credentials (username and password) , and I created this recipe:

LICENSE = "CLOSED"
SRCURL = "http://gitlab.tools.comp.local/comp/sense/sense_frontend"
SRCBRANCH = "master"
SRCPROTO = "https"
# Define the source for this recipe
SRC_URI += "${SRCURL};protocol=${SRCPROTO};branch=${SRCBRANCH}"
SRC_URI[md5sum] = "1becf51a6312d09f0c1c22120efd499c"
SRC_URI[sha256sum] = "142e3af77b6851b614d07012abce145ce2526b8d0d95e7a94cff62f0e6432d26"

When I do do_fetch and do_unpack I only see the index.html file of the repo is downloaded.
What is the problem ?
How can I solve this?

Thanks, Talel


[meta-security][zeus][PATCH 1/1] clamav: add INSTALL_CLAMAV_CVD flag to do_install

Charlie Davies
 

Recipe provides INSTALL_CLAMAV_CVD flag to bypass clamav
cvd db creation. During do_install this flag should be
used to conditionally skip install of cvd db if needed.

Signed-off-by: Charlie Davies <charles.davies@...>
---
recipes-security/clamav/clamav_0.99.4.bb | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/recipes-security/clamav/clamav_0.99.4.bb b/recipes-security/=
clamav/clamav_0.99.4.bb
index a340b48..1ee3f58 100644
--- a/recipes-security/clamav/clamav_0.99.4.bb
+++ b/recipes-security/clamav/clamav_0.99.4.bb
@@ -102,7 +102,10 @@ do_install_append_class-target () {
install -m 0644 ${WORKDIR}/volatiles.03_clamav ${D}${sysconfdir}/de=
fault/volatiles/volatiles.03_clamav
sed -i -e 's#${STAGING_DIR_HOST}##g' ${D}${libdir}/pkgconfig/libclam=
av.pc
rm ${D}/${libdir}/libclamav.so
- install -m 666 ${S}/clamav_db/* ${D}/${localstatedir}/lib/clamav/.
+ if [ "${INSTALL_CLAMAV_CVD}" =3D "1" ]; then
+ bbnote "CLAMAV installing cvd"
+ install -m 666 ${S}/clamav_db/* ${D}/${localstatedir}/lib/clamav=
/.
+ fi
if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d=
)};then
install -D -m 0644 ${WORKDIR}/clamav.service ${D}${systemd_unitd=
ir}/system/clamav.service
install -d ${D}${sysconfdir}/tmpfiles.d
--=20
2.28.0


Re: Perl populate sysroot fails (yocto 2.0.3)

Khem Raj
 

Please find which other recipe is creating /usr/lib/perl5 directory,
perhaps you can look through builddir for that. I think we had this
kind of sysroot clash with libhugetlbfs and as a workaround may be add
DEPENDS = "perl" in that recipe to pre-empt the clash.

On Tue, Oct 6, 2020 at 1:36 PM Varangu-Booth, Valen
<Valen.Varangu-Booth@...> wrote:

Hi all,

I'm trying to re-create a build that was previously made by someone else (in an effort to reproduce an exact old build). This is based on Yocto 2.0.3.
I'm encountering an issue in do_populate_sysroot for Perl, where it fails because /usr/lib/perl5 already exists. (See details below:)

Exception: CalledProcessError: Command 'cd YOCTO_ROOT/build/tmp/work/corei7-64-poky-linux/perl/5.22.0-r0/sysroot-destdir; find . -type d -print | tar -cf - -C YOCTO_ROOT/build/tmp/work/corei7-64-poky-linux/perl/5.22.0-r0/sysroot-destdir -p --files-from - --no-recursion | tar -xf - -C YOCTO_ROOT/build/tmp/sysroots/intel-corei7-64' returned non-zero exit status 2 with output tar: ./usr/lib/perl5: Cannot create symlink to 'perl': File exists
tar: ./usr/lib/perl5: Cannot create symlink to 'perl': File exists
tar: ./usr/lib/perl5: Cannot create symlink to 'perl': File exists

The issue seems to always occur when the sstate-cache is present, so do_populate_sysroot_setscene fails first, then it tries to build from scratch and do_populate_sysroot fails as well.
I have seen it in a completely fresh build as well, though this seems intermittent (or I haven't yet nailed down what changes when it does/doesn't happen).

It seems like somehow some recipe ahead of Perl is putting something in /usr/lib/perl5 and perhaps some kind of race condition caused this to be intermittent?

Any input would be greatly appreciated, eventually I will get this onto a newer version of Yocto but first I need to be able to reliably re-create this exact build.


Perl populate sysroot fails (yocto 2.0.3)

Varangu-Booth, Valen
 

Hi all,

I'm trying to re-create a build that was previously made by someone else (in an effort to reproduce an exact old build). This is based on Yocto 2.0.3.
I'm encountering an issue in do_populate_sysroot for Perl, where it fails because /usr/lib/perl5 already exists. (See details below:)

Exception: CalledProcessError: Command 'cd YOCTO_ROOT/build/tmp/work/corei7-64-poky-linux/perl/5.22.0-r0/sysroot-destdir; find . -type d -print | tar -cf - -C YOCTO_ROOT/build/tmp/work/corei7-64-poky-linux/perl/5.22.0-r0/sysroot-destdir -p --files-from - --no-recursion | tar -xf - -C YOCTO_ROOT/build/tmp/sysroots/intel-corei7-64' returned non-zero exit status 2 with output tar: ./usr/lib/perl5: Cannot create symlink to 'perl': File exists
tar: ./usr/lib/perl5: Cannot create symlink to 'perl': File exists
tar: ./usr/lib/perl5: Cannot create symlink to 'perl': File exists

The issue seems to always occur when the sstate-cache is present, so do_populate_sysroot_setscene fails first, then it tries to build from scratch and do_populate_sysroot fails as well.
I have seen it in a completely fresh build as well, though this seems intermittent (or I haven't yet nailed down what changes when it does/doesn't happen).

It seems like somehow some recipe ahead of Perl is putting something in /usr/lib/perl5 and perhaps some kind of race condition caused this to be intermittent?

Any input would be greatly appreciated, eventually I will get this onto a newer version of Yocto but first I need to be able to reliably re-create this exact build.


Re: Automated script to know all the Recipes details

Paul Eggleton
 

Hi there

On Friday, 2 October 2020 01:16:15 NZDT Yocto_user wrote:
Hi, do we have any automated script that we can run in Yocto 3.0 Zues
release or any general release to get all these information of all the
packages installed in a particular Yocto release:
1. Name
2. Version
3. Homepage link of the Recipes from where it was downloaded.
So if you're familiar with Python you could fairly quickly write a script to
iterate over recipes and get these values using tinfoil:

https://wiki.yoctoproject.org/wiki/TipsAndTricks/Tinfoil

Cheers,
Paul


Re: [OE-core] [devtool] problem with PACKAGE_ARCH and TARGET_OS

Adrian
 

Hi Richard,

I have tried with the latest version of Zeus
(d88d62c20d7d8da85f02edb170dae0280624ad7e) and the problem is not solved
yet. Do you need more information on my side?

Regards,

Adrian

On 25.08.2020 17:16, Adrian Fiergolski wrote:
Hi Richard,

Thank you for your reply.

On 25.08.2020 15:05, Richard Purdie wrote:
On Tue, 2020-08-25 at 14:47 +0200, Adrian wrote:
Hi,

After recent update of poky, I started to experience an issue with
devtool. Currently, I am using the latest zeus version. I have a
multiconfig environment (Xilinx ZynqMP+ with ARM64 and Microblaze). I
am
modifying my recipe compiled from local sources. The custom target
machine configuration sets DEAULTTUNE="cortexa53"

When I call:

$> devtool build peary
$>devtool deploy-target peary root@...

I get the error:

ERROR: No files to deploy - have you built the peary recipe? If so,
the
install step has not installed any files.

In fact, I see that 'devtool build' creates image under
'/home/afiergol/poky/build/tmp/work/aarch64-poky-
linux/peary/1.0+git999-r0/image',
while 'devtool deploy-target' search for files under
'/home/afiergol/poky/build/tmp/work/cortexa53-poky-linux-
gnueabi/peary/1.0+git999-r0/image'

If in the 'peary' recipe I add a line

PACKAGE_ARCH = "${MACHINE_ARCH}"

'devtool deploy-target' starts to search under
'/home/afiergol/poky/build/tmp/work/aarch64-poky-linux-
gnueabi/peary/1.0+git999-r0/image'

If further, I fix in the 'peary' recipe:

TARGET_OS = "linux"

'devtool deploy-target' properly deploys the binaries to the target
machine.

However, as I explained, I had to fix in the recipe PACKAGE_ARCH and
TARGET_OS variables. It is required only for devtool to work, as
bitbake
builds properly my custom Linux image containing the recipe without
those variables being set anywhere in my layer.

Has anybody else experienced a similar issue? Could somebody give a
reference (I didn't find) to documentation which explains why and how
those variables need to be set (I especially concerned about
TARGET_OS)?
devtool is working for other recipes in oe-core so this peary recipe is
probably doing something which is confusing devtool. Or its perhaps the
machine configuration. Is that a public recipe? If not, is there a
recipe you could share which shows the issue?

Basically we need some way to reproduce the issue to be able to
comment. You certainly should not have to set those variables.

Cheers,

Richard
I am enclosing the recipe to this message (peary.bb).

When it comes to the machine configuration, its an extension of
meta-xilinx
(https://github.com/adrianf0/meta-xilinx/tree/rel-v2020.1_fastree3d).
Though, I can't share with you the full conf file, the issue related parts:

#@TYPE: Machine
#@NAME: falcon-zynqmp
#@DESCRIPTION: Machine support for Fastree SoC board.
#
SOC_VARIANT ?= "eg"
DEFAULTTUNE_falcon-zynqmp = "cortexa53"
require conf/machine/include/soc-zynqmp.inc
require conf/machine/include/machine-xilinx-default.inc

MACHINE_FEATURES = "rtc ext2 ext3 vfat"

SERIAL_CONSOLE = "115200 ttyPS0"
SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"

PREFERRED_PROVIDER_virtual/kernel ?= "linux-xlnx"
PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot-xlnx"

EXTRA_IMAGEDEPENDS += " \
        u-boot-zynq-scr \
        arm-trusted-firmware \
        virtual/boot-bin \
        virtual/bootloader \
        virtual/bitstream \
        "

The local.conf, has nothing special, probably this is the most related
to the issue: MACHINE ??= "falcon-zynqmp"

Regards,

Adrian


Yocto Project Status WW40'20

Stephen Jolley
 

Current Dev Position: YP 3.2 M4

Next Deadline: YP 3.2 M4 Feature Freeze - Now

 

Next Team Meetings:

 

Key Status/Updates:

  • YP M3 has been released
  • YP 3.1.3 is out of QA, there were questions about a failing ptest but those are due to a test issue, not a regression so its likely to be released imminently.
  • We are now due to build M4 rc1. The builds will happen when the current pseudo issues are resolved to a suitable conclusion for the release.
  • As mentioned above, there is a continued concern about file mode corruption issues in pseudo. We do now have patches which reduce the corruption window by orders of magnitude by they don’t entirely remove the potential race. Test builds have been seeing issues in wic in particular and testing is ongoing to try and identify and fix the remaining issues.
  • Unfortunately, intermittent autobuilder issues are still occurring, whilst reducing in frequency and number, possibly due to less frequency full rebuilds. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

Help with any of these would be much appreciated, unfortunately it is proving hard to find anyone interested in helping figure these out and they significantly hamper our testing.

 

Ways to contribute:

 

YP 3.2 Milestone Dates:

  • YP 3.2 M3 was released.
  • YP 3.2 M4 build date 2020/10/5
  • YP 3.2 M4 Release date 2020/10/30

 

Planned upcoming dot releases:

  • YP 3.1.3 is out of QA and should release soon.
  • YP 3.1.4 build date 2020/11/2
  • YP 3.1.4 release date 2020/11/13

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


[meta-security][PATCH 3/3] suricata: fix compiling on gcc10

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-ids/suricata/suricata_4.1.8.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-ids/suricata/suricata_4.1.8.bb b/recipes-ids/suricata/suricata_4.1.8.bb
index 9b7122b..135871c 100644
--- a/recipes-ids/suricata/suricata_4.1.8.bb
+++ b/recipes-ids/suricata/suricata_4.1.8.bb
@@ -14,7 +14,7 @@ SRC_URI += " \

inherit autotools-brokensep pkgconfig python3-dir systemd ptest

-CFLAGS += "-D_DEFAULT_SOURCE"
+CFLAGS += "-D_DEFAULT_SOURCE -fcommon"

CACHED_CONFIGUREVARS = "ac_cv_header_htp_htp_h=yes ac_cv_lib_htp_htp_conn_create=yes \
ac_cv_path_HAVE_WGET=no ac_cv_path_HAVE_CURL=no "
--
2.17.1


[meta-security][PATCH 2/3] packagegroup-core-security: apparmor 3.0 ptest does not build

Armin Kuster
 

for now skip apparmor ptest

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

diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb b/recipes-core/packagegroup/packagegroup-core-security.bb
index 9546e0f..1a55c1b 100644
--- a/recipes-core/packagegroup/packagegroup-core-security.bb
+++ b/recipes-core/packagegroup/packagegroup-core-security.bb
@@ -87,6 +87,5 @@ RDEPENDS_packagegroup-meta-security-ptest-packages = "\
suricata-ptest \
tripwire-ptest \
python3-fail2ban-ptest \
- ${@bb.utils.contains("DISTRO_FEATURES", "apparmor", "apparmor-ptest", "",d)} \
${@bb.utils.contains("DISTRO_FEATURES", "smack", "smack-ptest", "",d)} \
"
--
2.17.1


[meta-security][PATCH 1/3] apparmor: update to 3.0

Armin Kuster
 

skip ptest for now, on todo list for fix.
Runtime test pass

remove patch now included in update: 0001-regression-tests-Don-t-build-syscall_sysctl-if-missi.patch

Signed-off-by: Armin Kuster <akuster808@...>
---
.../{apparmor_2.13.4.bb => apparmor_3.0.bb} | 62 +++++-------
...Update-make-check-to-select-tools-ba.patch | 91 ++++++++++++++++++
.../0001-apparmor-fix-manpage-order.patch | 43 +++++++++
...-Don-t-build-syscall_sysctl-if-missi.patch | 96 -------------------
recipes-mac/AppArmor/files/functions | 2 +-
5 files changed, 158 insertions(+), 136 deletions(-)
rename recipes-mac/AppArmor/{apparmor_2.13.4.bb => apparmor_3.0.bb} (70%)
create mode 100644 recipes-mac/AppArmor/files/0001-Revert-profiles-Update-make-check-to-select-tools-ba.patch
create mode 100644 recipes-mac/AppArmor/files/0001-apparmor-fix-manpage-order.patch
delete mode 100644 recipes-mac/AppArmor/files/0001-regression-tests-Don-t-build-syscall_sysctl-if-missi.patch

diff --git a/recipes-mac/AppArmor/apparmor_2.13.4.bb b/recipes-mac/AppArmor/apparmor_3.0.bb
similarity index 70%
rename from recipes-mac/AppArmor/apparmor_2.13.4.bb
rename to recipes-mac/AppArmor/apparmor_3.0.bb
index 6ba1ea8..9c98199 100644
--- a/recipes-mac/AppArmor/apparmor_2.13.4.bb
+++ b/recipes-mac/AppArmor/apparmor_3.0.bb
@@ -11,10 +11,10 @@ SECTION = "admin"
LICENSE = "GPLv2 & GPLv2+ & BSD-3-Clause & LGPLv2.1+"
LIC_FILES_CHKSUM = "file://${S}/LICENSE;md5=fd57a4b0bc782d7b80fd431f10bbf9d0"

-DEPENDS = "bison-native apr gettext-native coreutils-native"
+DEPENDS = "bison-native apr gettext-native coreutils-native swig-native"

SRC_URI = " \
- git://gitlab.com/apparmor/apparmor.git;protocol=https;branch=apparmor-2.13 \
+ git://gitlab.com/apparmor/apparmor.git;protocol=https;branch=apparmor-3.0 \
file://disable_perl_h_check.patch \
file://crosscompile_perl_bindings.patch \
file://apparmor.rc \
@@ -23,32 +23,31 @@ SRC_URI = " \
file://apparmor.service \
file://0001-Makefile.am-suppress-perllocal.pod.patch \
file://run-ptest \
- file://0001-regression-tests-Don-t-build-syscall_sysctl-if-missi.patch \
+ file://0001-apparmor-fix-manpage-order.patch \
+ file://0001-Revert-profiles-Update-make-check-to-select-tools-ba.patch \
"

-SRCREV = "df0ac742f7a1146181d8734d03334494f2015134"
+SRCREV = "5d51483bfecf556183558644dc8958135397a7e2"
S = "${WORKDIR}/git"

PARALLEL_MAKE = ""

COMPATIBLE_MACHINE_mips64 = "(!.*mips64).*"

-inherit pkgconfig autotools-brokensep update-rc.d python3native perlnative ptest cpan manpages systemd features_check
+inherit pkgconfig autotools-brokensep update-rc.d python3native perlnative cpan systemd features_check bash-completion
+
REQUIRED_DISTRO_FEATURES = "apparmor"

-PACKAGECONFIG ??= "python perl aa-decode"
+PACKAGECONFIG ?= "python perl aa-decode"
PACKAGECONFIG[manpages] = "--enable-man-pages, --disable-man-pages"
-PACKAGECONFIG[python] = "--with-python, --without-python, python3 swig-native"
-PACKAGECONFIG[perl] = "--with-perl, --without-perl, perl perl-native swig-native"
+PACKAGECONFIG[python] = "--with-python, --without-python, python3 , python3-core python3-modules"
+PACKAGECONFIG[perl] = "--with-perl, --without-perl, "
PACKAGECONFIG[apache2] = ",,apache2,"
PACKAGECONFIG[aa-decode] = ",,,bash"

-PAMLIB="${@bb.utils.contains('DISTRO_FEATURES', 'pam', '1', '0', d)}"
-HTTPD="${@bb.utils.contains('PACKAGECONFIG', 'apache2', '1', '0', d)}"
-
python() {
if 'apache2' in d.getVar('PACKAGECONFIG').split() and \
- 'webserver' not in d.getVar('BBFILE_COLLECTIONS').split():
+ 'webserver' not in d.getVar('BBFILE_COLLECTIONS').split():
raise bb.parse.SkipRecipe('Requires meta-webserver to be present.')
}

@@ -64,24 +63,18 @@ do_configure() {
}

do_compile () {
- # Fixes:
- # | sed -ie 's///g' Makefile.perl
- # | sed: -e expression #1, char 0: no previous regular expression
- #| Makefile:478: recipe for target 'Makefile.perl' failed
sed -i "s@sed -ie 's///g' Makefile.perl@@" ${S}/libraries/libapparmor/swig/perl/Makefile
-
-
oe_runmake -C ${B}/libraries/libapparmor
oe_runmake -C ${B}/binutils
oe_runmake -C ${B}/utils
oe_runmake -C ${B}/parser
oe_runmake -C ${B}/profiles

- if test -z "${HTTPD}" ; then
+ if ${@bb.utils.contains('PACKAGECONFIG','apache2','true','false', d)}; then
oe_runmake -C ${B}/changehat/mod_apparmor
fi

- if test -z "${PAMLIB}" ; then
+ if ${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'true', 'false', d)}; then
oe_runmake -C ${B}/changehat/pam_apparmor
fi
}
@@ -95,31 +88,21 @@ do_install () {
oe_runmake -C ${B}/parser DESTDIR="${D}" install
oe_runmake -C ${B}/profiles DESTDIR="${D}" install

- # If perl is disabled this script won't be any good
- if ! ${@bb.utils.contains('PACKAGECONFIG','perl','true','false', d)}; then
- rm -f ${D}${sbindir}/aa-notify
- fi
-
if ! ${@bb.utils.contains('PACKAGECONFIG','aa-decode','true','false', d)}; then
rm -f ${D}${sbindir}/aa-decode
fi

- if test -z "${HTTPD}" ; then
+ if ${@bb.utils.contains('PACKAGECONFIG','apache2','true','false', d)}; then
oe_runmake -C ${B}/changehat/mod_apparmor DESTDIR="${D}" install
fi

- if test -z "${PAMLIB}" ; then
+ if ${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'true', 'false', d)}; then
+ install -d ${D}/lib/security
oe_runmake -C ${B}/changehat/pam_apparmor DESTDIR="${D}" install
fi

- # aa-easyprof is installed by python-tools-setup.py, fix it up
- sed -i -e 's:/usr/bin/env.*:/usr/bin/python3:' ${D}${bindir}/aa-easyprof
- chmod 0755 ${D}${bindir}/aa-easyprof
-
- install ${WORKDIR}/apparmor ${D}/${INIT_D_DIR}/apparmor
- install ${WORKDIR}/functions ${D}/lib/apparmor
- sed -i -e 's/getconf _NPROCESSORS_ONLN/nproc/' ${D}/lib/apparmor/functions
- sed -i -e 's/ls -AU/ls -A/' ${D}/lib/apparmor/functions
+ install -m 755 ${WORKDIR}/apparmor ${D}/${INIT_D_DIR}/apparmor
+ install -m 755 ${WORKDIR}/functions ${D}/lib/apparmor

if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
install -d ${D}${systemd_system_unitdir}
@@ -138,8 +121,8 @@ do_compile_ptest_arm () {

do_compile_ptest () {
sed -i -e 's/cpp \-dM/${HOST_PREFIX}gcc \-dM/' ${B}/tests/regression/apparmor/Makefile
- oe_runmake -C ${B}/tests/regression/apparmor
- oe_runmake -C ${B}/libraries/libapparmor
+ oe_runmake -C ${B}/tests/regression/apparmor USE_SYSTEM=0
+ oe_runmake -C ${B}/libraries/libapparmor
}

do_install_ptest () {
@@ -189,12 +172,13 @@ SYSTEMD_AUTO_ENABLE ?= "enable"

PACKAGES += "mod-${PN}"

-FILES_${PN} += "/lib/apparmor/ ${sysconfdir}/apparmor ${PYTHON_SITEPACKAGES_DIR}"
+FILES_${PN} += "/lib/apparmor/ /lib/security/ ${sysconfdir}/apparmor ${PYTHON_SITEPACKAGES_DIR}"
FILES_mod-${PN} = "${libdir}/apache2/modules/*"

# Add coreutils and findutils only if sysvinit scripts are in use
-RDEPENDS_${PN} += "${@["coreutils findutils", ""][(d.getVar('VIRTUAL-RUNTIME_init_manager') == 'systemd')]} ${@bb.utils.contains('PACKAGECONFIG','python','python3-core python3-modules','', d)}"
+RDEPENDS_${PN} += "glibc-utils ${@["coreutils findutils", ""][(d.getVar('VIRTUAL-RUNTIME_init_manager') == 'systemd')]} ${@bb.utils.contains('PACKAGECONFIG','python','python3-core python3-modules','', d)}"
RDEPENDS_${PN}_remove += "${@bb.utils.contains('PACKAGECONFIG','perl','','perl', d)}"
RDEPENDS_${PN}-ptest += "perl coreutils dbus-lib bash"

+INSANE_SKIP_${PN} = "ldflags"
PRIVATE_LIBS_${PN}-ptest = "libapparmor.so*"
diff --git a/recipes-mac/AppArmor/files/0001-Revert-profiles-Update-make-check-to-select-tools-ba.patch b/recipes-mac/AppArmor/files/0001-Revert-profiles-Update-make-check-to-select-tools-ba.patch
new file mode 100644
index 0000000..791437d
--- /dev/null
+++ b/recipes-mac/AppArmor/files/0001-Revert-profiles-Update-make-check-to-select-tools-ba.patch
@@ -0,0 +1,91 @@
+From 5ed21abbef4d4c2983e70bd2868fb817150e883e Mon Sep 17 00:00:00 2001
+From: Armin Kuster <akuster808@...>
+Date: Sat, 3 Oct 2020 11:26:46 -0700
+Subject: [PATCH] Revert "profiles: Update 'make check' to select tools based
+ on USE_SYSTEM"
+
+This reverts commit 6016f931ebf7b61e1358f19453ef262d9d184a4e.
+
+Upstream-Statue: OE specific
+These changes cause during packaging with perms changing.
+
+Signed-off-by: Armin Kuster <akuster808@...>
+
+---
+ profiles/Makefile | 50 ++++++++++-------------------------------------
+ 1 file changed, 10 insertions(+), 40 deletions(-)
+
+diff --git a/profiles/Makefile b/profiles/Makefile
+index ba47fc16..5384cb05 100644
+--- a/profiles/Makefile
++++ b/profiles/Makefile
+@@ -35,49 +35,9 @@ EXTRAS_SOURCE=./apparmor/profiles/extras/
+ SUBDIRS=$(shell find ${PROFILES_SOURCE} -type d -print)
+ TOPLEVEL_PROFILES=$(filter-out ${SUBDIRS}, $(wildcard ${PROFILES_SOURCE}/*))
+
+-ifdef USE_SYSTEM
+- PYTHONPATH=
+- PARSER?=apparmor_parser
+- LOGPROF?=aa-logprof
+-else
+- # PYTHON_DIST_BUILD_PATH based on libapparmor/swig/python/test/Makefile.am
+- PYTHON_DIST_BUILD_PATH = ../libraries/libapparmor/swig/python/build/$$($(PYTHON) -c "import distutils.util; import platform; print(\"lib.%s-%s\" %(distutils.util.get_platform(), platform.python_version()[:3]))")
+- LIBAPPARMOR_PATH=../libraries/libapparmor/src/.libs/
+- LD_LIBRARY_PATH=$(LIBAPPARMOR_PATH):$(PYTHON_DIST_BUILD_PATH)
+- PYTHONPATH=../utils/:$(PYTHON_DIST_BUILD_PATH)
+- PARSER?=../parser/apparmor_parser
+- # use ../utils logprof
+- LOGPROF?=LD_LIBRARY_PATH=$(LD_LIBRARY_PATH) PYTHONPATH=$(PYTHONPATH) $(PYTHON) ../utils/aa-logprof
+-endif
+-
+ # $(PWD) is wrong when using "make -C profiles" - explicitely set it here to get the right value
+ PWD=$(shell pwd)
+
+-.PHONY: test-dependencies
+-test-dependencies: __parser __libapparmor
+-
+-
+-.PHONY: __parser __libapparmor
+-__parser:
+-ifndef USE_SYSTEM
+- @if [ ! -f $(PARSER) ]; then \
+- echo "error: $(PARSER) is missing. Pick one of these possible solutions:" 1>&2; \
+- echo " 1) Test using the in-tree parser by building it first and then trying again. See the top-level README for help." 1>&2; \
+- echo " 2) Test using the system parser by adding USE_SYSTEM=1 to your make command." 1>&2; \
+- exit 1; \
+- fi
+-endif
+-
+-__libapparmor:
+-ifndef USE_SYSTEM
+- @if [ ! -f $(LIBAPPARMOR_PATH)libapparmor.so ]; then \
+- echo "error: $(LIBAPPARMOR_PATH)libapparmor.so is missing. Pick one of these possible solutions:" 1>&2; \
+- echo " 1) Build against the in-tree libapparmor by building it first and then trying again. See the top-level README for help." 1>&2; \
+- echo " 2) Build against the system libapparmor by adding USE_SYSTEM=1 to your make command." 1>&2; \
+- exit 1; \
+- fi
+-endif
+-
+ local:
+ for profile in ${TOPLEVEL_PROFILES}; do \
+ fn=$$(basename $$profile); \
+@@ -109,6 +69,16 @@ else
+ Q=
+ endif
+
++ifndef PARSER
++# use system parser
++PARSER=../parser/apparmor_parser
++endif
++
++ifndef LOGPROF
++# use ../utils logprof
++LOGPROF=PYTHONPATH=../utils $(PYTHON) ../utils/aa-logprof
++endif
++
+ .PHONY: docs
+ # docs: should we have some here?
+ docs:
+--
+2.17.1
+
diff --git a/recipes-mac/AppArmor/files/0001-apparmor-fix-manpage-order.patch b/recipes-mac/AppArmor/files/0001-apparmor-fix-manpage-order.patch
new file mode 100644
index 0000000..9f3dce4
--- /dev/null
+++ b/recipes-mac/AppArmor/files/0001-apparmor-fix-manpage-order.patch
@@ -0,0 +1,43 @@
+From c9baef0c70122e1be33b627874772e6e9a5d7744 Mon Sep 17 00:00:00 2001
+From: Armin Kuster <akuster808@...>
+Date: Fri, 2 Oct 2020 19:43:44 -0700
+Subject: [PATCH] apparmor: fix manpage order
+
+It trys to create a symlink before the man pages are installed.
+
+ ln -sf aa-status.8 /(path}/apparmor/3.0-r0/image/usr/share/man/man8/apparmor_status.8
+ | ln: failed to create symbolic link '{path}/apparmor/3.0-r0/image/usr/share/man/man8/apparmor_status.8': No such file or directory
+
+Upstream-Status: Pending
+Signed-off-by: Armin Kuster <akuster808@...>
+
+...
+
+install -d /{path}/apparmor/3.0-r0/image/usr/share/man/man8 ; install -m 644 aa-status.8 /{path}/apparmor/3.0-r0/image/usr/share/man/man8;
+
+Signed-off-by: Armin Kuster <akuster@...>
+---
+ binutils/Makefile | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/binutils/Makefile b/binutils/Makefile
+index 99e54875..3f1d0011 100644
+--- a/binutils/Makefile
++++ b/binutils/Makefile
+@@ -156,12 +156,12 @@ install-arch: arch
+ install -m 755 -d ${SBINDIR}
+ ln -sf aa-status ${SBINDIR}/apparmor_status
+ install -m 755 ${SBINTOOLS} ${SBINDIR}
+- ln -sf aa-status.8 ${DESTDIR}/${MANDIR}/man8/apparmor_status.8
+
+ .PHONY: install-indep
+ install-indep: indep
+ $(MAKE) -C po install NAME=${NAME} DESTDIR=${DESTDIR}
+ $(MAKE) install_manpages DESTDIR=${DESTDIR}
++ ln -sf aa-status.8 ${DESTDIR}/${MANDIR}/man8/apparmor_status.8
+
+ ifndef VERBOSE
+ .SILENT: clean
+--
+2.17.1
+
diff --git a/recipes-mac/AppArmor/files/0001-regression-tests-Don-t-build-syscall_sysctl-if-missi.patch b/recipes-mac/AppArmor/files/0001-regression-tests-Don-t-build-syscall_sysctl-if-missi.patch
deleted file mode 100644
index 3cd1e88..0000000
--- a/recipes-mac/AppArmor/files/0001-regression-tests-Don-t-build-syscall_sysctl-if-missi.patch
+++ /dev/null
@@ -1,96 +0,0 @@
-From 7a7c7fb346ded6f017c8df44486778a5f032d41a Mon Sep 17 00:00:00 2001
-From: John Johansen <john.johansen@...>
-Date: Tue, 29 Sep 2020 03:05:22 -0700
-Subject: [PATCH] regression tests: Don't build syscall_sysctl if missing
- kernel headers
-
-sys/sysctl.h is not guaranteed to exist anymore since
-https://sourceware.org/pipermail/glibc-cvs/2020q2/069366.html
-
-which is a follow on to the kernel commit
-61a47c1ad3a4 sysctl: Remove the sysctl system call
-
-While the syscall_sysctl currently checks if the kernel supports
-sysctrs before running the tests. The tests can't even build if the
-kernel headers don't have the sysctl defines.
-
-Fixes: https://gitlab.com/apparmor/apparmor/-/issues/119
-Fixes: https://bugs.launchpad.net/apparmor/+bug/1897288
-MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/637
-Signed-off-by: John Johansen <john.johansen@...>
-Acked-by: Steve Beattie <steve.beattie@...>
-(cherry picked from commit 2e5a266eb715fc7e526520235a6450444775791f)
-
-Upstream-Status: Backport
-Signed-off-by: Armin Kuster <akuster808@...>
-
----
- tests/regression/apparmor/Makefile | 10 +++++++++-
- tests/regression/apparmor/syscall_sysctl.sh | 15 +++++++++++----
- 2 files changed, 20 insertions(+), 5 deletions(-)
-
-diff --git a/tests/regression/apparmor/Makefile b/tests/regression/apparmor/Makefile
-index 198ca421..c3d0cfb7 100644
---- a/tests/regression/apparmor/Makefile
-+++ b/tests/regression/apparmor/Makefile
-@@ -69,6 +69,9 @@ endif # USE_SYSTEM
-
- CFLAGS += -g -O0 -Wall -Wstrict-prototypes
-
-+USE_SYSCTL:=$(shell echo "#include <sys/sysctl.h>" | cpp -dM >/dev/null 2>/dev/null && echo true)
-+
-+
- SRC=access.c \
- at_secure.c \
- introspect.c \
-@@ -130,7 +133,6 @@ SRC=access.c \
- syscall_sethostname.c \
- syscall_setdomainname.c \
- syscall_setscheduler.c \
-- syscall_sysctl.c \
- sysctl_proc.c \
- tcp.c \
- transition.c \
-@@ -146,6 +148,12 @@ ifneq (,$(findstring $(shell uname -i),i386 i486 i586 i686 x86 x86_64))
- SRC+=syscall_ioperm.c syscall_iopl.c
- endif
-
-+#only do sysctl syscall test if defines installed and OR supported by the
-+# kernel
-+ifeq ($(USE_SYSCTL),true)
-+SRC+=syscall_sysctl.c
-+endif
-+
- #only do dbus if proper libs are installl
- ifneq (,$(shell pkg-config --exists dbus-1 && echo TRUE))
- SRC+=dbus_eavesdrop.c dbus_message.c dbus_service.c dbus_unrequested_reply.c
-diff --git a/tests/regression/apparmor/syscall_sysctl.sh b/tests/regression/apparmor/syscall_sysctl.sh
-index f93946f3..5f856984 100644
---- a/tests/regression/apparmor/syscall_sysctl.sh
-+++ b/tests/regression/apparmor/syscall_sysctl.sh
-@@ -148,11 +148,18 @@ test_sysctl_proc()
- # check if the kernel supports CONFIG_SYSCTL_SYSCALL
- # generally we want to encourage kernels to disable it, but if it's
- # enabled we want to test against it
--settest syscall_sysctl
--if ! res="$(${test} ro 2>&1)" && [ "$res" = "FAIL: sysctl read failed - Function not implemented" ] ; then
-- echo " WARNING: syscall sysctl not implemented, skipping tests ..."
-+# In addition test that sysctl exists in the kernel headers, if it does't
-+# then we can't even built the syscall_sysctl test
-+if echo "#include <sys/sysctl.h>" | cpp -dM >/dev/null 2>/dev/null ; then
-+ settest syscall_sysctl
-+
-+ if ! res="$(${test} ro 2>&1)" && [ "$res" = "FAIL: sysctl read failed - Function not implemented" ] ; then
-+ echo " WARNING: syscall sysctl not implemented, skipping tests ..."
-+ else
-+ test_syscall_sysctl
-+ fi
- else
-- test_syscall_sysctl
-+ echo " WARNING: syscall sysctl not supported by kernel headers, skipping tests ..."
- fi
-
- # now test /proc/sys/ paths
---
-2.17.1
-
diff --git a/recipes-mac/AppArmor/files/functions b/recipes-mac/AppArmor/files/functions
index cef8cfe..e9e2bbf 100644
--- a/recipes-mac/AppArmor/files/functions
+++ b/recipes-mac/AppArmor/files/functions
@@ -144,7 +144,7 @@ clear_cache_var() {

read_features_dir()
{
- for f in `ls -AU "$1"` ; do
+ for f in `ls -A "$1"` ; do
if [ -f "$1/$f" ] ; then
read -r KF < "$1/$f" || true
echo -n "$f {$KF } "
--
2.17.1


Re: Kernel panic after failing to load libssl.so.1.0.0 #kernel

aravind.chittapur@...
 

Copying libssl.so.1.0.0 to boot initrd image solved the problem.

Thanks,
Aravind


M+ & H bugs with Milestone Movements WW40

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW40 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

5322

Global DNS fallback mechanism not present in poky distro

kai.kang@...

kai.kang@...

3.2 M3

3.2 M4

 

10693

Add a testcase for multilib eSDK on the autobuilder

Qi.Chen@...

Qi.Chen@...

3.2 M3

3.3

 

11385

poky-container: clarify that meta-data should be checked out using native tools that run the host and not with tools in container

timothy.t.orling@...

timothy.t.orling@...

3.99

3.3 M1

 

12060

It is possible to specify a PACKAGE and a PKG_ rename that conflict

kai.kang@...

kai.kang@...

3.2 M3

3.3 M1

 

12342

lib32-core-image-sato -ctestimage failed due to wrong package names

kai.kang@...

kai.kang@...

3.2 M3

3.2 M4

 

12917

Warnings from nightly-multilib builds (build-deps)

kai.kang@...

kai.kang@...

3.2 M3

3.2 M4

 

13182

Inconsistency detected by ld.so: dl-open.c: 274: dl_open_worker: Assertion xxx failed

Qi.Chen@...

Qi.Chen@...

3.2 M3

3.3

 

13288

pseudo should not follow symlinks in /proc

randy.macleod@...

sakib.sajal@...

3.2 M3

3.2 M4

 

13581

Line wrapping over prompt in BASH

randy.macleod@...

jason.wessel@...

3.2 M3

3.2 M4

 

13589

Document sstate cache mirror best practices

randy.macleod@...

mark.morton@...

3.2 M3

3.2 M4

 

13631

core-image-full-cmdline qemumips systemd boot failure

kai.kang@...

kai.kang@...

3.2 M3

3.2 M4

 

13646

runtime tests sometimes can't login to the serial console on systemd images (generates warning)

kai.kang@...

richard.purdie@...

3.2 M3

3.2 M4

 

13666

[QA 3.0.1 RC3] valgrind.drd failure in ptest

randy.macleod@...

stacy.gaikovaia@...

3.2 M3

3.2 M4

 

13838

[QA 3.1 M3 RC1] failure in ptest: valgrind.drd/tests/bar_bad and valgrind.drd/tests/bar_bad_xml

randy.macleod@...

stacy.gaikovaia@...

3.2 M3

3.2 M4

 

13841

quilt ptest intermittent failure

joe.slater@...

joe.slater@...

3.2 M3

3.2 M4

 

13904

do_prepare_recipe_sysroot: postinst-useradd-* does not run in order of dependency and sometimes fails

randy.macleod@...

sakib.sajal@...

3.2 M3

3.2 M4

 

13997

[QA 3.2 M2 RC1] failure in ptest : libinput.libinput-test-suite

randy.macleod@...

sakib.sajal@...

3.2 M3

3.2 M4

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Enhancements/Bugs closed WW40

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

duziheng2010@...

2

Qi.Chen@...

2

bruce.ashfield@...

1

akuster808@...

1

randy.macleod@...

1

timothy.t.orling@...

1

Grand Total

8

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: [meta-gplv2] [PATCH] gnupg: Make it build with GCC 10 (which uses -fno-common by default)

Joshua Watt
 

On 10/5/20 3:36 PM, Peter Kjellerstedt wrote:
-----Original Message-----
From: yocto@... <yocto@...> On
Behalf Of Joshua Watt
Sent: den 1 oktober 2020 15:27
To: Khem Raj <raj.khem@...>
Cc: Peter Kjellerstedt <peter.kjellerstedt@...>;
yocto@...
Subject: Re: [yocto] [meta-gplv2] [PATCH] gnupg: Make it build with GCC
10 (which uses -fno-common by default)

On Wed, Sep 30, 2020 at 4:34 PM Khem Raj <raj.khem@...> wrote:
On Wed, Sep 30, 2020 at 1:37 PM Joshua Watt <JPEWhacker@...>
wrote:
With this patch applied, I get the following errors when using the
latest master branches:

| ../mpi/libmpi.a(mpiutil.o): In function `mpi_alloc_limb_space':
| mpiutil.c:(.text+0x84): undefined reference to `memory_debug_mode'
| ../mpi/libmpi.a(mpiutil.o): In function `mpi_alloc':
| mpiutil.c:(.text+0xda): undefined reference to `memory_debug_mode'
| ../mpi/libmpi.a(mpiutil.o): In function `mpi_alloc_secure':
| mpiutil.c:(.text+0x14a): undefined reference to `memory_debug_mode'
| ../mpi/libmpi.a(mpiutil.o): In function `mpi_free_limb_space':
| mpiutil.c:(.text+0x1c7): undefined reference to `memory_debug_mode'
| ../mpi/libmpi.a(mpiutil.o): In function `mpi_free':
| mpiutil.c:(.text+0x267): undefined reference to `memory_debug_mode'
| ../util/libutil.a(iobuf.o): In function `file_filter':
| iobuf.c:(.text+0x1c0): undefined reference to `iobuf_debug_mode'
| iobuf.c:(.text+0x1ea): undefined reference to `iobuf_debug_mode'
| iobuf.c:(.text+0x2e0): undefined reference to `iobuf_debug_mode'
| iobuf.c:(.text+0x305): undefined reference to `iobuf_debug_mode'
| ../util/libutil.a(iobuf.o): In function `underflow':
| iobuf.c:(.text+0x4b3): undefined reference to `iobuf_debug_mode'
| ../util/libutil.a(iobuf.o):iobuf.c:(.text+0x567): more undefined
references to `iobuf_debug_mode' follow
| collect2: error: ld returned 1 exit status

If I revert this commit, gnupg-native will again build correctly. Any
ideas?
Interesting. I had not considered building the recipes from
meta-gplv2 for native as we only use them for target builds.

does it help if you add -fno-common to native CFLAGS
No. It works in all cases if I remove the patch and use "-fcommon"
though. Oddly enough, in my build having the patch caused the target
recipe to fail one way, and not having it caused it to fail another
way....
Are you saying you still have build failures when building gnupg for
target as well, with the patch applied?
Correct. I don't remember exactly, but there was no combination of "-fno-common" and the patch that worked for both native and target cases. The only way I could get it to work for both was without the patch and with "-fcommon"


not sure what's going on there, but I suspect for something
this old, adding "-fcommon" to restore the original behavior makes the
most sense.
Anyway, I get the same errors as above when I try building it for
native using gcc 9.3.1. I'll look into it and see if I can improve
the patch, or if I will have to resort to using -fcommon.

//Peter

8161 - 8180 of 59086