Re: [yocto] Y2038 proposal
Hi Alexander, > 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? Yes. You need to run them with adjusted date: date +'%Y-%m-%d %T' -s "2038-01-19 03:14:07" ptest-runner glibc-tests More info: https://github.com/lmajewski/meta-y2038/blob/master/README#L201 > > 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 pgpZZ7nYE2u3S.pgp Description: OpenPGP digital signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58693): https://lists.yoctoproject.org/g/yocto/message/58693 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: > 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] 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: [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: [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 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 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
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 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 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] -=-=-=-=-=-=-=-=-=-=-=-
