From: Bruce Ashfield <bruce.ashfield@...>

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
.../linux/linux-yocto_5.4.bbappend | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.4.bbappend b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.4.bbappend
index 2c73eb2f67..e1c7372417 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.4.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.4.bbappend
@@ -7,17 +7,17 @@ KMACHINE_genericx86 ?= "common-pc"
KMACHINE_genericx86-64 ?= "common-pc-64"
KMACHINE_beaglebone-yocto ?= "beaglebone"

-SRCREV_machine_genericx86 ?= "9fc2fb2e73466a520ee9a3c48b3ca2f5b21415dc"
-SRCREV_machine_genericx86-64 ?= "9fc2fb2e73466a520ee9a3c48b3ca2f5b21415dc"
-SRCREV_machine_edgerouter ?= "9fc2fb2e73466a520ee9a3c48b3ca2f5b21415dc"
-SRCREV_machine_beaglebone-yocto ?= "9fc2fb2e73466a520ee9a3c48b3ca2f5b21415dc"
+SRCREV_machine_genericx86 ?= "eaeb8b7e17aaf93a3b727a51731b1c9a3916009f"
+SRCREV_machine_genericx86-64 ?= "eaeb8b7e17aaf93a3b727a51731b1c9a3916009f"
+SRCREV_machine_edgerouter ?= "eaeb8b7e17aaf93a3b727a51731b1c9a3916009f"
+SRCREV_machine_beaglebone-yocto ?= "eaeb8b7e17aaf93a3b727a51731b1c9a3916009f"

COMPATIBLE_MACHINE_genericx86 = "genericx86"
COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
COMPATIBLE_MACHINE_edgerouter = "edgerouter"
COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"

-LINUX_VERSION_genericx86 = "5.4.54"
-LINUX_VERSION_genericx86-64 = "5.4.54"
-LINUX_VERSION_edgerouter = "5.4.54"
-LINUX_VERSION_beaglebone-yocto = "5.4.54"
+LINUX_VERSION_genericx86 = "5.4.56"
+LINUX_VERSION_genericx86-64 = "5.4.56"
+LINUX_VERSION_edgerouter = "5.4.56"
+LINUX_VERSION_beaglebone-yocto = "5.4.56"
--
2.19.1

From: Bruce Ashfield <bruce.ashfield@...>

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
meta-poky/conf/distro/poky.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-poky/conf/distro/poky.conf b/meta-poky/conf/distro/poky.conf
index f2ee0d1877..826f0d633a 100644
--- a/meta-poky/conf/distro/poky.conf
+++ b/meta-poky/conf/distro/poky.conf
@@ -21,7 +21,7 @@ POKY_DEFAULT_EXTRA_RRECOMMENDS = "kernel-module-af-packet"

DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${POKY_DEFAULT_DISTRO_FEATURES}"

-PREFERRED_VERSION_linux-yocto ?= "5.4%"
+PREFERRED_VERSION_linux-yocto ?= "5.8%"

SDK_NAME = "${DISTRO}-${TCLIBC}-${SDKMACHINE}-${IMAGE_BASENAME}-${TUNE_PKGARCH}-${MACHINE}"
SDKPATH = "/opt/${DISTRO}/${SDK_VERSION}"
--
2.19.1

From: Bruce Ashfield <bruce.ashfield@...>

Richard,

Similar to oe-core, these are the patches I'm carrying to update the
reference BSPs to the latest 5.4 (we still need a 5.8 bbappend and
confirmed booting), as well as a switch to 5.8 as the default.

That being said, I'm not sure of the way you'd like the default kernel
set to differentiate between the reference BSPs and qemu. So currently,
I just have the single preferred version set.

Cheers,

Bruce

The following changes since commit c9d0bb421a2f7c6783f2c2bbf47c95da5537985d:

linux-yocto/5.8: update to v5.8.2 (2020-08-21 14:55:05 -0400)

are available in the Git repository at:

git://git.yoctoproject.org/poky-contrib zedd/kernel-yocto
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-yocto

Bruce Ashfield (3):
poky: set preferred version for linux-yocto to be v5.8
yocto-bsp: update to v5.4.56
yocto-bsp: update to v5.4.58

meta-poky/conf/distro/poky.conf | 2 +-
.../linux/linux-yocto_5.4.bbappend | 16 ++++++++--------
2 files changed, 9 insertions(+), 9 deletions(-)

--
2.19.1

Hi all,

I'm using Yocto warrior building a system based on NIVIDA tegra TX2i. My tree is using an external toolchain, gcc linaro 7.2.1 (specified through EXTERNAL_TOOLCHAIN variable in local.conf). I'm confused on setting up security flags.

In ,y local.conf, I have `GCCPIE ?= "--enable-default-pie"` enabled, but binaries built are not actually compiled with PIE not sure about PIC. I found out that this is due to the following condition in security_flags.inc:

```

# Inject pie flags into compiler flags if not configured with gcc itself

# especially useful with external toolchains

SECURITY_PIE_CFLAGS ?= "${@'' if '${GCCPIE}' else '-pie -fPIE'}"

```

So I tried to setup GCCPIE as `GCCPIE = ""`.  This actually includes `-pie -fPIE` in gcc, but then the build failed when building attr_2.4.47. The error messages are pretty long if anyone want to see it I will attach in a followup email.

My question is that is there a way to properly add PIE or at least PIC for Yocto Warrior with external toolchain?

Thanks
-Daniel

On Fri, Aug 21, 2020 at 8:30 AM Damien LEFEVRE <lefevre.da@...> wrote:

Hi,

I would need that to change the default location for the SDK install script to avoid mistakes with multiple SDKs and ease installations. How can I change the SDKPATH?

My distro includes conf/distro/poky.conf and I overwrite
SDKPATH = "/opt/${IMAGE_BASENAME}-${SDK_VERSION}-${DISTRO_CODENAME}-${MACHINE}"

You can't include IMAGE_BASENAME in SDKPATH because it's not known at
the time recipe are built; it's only defined when the final image is
created. I'm guessing that's the source of your error.

For reference, we do:

SDKPATH = "/opt/toolchains/${DISTRO}-${MACHINE}/${SDK_VERSION}"

and it works fine.

If I set SDKPATH to something other than /opt/${DISTRO}/${SDK_VERSION} , nativesdk-libgcc-initial fails some sanity test:
...
checking how to run the C preprocessor... x86_64-pokysdk-linux-gcc -E --sysroot=/data/yocto/zeus/build-jetson-xavier/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-libgcc-initial/7.3.0-r0/recipe-sysroot
configure: error: in `/data/yocto/zeus/build-jetson-xavier/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-libgcc-initial/7.3.0-r0/gcc-7.3.0/build.x86_64-pokysdk-linux.x86_64-pokysdk-linux/libgcc':
configure: error: C preprocessor "x86_64-pokysdk-linux-gcc -E --sysroot=/data/yocto/zeus/build-jetson-xavier/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-libgcc-initial/7.3.0-r0/recipe-sysroot " fails sanity check
See `config.log' for more details.
WARNING: exit code 1 from a shell command.
...

Thanks,
-Damien

This was repsonsible for some strange differences in behaviour between
other OE-Core recipes and this one. Its assumed this package is present
in any SDK build.

Signed-off-by: Richard Purdie <richard.purdie@...>
---
.../packagegroups/nativesdk-packagegroup-sdk-host.bbappend | 1 +
1 file changed, 1 insertion(+)

diff --git a/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend b/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend
index a9a51a6..b3ffb82 100644
--- a/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend
+++ b/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend
@@ -1,4 +1,5 @@
RDEPENDS_${PN}_mingw32 = "\
+ nativesdk-sdk-provides-dummy \
nativesdk-pkgconfig \
nativesdk-libtool \
nativesdk-qemu \
--
2.25.1

On Wed, Aug 19, 2020 at 3:08 AM MikeB <mabnhdev@...> wrote:

Reposting in the hopes of getting an answer - I'm stuck.

I'm in the process of upgrading from Zeus to Dunfell. For my MIPS platform, the library ABI version has changed from 0 to 5. I have some backward compatibility issues that require generating at least some libraries with ABI version 0. I've tried using -fabi_version=0 in my CCFLAGS, but that seems to be ignored. Can someone tell me how to set the ABI version back to 0 in my image and SDK?

I'm building for a custom MIPs platform running on a Cavium Octeon II in 32-bit mode.

TUNE_FEATURES = "o32 bigendian fpu-hard octeon2"

A current Dunfell shared library ELF Header looks like this:

ELF Header:
Magic: 7f 45 4c 46 01 02 01 00 05 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, big endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 5
Type: DYN (Shared object file)
Machine: MIPS R3000
Version: 0x1
Entry point address: 0x1630
Start of program headers: 52 (bytes into file)
Start of section headers: 22488 (bytes into file)
Flags: 0x808d1107, noreorder, pic, cpic, 32bitmode, octeon2, o32, mips64r2

The same library built with Zeus looks like this.

ELF Header:
Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, big endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: MIPS R3000
Version: 0x1
Entry point address: 0x1500
Start of program headers: 52 (bytes into file)
Start of section headers: 22340 (bytes into file)
Flags: 0x808d1107, noreorder, pic, cpic, 32bitmode, octeon2, o32, mips64r2

The ABI Version being the issue.

This is due to switching default hash style from sysv to gnu starting
dunfell. You can switch back to sysv either via LDFLAGS
or explicitly define

LINKER_HASH_STYLE_mipsarch = "sysv"

in your distro.

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

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

== attendees ==
Trevor Woerner, Stephen Jolley, Armin Kuster, Josef Holzmayr, Joshua Watt,
Tim Orling, Jan-Simon Möller, Mark Morton, Randy MacLeod, Alejandro,
Michael Halstead, Jeremy Puhlman, Richard Purdie, Scott Murray, Paul
Barker, Mark Asselstine, Martin Jansa (JaMa)

== notes ==
- 3.2-m2 released last week
- 3.0.4 (last of zeus) going through QA curruently (out in next day or so)
- sharp increase in AB bugs (intermittent)
- AUH upgrade script failed
- trying to drop fno-common scripts from gcc

== general ==
RP: trying to cleanup the fno-common vs not-common gcc patches, thanks Khem

RP: there has been good work to fix proper back tracing

RP: intermittent AB issues, got leads in some, struggling in others. not a lot
of people with which to discuss these (never mind fix)
Randy: we’ve been able to reproduce some of these on a different setup, but
not many
RP: i don’t think one needs to setup a clone of the AB in order to reproduce
these issues, simply run some of the builds (oe-selftest) with various
loads (cpu, I/O) on the rest of the system. Armin tried this and was able
to see them
Armin: and more, actually
(various): using a VM helps
Timo: point being, an idle system rarely shows any of these issues

Timo: did we fix the 500 issue?
MH: we definitely were able to fix the one SS reported
RP: i was able to find a reproducer over the weekend and gave it to SS, MH:
did you document/close the issue?
MH: i will

RP: for one of the tests, the solution seems to be to extend the timeout from
5s to 10s. we’ll see what failure rate we get at 10s

Armin: bind and dhcp. not sure if we want to replace things, or have things
co-exist
RP: going forward i think we’re going to switch over, so might as well bite
the bullet and switch

RP: speaking of compatibility… i pulled out the packaging code (PRserv and
hash equivalence) PRserv is deprecated in favour of hash equivalence

RP: we’re staying close to upstream thanks to AUH, please send out updates.
some packages still need manual maintenance (i.e. qemu)
Randy: did you create a defect for it? i can
RP: please do

Armin: future planning, since we have an LTS now, any benefit to plan for next
LTS? (i.e. bigger, larger changes)
JPEW: when is the next LTS
Armin: technically, in 3 more releases
SJ: so 3.5 or so
Paul: the longer the timeframe, the worse the predictions
Timo: chance some features will not get the testing they would otherwise
RP: historically we’ve experimented with different release cycles, causes
too much load for some releases, “stampeding herd” effect for
patches/QA. our current system seems to be the “happy medium”
Armin: i wasn’t proposing to change the milestones or the current release
system
Paul: i think the proposed features page on the wiki is probably the best
place to look (https://wiki.yoctoproject.org/wiki/Future_Directions)
RP: or bring it up with the TSC. we’re struggling more with contributors
rather than planning. we could fill in the target milestones better in the
bugzilla (talk to MH to get more added)

Paul: what are you proposing for the process to modify that page?
RP: probably best to discuss on ml before simply updating the page, the list
is of things that have already been vetted by the TSC. do you have any
ideas?

Paul: LF core infrastructure list of “best practices”
(https://bestpractices.coreinfrastructure.org/en/projects?q=yocto)
RP: we’ve taken a look at that already, we have a badge! e.g. need to run
pylint, has been added (now someone has to look at the results)
Armin: we don’t advertise that we have the badge, we should put it on the
website somewhere
Randy: i’d like to know more about the pylint
RP: just used in a couple places for now, want to add more later. lots of
output, we don’t care about some things. we need a profile to teach the
linter what things are “don’t care” (e.g. line length)
Timo: looked at some of the linting stuff Conrad (Siemens?) was doing
RP: Ross and I looked at some of the linter output and it does catch some good
things. the future directions page needs to be advertised more
Paul: can’t figure out which things are YP vs OE
RP: depends on which TSC discusses it
Timo: hard to figure out how people can find things

RP: docs, have been working on the version selection stuff, updating links to
point to “read the docs” links
Randy: is the Sphinx stuff visible yet?
RP: not quite, see the status updates on the docs ml
Randy: need to subscribe
RP: seems we need more mailing lists (e.g. AB output). naming is the issue
Timo: 7 people → 10 suggestions

RP: any thoughts on an AB list. a list for AB patches. “yocto-autobuilder”?
Armin: sounds fine
RP: needs to be better than “yocto-builds”, which is too ambiguous
TrevorW: maybe add “-dev” to the name?
RP: seems there’s more problems adding “-dev” and separating the people
into “developers” vs “users”
Armin: just don’t use AB to refer to it! (i.e. advisory board vs autobuilder)
Timo: and not let the names get too long

Hi all,

 

I’m trying to fech packages and dependencies from a nmp-shrinkwrap.json file but I get next error:

 

                npm-shrinkwrap.json' has invalid parameters. Unsupported dependency: arr-flatten

I don't know but you'll get more people on the main yocto list so I've replied there.

People often mistakenly use yocto-builds so we're going to drop that list at some point.

../Randy

 

The fragment of shrinkwrap file is

 

 

{

  "name": "Gateway_node_webserver",

  "version": "2.5.0",

  "lockfileVersion": 1,

  "requires": true,

  "dependencies": {

    "chokidar": {

      "version": "1.0.6",

      "requires": {

        "anymatch": "1.3.2",

        "arrify": "1.0.1",

        "async-each": "0.1.6",

        "glob-parent": "1.3.0",

        "is-binary-path": "1.0.1",

        "is-glob": "1.1.3",

        "path-is-absolute": "1.0.1",

        "readdirp": "1.4.0"

      },

      "dependencies": {

        "anymatch": {

          "version": "1.3.2",

          "requires": {

            "micromatch": "2.3.11",

            "normalize-path": "2.1.1"

          },

          "dependencies": {

            "micromatch": {

              "version": "2.3.11",

              "requires": {

                "arr-diff": "2.0.0",

                "array-unique": "0.2.1",

                "braces": "1.8.5",

                "expand-brackets": "0.1.5",

                "extglob": "0.3.2",

                "filename-regex": "2.0.1",

                "is-extglob": "1.0.0",

                "is-glob": "2.0.1",

                "kind-of": "3.2.2",

                "normalize-path": "2.1.1",

                "object.omit": "2.0.1",

                "parse-glob": "3.0.4",

                "regex-cache": "0.4.4"

              },

              "dependencies": {

                "arr-diff": {

                  "version": "2.0.0",

                  "requires": {

                    "arr-flatten": "1.1.0"

                  },

                  "dependencies": {

                    "arr-flatten": {

                      "version": "1.1.0"

                    }

                  }

                },

                "array-unique": {

                  "version": "0.2.1"

                },

 

 

The recipe SRC_URI is :

 

SRC_URI = " \

           npmsw://${THISDIR}/${PN}/npm-shrinkwrap.json \

           "

 

Any idea why is failing the fetch?

 

Regards.

-- 
# Randy MacLeod
# Wind River Linux

On Wed, 2020-08-19 at 09:09 +0000, Jain, Sangeeta wrote:

This is the full report for yocto-3.0.4.rc1:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

======= Summary ========
No high milestone defects.
No new defects are found in this cycle.

Thanks Sangeeta and team!

Cheers,

Richard

Reposting in the hopes of getting an answer - I'm stuck.

I'm in the process of upgrading from Zeus to Dunfell.  For my MIPS platform, the library ABI version has changed from 0 to 5.  I have some backward compatibility issues that require generating at least some libraries with ABI version 0.  I've tried using -fabi_version=0 in my CCFLAGS, but that seems to be ignored.  Can someone tell me how to set the ABI version back to 0 in my image and SDK?

I'm building for a custom MIPs platform running on a Cavium Octeon II in 32-bit mode.

TUNE_FEATURES  = "o32 bigendian fpu-hard octeon2"

A current Dunfell shared library ELF Header looks like this:


Thanks.

Hello all,

This is the full report for yocto-3.0.4.rc1:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

======= Summary ========
No high milestone defects.
No new defects are found in this cycle.

Thanks,
Sangeeta

On 2020-08-17 6:59 p.m., Khem Raj wrote:

did you look at
https://github.com/kraj/meta-openwrt/blob/master/recipes-networking/ipset/ipset_6.38.bb

And do you know about the layer index:
https://layers.openembedded.org/layerindex/branch/master/recipes/?q=ipset

../Randy

On Mon, Aug 17, 2020 at 10:14 AM Rob Prowel <rprowel@...> wrote:

I'm trying to add the ipset utility to my arm build so that I can group
IP/ports for use in tc and netfilter. I was able to update the vendor
supplied iptools2 recipe to install tc and iptables, but ipset is a
fresh recipe, not included in another existing layer.

I'm adding the following in its bb file:

# -----------------------------------------------------------------
SRC_URI = "file://ipset-7.6.tar.bz2"
SRC_URI[md5sum] = "3a6f5952fd1bcf0eefb9c7c087acbfc9"


inherit pkgconfig

S = "${WORKDIR}/ipset-7.6"

RDEPENDS_${PN} += "libmnl"

FILES_${PN} = ""
# list will be populated once I know what the package wants to install

do_configure(){
./configure --prefix=/ --host=arm-linuxeabi
}

do_compile(){
make DESTDIR=${D}
}

do_install(){
oe_runmake install DESTDIR=${D}
}

# -----------------------------------------------------------------

problem is that it depends on libmnl (which already exists as a lower
layer recipe), and the ipset configure script barfs on pkg-config with
the following message.

| checking whether ln -s works... yes
| checking for libmnl... no
| configure: error: Package requirements (libmnl >= 1) were not met:
|
| No package 'libmnl' found
|
| Consider adjusting the PKG_CONFIG_PATH environment variable if you
| installed software in a non-standard prefix.
|
| Alternatively, you may set the environment variables libmnl_CFLAGS
| and libmnl_LIBS to avoid the need to call pkg-config.
| See the pkg-config man page for more details.
| WARNING: exit code 1 from a shell command.


the PKG_CONFIG_PATH variable seems correct under devshell, but there is
no libmnl.pc file in there. How do I force libmnl to create and stage a
proper pkg-config .pc file where it needs to be?

--
# Randy MacLeod
# Wind River Linux