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

Hi Michael, Richard,

On Wed, Nov 24, 2021 at 06:10:56PM +0000, Richard Purdie wrote:

On Wed, 2021-11-24 at 18:16 +0100, Michael Opdenacker wrote:

Together with the corresponding Bitbake version, which are no
longer supported.

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

diff --git a/scripts/run-docs-build b/scripts/run-docs-build
index 3db4a97..5e1d649 100755
--- a/scripts/run-docs-build
+++ b/scripts/run-docs-build
@@ -35,7 +35,7 @@ mkdir $outputdir/bitbake/next
cp -r ./_build/final/* $outputdir/bitbake/next

# stable branches
-for branch in 1.46 1.48 1.50 1.52; do
+for branch in 1.46 1.50 1.52; do
git checkout $branch
make clean
make publish
@@ -68,7 +68,7 @@ mkdir $outputdir/next
cp -r ./_build/final/* $outputdir/next

# stable branches
-for branch in dunfell gatesgarth hardknott honister; do
+for branch in dunfell hardknott honister; do
cd $ypdocs
git checkout $branch
make clean

I'm a bit torn on this. They are no longer officially supported releases now but
it may make sense to rebuild all the sphinx docs in this script rather than some
subset?

I think we want to make sure we have all docs up-to-date, even for the
branches that aren't maintained anymore. Especially since it's not
taking a lot of CPU time to build them, it's fine IMO. We could always
make minor changes to old docs. E.g. the releases.rst might get updates
until we figure something out.

Cheers,
Quentin

On 11/27/21 2:41 AM, akuster808 wrote:

merged.

Hi Armin,

Would you like to double check the commit, please? I don't see it in branch hardknott.

Regards,
Kai

On 11/16/21 10:28 AM, Jeremy A. Puhlman wrote:

It packages all file in ${libdir} to package sssd, including the .so
symlink files. Then it causes QA issues:

| ERROR: QA Issue: sssd rdepends on dbus-dev [dev-deps]
| ERROR: QA Issue: sssd rdepends on ding-libs-dev [dev-deps]

So re-package sssd then the .so symlink files and .pc files are packaged
to sssd-dev which should be.

File ${libdir}/libsss_sudo.so is not a symlink file but packaged to
sssd-dev too. Then causes another QA issue:

| ERROR: sssd-2.5.2-r0 do_package_qa: QA Issue:
-dev package sssd-dev contains non-symlink .so '/usr/lib/libsss_sudo.so' [dev-elf]

So create a new sub-package libsss-sudo to package file libsss_sudo.so
and make sssd rdepends on it.

JP: Updated for version differences.

Signed-off-by: Kai Kang <kai.kang@...>
Signed-off-by: Armin Kuster <akuster808@...>
(cherry picked from commit e81c15f851ca5396c78c8737967ee38db0ebe0cd)
Signed-off-by: Jeremy A. Puhlman <jpuhlman@...>
---
recipes-security/sssd/sssd_1.16.5.bb | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/recipes-security/sssd/sssd_1.16.5.bb b/recipes-security/sssd/sssd_1.16.5.bb
index 02d0837..f13fc49 100644
--- a/recipes-security/sssd/sssd_1.16.5.bb
+++ b/recipes-security/sssd/sssd_1.16.5.bb
@@ -120,10 +120,17 @@ SYSTEMD_SERVICE_${PN} = " \
"
SYSTEMD_AUTO_ENABLE = "disable"
-FILES_${PN} += "${libdir} ${datadir} ${base_libdir}/security/pam_sss.so"
-FILES_${PN}-dev = " ${includedir}/* ${libdir}/*la ${libdir}/*/*la"
-
-# The package contains symlinks that trip up insane
-INSANE_SKIP_${PN} = "dev-so"
-
-RDEPENDS_${PN} = "bind dbus libldb libpam"
+PACKAGES =+ "libsss-sudo libsss-autofs"
+ALLOW_EMPTY_libsss-sudo = "1"
+ALLOW_EMPTY_libsss-autofs = "1"
+
+FILES_${PN}-dev += "${libdir}/sssd/modules/lib*.so"
+FILES_${PN} += "${base_libdir}/security/pam_sss*.so \
+ ${datadir}/dbus-1/system-services/*.service \
+ ${libdir}/krb5/* \
+ ${libdir}/ldb/* \
+ "
+FILES_libsss-autofs = "${libdir}/sssd/modules/libsss_autofs.so"
+FILES_libsss-sudo = "${libdir}/libsss_sudo.so"
+
+RDEPENDS_${PN} = "bind dbus libldb libpam libsss-sudo libsss-autofs"

--
Kai Kang
Wind River Linux