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 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@...