Hi Alexander,

On Wed, 30 Nov 2022 at 09:28, Lukasz Majewski <lukma@...> 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: lukma@...

On Wed, 30 Nov 2022 at 09:28, Lukasz Majewski <lukma@...> 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

On Wed, 30 Nov 2022 at 11:52, Stephen John Smoogen <smooge@...> 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

On Wed, 30 Nov 2022 05:52:03 -0500
"Stephen John Smoogen" <smooge@...> wrote:

On Wed, 30 Nov 2022 at 03:08, Alexander Kanavin
<alex.kanavin@...> wrote:

On Tue, 29 Nov 2022 at 16:45, Stephen Jolley
<sjolley.yp.pm@...> 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: lukma@...

On 30/11/2022 09:07:50+0100, Alexander Kanavin wrote:

On Tue, 29 Nov 2022 at 16:45, Stephen Jolley <sjolley.yp.pm@...> 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 dev etc home lib lost+found media mnt proc
run sbin sys tmp usr var
root@qemux86:~# date -s "2040-01-01"
Sun Jan 1 00:00:00 UTC 2040
root@qemux86:~# ls /
bin boot dev etc home lib lost+found media mnt proc
run sbin sys tmp usr var
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

On Wed, 30 Nov 2022 at 10:40, Lukasz Majewski <lukma@...> 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

Hi Alexander,

On Wed, 30 Nov 2022 at 09:28, Lukasz Majewski <lukma@...> 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: lukma@...

On Wed, 30 Nov 2022 at 09:28, Lukasz Majewski <lukma@...> 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

Hi Alexander,

On Tue, 29 Nov 2022 at 16:45, Stephen Jolley
<sjolley.yp.pm@...> 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 dev etc home lib lost+found media mnt proc
run sbin sys tmp usr var
root@qemux86:~# date -s "2040-01-01"
Sun Jan 1 00:00:00 UTC 2040
root@qemux86:~# ls /
bin boot dev etc home lib lost+found media mnt proc
run sbin sys tmp usr var
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: lukma@...

On Tue, 29 Nov 2022 at 16:45, Stephen Jolley <sjolley.yp.pm@...> 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 dev etc home lib lost+found media mnt proc
run sbin sys tmp usr var
root@qemux86:~# date -s "2040-01-01"
Sun Jan 1 00:00:00 UTC 2040
root@qemux86:~# ls /
bin boot dev etc home lib lost+found media mnt proc
run sbin sys tmp usr var
root@qemux86:~# ls /
-sh: ls: command not found

On qemux86_64 the same sequence works as expected, of course.

Alex