This email is a follow-up from the session held on Friday at the
OpenEmbedded Developer's Virtual Meeting (see
https://www.openembedded.org/wiki/OEDVM_Nov_2021)

The session was not recorded, but the slides can be found at
https://docs.google.com/presentation/d/146ueVVTMeA8JI43wqv5kFmdYEygqqmfGH0z1VRL2bDA/edit?usp=sharing

The outcome from the discussion was that inclusive language changes
are something that we want to accomplish in the kirkstone release
timeframe (with an exception for the "master" branch name, which will
be handled at a future date).

There has already been a pass at collecting the needed changes at
https://wiki.yoctoproject.org/wiki/Inclusive_language

This is not as simple as a find/replace of offending words. There is
a desire for backward compatibility or to provide some kind of "you
want X, which is now Y" (which complicates things).

The intention of this email is to see who is interested in helping
out. Once we know how many people are available and what time frames,
we can plan out a roadmap. So, please email me (or respond to this
thread publicly) and I'll add you to the list. There will then be a
follow-up zoom call in the next week or so to plan out the roadmap.

We will document the roadmap and everything else on the YP wiki page above.

Questions and comments are welcome, but not interested in debating the
necessity or timeframe of this task. It has already been decided.

Thanks,
Jon

On Mon, 2021-12-06 at 14:27 -1000, Steve Sakoman wrote:

On Mon, Dec 6, 2021 at 6:40 AM Henrik Riomar <henrik.riomar@...> wrote:

Hi,

We set the BUILDNAME (via local.conf) variable to the output of "git
describe --long --always" so this info ends up in /etc/version instead
of a date. (i.e to know the exact source version of the code
deployed on a target)

This has worked fine for us up until 3.1.12, but now we just get a
date (201803...) in /etc/version.

After doing a bit of bisecting it appears that this commit is the culprit:

reproducible_build: Remove BUILD_REPRODUCIBLE_BINARIES checking
https://git.yoctoproject.org/poky/commit/?h=dunfell&id=0d6ebaf8ff3232248ebf0e859cd09aefaee54a8a

Since this was cherry-picked from master to fix some reproducibililty
errors I suspected that the issue might also exist in the master
branch.

A quick test with:

BUILD_REPRODUCIBLE_BINARIES = "0"
BUILDNAME = "my custom name"

added to local.conf confirmed that /etc/version was indeed
"20180309123456" instead of the expected "my custom name"

I'm out of time to work on this today, but perhaps Richard might have
some ideas on how to address this.

rootfs-postcommands.bbclass says:

# Perform any additional adjustments needed to make rootf binary reproducible
rootfs_reproducible () {
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`
echo $sformatted > ${IMAGE_ROOTFS}/etc/version
bbnote "rootfs_reproducible: set /etc/version to $sformatted"

if [ -d ${IMAGE_ROOTFS}${sysconfdir}/gconf ]; then
find ${IMAGE_ROOTFS}${sysconfdir}/gconf -name '%gconf.xml' -print0 | xargs -0r \
sed -i -e 's@\bmtime="[0-9][0-9]*"@mtime="'${REPRODUCIBLE_TIMESTAMP_ROOTFS}'"@g'
fi
fi
}

so I'd try setting REPRODUCIBLE_TIMESTAMP_ROOTFS to "". I suspect the change
above started setting that to some value incidentally.

Cheers,

Richard

On Mon, Dec 6, 2021 at 6:40 AM Henrik Riomar <henrik.riomar@...> wrote:

Hi,

We set the BUILDNAME (via local.conf) variable to the output of "git
describe --long --always" so this info ends up in /etc/version instead
of a date. (i.e to know the exact source version of the code
deployed on a target)

This has worked fine for us up until 3.1.12, but now we just get a
date (201803...) in /etc/version.

After doing a bit of bisecting it appears that this commit is the culprit:

reproducible_build: Remove BUILD_REPRODUCIBLE_BINARIES checking
https://git.yoctoproject.org/poky/commit/?h=dunfell&id=0d6ebaf8ff3232248ebf0e859cd09aefaee54a8a

Since this was cherry-picked from master to fix some reproducibililty
errors I suspected that the issue might also exist in the master
branch.

A quick test with:

BUILD_REPRODUCIBLE_BINARIES = "0"
BUILDNAME = "my custom name"

added to local.conf confirmed that /etc/version was indeed
"20180309123456" instead of the expected "my custom name"

I'm out of time to work on this today, but perhaps Richard might have
some ideas on how to address this.

Steve

Note that since switching to Dunfell we were forced to set
BUILD_REPRODUCIBLE_BINARIES to 0, so the build system would not "mess
up" /etc/version, but not even that helps now.

What's the official way to get something more useful than a date (in
the long past) in /etc/version?

Thanks,
Henrik

Hello,

I've been working on extending SPDX SBOMs for SDKs. In poky/meta/classes/create-spdx.bbclass I added:

 

do_populate_sdk[recrdeptask] += "do_create_spdx do_create_runtime_spdx"

 

I ran into a dependency loop when I try to build an SDK that contains nativesdk-clang (it works fine for other SDKs):

 

ERROR:

Dependency loop #1 found:

Task mc:lnx-sdk:/__w/1/s/sources/poky/../meta-clang/recipes-devtools/clang/clang-crosssdk_git.bb:do_create_spdx (dependent Tasks ['glibc_2.31.bb:do_create_spdx', 'binutils-crosssdk_2.34.bb:do_create_spdx', 'clang_git.bb:do_create_spdx', 'quilt-native_0.66.bb:do_populate_sysroot', 'nativesdk-clang-glue.bb:do_create_spdx'])

 

Task mc:lnx-sdk:virtual:nativesdk:/__w/1/s/sources/poky/../meta-clang/recipes-devtools/clang/clang_git.bb:do_create_spdx (dependent Tasks ['clang_git.bb:do_packagedata', 'cmake-native_3.16.5.bb:do_create_spdx', 'swig_3.0.12.bb:do_create_spdx', 'libedit_20191231-3.1.bb:do_create_spdx', 'binutils-crosssdk_2.34.bb:do_create_spdx', 'chrpath_0.16.bb:do_create_spdx', 'libffi_3.3.bb:do_create_spdx', 'clang-crosssdk_git.bb:do_create_spdx', 'zlib_1.2.11.bb:do_create_spdx', 'clang_git.bb:do_package', 'python3_3.8.2.bb:do_create_spdx', 'libxml2_2.9.10.bb:do_create_spdx', 'python3_3.8.2.bb:do_create_spdx', 'pkgconfig_git.bb:do_create_spdx', 'binutils_2.34.bb:do_create_spdx', 'quilt-native_0.66.bb:do_populate_sysroot', 'libedit_20191231-3.1.bb:do_create_spdx', 'libxml2_2.9.10.bb:do_create_spdx', 'ninja_1.10.0.bb:do_create_spdx'])

 

Task mc:lnx-sdk:/__w/1/s/sources/poky/../meta-clang/recipes-devtools/clang/nativesdk-clang-glue.bb:do_create_spdx (dependent Tasks ['gcc-runtime_9.3.bb:do_create_spdx', 'glibc_2.31.bb:do_create_spdx', 'nativesdk-clang-glue.bb:do_package', 'gcc-crosssdk_9.3.bb:do_create_spdx', 'chrpath_0.16.bb:do_create_spdx', 'quilt-native_0.66.bb:do_populate_sysroot', 'nativesdk-clang-glue.bb:do_packagedata', 'clang_git.bb:do_create_spdx'])

 

Any help on this would be appreciated.

 

Thanks,

Andres Beltran

Hi,

On Mon, 6 Dec 2021 at 17:40, Henrik Riomar <henrik.riomar@...> wrote:

Hi,

We set the BUILDNAME (via local.conf) variable to the output of "git
describe --long --always" so this info ends up in /etc/version instead
of a date. (i.e to know the exact source version of the code
deployed on a target)

This has worked fine for us up until 3.1.12, but now we just get a
date (201803...) in /etc/version.

Note that since switching to Dunfell we were forced to set
BUILD_REPRODUCIBLE_BINARIES to 0, so the build system would not "mess
up" /etc/version, but not even that helps now.

What's the official way to get something more useful than a date (in
the long past) in /etc/version?

We use build image-buildinfo class:
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#ref-classes-image-buildinfo

Just add INHERIT += "image-buildinfo" to your local.conf to get the build info.

Daniel

Thanks,
Henrik

Hi,

We set the BUILDNAME (via local.conf) variable to the output of "git
describe --long --always" so this info ends up in /etc/version instead
of a date. (i.e to know the exact source version of the code
deployed on a target)

This has worked fine for us up until 3.1.12, but now we just get a
date (201803...) in /etc/version.

Note that since switching to Dunfell we were forced to set
BUILD_REPRODUCIBLE_BINARIES to 0, so the build system would not "mess
up" /etc/version, but not even that helps now.

What's the official way to get something more useful than a date (in
the long past) in /etc/version?

Thanks,
Henrik

Hello everyone,

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

======= Summary ========
No high milestone defects.

new issue found

Bug 14622 - bsps-hw.bsps-hw.Test_Seek_bar_and_volume_control manual test case failure

======= Bugs ========
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14622

Thanks,
Jay

merged.

thanks
armin

Hello, I'm having some issue moving from an HDMI display to a USB display.

I figure out that I needed to enable these parameter in the kernel to use the USB monitor

CONFIG_DRM_UDL=y
CONFIG_FB_UDL=y

With those I'm able to see the terminal and login

However I'm still struggling and confused on how to get my GUI to show up with startx.

I don't know if I still need to install the displaylink driver since I've enabled UDL or if I need to set something with xorg to let him know to use the USB display.

I've tried to install the displaylink driver manually but I'm missing the DKMS component, not entirely sure what that is and how I would install this (or if I should).

I tried to follow some guide about displaylink with xorg and replacing it with udl and udlfb without success.

Thanks for your help

Simon

On Fri, 3 Dec 2021 at 16:16, <kkubkowski@...> wrote:

Hi all,
I have what I believe is a basic question yet I cannot find any definitive answer: is it possible for a target recipe (e.g. u-boot or barebox) to provide a native tool (i.e. mkimage) for the build system without the need to rebuild the providing recipe as a native one? To be more specific: I am using barebox as a bootloader and it always builds mkimage for host. I would like to use it later during the build process in another recipe (e.g. after the kernel is built) but I don't want to rebuild the bootloader as a native package. Given how flexible the build system is I suppose it is doable, but what is "the proper" way?

The usual solution is for the recipe to allow building native and you
install the tools from that recipe for the target recipe to use.

The better solution is that the source knows how to build host tools
for the host and target binaries for the target. barebox does, so
just set HOSTCC=${BUILD_CC} when you call make.

Ross

Hi all,
I have what I believe is a basic question yet I cannot find any definitive answer: is it possible for a target recipe (e.g. u-boot or barebox) to provide a native tool (i.e. mkimage) for the build system without the need to rebuild the providing recipe as a native one? To be more specific: I am using barebox as a bootloader and it always builds mkimage for host. I would like to use it later during the build process in another recipe (e.g. after the kernel is built) but I don't want to rebuild the bootloader as a native package. Given how flexible the build system is I suppose it is doable, but what is "the proper" way?

Kind regards,
Kacper

On Fri, Dec 03, 2021 at 11:48:29AM +0100, Nicolas Dechesne wrote:

On Fri, Dec 3, 2021 at 11:03 AM Quentin Schulz <
quentin.schulz@...> wrote:

Hi Nicolas,

On Fri, Dec 03, 2021 at 10:49:40AM +0100, Nicolas Dechesne wrote:

On Fri, Dec 3, 2021 at 10:34 AM Quentin Schulz <
quentin.schulz@...> wrote:

On Wed, Dec 01, 2021 at 02:59:49PM +0100, Michael Opdenacker wrote:

No longer necessary now that the transition from DocBook to Sphinx is

over

Signed-off-by: Michael Opdenacker <michael.opdenacker@...>

Reviewed-by: Quentin Schulz <foss+yocto@...>

I don't understand. With this change, we no longer build the pages we
reference here:

https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.yoctoproject.org_releases.html-23outdated-2Drelease-2Dmanuals&d=DwIBaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=nyCl21erajBNcx6SkCKI_BEntNgbh6114vcdWp_vB5yDzorVFjmzdqp0WXIIpQyK&s=rw5wG0nk_9KQ8RLvE1-sbSicy4NslWaeMwoyTSUuIyY&e=

Or am I missing here?

Indeed. But this should be fixed, because we should handle this the same
way documentation/releases.html is, with a common one across all
releases. With the current implementation, only master has a list of all
outdated releases. e.g.
https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.yoctoproject.org_3.3_releases.html-23outdated-2Drelease-2Dmanuals&d=DwIFaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=0ATdi4CSdy8VvhAKg6W6Qe5J7HEmGOLkDTVb13pe2bQyCiXzZxZGI_ePuUigui73&s=sW9qt9Z46xCwvoaxsU7RvUYqfKmOlSN8T_vDv0Yc_qE&e=
does not exist, but
https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.yoctoproject.org_releases.html-23outdated-2Drelease-2Dmanuals&d=DwIFaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=0ATdi4CSdy8VvhAKg6W6Qe5J7HEmGOLkDTVb13pe2bQyCiXzZxZGI_ePuUigui73&s=vI9nhu-xEodig5uSD7RDYKswiZHG_8PDgnd2No0oXMA&e=
does (and weirdly enough 3.4 too).

Yes, this part is indeed poorly implemented. But I don't think we can
remove the transition branch until we fix it, so I don't think we can take
this patch now.

Agreed, I poorly reviewed it. Thanks for stoping us before the disaster
:)

perhaps we should maintain the overall documentation (for all versions) in
the same branch.. all these branches are making everything much
complicated.. Or perhaps we should split the documentation 'content' and
the documentation config and scripts. I am wondering how other projects are
doing it to support such complex doc setup (multiple versions to support
and to publish)!

I think all our issues always come down to this weird and inefficient
organization we have for docs and common files between doc releases.
We'll need to settle on something one day because I don't think what
we're doing today is working :/

Cheers,
Quentin

Hi Nicolas,

On Fri, Dec 03, 2021 at 10:49:40AM +0100, Nicolas Dechesne wrote:

On Fri, Dec 3, 2021 at 10:34 AM Quentin Schulz <
quentin.schulz@...> wrote:

On Wed, Dec 01, 2021 at 02:59:49PM +0100, Michael Opdenacker wrote:

No longer necessary now that the transition from DocBook to Sphinx is

over

Signed-off-by: Michael Opdenacker <michael.opdenacker@...>

Reviewed-by: Quentin Schulz <foss+yocto@...>

I don't understand. With this change, we no longer build the pages we
reference here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.yoctoproject.org_releases.html-23outdated-2Drelease-2Dmanuals&d=DwIBaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=nyCl21erajBNcx6SkCKI_BEntNgbh6114vcdWp_vB5yDzorVFjmzdqp0WXIIpQyK&s=rw5wG0nk_9KQ8RLvE1-sbSicy4NslWaeMwoyTSUuIyY&e=

Or am I missing here?

Indeed. But this should be fixed, because we should handle this the same
way documentation/releases.html is, with a common one across all
releases. With the current implementation, only master has a list of all
outdated releases. e.g.
https://docs.yoctoproject.org/3.3/releases.html#outdated-release-manuals
does not exist, but
https://docs.yoctoproject.org/releases.html#outdated-release-manuals
does (and weirdly enough 3.4 too).

I assume we want this in all branches. Therefore I think we should move
documentation/transition from that branch to master and copy the whole
directory for each non-master branch (with the git checkout master trick
from an earlier patch from Michael). I think this makes more sense than
keeping a transition branch? Especially since I assume we want to move
every 6 months one release from "Supported release manuals" to "Outdated
releae manuals" ?

Cheers,
Quentin

On Wed, Dec 01, 2021 at 02:59:49PM +0100, Michael Opdenacker wrote:

No longer necessary now that the transition from DocBook to Sphinx is over

Signed-off-by: Michael Opdenacker <michael.opdenacker@...>

Reviewed-by: Quentin Schulz <foss+yocto@...>

Thanks,
Quentin

Hi Michael,

On Wed, Dec 01, 2021 at 02:49:31PM +0100, Michael Opdenacker wrote:

This allows all versions of Bitbake and Yocto Project manuals
to see the manuals for the latest versions.

This also simplifies the release process, not having to update the
releases.rst file for all releases every time a new release is made.

Note that such synchronization is already done for the
switchers.js file (but in a different way). This way, advertised
releases are in sync with switchers.js.

Why don't we migrate this different method (find) to the one you
implement in this commit too?

I could see a variable storing all "force-latest" files or someting like
that to make it obvious why they have a specific handling.

Signed-off-by: Michael Opdenacker <michael.opdenacker@...>
---
scripts/run-docs-build | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/scripts/run-docs-build b/scripts/run-docs-build
index 4451018..5d6d24a 100755
--- a/scripts/run-docs-build
+++ b/scripts/run-docs-build
@@ -39,8 +39,11 @@ cp -r ./_build/final/* $outputdir/bitbake/next
# A decision was made to keep updating all the Sphinx generated docs for the moment,
# even the ones corresponding to no longer supported releases
# https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.yoctoproject.org_g_docs_message_2193&d=DwIDAg&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=41QznJ3f-1jbT6A1N9c2-XE7vAUbnla1A6cM0yaU8thgWg_WVfeII9dfe8Uq2JTO&s=YCQsQAquPWLLWl11yDzvgP9zkF-UkMF0c8B3BASBDbk&e=
+# We copy the releases.rst file from master so that all versions of the docs
+# see the latest releases.
for branch in 1.46 1.48 1.50 1.52; do
git checkout $branch
+ git checkout master doc/releases.rst

That's one way to do it, not sure this is really what we want but at
least it lowers the maintenance burden so it's a good improvement.

Cheers,
Quentin

Hi,

I created a build for a digilent zybo zynq7. And I create a small server code I need to run on the board.
When I connect the board with ethernet cable to my laptop and try to ping the board I will get the following answer:
$ ping fe80::3478:6c8d:ad4e:43f8%eth0
PING fe80::3478:6c8d:ad4e:43f8%eth0(fe80::3478:6c8d:ad4e:43f8%eth0) 56 data bytes
From fe80::6504:a10e:942f:7cfd%eth0: icmp_seq=1 Destination unreachable: Address unreachable
From fe80::6504:a10e:942f:7cfd%eth0: icmp_seq=2 Destination unreachable: Address unreachable
From fe80::6504:a10e:942f:7cfd%eth0: icmp_seq=3 Destination unreachable: Address unreachable

I've configured the eth0 in /etc/network/interfaces.
The laptop get the connection to the board but can' t reach it or the gateway.
There is no firewall or iptables rules.

Anyone an idea how to deal with it?

B/R
Mike