Re: [OE-core] [PATCH] kernel: Commit without running hooks
On Fri, Oct 27, 2023 at 3:08 AM Luca Ceresoli wrote: > > Hello William, > > On Wed, 25 Oct 2023 15:37:10 -0700 > "William A. Kennington III via lists.openembedded.org" > wrote: > ^ > > As you can see your sender address has been mangled, and as a result > the patch is rejected by the the openembedded git server. This is not > your fault, but we need you to modify your git configuration to prevent > this from happening in the future. Have a look at the Contributor Guide > for more info: > > https://docs.yoctoproject.org/contributor-guide/submit-changes.html#fixing-your-from-identity Ah interesting, I didn't know there was a missing setting and assumed it was our special mail server config that always caused the issue. > > I'm taking your patch for testing on the autobuilders, fixing it > manually so you don't need to resend your patch this time. > > Best regards, > Luca > > -- > Luca Ceresoli, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189754): https://lists.openembedded.org/g/openembedded-core/message/189754 Mute This Topic: https://lists.openembedded.org/mt/102189231/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] kernel: Commit without running hooks
On Wed, Oct 25, 2023 at 7:08 PM Bruce Ashfield wrote:
>
> On Wed, Oct 25, 2023 at 6:37 PM William A. Kennington III via
> lists.openembedded.org wrote:
> >
> > The hooks are pulled from the impure environment and are often broken in
> > our environments. There is no reason to add extra metadata or verify the
> > commit message as its arbitrary to turn the tarball into a git repo.
>
> But what about the other uses of git ? If the hooks are broken during
> the creation step, other uses of git should also be broken.
The only time hooks are run is for `git commit`. AFAIK our build
process has no other invocations of `git commit`. All other git
operations work fine.
>
> We've had the ability to check the git config for quite some time, we
> could take it further an inhibit the use of the host config if we are
> worried about breakage like this.
Maybe this would be the best idea overall for our git support inside
the build system, avoiding the build user global git config. That
probably solves the issue we generally have. I'm okay either way.
>
> Bruce
>
> >
> > Signed-off-by: William A. Kennington III
> > ---
> > meta/classes-recipe/kernel-yocto.bbclass | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/classes-recipe/kernel-yocto.bbclass
> > b/meta/classes-recipe/kernel-yocto.bbclass
> > index 4ac977b122..cb9cd26b09 100644
> > --- a/meta/classes-recipe/kernel-yocto.bbclass
> > +++ b/meta/classes-recipe/kernel-yocto.bbclass
> > @@ -408,7 +408,7 @@ do_kernel_checkout() {
> > git init
> > check_git_config
> > git add .
> > - git commit -q -m "baseline commit: creating repo for
> > ${PN}-${PV}"
> > + git commit -q -n -m "baseline commit: creating repo for
> > ${PN}-${PV}"
> > git clean -d -f
> > fi
> >
> > --
> > 2.42.0.820.g83a721a137-goog
> >
> >
> >
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189710):
https://lists.openembedded.org/g/openembedded-core/message/189710
Mute This Topic: https://lists.openembedded.org/mt/102189231/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] kernel: Commit without running hooks
The hooks are pulled from the impure environment and are often broken in
our environments. There is no reason to add extra metadata or verify the
commit message as its arbitrary to turn the tarball into a git repo.
Signed-off-by: William A. Kennington III
---
meta/classes-recipe/kernel-yocto.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes-recipe/kernel-yocto.bbclass
b/meta/classes-recipe/kernel-yocto.bbclass
index 4ac977b122..cb9cd26b09 100644
--- a/meta/classes-recipe/kernel-yocto.bbclass
+++ b/meta/classes-recipe/kernel-yocto.bbclass
@@ -408,7 +408,7 @@ do_kernel_checkout() {
git init
check_git_config
git add .
- git commit -q -m "baseline commit: creating repo for
${PN}-${PV}"
+ git commit -q -n -m "baseline commit: creating repo for
${PN}-${PV}"
git clean -d -f
fi
--
2.42.0.820.g83a721a137-goog
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189694):
https://lists.openembedded.org/g/openembedded-core/message/189694
Mute This Topic: https://lists.openembedded.org/mt/102189231/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] rootfs-postcommands: Make /etc/timestamp consistent with image
On Mon, Aug 29, 2022 at 5:19 PM Mark Hatle
wrote:
>
>
> On 8/29/22 6:59 PM, William A. Kennington III via lists.openembedded.org
> wrote:
> > This makes the determination of the timestamp for the /etc/timestamp
> > file consistent with mtimes in the generated image. This is desirable to
> > make the built image reproducible with the git commit date instead of
> > the current date.
>
> This is only going to pay attention to poky, or oe-core... the rootfs
> will vary
> with a change to ANY layer in the system.
Yes, this is what I expect. It is following the same behavior as
image.bbclass.
> If you really want to be consistent you would need to iterate over all of
> the
> layers and look at every file in the system for the timestamp (or if
> they're git
> repositories last commit in each layer..)
>
>
I'm just looking for consistency with the image generation side of things
that set the timestamp based on the same logic flow. It's weird that they
used different logic for setting timestamps in the output image. Sure we
could improve the most recent timestamp by looking at all the git repos of
all the meta layers, but that's not the point of this change.
> All of this doesn't seem like it really makes sense to me which is why a
> static
> timestamp was defined previously.
>
That's fine too, we just want our builds to have reasonably recent
timestamps that are deterministic when REPRODUCIBLE_TIMESTAMP_ROOTFS is
unset.
>
> (with the previous change to the time stamps, I've had more then one user
> get
> concerned they were 'using old software' when they just built something
> from
> scratch -- this will get even more confusing if it's only based on the
> oe-core/poky repository.)
>
> --Mark
>
> > Change-Id: I7d9fe32906aa93baf53948aa40b7a98fb05dd384
> > Signed-off-by: William A. Kennington III
> > ---
> > meta/classes-recipe/rootfs-postcommands.bbclass | 12 +++-
> > 1 file changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/meta/classes-recipe/rootfs-postcommands.bbclass
> b/meta/classes-recipe/rootfs-postcommands.bbclass
> > index 215e38e33d..8d710186d7 100644
> > --- a/meta/classes-recipe/rootfs-postcommands.bbclass
> > +++ b/meta/classes-recipe/rootfs-postcommands.bbclass
> > @@ -312,12 +312,14 @@ python write_image_manifest () {
> > # Can be used to create /etc/timestamp during image construction to
> give a reasonably
> > # sane default time setting
> > rootfs_update_timestamp () {
> > - if [ "${REPRODUCIBLE_TIMESTAMP_ROOTFS}" != "" ]; then
> > - # Convert UTC into %4Y%2m%2d%2H%2M%2S
> > - sformatted=`date -u -d @${REPRODUCIBLE_TIMESTAMP_ROOTFS}
> +%4Y%2m%2d%2H%2M%2S`
> > - else
> > - sformatted=`date -u +%4Y%2m%2d%2H%2M%2S`
> > + if [ "$REPRODUCIBLE_TIMESTAMP_ROOTFS" = "" ]; then
> > + REPRODUCIBLE_TIMESTAMP_ROOTFS=`git -C "${COREBASE}" log -1
> --pretty=%ct 2>/dev/null` || true
> > + if [ "$REPRODUCIBLE_TIMESTAMP_ROOTFS" = "" ]; then
> > + REPRODUCIBLE_TIMESTAMP_ROOTFS=`stat -c%Y
> ${@bb.utils.which(d.getVar("BBPATH"), "conf/bitbake.conf")}`
> > + fi
> > fi
> > + # Convert UTC into %4Y%2m%2d%2H%2M%2S
> > + sformatted=`date -u -d @${REPRODUCIBLE_TIMESTAMP_ROOTFS}
> +%4Y%2m%2d%2H%2M%2S`
> > echo $sformatted > ${IMAGE_ROOTFS}/etc/timestamp
> > bbnote "rootfs_update_timestamp: set /etc/timestamp to $sformatted"
> > }
> >
> >
> >
> >
> >
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170043):
https://lists.openembedded.org/g/openembedded-core/message/170043
Mute This Topic: https://lists.openembedded.org/mt/93339153/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] rootfs-postcommands: Make /etc/timestamp consistent with image
This makes the determination of the timestamp for the /etc/timestamp
file consistent with mtimes in the generated image. This is desirable to
make the built image reproducible with the git commit date instead of
the current date.
Change-Id: I7d9fe32906aa93baf53948aa40b7a98fb05dd384
Signed-off-by: William A. Kennington III
---
meta/classes-recipe/rootfs-postcommands.bbclass | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/meta/classes-recipe/rootfs-postcommands.bbclass
b/meta/classes-recipe/rootfs-postcommands.bbclass
index 215e38e33d..8d710186d7 100644
--- a/meta/classes-recipe/rootfs-postcommands.bbclass
+++ b/meta/classes-recipe/rootfs-postcommands.bbclass
@@ -312,12 +312,14 @@ python write_image_manifest () {
# Can be used to create /etc/timestamp during image construction to give a
reasonably
# sane default time setting
rootfs_update_timestamp () {
- if [ "${REPRODUCIBLE_TIMESTAMP_ROOTFS}" != "" ]; then
- # Convert UTC into %4Y%2m%2d%2H%2M%2S
- sformatted=`date -u -d @${REPRODUCIBLE_TIMESTAMP_ROOTFS}
+%4Y%2m%2d%2H%2M%2S`
- else
- sformatted=`date -u +%4Y%2m%2d%2H%2M%2S`
+ if [ "$REPRODUCIBLE_TIMESTAMP_ROOTFS" = "" ]; then
+ REPRODUCIBLE_TIMESTAMP_ROOTFS=`git -C "${COREBASE}" log -1
--pretty=%ct 2>/dev/null` || true
+ if [ "$REPRODUCIBLE_TIMESTAMP_ROOTFS" = "" ]; then
+ REPRODUCIBLE_TIMESTAMP_ROOTFS=`stat -c%Y
${@bb.utils.which(d.getVar("BBPATH"), "conf/bitbake.conf")}`
+ fi
fi
+ # Convert UTC into %4Y%2m%2d%2H%2M%2S
+ sformatted=`date -u -d @${REPRODUCIBLE_TIMESTAMP_ROOTFS}
+%4Y%2m%2d%2H%2M%2S`
echo $sformatted > ${IMAGE_ROOTFS}/etc/timestamp
bbnote "rootfs_update_timestamp: set /etc/timestamp to $sformatted"
}
--
2.37.2.672.g94769d06f0-goog
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170041):
https://lists.openembedded.org/g/openembedded-core/message/170041
Mute This Topic: https://lists.openembedded.org/mt/93339153/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] image_types: Set SOURCE_DATE_EPOCH for squashfs
We want to use the reproducible timestamp for all of the files that is
set rootfs-postcommands.bbclass, derived from
REPRODUCIBLE_TIMESTAMP_ROOTFS. Without this, we use a hardcoded time
that is built into the squashfs sources.
Signed-off-by: William A. Kennington III
---
meta/classes-recipe/image_types.bbclass | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/meta/classes-recipe/image_types.bbclass
b/meta/classes-recipe/image_types.bbclass
index a731e585b2..764e6a5574 100644
--- a/meta/classes-recipe/image_types.bbclass
+++ b/meta/classes-recipe/image_types.bbclass
@@ -109,11 +109,19 @@ IMAGE_CMD:btrfs () {
mkfs.btrfs ${EXTRA_IMAGECMD} -r ${IMAGE_ROOTFS}
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.btrfs
}
-IMAGE_CMD:squashfs = "mksquashfs ${IMAGE_ROOTFS}
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs ${EXTRA_IMAGECMD}
-noappend"
-IMAGE_CMD:squashfs-xz = "mksquashfs ${IMAGE_ROOTFS}
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-xz ${EXTRA_IMAGECMD}
-noappend -comp xz"
-IMAGE_CMD:squashfs-lzo = "mksquashfs ${IMAGE_ROOTFS}
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-lzo
${EXTRA_IMAGECMD} -noappend -comp lzo"
-IMAGE_CMD:squashfs-lz4 = "mksquashfs ${IMAGE_ROOTFS}
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-lz4
${EXTRA_IMAGECMD} -noappend -comp lz4"
-IMAGE_CMD:squashfs-zst = "mksquashfs ${IMAGE_ROOTFS}
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-zst
${EXTRA_IMAGECMD} -noappend -comp zstd"
+oe_mksquashfs () {
+local comp=$1
+local suffix=$2
+
+# Use the bitbake reproducible timestamp instead of the hardcoded squashfs
one
+export SOURCE_DATE_EPOCH=$(stat -c '%Y' ${IMAGE_ROOTFS})
+mksquashfs ${IMAGE_ROOTFS}
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs${comp:+-}${suffix:-$comp}
${EXTRA_IMAGECMD} -noappend ${comp:+-comp }$comp
+}
+IMAGE_CMD:squashfs = "oe_mksquashfs"
+IMAGE_CMD:squashfs-xz = "oe_mksquashfs xz"
+IMAGE_CMD:squashfs-lzo = "oe_mksquashfs lzo"
+IMAGE_CMD:squashfs-lz4 = "oe_mksquashfs lz4"
+IMAGE_CMD:squashfs-zst = "oe_mksquashfs zstd zst"
IMAGE_CMD:erofs = "mkfs.erofs ${EXTRA_IMAGECMD}
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.erofs ${IMAGE_ROOTFS}"
IMAGE_CMD:erofs-lz4 = "mkfs.erofs -zlz4 ${EXTRA_IMAGECMD}
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.erofs-lz4 ${IMAGE_ROOTFS}"
--
2.37.2.672.g94769d06f0-goog
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170040):
https://lists.openembedded.org/g/openembedded-core/message/170040
Mute This Topic: https://lists.openembedded.org/mt/93338404/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] rng-tools: disable libjitterentropy due to cpu usage
Isn't this desirable if you don't have an hwrng? We want to generate entropy so we can perform cryptographic operations by default if we bring in rng-tools. On Mon, May 2, 2022 at 2:10 PM Wes Malone wrote: > > After boot rngd maxes out the processor initializing JITTER entropy for > some minutes. Here we disable libjitterentropy in favor of only using > the hardware random source via config. > > Signed-off-by: Wes Malone > --- > meta/recipes-support/rng-tools/rng-tools_6.15.bb | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/meta/recipes-support/rng-tools/rng-tools_6.15.bb > b/meta/recipes-support/rng-tools/rng-tools_6.15.bb > index 0696351903..4eed060960 100644 > --- a/meta/recipes-support/rng-tools/rng-tools_6.15.bb > +++ b/meta/recipes-support/rng-tools/rng-tools_6.15.bb > @@ -21,7 +21,6 @@ inherit autotools update-rc.d systemd pkgconfig > > EXTRA_OECONF = "--without-rtlsdr" > > -PACKAGECONFIG ??= "libjitterentropy" > PACKAGECONFIG:libc-musl = "libargp libjitterentropy" > > PACKAGECONFIG[libargp] = "--with-libargp,--without-libargp,argp-standalone," > -- > 2.36.0 > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#165177): https://lists.openembedded.org/g/openembedded-core/message/165177 Mute This Topic: https://lists.openembedded.org/mt/90845997/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH] rm_work.bbclass: Fix for files starting with -
This makes it possible to name files starting with a hyphen in the work
directory. Without this change rm will fail due to an unexpected option
being passed.
Signed-off-by: William A. Kennington III
---
meta/classes/rm_work.bbclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/classes/rm_work.bbclass b/meta/classes/rm_work.bbclass
index 07901d7597..5f12d5aaeb 100644
--- a/meta/classes/rm_work.bbclass
+++ b/meta/classes/rm_work.bbclass
@@ -73,7 +73,7 @@ do_rm_work () {
# sstate version since otherwise we'd need to leave 'plaindirs'
around
# such as 'packages' and 'packages-split' and these can be large.
No end
# of chain tasks depend directly on do_package anymore.
-rm -f $i;
+rm -f -- $i;
;;
*_setscene*)
# Skip stamps which are already setscene versions
@@ -90,7 +90,7 @@ do_rm_work () {
;;
esac
done
-rm -f $i
+rm -f -- $i
esac
done
@@ -100,9 +100,9 @@ do_rm_work () {
# Retain only logs and other files in temp, safely ignore
# failures of removing pseudo folers on NFS2/3 server.
if [ $dir = 'pseudo' ]; then
-rm -rf $dir 2> /dev/null || true
+rm -rf -- $dir 2> /dev/null || true
elif ! echo "$excludes" | grep -q -w "$dir"; then
-rm -rf $dir
+rm -rf -- $dir
fi
done
}
--
2.33.0.685.g46640cef36-goog
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156402):
https://lists.openembedded.org/g/openembedded-core/message/156402
Mute This Topic: https://lists.openembedded.org/mt/85912333/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [V2][PATCH] libjpeg-turbo: fix do_compile error on armv5
Btw, I'm hoping upstream will fix this for all arm
https://github.com/libjpeg-turbo/libjpeg-turbo/issues/523
On Wed, Jun 9, 2021 at 12:32 AM Changqing Li wrote:
>
> From: Changqing Li
>
> fix below error:
> /include/arm_neon.h:31:2: error: #error "NEON intrinsics not available with
> the soft-float ABI. Please use -mfloat-abi=softfp or -mfloat-abi=hard"
> 31 | #error "NEON intrinsics not available with the soft-float ABI. Please
> use -mfloat-abi=softfp or -mfloat-abi=hard"
>
> Neon is not supported by armv5, disable the simd extension build.
>
> Signed-off-by: Changqing Li
> ---
> meta/recipes-graphics/jpeg/libjpeg-turbo_2.1.0.bb | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-graphics/jpeg/libjpeg-turbo_2.1.0.bb
> b/meta/recipes-graphics/jpeg/libjpeg-turbo_2.1.0.bb
> index 7f91cc02ac..da21971113 100644
> --- a/meta/recipes-graphics/jpeg/libjpeg-turbo_2.1.0.bb
> +++ b/meta/recipes-graphics/jpeg/libjpeg-turbo_2.1.0.bb
> @@ -40,6 +40,8 @@ EXTRA_OECMAKE_append_class-target = "
> ${@bb.utils.contains("TUNE_FEATURES", "mx3
> # Work around missing non-floating point ABI support in MIPS
> EXTRA_OECMAKE_append_class-target = " ${@bb.utils.contains("MIPSPKGSFX_FPU",
> "-nf", "-DWITH_SIMD=False", "", d)}"
>
> +EXTRA_OECMAKE_append_class-target = " ${@ ('') if
> (d.getVar('TUNE_CCARGS_MFPU') != '') else '-DWITH_SIMD=False'}"
> +
> # Provide a workaround if Altivec unit is not present in PPC
> EXTRA_OECMAKE_append_class-target_powerpc = "
> ${@bb.utils.contains("TUNE_FEATURES", "altivec", "", "-DWITH_SIMD=False", d)}"
> EXTRA_OECMAKE_append_class-target_powerpc64 = "
> ${@bb.utils.contains("TUNE_FEATURES", "altivec", "", "-DWITH_SIMD=False", d)}"
> --
> 2.17.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#152800):
https://lists.openembedded.org/g/openembedded-core/message/152800
Mute This Topic: https://lists.openembedded.org/mt/83415559/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH 1/2] systemd: Fix static neighbor creation in networkd
It would be nice, but it was non-trivial so I opted to go this path
first. These patches can be dropped once v248.2 is brought in.
On Tue, May 18, 2021 at 2:26 AM Alexander Kanavin
wrote:
>
> At this point it might be better to update systemd itself to 248?
>
> Alex
>
> On Tue, 18 May 2021 at 00:51, William A. Kennington III via
> lists.openembedded.org wrote:
>>
>> Backport a patch to fix the creation of static neighbors.
>>
>> Signed-off-by: William A. Kennington III
>> ---
>> ...or-Always-add-neighbors-with-replace.patch | 50 +++
>> meta/recipes-core/systemd/systemd_247.6.bb| 1 +
>> 2 files changed, 51 insertions(+)
>> create mode 100644
>> meta/recipes-core/systemd/systemd/0001-network-neighbor-Always-add-neighbors-with-replace.patch
>>
>> diff --git
>> a/meta/recipes-core/systemd/systemd/0001-network-neighbor-Always-add-neighbors-with-replace.patch
>>
>> b/meta/recipes-core/systemd/systemd/0001-network-neighbor-Always-add-neighbors-with-replace.patch
>> new file mode 100644
>> index 00..5593c3f479
>> --- /dev/null
>> +++
>> b/meta/recipes-core/systemd/systemd/0001-network-neighbor-Always-add-neighbors-with-replace.patch
>> @@ -0,0 +1,50 @@
>> +From faa0f758bc2f194d63bbed6e7f91df176f594a06 Mon Sep 17 00:00:00 2001
>> +From: "William A. Kennington III"
>> +Date: Tue, 27 Apr 2021 01:25:58 -0700
>> +Subject: [PATCH] network: neighbor: Always add neighbors with replace
>> +
>> +We were duplicating setting flags for the message and a combination of
>> +NLM_F_APPEND and NLM_F_CREATE which does not make sense. We should have
>> +been using NLM_F_REPLACE and NLM_F_CREATE since the kernel can
>> +dynamically create neighbors prior to us adding an entry. Otherwise, we
>> +can end up with cases where the message will time out after ~25s even
>> +though the neighbor still gets added. This delays the rest of the setup
>> +of the interface even though the error is ultimately ignored.
>> +
>> +Upstream-Status: Backport
>> [https://github.com/systemd/systemd/commit/192a9d95ea3e058afd824d38a9cea16ad0a84a57]
>> +---
>> + src/libsystemd/sd-netlink/rtnl-message.c | 2 +-
>> + src/network/networkd-neighbor.c | 4
>> + 2 files changed, 1 insertion(+), 5 deletions(-)
>> +
>> +diff --git a/src/libsystemd/sd-netlink/rtnl-message.c
>> b/src/libsystemd/sd-netlink/rtnl-message.c
>> +index 4cabbabba6..c9d0c9b1e7 100644
>> +--- a/src/libsystemd/sd-netlink/rtnl-message.c
>> b/src/libsystemd/sd-netlink/rtnl-message.c
>> +@@ -445,7 +445,7 @@ int sd_rtnl_message_new_neigh(sd_netlink *rtnl,
>> sd_netlink_message **ret, uint16
>> + return r;
>> +
>> + if (nlmsg_type == RTM_NEWNEIGH)
>> +-(*ret)->hdr->nlmsg_flags |= NLM_F_CREATE | NLM_F_APPEND;
>> ++(*ret)->hdr->nlmsg_flags |= NLM_F_CREATE | NLM_F_REPLACE;
>> +
>> + ndm = NLMSG_DATA((*ret)->hdr);
>> +
>> +diff --git a/src/network/networkd-neighbor.c
>> b/src/network/networkd-neighbor.c
>> +index c805d52cf3..adce055009 100644
>> +--- a/src/network/networkd-neighbor.c
>> b/src/network/networkd-neighbor.c
>> +@@ -259,10 +259,6 @@ static int neighbor_configure(Neighbor *neighbor, Link
>> *link) {
>> + if (r < 0)
>> + return log_link_error_errno(link, r, "Could not set state:
>> %m");
>> +
>> +-r = sd_netlink_message_set_flags(req, NLM_F_REQUEST | NLM_F_ACK |
>> NLM_F_CREATE | NLM_F_REPLACE);
>> +-if (r < 0)
>> +-return log_link_error_errno(link, r, "Could not set flags:
>> %m");
>> +-
>> + r = sd_netlink_message_append_data(req, NDA_LLADDR,
>> >lladdr, neighbor->lladdr_size);
>> + if (r < 0)
>> + return log_link_error_errno(link, r, "Could not append
>> NDA_LLADDR attribute: %m");
>> +--
>> +2.31.1.498.g6c1eba8ee3d-goog
>> +
>> diff --git a/meta/recipes-core/systemd/systemd_247.6.bb
>> b/meta/recipes-core/systemd/systemd_247.6.bb
>> index ce6ac7ebaa..fb4acf2d37 100644
>> --- a/meta/recipes-core/systemd/systemd_247.6.bb
>> +++ b/meta/recipes-core/systemd/systemd_247.6.bb
>> @@ -27,6 +27,7 @@ SRC_URI += "file://touchscreen.rules \
>>
>> file://0001-logind-Restore-chvt-as-non-root-user-without-polkit.patch \
>>
>> file://0027-proc-dont-trigger-mount-error-with-invalid-options-o.patch \
>>
[OE-core][PATCH 2/2] systemd: Fix networkd failing links with loopback RAs
Backport a patch to situations where the current node receives an RA
packet from itself, which triggers systemd-networkd to put the link into
a failed state which turns off internal RA functionality.
Signed-off-by: William A. Kennington III
---
...le-ignoring-ll-gateway-being-link-ll.patch | 68 +++
meta/recipes-core/systemd/systemd_247.6.bb| 1 +
2 files changed, 69 insertions(+)
create mode 100644
meta/recipes-core/systemd/systemd/0001-networkd-handle-ignoring-ll-gateway-being-link-ll.patch
diff --git
a/meta/recipes-core/systemd/systemd/0001-networkd-handle-ignoring-ll-gateway-being-link-ll.patch
b/meta/recipes-core/systemd/systemd/0001-networkd-handle-ignoring-ll-gateway-being-link-ll.patch
new file mode 100644
index 00..47e81a6c38
--- /dev/null
+++
b/meta/recipes-core/systemd/systemd/0001-networkd-handle-ignoring-ll-gateway-being-link-ll.patch
@@ -0,0 +1,68 @@
+From 40c6396bfd1e83f80dde31f4886bb1dbf155012d Mon Sep 17 00:00:00 2001
+From: Devon Pringle
+Date: Mon, 14 Dec 2020 14:22:18 +1000
+Subject: [PATCH] networkd: handle ignoring ll gateway being link ll
+
+In the event where network discovery gets a route with the gateway being
+the interfaces local link address, networkd will fail the interface.
+
+systemd-networkd[44319]: br_lan: Configuring route: dst:
fdcd:41a4:5559:ec03::/64, src: n/a, gw: fe80::e4da:7eff:fe77:5c5e, prefsrc:
n/a, scope: global, table: main, proto: ra, type: unicast
+systemd-networkd[44319]: br_lan: Could not set NDisc route or address: Gateway
can not be a local address. Invalid argument
+systemd-networkd[44319]: br_lan: Failed
+systemd-networkd[44319]: br_lan: State changed: configuring -> failed
+
+This patch, instead of allowing the interface to fail, will instead log
+the event and skip setting the route.
+
+Upstream-Status: Backport
[https://github.com/systemd/systemd/commit/221019166f315252304b3459902ead613b905de5]
+---
+ src/network/networkd-ndisc.c | 16 +---
+ 1 file changed, 13 insertions(+), 3 deletions(-)
+
+diff --git a/src/network/networkd-ndisc.c b/src/network/networkd-ndisc.c
+index d2aa3db175..41591900e9 100644
+--- a/src/network/networkd-ndisc.c
b/src/network/networkd-ndisc.c
+@@ -820,7 +820,7 @@ static int ndisc_router_process_onlink_prefix(Link *link,
sd_ndisc_router *rt) {
+
+ static int ndisc_router_process_route(Link *link, sd_ndisc_router *rt) {
+ _cleanup_(route_freep) Route *route = NULL;
+-struct in6_addr gateway;
++union in_addr_union gateway;
+ uint32_t lifetime;
+ unsigned preference, prefixlen;
+ usec_t time_now;
+@@ -835,10 +835,20 @@ static int ndisc_router_process_route(Link *link,
sd_ndisc_router *rt) {
+ if (lifetime == 0)
+ return 0;
+
+-r = sd_ndisc_router_get_address(rt, );
++r = sd_ndisc_router_get_address(rt, );
+ if (r < 0)
+ return log_link_error_errno(link, r, "Failed to get gateway
address from RA: %m");
+
++if (address_exists(link, AF_INET6, )) {
++_cleanup_free_ char *buf = NULL;
++
++if (DEBUG_LOGGING) {
++(void) in_addr_to_string(AF_INET6, , );
++log_link_debug(link, "Advertised route gateway, %s,
is local to the link, ignoring route", strnull(buf));
++}
++return 0;
++}
++
+ r = sd_ndisc_router_route_get_prefixlen(rt, );
+ if (r < 0)
+ return log_link_error_errno(link, r, "Failed to get route
prefix length: %m");
+@@ -860,7 +870,7 @@ static int ndisc_router_process_route(Link *link,
sd_ndisc_router *rt) {
+ route->priority = link->network->dhcp6_route_metric;
+ route->protocol = RTPROT_RA;
+ route->pref = preference;
+-route->gw.in6 = gateway;
++route->gw.in6 = gateway.in6;
+ route->gw_family = AF_INET6;
+ route->dst_prefixlen = prefixlen;
+ route->lifetime = time_now + lifetime * USEC_PER_SEC;
+--
+2.31.1.607.g51e8a6a459-goog
+
diff --git a/meta/recipes-core/systemd/systemd_247.6.bb
b/meta/recipes-core/systemd/systemd_247.6.bb
index fb4acf2d37..dc04908922 100644
--- a/meta/recipes-core/systemd/systemd_247.6.bb
+++ b/meta/recipes-core/systemd/systemd_247.6.bb
@@ -28,6 +28,7 @@ SRC_URI += "file://touchscreen.rules \
file://0027-proc-dont-trigger-mount-error-with-invalid-options-o.patch \
file://0001-analyze-resolve-executable-path-if-it-is-relative.patch
\
file://0001-network-neighbor-Always-add-neighbors-with-replace.patch \
+ file://0001-networkd-handle-ignoring-ll-gateway-being-link-ll.patch
\
"
# patches needed by musl
--
2.31.1.751.gd2f1c929bd-goog
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#152014):
https://lists.openembedded.org/g/openembedded-core/message/152014
Mute This Topic:
[OE-core][PATCH 1/2] systemd: Fix static neighbor creation in networkd
Backport a patch to fix the creation of static neighbors.
Signed-off-by: William A. Kennington III
---
...or-Always-add-neighbors-with-replace.patch | 50 +++
meta/recipes-core/systemd/systemd_247.6.bb| 1 +
2 files changed, 51 insertions(+)
create mode 100644
meta/recipes-core/systemd/systemd/0001-network-neighbor-Always-add-neighbors-with-replace.patch
diff --git
a/meta/recipes-core/systemd/systemd/0001-network-neighbor-Always-add-neighbors-with-replace.patch
b/meta/recipes-core/systemd/systemd/0001-network-neighbor-Always-add-neighbors-with-replace.patch
new file mode 100644
index 00..5593c3f479
--- /dev/null
+++
b/meta/recipes-core/systemd/systemd/0001-network-neighbor-Always-add-neighbors-with-replace.patch
@@ -0,0 +1,50 @@
+From faa0f758bc2f194d63bbed6e7f91df176f594a06 Mon Sep 17 00:00:00 2001
+From: "William A. Kennington III"
+Date: Tue, 27 Apr 2021 01:25:58 -0700
+Subject: [PATCH] network: neighbor: Always add neighbors with replace
+
+We were duplicating setting flags for the message and a combination of
+NLM_F_APPEND and NLM_F_CREATE which does not make sense. We should have
+been using NLM_F_REPLACE and NLM_F_CREATE since the kernel can
+dynamically create neighbors prior to us adding an entry. Otherwise, we
+can end up with cases where the message will time out after ~25s even
+though the neighbor still gets added. This delays the rest of the setup
+of the interface even though the error is ultimately ignored.
+
+Upstream-Status: Backport
[https://github.com/systemd/systemd/commit/192a9d95ea3e058afd824d38a9cea16ad0a84a57]
+---
+ src/libsystemd/sd-netlink/rtnl-message.c | 2 +-
+ src/network/networkd-neighbor.c | 4
+ 2 files changed, 1 insertion(+), 5 deletions(-)
+
+diff --git a/src/libsystemd/sd-netlink/rtnl-message.c
b/src/libsystemd/sd-netlink/rtnl-message.c
+index 4cabbabba6..c9d0c9b1e7 100644
+--- a/src/libsystemd/sd-netlink/rtnl-message.c
b/src/libsystemd/sd-netlink/rtnl-message.c
+@@ -445,7 +445,7 @@ int sd_rtnl_message_new_neigh(sd_netlink *rtnl,
sd_netlink_message **ret, uint16
+ return r;
+
+ if (nlmsg_type == RTM_NEWNEIGH)
+-(*ret)->hdr->nlmsg_flags |= NLM_F_CREATE | NLM_F_APPEND;
++(*ret)->hdr->nlmsg_flags |= NLM_F_CREATE | NLM_F_REPLACE;
+
+ ndm = NLMSG_DATA((*ret)->hdr);
+
+diff --git a/src/network/networkd-neighbor.c b/src/network/networkd-neighbor.c
+index c805d52cf3..adce055009 100644
+--- a/src/network/networkd-neighbor.c
b/src/network/networkd-neighbor.c
+@@ -259,10 +259,6 @@ static int neighbor_configure(Neighbor *neighbor, Link
*link) {
+ if (r < 0)
+ return log_link_error_errno(link, r, "Could not set state:
%m");
+
+-r = sd_netlink_message_set_flags(req, NLM_F_REQUEST | NLM_F_ACK |
NLM_F_CREATE | NLM_F_REPLACE);
+-if (r < 0)
+-return log_link_error_errno(link, r, "Could not set flags:
%m");
+-
+ r = sd_netlink_message_append_data(req, NDA_LLADDR,
>lladdr, neighbor->lladdr_size);
+ if (r < 0)
+ return log_link_error_errno(link, r, "Could not append
NDA_LLADDR attribute: %m");
+--
+2.31.1.498.g6c1eba8ee3d-goog
+
diff --git a/meta/recipes-core/systemd/systemd_247.6.bb
b/meta/recipes-core/systemd/systemd_247.6.bb
index ce6ac7ebaa..fb4acf2d37 100644
--- a/meta/recipes-core/systemd/systemd_247.6.bb
+++ b/meta/recipes-core/systemd/systemd_247.6.bb
@@ -27,6 +27,7 @@ SRC_URI += "file://touchscreen.rules \
file://0001-logind-Restore-chvt-as-non-root-user-without-polkit.patch \
file://0027-proc-dont-trigger-mount-error-with-invalid-options-o.patch \
file://0001-analyze-resolve-executable-path-if-it-is-relative.patch
\
+
file://0001-network-neighbor-Always-add-neighbors-with-replace.patch \
"
# patches needed by musl
--
2.31.1.751.gd2f1c929bd-goog
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#152013):
https://lists.openembedded.org/g/openembedded-core/message/152013
Mute This Topic: https://lists.openembedded.org/mt/82899808/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] libxcb: Add inherit python3native
It's correct because the package it depends on (xcb-proto-native) is already `inherit python3native`. This package's xcbgen invocation is broken because it is using a combination of files generated for native python but executed through host python (look at the site-packages version). It can't bloat our dependency tree any more as it already implicitly depends on python3-native. On Wed, Apr 14, 2021 at 12:25 AM Alexander Kanavin wrote: > > As a matter of policy, yocto recipes default to using python from the host, > and are only switched to native python when there host python does not come > with needed 3rd party modules (which are then pulled in via -native DEPENDS), > or there is some other issue that cannot be resolved with host python. Native > python dependency lengthens the dependency chains, which is especially > critical for -native recipes. > > In this case, the problem is that libxcb in your build is too old for the > latest python 3.9, so you need to either update libxcb or backport an > upstream fix to make it work with 3.9 again. Your patch would not resolve the > issue, as native python in latest oe-core master is also 3.9, and the > failure would be the same. > > Alex > > On Wed, 14 Apr 2021 at 07:15, Josh Lehan wrote: >> >> Thanks. It's true, my local build is a little bit outdated. I'm running >> OpenBMC and it's slightly behind the latest upstream master. For now, it is >> still compiling with Python 3.8. >> >> However, there is the same underlying problem, even if I upgraded. It looks >> like the version of Python on the build machine is wrongly leaking into the >> build, and it's being used instead of the oe-core preferred version of >> Python. Ideally, the locally-installed Python wouldn't influence the outcome >> of the build, as oe-core has its own Python that it should prefer to use >> instead, as it does for other packages. This is what "inherit python3native" >> enables, right? Otherwise, the problem will happen again in the future, >> whenever somebody wants to try out a new Python version on their machine. >> The idea is to obtain some separation, for safety, and to help ensure a >> clean reproducible build. It's a good practice, I think, to minimize the >> opportunities for local variance to creep into the build. >> >> As for "from fractions import gcd" becoming an error in 3.9, there was this >> change: https://bugs.python.org/issue39350 >> >> It appears fractions.gcd was deprecated for a while. It was moved to >> math.gcd a while ago, and deprecated, but not deleted entirely until Python >> 3.9. So, that's why it works in 3.8 (what my old oe-core build is running), >> but not in 3.9 (what my local distribution is running). >> >> Josh >> >> Josh Lehan | Software Engineer | krel...@google.com | +1 650-733-8941 >> >> >> >> On Tue, Apr 13, 2021 at 1:08 PM Alexander Kanavin >> wrote: >>> >>> Also note: oe-core master already has 3.9, so you need to find out why >>> '3.8' shows up in install paths as well. Something doesn't compute here. >>> >>> Alex >>> >>> On Tue, 13 Apr 2021 at 22:07, Alexander Kanavin >>> wrote: I think you need to dig a little deeper. Why 'from fractions import gcd' is a problem with host python3.9 but not a problem with native python 3.9? Alex On Tue, 13 Apr 2021 at 20:58, Josh Lehan via lists.openembedded.org wrote: > > Hi there, thanks. I'm not entirely sure what "python3native" does > exactly, but this is my observation. The problem we are seeing is that, > without "inherit python3native", the build machine's local Python version > (whatever it happens to be) takes precedence over the Yocto-included > Python version. In our case, the build machine is running Python 3.9, and > evidently something changed between Python 3.8 and Python 3.9 to be > incompatible with libxcb. Here's the error message: > > Failed to load the xcbgen Python package! > Make sure that xcb/proto installed it on your Python path. > If not, you will need to create a .pth file or define $PYTHONPATH > to extend the path. > Refer to the README file in xcb/proto for more info. > > Traceback (most recent call last): > File > "/OpenBMC/build/tmp/work/x86_64-linux/libxcb-native/1.14-r0/build/src/../../libxcb-1.14/src/c_client.py", > line 3338, in > from xcbgen.state import Module > File > "/OpenBMC/build/tmp/work/x86_64-linux/libxcb-native/1.14-r0/recipe-sysroot-native/usr/lib/pkgconfig/../../../usr/lib/python3.8/site-packages/xcbgen/state.py", > line 7, in > from xcbgen import matcher > File > "/OpenBMC/build/tmp/work/x86_64-linux/libxcb-native/1.14-r0/recipe-sysroot-native/usr/lib/pkgconfig/../../../usr/lib/python3.8/site-packages/xcbgen/matcher.py", > line 12, in > from xcbgen.xtypes import * > File >
