[yocto] Y2038 proposal
On Tue, 29 Nov 2022 at 16:45, Stephen Jolley wrote: > We’d welcome a proposal/series on how to move forward with the Y2038 work for > 32 bit platforms. I have the following proposal: 1. A branch is made where: a. "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" is enabled globally. b. qemu is always started with "-rtc base=2040-01-01", simulating Y2038 actually occurring. c. an additional runtime test verifies that both RTC clock and system clock report 2040. 2. This branch is run through a-full on the autobuilder. Any uncovered issues are filed as bugs. 3. Once *all* of the bugs are addressed, repeat point 2. 4. Once there are no more open bugs, 1a is merged into master. Any fatal flaws in the plan? It's not hard to see that Y2038 problem is real and serious, e.g. on qemux86 core-image-full-cmdline built from master: root@qemux86:~# ls / bin boot devetc home liblost+found media mntproc run sbin sys tmp usrvar root@qemux86:~# date -s "2040-01-01" Sun Jan 1 00:00:00 UTC 2040 root@qemux86:~# ls / bin boot devetc home liblost+found media mntproc run sbin sys tmp usrvar root@qemux86:~# ls / -sh: ls: command not found On qemux86_64 the same sequence works as expected, of course. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58663): https://lists.yoctoproject.org/g/yocto/message/58663 Mute This Topic: https://lists.yoctoproject.org/mt/95354041/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Y2038 proposal
Hi Alexander, > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley > wrote: > > We’d welcome a proposal/series on how to move forward with the > > Y2038 work for 32 bit platforms. > > I have the following proposal: > > 1. A branch is made where: > a. "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" is enabled globally. > b. qemu is always started with "-rtc base=2040-01-01", simulating > Y2038 actually occurring. > c. an additional runtime test verifies that both RTC clock and system > clock report 2040. > Please find a few comments: 1. There is already provided meta-y2038 [1] to test if 32 bit systems correctly support Y2038 problem. It uses qemu machines from OE/Yocto 2. There are ptest available [2] to validate if the Y2038 problem works correctly. 3. Support for running ptests mentioned in point 2. is already available in the poky repository [3]. > 2. This branch is run through a-full on the autobuilder. Any uncovered > issues are filed as bugs. > > 3. Once *all* of the bugs are addressed, repeat point 2. > > 4. Once there are no more open bugs, 1a is merged into master. > > Any fatal flaws in the plan? > > It's not hard to see that Y2038 problem is real and serious, e.g. on > qemux86 core-image-full-cmdline built from master: > > root@qemux86:~# ls / > bin boot devetc home liblost+found media mntproc > run sbin sys tmp usrvar > root@qemux86:~# date -s "2040-01-01" > Sun Jan 1 00:00:00 UTC 2040 > root@qemux86:~# ls / > bin boot devetc home liblost+found media mntproc > run sbin sys tmp usrvar > root@qemux86:~# ls / > -sh: ls: command not found > > On qemux86_64 the same sequence works as expected, of course. > Yes, y2038 is an important issue. I would be more than happy if we could reuse the previous work [1]. I've used OE/Yocto to validate the code during developing support for '-D_TIME_BITS=64 ' flag in glibc. It looks like the meta-y2038 can be used out of the box (after checking if it still works with newest poky) when added to the Yocto Project build/test infrastructure. > Alex Links: [1] - https://github.com/lmajewski/meta-y2038 [2] - https://github.com/lmajewski/meta-y2038/blob/master/README#L201 [3] - https://git.yoctoproject.org/poky/commit/?id=0e0c481a25f10f8f7ff1d69bda7f015186da0202 Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpTgIKasUGYm.pgp Description: OpenPGP digital signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58664): https://lists.yoctoproject.org/g/yocto/message/58664 Mute This Topic: https://lists.yoctoproject.org/mt/95354041/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Y2038 proposal
On Wed, 30 Nov 2022 at 09:28, Lukasz Majewski wrote: > Please find a few comments: > > 1. There is already provided meta-y2038 [1] to test if 32 bit systems > correctly support Y2038 problem. It uses qemu machines from OE/Yocto > > 2. There are ptest available [2] to validate if the Y2038 problem works > correctly. > > 3. Support for running ptests mentioned in point 2. is already > available in the poky repository [3]. Thanks! So there should be a d. 'glibc-tests-ptest' is executed across all architectures - probably as a machine-specific selftest, and as well with qemu time set into the future. > It looks like the meta-y2038 can be used out of the box (after checking > if it still works with newest poky) when added to the Yocto Project > build/test infrastructure. Unfortunately I do not think that layer can be easily added into the test matrix. It has its own distro and images. No, we need to maintain a poky branch where the same tweaks and fixes happen. Besides, those fixes would need to be merged into oe-core proper eventually anyway. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58665): https://lists.yoctoproject.org/g/yocto/message/58665 Mute This Topic: https://lists.yoctoproject.org/mt/95354041/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Y2038 proposal
Hi Alexander, > On Wed, 30 Nov 2022 at 09:28, Lukasz Majewski wrote: > > Please find a few comments: > > > > 1. There is already provided meta-y2038 [1] to test if 32 bit > > systems correctly support Y2038 problem. It uses qemu machines from > > OE/Yocto > > > > 2. There are ptest available [2] to validate if the Y2038 problem > > works correctly. > > > > 3. Support for running ptests mentioned in point 2. is already > > available in the poky repository [3]. > > Thanks! So there should be a > > d. 'glibc-tests-ptest' is executed across all architectures - probably > as a machine-specific selftest, and as well with qemu time set into > the future. +1 > > > It looks like the meta-y2038 can be used out of the box (after > > checking if it still works with newest poky) when added to the > > Yocto Project build/test infrastructure. > > Unfortunately I do not think that layer can be easily added into the > test matrix. It has its own distro and images. No, we need to maintain > a poky branch where the same tweaks and fixes happen. Besides, those > fixes would need to be merged into oe-core proper eventually anyway. > It would be even better if the meta-y2038 could be dropped and _all_ its functionality could be merged to poky. That would be _awesome_. Please just be aware that this meta layer has some fixes for some packages (for Y2038 ready glibc). > Alex Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpQ80_v7k1d3.pgp Description: OpenPGP digital signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58666): https://lists.yoctoproject.org/g/yocto/message/58666 Mute This Topic: https://lists.yoctoproject.org/mt/95354041/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Y2038 proposal
On Wed, 30 Nov 2022 at 10:40, Lukasz Majewski wrote: > It would be even better if the meta-y2038 could be dropped and _all_ > its functionality could be merged to poky. > > That would be _awesome_. > > Please just be aware that this meta layer has some fixes for some > packages (for Y2038 ready glibc). Little by little. As long as we have a well-defined test plan, a well-known list of issues, and follow a strict 'upstream first' policy in addressing them (e.g. no fixes in layers that are 'forever pending', un-upstreamable or have been rejected by upstreams), we'll eventually get there. And absolutely no promise to make this available anywhere except master. If someone is using ancient yocto releases, they should run a retro computing museum rather than critical infrastructure. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58667): https://lists.yoctoproject.org/g/yocto/message/58667 Mute This Topic: https://lists.yoctoproject.org/mt/95354041/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Y2038 proposal
On Wed, 30 Nov 2022 at 03:08, Alexander Kanavin wrote: > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley > wrote: > > We’d welcome a proposal/series on how to move forward with the Y2038 > work for 32 bit platforms. > > I have the following proposal: > > 1. A branch is made where: > a. "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" is enabled globally. > b. qemu is always started with "-rtc base=2040-01-01", simulating > Y2038 actually occurring. > c. an additional runtime test verifies that both RTC clock and system > clock report 2040. > > Going from various problems I saw with systems with smaller time wraps, setting a time after wrap occurs misses most of the problems which wall occur. Many systems will work fine with either 'negative' or 'smaller dates' but crash, burn, etc when running when the counter wraps around. I would suggest setting the test date to -N minutes before wrap over to run a first set of tests, and then N minutes after the wrap to run a second set of tests. This would hopefully catch programs which are worse off. -- Stephen J Smoogen. Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58668): https://lists.yoctoproject.org/g/yocto/message/58668 Mute This Topic: https://lists.yoctoproject.org/mt/95354041/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Y2038 proposal
On 30/11/2022 09:07:50+0100, Alexander Kanavin wrote: > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley wrote: > > We’d welcome a proposal/series on how to move forward with the Y2038 work > > for 32 bit platforms. > > I have the following proposal: > > 1. A branch is made where: > a. "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" is enabled globally. > b. qemu is always started with "-rtc base=2040-01-01", simulating > Y2038 actually occurring. > c. an additional runtime test verifies that both RTC clock and system > clock report 2040. > > 2. This branch is run through a-full on the autobuilder. Any uncovered > issues are filed as bugs. > I ran a-full with "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" last week, it didn't go too well gcc-sanitizer and pulseaudio being the main offenders but buildtools needs to be investigated. > 3. Once *all* of the bugs are addressed, repeat point 2. > > 4. Once there are no more open bugs, 1a is merged into master. > > Any fatal flaws in the plan? > > It's not hard to see that Y2038 problem is real and serious, e.g. on > qemux86 core-image-full-cmdline built from master: > > root@qemux86:~# ls / > bin boot devetc home liblost+found media mntproc > run sbin sys tmp usrvar > root@qemux86:~# date -s "2040-01-01" > Sun Jan 1 00:00:00 UTC 2040 > root@qemux86:~# ls / > bin boot devetc home liblost+found media mntproc > run sbin sys tmp usrvar > root@qemux86:~# ls / > -sh: ls: command not found > > On qemux86_64 the same sequence works as expected, of course. > The main issue with the plan is that we are not running tests on 32 qemu anymore. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58669): https://lists.yoctoproject.org/g/yocto/message/58669 Mute This Topic: https://lists.yoctoproject.org/mt/95354041/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Y2038 proposal
On Wed, 30 Nov 2022 05:52:03 -0500 "Stephen John Smoogen" wrote: > On Wed, 30 Nov 2022 at 03:08, Alexander Kanavin > wrote: > > > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley > > wrote: > > > We’d welcome a proposal/series on how to move forward with the > > > Y2038 > > work for 32 bit platforms. > > > > I have the following proposal: > > > > 1. A branch is made where: > > a. "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" is enabled globally. > > b. qemu is always started with "-rtc base=2040-01-01", simulating > > Y2038 actually occurring. > > c. an additional runtime test verifies that both RTC clock and > > system clock report 2040. > > > > > Going from various problems I saw with systems with smaller time > wraps, setting a time after wrap occurs misses most of the problems > which wall occur. Many systems will work fine with either 'negative' > or 'smaller dates' but crash, burn, etc when running when the counter > wraps around. I would suggest setting the test date to -N minutes > before wrap over to run a first set of tests, and then N minutes > after the wrap to run a second set of tests. This would hopefully > catch programs which are worse off. > IIRC ptests for y2038 covers this problem in this exact way. Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpl0cjdjjqBQ.pgp Description: OpenPGP digital signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58670): https://lists.yoctoproject.org/g/yocto/message/58670 Mute This Topic: https://lists.yoctoproject.org/mt/95354041/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [yocto] Y2038 proposal
On Wed, 2022-11-30 at 12:02 +0100, Alexandre Belloni via lists.openembedded.org wrote: > On 30/11/2022 09:07:50+0100, Alexander Kanavin wrote: > > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley > > wrote: > > > We’d welcome a proposal/series on how to move forward with the Y2038 work > > > for 32 bit platforms. > > > > I have the following proposal: > > > > 1. A branch is made where: > > a. "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" is enabled globally. > > b. qemu is always started with "-rtc base=2040-01-01", simulating > > Y2038 actually occurring. > > c. an additional runtime test verifies that both RTC clock and system > > clock report 2040. > > > > 2. This branch is run through a-full on the autobuilder. Any uncovered > > issues are filed as bugs. > > > > I ran a-full with "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" last week, it > didn't go too well gcc-sanitizer and pulseaudio being the main offenders > but buildtools needs to be investigated. What is the potential issue with builtools? > > 3. Once *all* of the bugs are addressed, repeat point 2. > > > > 4. Once there are no more open bugs, 1a is merged into master. > > > > Any fatal flaws in the plan? > > > > It's not hard to see that Y2038 problem is real and serious, e.g. on > > qemux86 core-image-full-cmdline built from master: > > > > root@qemux86:~# ls / > > bin boot devetc home liblost+found media mntproc > > run sbin sys tmp usrvar > > root@qemux86:~# date -s "2040-01-01" > > Sun Jan 1 00:00:00 UTC 2040 > > root@qemux86:~# ls / > > bin boot devetc home liblost+found media mntproc > > run sbin sys tmp usrvar > > root@qemux86:~# ls / > > -sh: ls: command not found > > > > On qemux86_64 the same sequence works as expected, of course. > > > > The main issue with the plan is that we are not running tests on 32 > qemu anymore. To be clear, we don't run ptests on 32 bit targets, only on qemux86-64 and qemuarm64 where we have KVM available. We do run image, sdk and eSDK tests on our supported qemu targets, 32 and 64 bit. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58671): https://lists.yoctoproject.org/g/yocto/message/58671 Mute This Topic: https://lists.yoctoproject.org/mt/95355888/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [yocto] Y2038 proposal
On Wed, 30 Nov 2022 at 12:40, Richard Purdie wrote: > To be clear, we don't run ptests on 32 bit targets, only on qemux86-64 > and qemuarm64 where we have KVM available. We do run image, sdk and > eSDK tests on our supported qemu targets, 32 and 64 bit. I think kvm does allow 32 bit guest on a 64 bit host. But I can imagine making full ptests work on 32 bit guests would be a struggle for reasons unrelated to 2038, specifically lack of users outside of embedded world. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58672): https://lists.yoctoproject.org/g/yocto/message/58672 Mute This Topic: https://lists.yoctoproject.org/mt/95355888/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Y2038 proposal
On Wed, 30 Nov 2022 at 11:52, Stephen John Smoogen wrote: > Going from various problems I saw with systems with smaller time wraps, > setting a time after wrap occurs misses most of the problems which wall > occur. Many systems will work fine with either 'negative' or 'smaller dates' > but crash, burn, etc when running when the counter wraps around. I would > suggest setting the test date to -N minutes before wrap over to run a first > set of tests, and then N minutes after the wrap to run a second set of tests. > This would hopefully catch programs which are worse off. Testing the rollover could be done in later stages. I can imagine we'll have enough just by setting the date in the future and getting those magic glibc flags to not cause build fails. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58673): https://lists.yoctoproject.org/g/yocto/message/58673 Mute This Topic: https://lists.yoctoproject.org/mt/95354041/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [yocto] Y2038 proposal
On Wed, 30 Nov 2022 13:07:27 +0100 "Alexander Kanavin" wrote: > On Wed, 30 Nov 2022 at 12:40, Richard Purdie > wrote: > > > To be clear, we don't run ptests on 32 bit targets, only on > > qemux86-64 and qemuarm64 where we have KVM available. We do run > > image, sdk and eSDK tests on our supported qemu targets, 32 and 64 > > bit. > > I think kvm does allow 32 bit guest on a 64 bit host. +1 IIRC the MACH=qemux86 was working correctly... > But I can > imagine making full ptests work on 32 bit guests Maybe only subset of ptests - i.e. those related to Y2038 could be run? > would be a struggle > for reasons unrelated to 2038, specifically lack of users outside of > embedded world. > > Alex Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpWOBF1a_wZb.pgp Description: OpenPGP digital signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58674): https://lists.yoctoproject.org/g/yocto/message/58674 Mute This Topic: https://lists.yoctoproject.org/mt/95355888/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [yocto] Y2038 proposal
On Wed, 2022-11-30 at 13:07 +0100, Alexander Kanavin wrote: > On Wed, 30 Nov 2022 at 12:40, Richard Purdie > wrote: > > > To be clear, we don't run ptests on 32 bit targets, only on qemux86-64 > > and qemuarm64 where we have KVM available. We do run image, sdk and > > eSDK tests on our supported qemu targets, 32 and 64 bit. > > I think kvm does allow 32 bit guest on a 64 bit host. For x86, yes. For arm, it varies and I know at least one of our arm hosts doesn't support it, I don't know about the newer ones. > But I can imagine making full ptests work on 32 bit guests would be a > struggle > for reasons unrelated to 2038, specifically lack of users outside of > embedded world. In general I think it shouldn't be too bad but we really do need to test it and see. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58675): https://lists.yoctoproject.org/g/yocto/message/58675 Mute This Topic: https://lists.yoctoproject.org/mt/95355888/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] How to enabled systemd unit files automatically using recipe?
I have a question here:
If I something like below in my recipe
SYSTEMD_SERVICE:${PN} = "${@bb.utils.contains('DISTRO_FEATURES', 'systemd',
'one.service', '', d)}"
Then, can I add multiple files with:
SYSTEMD_SERVICE:${PN} = "${@bb.utils.contains('DISTRO_FEATURES', 'systemd',
'one.service one.path two.service two.path', '', d)}"
?
Is this valid? Or should I use only SYSTEMD_SERVICE:${PN} = "one.service
two.service one.path two.path" ?
Thanks in advance
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58676): https://lists.yoctoproject.org/g/yocto/message/58676
Mute This Topic: https://lists.yoctoproject.org/mt/94553177/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [Openembedded-architecture] Y2038 proposal
On Wed, 2022-11-30 at 09:07 +0100, Alexander Kanavin wrote: > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley wrote: > > We’d welcome a proposal/series on how to move forward with the Y2038 work > > for 32 bit platforms. > > I have the following proposal: > > 1. A branch is made where: > a. "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" is enabled globally. > b. qemu is always started with "-rtc base=2040-01-01", simulating > Y2038 actually occurring. > c. an additional runtime test verifies that both RTC clock and system > clock report 2040. > > 2. This branch is run through a-full on the autobuilder. Any uncovered > issues are filed as bugs. > > 3. Once *all* of the bugs are addressed, repeat point 2. > > 4. Once there are no more open bugs, 1a is merged into master. > > Any fatal flaws in the plan? Others have made some good comments. My thoughts: * We need to add some runtime tests to oeqa for this (in addition to the ptests) * We need to have a 32 bit ptest run on the autobuilder (qemux86 should work, not sure we can make qemuarm fast). Whether this is manually triggered, not sure. We could have a smaller set of ptests to run for it? * Could we optionally disable some of the glibc 32 bit function calls to ensure they're not being used? We don't really want to diverge from upstream glibc much though. * We need to work out how to communicate this change happened and have people "buy in" to it. The reason for that is that if someone has existing binaries, there could be problems using them after the change. We therefore need to be sure they are aware of it. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58677): https://lists.yoctoproject.org/g/yocto/message/58677 Mute This Topic: https://lists.yoctoproject.org/mt/95357215/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] [Openembedded-architecture] Y2038 proposal
Hi Richard, > On Wed, 2022-11-30 at 09:07 +0100, Alexander Kanavin wrote: > > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley > > wrote: > > > We’d welcome a proposal/series on how to move forward with the > > > Y2038 work for 32 bit platforms. > > > > I have the following proposal: > > > > 1. A branch is made where: > > a. "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" is enabled globally. > > b. qemu is always started with "-rtc base=2040-01-01", simulating > > Y2038 actually occurring. > > c. an additional runtime test verifies that both RTC clock and > > system clock report 2040. > > > > 2. This branch is run through a-full on the autobuilder. Any > > uncovered issues are filed as bugs. > > > > 3. Once *all* of the bugs are addressed, repeat point 2. > > > > 4. Once there are no more open bugs, 1a is merged into master. > > > > Any fatal flaws in the plan? > > Others have made some good comments. My thoughts: > > * We need to add some runtime tests to oeqa for this (in addition to > the ptests) > > * We need to have a 32 bit ptest run on the autobuilder (qemux86 > should work, not sure we can make qemuarm fast). Whether this is > manually triggered, not sure. We could have a smaller set of ptests > to run for it? Y2038 ptests maybe? Here is the list of integrated tests to ptests: https://github.com/lmajewski/y2038-tests > > * Could we optionally disable some of the glibc 32 bit function calls > to ensure they're not being used? Could you be more specific here? Would you like to disable some syscalls? > We don't really want to diverge from > upstream glibc much though. Could you be more specific here? The glibc now supports the whole set of syscalls as of 2.34 version? To enable them one needs to pass -D_TIME_BITS=64 flag when compiling programs. This is now the official glibc ABI. > > * We need to work out how to communicate this change happened and have > people "buy in" to it. Ok. > The reason for that is that if someone has > existing binaries, there could be problems using them after the > change. The binary shall work without issues on glibc 2.34+ and 5.10+ kernel without issues. The only problem happens when new binaries with 64 bit time support are run on glibc or kernel not supporting 64 bit time. > We therefore need to be sure they are aware of it. > > Cheers, > > Richard > > > > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpFXqfNXSdfb.pgp Description: OpenPGP digital signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58678): https://lists.yoctoproject.org/g/yocto/message/58678 Mute This Topic: https://lists.yoctoproject.org/mt/95357621/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] [Openembedded-architecture] Y2038 proposal
On Wed, 2022-11-30 at 14:36 +0100, Lukasz Majewski wrote: > > On Wed, 2022-11-30 at 09:07 +0100, Alexander Kanavin wrote: > > > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley > > > wrote: > > > > We’d welcome a proposal/series on how to move forward with the > > > > Y2038 work for 32 bit platforms. > > > > > > I have the following proposal: > > > > > > 1. A branch is made where: > > > a. "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" is enabled globally. > > > b. qemu is always started with "-rtc base=2040-01-01", simulating > > > Y2038 actually occurring. > > > c. an additional runtime test verifies that both RTC clock and > > > system clock report 2040. > > > > > > 2. This branch is run through a-full on the autobuilder. Any > > > uncovered issues are filed as bugs. > > > > > > 3. Once *all* of the bugs are addressed, repeat point 2. > > > > > > 4. Once there are no more open bugs, 1a is merged into master. > > > > > > Any fatal flaws in the plan? > > > > Others have made some good comments. My thoughts: > > > > * We need to add some runtime tests to oeqa for this (in addition to > > the ptests) > > > > * We need to have a 32 bit ptest run on the autobuilder (qemux86 > > should work, not sure we can make qemuarm fast). Whether this is > > manually triggered, not sure. We could have a smaller set of ptests > > to run for it? > > Y2038 ptests maybe? > > Here is the list of integrated tests to ptests: > https://github.com/lmajewski/y2038-tests Perhaps, yes. > > * Could we optionally disable some of the glibc 32 bit function calls > > to ensure they're not being used? > > Could you be more specific here? Would you like to disable some > syscalls? I'm meaning disabling the 32 bit glibc time functions. > > We don't really want to diverge from > > upstream glibc much though. > > Could you be more specific here? The glibc now supports the whole set > of syscalls as of 2.34 version? > > To enable them one needs to pass -D_TIME_BITS=64 flag when compiling > programs. > > This is now the official glibc ABI. Right, but the 32 bit time functions/symbols are still available for older binaries. My point is that anything using those older functions is likely in need of attention so for Yocto Project/OE usage, identifying those would be helpful. If we were to disable them, that would make such usage very obvious. > > > The reason for that is that if someone has > > existing binaries, there could be problems using them after the > > change. > > The binary shall work without issues on glibc 2.34+ and 5.10+ kernel > without issues. Not necessarily. If it were a binary library, compiled with 32 bit time_t, new binaries using it would use a different sized field. > The only problem happens when new binaries with 64 bit time support are > run on glibc or kernel not supporting 64 bit time. That is definitely not the only problem. Some of the problems are unlikely but we do need to consider them. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58679): https://lists.yoctoproject.org/g/yocto/message/58679 Mute This Topic: https://lists.yoctoproject.org/mt/95357621/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] Add user to group that's created in other recipe
Hi,
I have intermittent problems with a recipe that creates a user that is member
of groups that are created by a different recipe. This is the recipe that
creates the groups:
# recipe-a.bb
inherit useradd
USERADD_PACKAGES = "${PN}"
GROUPADD_PARAM:${PN} = "--system gpio;--system i2c"
This is the recipe that creates the user:
# recipe-b.bb
inherit useradd
USERADD_PACKAGES = "${PN}"
GROUPADD_PARAM:${PN} = "--system mygroup"
GROUPS = "dialout,mygroup,gpio,i2c"
USERADD_PARAM:${PN} = "--system --no-create-home --shell /bin/false
--no-user-group --groups ${GROUPS} myuser"
DEPENDS = "recipe-a"
I guess it's also worth pointing out, that I use useradd-static:
USERADDEXTENSION = "useradd-staticids"
USERADD_ERROR_DYNAMIC = "error"
USERADD_UID_TABLES = "files/passwd"
USERADD_GID_TABLES = "files/group"
Every now and then I get and error in recipe_b's do_package_setscene task where
useradd complains that one of the groups provided by recipe_a does not exist.
This appears to be a race condition since most of the times, this works OK. I
was under the impression that specifying DEPENDS="recipe-a" in recipe_b.bb
would be enough to declare this dependency. What am I doing wrong?
Best regards,
Sven
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58680): https://lists.yoctoproject.org/g/yocto/message/58680
Mute This Topic: https://lists.yoctoproject.org/mt/95359282/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [Openembedded-architecture] Y2038 proposal
On Wed, Nov 30, 2022 at 12:08 AM Alexander Kanavin wrote: > > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley wrote: > > We’d welcome a proposal/series on how to move forward with the Y2038 work > > for 32 bit platforms. > > I have the following proposal: > > 1. A branch is made where: > a. "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" is enabled globally. I have something like this on yoe/mut branch on contrib repo ( due to musl removing the LFS hacks). However there are packages which need to be fixed at build time. > b. qemu is always started with "-rtc base=2040-01-01", simulating > Y2038 actually occurring. this is a good time machine :) > c. an additional runtime test verifies that both RTC clock and system > clock report 2040. > > 2. This branch is run through a-full on the autobuilder. Any uncovered > issues are filed as bugs. > > 3. Once *all* of the bugs are addressed, repeat point 2. > > 4. Once there are no more open bugs, 1a is merged into master. > > Any fatal flaws in the plan? > Not much issues except that package fixes may need to be carried locally for a while. > It's not hard to see that Y2038 problem is real and serious, e.g. on > qemux86 core-image-full-cmdline built from master: > > root@qemux86:~# ls / > bin boot devetc home liblost+found media mntproc > run sbin sys tmp usrvar > root@qemux86:~# date -s "2040-01-01" > Sun Jan 1 00:00:00 UTC 2040 > root@qemux86:~# ls / > bin boot devetc home liblost+found media mntproc > run sbin sys tmp usrvar > root@qemux86:~# ls / > -sh: ls: command not found > > On qemux86_64 the same sequence works as expected, of course. > > Alex > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58681): https://lists.yoctoproject.org/g/yocto/message/58681 Mute This Topic: https://lists.yoctoproject.org/mt/95361830/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] [Openembedded-architecture] Y2038 proposal
On 30 Nov 2022, at 14:20, Richard Purdie via lists.yoctoproject.org wrote: >>> * Could we optionally disable some of the glibc 32 bit function calls >>> to ensure they're not being used? >> >> Could you be more specific here? Would you like to disable some >> syscalls? > > I'm meaning disabling the 32 bit glibc time functions. Some time ago I filed https://bugzilla.yoctoproject.org/show_bug.cgi?id=6803 as Debian has a nice sanity check where it warns if non-LFS glibc functions are used. I imagine the same logic could be used to check for 32-bit time_t use. Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58682): https://lists.yoctoproject.org/g/yocto/message/58682 Mute This Topic: https://lists.yoctoproject.org/mt/95357621/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] [Openembedded-architecture] Y2038 proposal
On 30/11/2022 16:46:17+, Ross Burton wrote: > On 30 Nov 2022, at 14:20, Richard Purdie via lists.yoctoproject.org > wrote: > >>> * Could we optionally disable some of the glibc 32 bit function calls > >>> to ensure they're not being used? > >> > >> Could you be more specific here? Would you like to disable some > >> syscalls? > > > > I'm meaning disabling the 32 bit glibc time functions. > > Some time ago I filed https://bugzilla.yoctoproject.org/show_bug.cgi?id=6803 > as Debian has a nice sanity check where it warns if non-LFS glibc functions > are used. I imagine the same logic could be used to check for 32-bit time_t > use. > We can simply disable COMPAT_32BIT_TIME in the kernel config. > Ross > > > -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58683): https://lists.yoctoproject.org/g/yocto/message/58683 Mute This Topic: https://lists.yoctoproject.org/mt/95357621/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] [Openembedded-architecture] Y2038 proposal
On Wed, 2022-11-30 at 17:56 +0100, Alexandre Belloni wrote: > On 30/11/2022 16:46:17+, Ross Burton wrote: > > On 30 Nov 2022, at 14:20, Richard Purdie via lists.yoctoproject.org > > wrote: > > > > > * Could we optionally disable some of the glibc 32 bit function calls > > > > > to ensure they're not being used? > > > > > > > > Could you be more specific here? Would you like to disable some > > > > syscalls? > > > > > > I'm meaning disabling the 32 bit glibc time functions. > > > > Some time ago I filed > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=6803 as Debian > > has a nice sanity check where it warns if non-LFS glibc functions > > are used. I imagine the same logic could be used to check for 32- > > bit time_t use. That sounds interesting and something we should probably look into for both issues... > > > > We can simply disable COMPAT_32BIT_TIME in the kernel config. That would cause runtime issues but not build time linking ones? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58684): https://lists.yoctoproject.org/g/yocto/message/58684 Mute This Topic: https://lists.yoctoproject.org/mt/95357621/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] OpenEmbedded Happy Hour November 30
Well, historically we used to have the OpenEmbedded Happy Hour after the sessions on the second day of the Yocto Project Summit and ask people to re-join a different Zoom room to socialize. This time around there's a dedicated YP Summit social time reserved, so to avoid switchig Zooms, we decided to move the OpenEmbedded Happy Hour to Friday, December 2, after the virtual Developers Meeting. The public calendar has been updated accordingly. Thank you. -- Denys On Tue, Nov 29, 2022 at 07:57:57PM +0100, Alexander Kanavin wrote: > Isn't that clashing with YPS social slot? > https://summit.yoctoproject.org/yocto-project-summit-2022-11/talk/UBXLG8/ > > Alex > > On Tue, 29 Nov 2022 at 14:15, Denys Dmytriyenko wrote: > > > > All, > > > > This month OpenEmbedded Happy Hour coincides with the Yocto Project Summit > > and will be held on Wednesday, November 30 after the sessions are over, > > aroud 1800/6pm UTC (1pm ET / 10am PT). The usual Zoom link is in the Wiki: > > > > https://www.openembedded.org/wiki/Calendar > > https://www.openembedded.org/wiki/Happy_Hours -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58685): https://lists.yoctoproject.org/g/yocto/message/58685 Mute This Topic: https://lists.yoctoproject.org/mt/95341821/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Y2038 proposal
On Wed, 30 Nov 2022 at 09:28, Lukasz Majewski wrote: > 2. There are ptest available [2] to validate if the Y2038 problem works > correctly. > > 3. Support for running ptests mentioned in point 2. is already > available in the poky repository [3]. I just ran these tests in (32 bit) qemux86 on top of poky master (e.g. no magic glibc flags), and they all passed. Do they need to be ran after setting the date to the 'post-2038 future' to reveal the issues and produce failures? Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58686): https://lists.yoctoproject.org/g/yocto/message/58686 Mute This Topic: https://lists.yoctoproject.org/mt/95354041/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Add user to group that's created in other recipe
On Wed, 2022-11-30 at 06:55 -0800, Sven via lists.yoctoproject.org
wrote:
> I have intermittent problems with a recipe that creates a user that
> is member of groups that are created by a different recipe. This is
> the recipe that creates the groups:
>
> # recipe-a.bb
> inherit useradd
> USERADD_PACKAGES = "${PN}"
> GROUPADD_PARAM:${PN} = "--system gpio;--system i2c"
>
> This is the recipe that creates the user:
>
> # recipe-b.bb
> inherit useradd
> USERADD_PACKAGES = "${PN}"
> GROUPADD_PARAM:${PN} = "--system mygroup"
> GROUPS = "dialout,mygroup,gpio,i2c"
> USERADD_PARAM:${PN} = "--system --no-create-home --shell /bin/false -
> -no-user-group --groups ${GROUPS} myuser"
> DEPENDS = "recipe-a"
>
> I guess it's also worth pointing out, that I use useradd-static:
> USERADDEXTENSION = "useradd-staticids"
> USERADD_ERROR_DYNAMIC = "error"
> USERADD_UID_TABLES = "files/passwd"
> USERADD_GID_TABLES = "files/group"
>
> Every now and then I get and error in recipe_b's do_package_setscene
> task where useradd complains that one of the groups provided by
> recipe_a does not exist. This appears to be a race condition since
> most of the times, this works OK. I was under the impression that
> specifying DEPENDS="recipe-a" in recipe_b.bb would be enough to
> declare this dependency. What am I doing wrong?
Just to confirm, this is with master?
I think there are some open bugs for useradd issues like this. It is
supposed to work but sounds like there are races. If there isn't a bug
open for it, there probably should be.
Sadly we don't have many people interested in working on issues like
this so I can't say when it might get fixed, we do our best!
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58687): https://lists.yoctoproject.org/g/yocto/message/58687
Mute This Topic: https://lists.yoctoproject.org/mt/95359282/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Add user to group that's created in other recipe
One way I have gotten around this is by using an .inc file to create the
users/groups and then the recipes that need the user/group require/include
that .inc file.
On Wed, Nov 30, 2022 at 3:05 PM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> On Wed, 2022-11-30 at 06:55 -0800, Sven via lists.yoctoproject.org
> wrote:
> > I have intermittent problems with a recipe that creates a user that
> > is member of groups that are created by a different recipe. This is
> > the recipe that creates the groups:
> >
> > # recipe-a.bb
> > inherit useradd
> > USERADD_PACKAGES = "${PN}"
> > GROUPADD_PARAM:${PN} = "--system gpio;--system i2c"
> >
> > This is the recipe that creates the user:
> >
> > # recipe-b.bb
> > inherit useradd
> > USERADD_PACKAGES = "${PN}"
> > GROUPADD_PARAM:${PN} = "--system mygroup"
> > GROUPS = "dialout,mygroup,gpio,i2c"
> > USERADD_PARAM:${PN} = "--system --no-create-home --shell /bin/false -
> > -no-user-group --groups ${GROUPS} myuser"
> > DEPENDS = "recipe-a"
> >
> > I guess it's also worth pointing out, that I use useradd-static:
> > USERADDEXTENSION = "useradd-staticids"
> > USERADD_ERROR_DYNAMIC = "error"
> > USERADD_UID_TABLES = "files/passwd"
> > USERADD_GID_TABLES = "files/group"
> >
> > Every now and then I get and error in recipe_b's do_package_setscene
> > task where useradd complains that one of the groups provided by
> > recipe_a does not exist. This appears to be a race condition since
> > most of the times, this works OK. I was under the impression that
> > specifying DEPENDS="recipe-a" in recipe_b.bb would be enough to
> > declare this dependency. What am I doing wrong?
>
> Just to confirm, this is with master?
>
> I think there are some open bugs for useradd issues like this. It is
> supposed to work but sounds like there are races. If there isn't a bug
> open for it, there probably should be.
>
> Sadly we don't have many people interested in working on issues like
> this so I can't say when it might get fixed, we do our best!
>
> Cheers,
>
> Richard
>
>
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58688): https://lists.yoctoproject.org/g/yocto/message/58688
Mute This Topic: https://lists.yoctoproject.org/mt/95359282/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] LAYERSERIES_COMPAT_ variable in the layer's recipe
Hello to Yocto community,
As I am much more passive yocto wise these few years ( working on
Android build systems and around, this is also a nightmare, I should
say ;-) ), I have one Yocto question which I never really understood.
I will ask it by example. I have one layer for the CAN tools and apps
which I have created 4 years ago:
https://github.com/ZoranStojsavljevic/meta-socketcan
In there, in conf/layer.conf:
https://github.com/ZoranStojsavljevic/meta-socketcan/blob/master/conf/layer.conf
I have the following line (layers' compatibility):
LAYERSERIES_COMPAT_meta-socketcan = "sumo thud warrior zeus dunfell
gatesgarth hardknott honister kirkstone"
I do not understand why we need to explicitly name releases for such
simple generic layers?!
Instead, for a virtual example:
LAYERSERIES_COMPAT_meta-socketcan = "${AUTOLAYER x}"
So all the layers might be included (or for at least lets say x = 4
latest releases, where x = 0 would be include all)? I do understand
that complex layers could NOT have such a definition (because of the
dependencies), but for the generic layers (as such presented), this
would be beneficial.
Thank you for the answers,
Zee
___
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58689): https://lists.yoctoproject.org/g/yocto/message/58689
Mute This Topic: https://lists.yoctoproject.org/mt/95375670/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] LAYERSERIES_COMPAT_ variable in the layer's recipe
On Wed, Nov 30, 2022, 20:27 Zoran wrote:
> Hello to Yocto community,
>
> As I am much more passive yocto wise these few years ( working on
> Android build systems and around, this is also a nightmare, I should
> say ;-) ), I have one Yocto question which I never really understood.
>
> I will ask it by example. I have one layer for the CAN tools and apps
> which I have created 4 years ago:
> https://github.com/ZoranStojsavljevic/meta-socketcan
>
> In there, in conf/layer.conf:
>
> https://github.com/ZoranStojsavljevic/meta-socketcan/blob/master/conf/layer.conf
>
> I have the following line (layers' compatibility):
> LAYERSERIES_COMPAT_meta-socketcan = "sumo thud warrior zeus dunfell
> gatesgarth hardknott honister kirkstone"
>
> I do not understand why we need to explicitly name releases for such
> simple generic layers?!
>
To me this indicates that the maintainer of the layer has tested the
compatibility of his layer with all of these releases of the Yocto Project.
A maintainer of a layer should make a deliberate decision of adding a
release or dropping one from the compatibility list. It should be an
attestation that the layer's compatibility with the releases in the list is
actually maintained and tested.
There have been changes to the syntax to conditional variables. Your layer
might well be compatible with all of the releases and it's great if you
tested it. But it's not a given.
>
> Instead, for a virtual example:
> LAYERSERIES_COMPAT_meta-socketcan = "${AUTOLAYER x}"
>
> So all the layers might be included (or for at least lets say x = 4
> latest releases, where x = 0 would be include all)? I do understand
> that complex layers could NOT have such a definition (because of the
> dependencies), but for the generic layers (as such presented), this
> would be beneficial.
>
I never cared for ${AUTOREV}, which is similar, in the first place for the
very reason that it creates inconsistent behavior. This would do the same
thing. What would the last 4 releases even mean? What is the reference and
where is it obtained from?
>
> Thank you for the answers,
> Zee
___
>
Best,
:rjs
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58690): https://lists.yoctoproject.org/g/yocto/message/58690
Mute This Topic: https://lists.yoctoproject.org/mt/95375670/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] LAYERSERIES_COMPAT_ variable in the layer's recipe
Agreed with Rudolf.
If the layer maintainer didn't bother to do at least do one build with new
release and adjust LAYERSERIES_COMPAT, then I don't consider that layer
well maintained (it could be someone else who uses the layer, tests it with
new release and sends PR to adjust LAYERSERIES_COMPAT).
Recently I've also seen this:
LAYERSERIES_COMPAT_phytec = "${LAYERSERIES_COMPAT_core}"
which is also bad as it completely disables the check (seen in
https://git.phytec.de/meta-phytec/tree/conf/layer.conf#n14).
On Thu, Dec 1, 2022 at 7:06 AM Rudolf J Streif
wrote:
>
>
> On Wed, Nov 30, 2022, 20:27 Zoran wrote:
>
>> Hello to Yocto community,
>>
>> As I am much more passive yocto wise these few years ( working on
>> Android build systems and around, this is also a nightmare, I should
>> say ;-) ), I have one Yocto question which I never really understood.
>>
>> I will ask it by example. I have one layer for the CAN tools and apps
>> which I have created 4 years ago:
>> https://github.com/ZoranStojsavljevic/meta-socketcan
>>
>> In there, in conf/layer.conf:
>>
>> https://github.com/ZoranStojsavljevic/meta-socketcan/blob/master/conf/layer.conf
>>
>> I have the following line (layers' compatibility):
>> LAYERSERIES_COMPAT_meta-socketcan = "sumo thud warrior zeus dunfell
>> gatesgarth hardknott honister kirkstone"
>>
>> I do not understand why we need to explicitly name releases for such
>> simple generic layers?!
>>
>
> To me this indicates that the maintainer of the layer has tested the
> compatibility of his layer with all of these releases of the Yocto Project.
>
> A maintainer of a layer should make a deliberate decision of adding a
> release or dropping one from the compatibility list. It should be an
> attestation that the layer's compatibility with the releases in the list is
> actually maintained and tested.
>
> There have been changes to the syntax to conditional variables. Your layer
> might well be compatible with all of the releases and it's great if you
> tested it. But it's not a given.
>
>>
>> Instead, for a virtual example:
>> LAYERSERIES_COMPAT_meta-socketcan = "${AUTOLAYER x}"
>>
>> So all the layers might be included (or for at least lets say x = 4
>> latest releases, where x = 0 would be include all)? I do understand
>> that complex layers could NOT have such a definition (because of the
>> dependencies), but for the generic layers (as such presented), this
>> would be beneficial.
>>
>
> I never cared for ${AUTOREV}, which is similar, in the first place for the
> very reason that it creates inconsistent behavior. This would do the same
> thing. What would the last 4 releases even mean? What is the reference and
> where is it obtained from?
>
>>
>> Thank you for the answers,
>> Zee
>
> ___
>>
>
> Best,
> :rjs
>
>>
>>
>>
>>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58691): https://lists.yoctoproject.org/g/yocto/message/58691
Mute This Topic: https://lists.yoctoproject.org/mt/95375670/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Add user to group that's created in other recipe
On Thu, Dec 1, 2022 at 12:05 AM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> On Wed, 2022-11-30 at 06:55 -0800, Sven via lists.yoctoproject.org
> wrote:
> > I have intermittent problems with a recipe that creates a user that
> > is member of groups that are created by a different recipe. This is
> > the recipe that creates the groups:
> >
> > # recipe-a.bb
> > inherit useradd
> > USERADD_PACKAGES = "${PN}"
> > GROUPADD_PARAM:${PN} = "--system gpio;--system i2c"
> >
> > This is the recipe that creates the user:
> >
> > # recipe-b.bb
> > inherit useradd
> > USERADD_PACKAGES = "${PN}"
> > GROUPADD_PARAM:${PN} = "--system mygroup"
> > GROUPS = "dialout,mygroup,gpio,i2c"
> > USERADD_PARAM:${PN} = "--system --no-create-home --shell /bin/false -
> > -no-user-group --groups ${GROUPS} myuser"
> > DEPENDS = "recipe-a"
> >
> > I guess it's also worth pointing out, that I use useradd-static:
> > USERADDEXTENSION = "useradd-staticids"
> > USERADD_ERROR_DYNAMIC = "error"
> > USERADD_UID_TABLES = "files/passwd"
> > USERADD_GID_TABLES = "files/group"
> >
> > Every now and then I get and error in recipe_b's do_package_setscene
> > task where useradd complains that one of the groups provided by
> > recipe_a does not exist. This appears to be a race condition since
> > most of the times, this works OK. I was under the impression that
> > specifying DEPENDS="recipe-a" in recipe_b.bb would be enough to
> > declare this dependency. What am I doing wrong?
>
> Just to confirm, this is with master?
>
> I think there are some open bugs for useradd issues like this. It is
> supposed to work but sounds like there are races. If there isn't a bug
> open for it, there probably should be.
>
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13904 is one of the bugs
I think.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58692): https://lists.yoctoproject.org/g/yocto/message/58692
Mute This Topic: https://lists.yoctoproject.org/mt/95359282/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
