Date   

Enhancements/Bugs closed WW49!

Stephen Jolley
 

All,

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

Who

Count

michael.opdenacker@...

1

Grand Total

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Current high bug count owners for Yocto Project 3.5

Stephen Jolley
 

All,

Below is the list as of top 46 bug owners as of the end of WW49 of who have open medium or higher bugs and enhancements against YP 3.5.   There are 99 possible work days left until the final release candidates for YP 3.5 needs to be released.

Who

Count

ross@...

36

michael.opdenacker@...

34

david.reyna@...

22

randy.macleod@...

20

bruce.ashfield@...

16

trevor.gamblin@...

15

timothy.t.orling@...

15

sakib.sajal@...

11

JPEWhacker@...

11

mhalstead@...

7

richard.purdie@...

7

kai.kang@...

7

saul.wold@...

6

bluelightning@...

6

kiran.surendran@...

5

hongxu.jia@...

4

chee.yang.lee@...

4

Qi.Chen@...

3

jon.mason@...

3

pgowda.cve@...

2

mshah@...

2

alejandro@...

2

yf3yu@...

1

angolini@...

1

mingli.yu@...

1

kexin.hao@...

1

alexandre.belloni@...

1

open.source@...

1

jay.shen.teoh@...

1

nicolas.dechesne@...

1

TicoTimo@...

1

yi.zhao@...

1

john.kaldas.enpj@...

1

limon.anibal@...

1

raj.khem@...

1

steve@...

1

thomas.perrot@...

1

aehs29@...

1

vinay.m.engg@...

1

matthewzmd@...

1

mark.hatle@...

1

Martin.Jansa@...

1

elberger@...

1

pokylinux@...

1

shachar@...

1

mostthingsweb@...

1

Grand Total

262

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 395 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.4”, “3.5, "3.99" and "Future", the more pressing/urgent issues being in "3.4" and then “3.5”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Re: Setting BUILDNAME to a string broke in 3.1.12

Daniel Gomez
 

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



Setting BUILDNAME to a string broke in 3.1.12

Henrik Riomar
 

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


Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.4.1.rc1)

Teoh, Jay Shen
 

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

-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Richard Purdie
Sent: Wednesday, 1 December, 2021 3:06 AM
To: <yocto@...> <yocto@...>
Cc: qa-build-notification <qa-build-notification@...>
Subject: [qa-build-notification] QA notification for completed autobuilder build
(yocto-3.4.1.rc1)

A build flagged for QA (yocto-3.4.1.rc1) was completed on the autobuilder and is
available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.4.1.rc1


Build hash information:

bitbake: 44a83b373e1fc34c93cd4a6c6cf8b73b230c1520
meta-agl: 83c5764a38902c6d17f106ea545533192ebd46fe
meta-arm: 55ae0eb1a6c210e6e87f5a553a1ebbb7dcc7a725
meta-aws: c92344938ab4d37de8bd8b799186dbbe3019a069
meta-gplv2: f04e4369bf9dd3385165281b9fa2ed1043b0e400
meta-intel: d0f1c1ebfd9b7fe8d22c6a62208f78bccc6f3bf6
meta-mingw: f5d761cbd5c957e4405c5d40b0c236d263c916a8
meta-openembedded: f31b9854b13e46cb74569538a33c36730c00c695
oecore: 70384dd958c57d1da924a66cffa35f80eb60d4b0
poky: b53230c08d9f02ecaf35b4f0b70512abbf10ae11



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...







meta-intel with a Celeron 6305E

Ori Pessach
 

Hello,

I'm trying to run an existing image (based on Gatesgarth) on a Celeron 6305E NUC. The application running on this image is a media player which uses Gstreamer for decoding and displaying video.

Performance on this CPU is inadequate (probably due to lack of acceleration support for decoding and display), and I've been trying to figure out how to fix that. I tried pulling different tags of the meta-intel BSP layer, with no success. 

So I guess my question is this - Is this processor fully supported by meta-intel, and if so, when was support added for this generation of CPU/GPU and how can I get that to work with my image?

Thanks,

Ori Pessach


Re: [meta-security][hardknott][PATCH v2] sssd: re-package to fix QA issues

Armin Kuster
 

merged.

thanks
armin

On 12/2/21 6:02 PM, Kai wrote:
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"


USB display

simon
 

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


Re: native tool from target recipe

Ross Burton <ross@...>
 

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


native tool from target recipe

Kacper Kubkowski
 

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


Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: stop using the "transition" branch

Quentin Schulz
 

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


Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: stop using the "transition" branch

Quentin Schulz
 

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


Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: stop using the "transition" branch

Quentin Schulz
 

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


Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: make all versions list releases known to master

Quentin Schulz
 

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


Zynq Board unreachable

m.kleber@...
 

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


Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: remove gatesgarth

Quentin Schulz
 

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


Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: stop using the "transition" branch

Nicolas Dechesne <nicolas.dechesne@...>
 



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://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).

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. 

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 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" ?

I think we had the 'transition' pages in master initially, and we moved that to its own branch. I believe it's something we discussed with Richard.. but i forgot the details. 
 

Cheers,
Quentin
> >


Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: stop using the "transition" branch

Nicolas Dechesne <nicolas.dechesne@...>
 



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:

Or am I missing here? 
 

Thanks,
Quentin




Re: [meta-security][hardknott][PATCH v2] sssd: re-package to fix QA issues

Kai Kang
 

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