XPost: linux.debian.devel.release

Hello.

This is an update for my previous MBF announcement here:

https://lists.debian.org/debian-devel/2024/05/msg00414.html

I did another test rebuild and found 11 new packages failing
in the not-so-distant future. I also found another package
for which the fix was lost and the bug had to reopened.

The tag for the bugs being reported is here:

https://bugs.debian.org/cgi-bin/[email protected];tag=ftbfs-during-trixie-support-period

I was told that it was ok to consider those bugs as "RC for trixie"
but I was also requested to be nice when reporting those bugs, so I have
been reporting them as severity:normal (except when the future
suddenly arrives, like the few ones that started to fail on 2025-01-01).

Can the Release Managers suggest a calendar for raising those bugs,
first to important, then to serious?

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

Hi!

This is an update for my previous MBF announcement here:

https://lists.debian.org/debian-devel/2024/05/msg00414.html

I did another test rebuild and found 11 new packages failing
in the not-so-distant future. I also found another package
for which the fix was lost and the bug had to reopened.

Did you use libfaketime in this round of rebuilds? (https://lists.debian.org/debian-devel/2024/05/msg00422.html)? Do you
think it works well, should we add an extra job in Salsa CI that does
the build or runs autopkgtests under 'faketime 2028-06-30'? Or even
'faketime 2038-06-30' to cover 32-bit issues too?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

El 5/1/25 a las 21:07, Otto Kekäläinen escribió:

This is an update for my previous MBF announcement here:

https://lists.debian.org/debian-devel/2024/05/msg00414.html

I did another test rebuild and found 11 new packages failing
in the not-so-distant future. I also found another package
for which the fix was lost and the bug had to reopened.

Did you use libfaketime in this round of rebuilds? (https://lists.debian.org/debian-devel/2024/05/msg00422.html)? Do you
think it works well, should we add an extra job in Salsa CI that does
the build or runs autopkgtests under 'faketime 2028-06-30'? Or even
'faketime 2038-06-30' to cover 32-bit issues too?

Yes, it would be *really* nice to have an extra job in Salsa CI for that!

No, I did not use libfaketime yet (sorry). If you want to make a job
in Salsa you can just test with any of the affected packages above and
the (failed) build log should be very similar to the one I provided
in each of the bugs.

I would be more than happy if we could release trixie
without time-bombs, but of course if we can also test
for 2038-06-30, the better.

Maybe a common job which may be fine-tuned using a variable
for the cut date would allow to do that easily.

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

Thanks for encouragement. I filed https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/411 and will
continue research on libfaketime/datefudge in CI there.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

Em 5 de janeiro de 2025 15:28:24 GMT-05:00, Santiago Vila <[email protected]> escreveu:

El 5/1/25 a las 21:07, Otto Kekäläinen escribió:

This is an update for my previous MBF announcement here:

https://lists.debian.org/debian-devel/2024/05/msg00414.html

I did another test rebuild and found 11 new packages failing
in the not-so-distant future. I also found another package
for which the fix was lost and the bug had to reopened.

Did you use libfaketime in this round of rebuilds?
(https://lists.debian.org/debian-devel/2024/05/msg00422.html)? Do you
think it works well, should we add an extra job in Salsa CI that does
the build or runs autopkgtests under 'faketime 2028-06-30'? Or even
'faketime 2038-06-30' to cover 32-bit issues too?

Yes, it would be *really* nice to have an extra job in Salsa CI for that!

No, I did not use libfaketime yet (sorry). If you want to make a job
in Salsa you can just test with any of the affected packages above and
the (failed) build log should be very similar to the one I provided
in each of the bugs.

JFTR, faketime causes issues in the reprotest job:

https://salsa.debian.org/salsa-ci-team/pipeline/#faketime-is-currently-disabled

I would be more than happy if we could release trixie
without time-bombs, but of course if we can also test
for 2038-06-30, the better.

Maybe a common job which may be fine-tuned using a variable
for the cut date would allow to do that easily.

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[ moving technical discussion to -devel, as -release was
just to ask RM for a calendar to raise severities ]

[ Bcc to Holger on this one ]

El 5/1/25 a las 23:59, Holger Levsen escribió:

so what did you use?

I still change the system clock. So, the same you did.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

Hi,

* Otto Kekäläinen <[email protected]> [250105 21:54]:

Thanks for encouragement. I filed https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/411 and will continue research on libfaketime/datefudge in CI there.

as we've seen in the time_t-64 transition, programs that interpose
library calls like this are extremely hard to get right and very
brittle.

I would strongly suggest to not put new load-bearing stuff on top of
such a program, especially when the rest of Debian is trying to get
rid of fakeroot.

Maybe you can consider using a time namespace (unshare -T) and
change the system date/time in that namespace.

Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

On Sun, Jan 05, 2025 at 09:28:24PM +0100, Santiago Vila wrote:

Did you use libfaketime in this round of rebuilds?

No, I did not use libfaketime yet (sorry).

so what did you use?

setting the system time to the future (like we've been doing for tests.reproducible-builds.org/debian for many years) works nicely (with caveats) in a dedicated setup, but is nothing which can be done for salsa (except with dedicated future runners...)

using faketime just wont work for too many packages/languages/ecosystems.


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

No more excuses. Small actions can make a big difference. We recently switched to paper straws on both of my private jets. (@lcamtuf)

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmd7DuIACgkQCRq4Vgaa qhzMcQ/+ORMWBQ/61NZoOZPWHjwU0M9NyqlnrPUtNV6JfW2YV5/9QbDOHqi4+qm/ 3n4fjigXZdDteIGvOiMm++VHZ6QvNjFy7xrYJcoAam/Ggv1SZ8TzpVNlRU57Uthd w9jmw0uCfCMM7H1WeIeXUSOE3OAqaW4dhG/beAsKq9n9T2jasDexfb26B3pQ1mZs ZgxmWbJUa+757PXlufz7Zwkxrj+QBQxDsMmd4PAYZt1WNAx7kI4AwYW+PEjy9vPY 7DNVjExHginaRzM48TY/u+hIWP+kpY6IPaXiVCUzYd3tOfF5DTBmCg8IX4ydW4mk DxR09Jk3amx8MjSy8weFusuAnf0HnlsA8cKokv8peU1+3prljTgWgxHP6mSSAqQg f/kI/+UP+mxbSvDfCZZz4aRVzacsW0GSy18SeZp2jhU2iY7wY5dMq4DhrUVG+lZN cu4Jdys07+ETIO9YOKl6Cu26Rb3dFOfcWshtE+CkoR9Nve6YOKb9j+28MZpJE6+W SE3qlJjuhUouJqmUMXhvDfBuqzDXUlB3uVL6f0XuBSV+

On Sun, Jan 05, 2025 at 11:58:40PM +0100, Chris Hofstaedtler wrote:

Maybe you can consider using a time namespace (unshare -T) and
change the system date/time in that namespace.

I'd also strongly suggest to do a full archive rebuild in such namespace comparing that with a full archive rebuild in the presense to get data
how much failures there are, before putting this into CI on salsa or elsewhere..


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

The greatest danger in times of turbulence is not the turbulence;
it is to act with yesterdays logic. (Peter Drucker)

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmd7FJsACgkQCRq4Vgaa qhxHBRAAsHHI0v4J5xlkKKcDnz1Ih3VZQDBNlUp1OOIOH+cHxD/LNxeHsDfqjnVZ jpx7D5dt8weg4Qz27fWtfWD/OteAmZhcTkYECQjvwQSMmqYzEL6sDdvse7Cd+TIy c/FJbb9n85wqTGwAdvp6DcmzoUtx/TDXeGj3Rf1wtTBU29OdGmtQ344BPqvWFUxF eOsaWentxa1C+nb5fW7x8usWprC9LpX/gAvQrYJXMoICJHdcQ2aZH4Xw4k8fq6yW EPLYUCxwl81xdQh4EVSKHDLSJQLGFEEWmvW4XMUQtdWD/UtVrXvqQUZRSxBAMooR m0dZ+ddh6jDYVfasfBK5V9KIMJgNChCpnHLvwt0iUJGAnfeAVflN1Ee2Mz1otKeQ TGbEqk+n3zg8Cz0z6E+cxjvJDS4n8svBRl299a0oCeQTCu12TxCma+b6tNp0Yob0 mr5mhcUUIDglB5oSsFYePGUmgtU0fsuxInSELj7d85akFTh5+ArtwaDZIBLURxVE TQAV03CNZL/C5y9izbZke38rY5PGFPQCohU4FBbj0qGQCtTt2g/MNtZ8TxJO

XPost: linux.debian.devel.release

On Sun, 05 Jan 2025 at 23:58:40 +0100, Chris Hofstaedtler wrote:

as we've seen in the time_t-64 transition, programs that interpose
library calls like this are extremely hard to get right and very
brittle.

I would strongly suggest to not put new load-bearing stuff on top of
such a program, especially when the rest of Debian is trying to get
rid of fakeroot.

Yes, this; but unfortunately...

Maybe you can consider using a time namespace (unshare -T) and
change the system date/time in that namespace.

... this isn't a feature that time namespaces offer. Unless the
documentation in time_namespaces(7) is outdated, time namespaces currently
only namespace CLOCK_MONOTONIC* and CLOCK_BOOTTIME*, not CLOCK_REALTIME;
but it's CLOCK_REALTIME (and related clocks like CLOCK_TAI) that represent wall-clock time, so it's those clocks that you'd need to fake in order
to answer questions like "what would happen if we recompiled this package
5 years in the future?".

Simpler/higher-level functions like time() and gettimeofday() usually
use the same clock as CLOCK_REALTIME, except for functions like g_get_monotonic_time() that specifically say they use a monotonic clock.

This also means that time namespaces are not (yet) a way to run legacy
binaries post-2038 by telling them an earlier date.

As far as I know, both of those use-cases require either LD_PRELOAD
interposing (brittle and error-prone) or a virtual machine with its clock intentionally set incorrectly.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Chris Hofstaedtler <[email protected]>, 2025-01-05 23:58:

Maybe you can consider using a time namespace (unshare -T) and change
the system date/time in that namespace.

I don't think that would work. From time_namespaces(7):

"Note that time namespaces do not virtualize the CLOCK_REALTIME clock. Virtualization of this clock was avoided for reasons of complexity and
overhead within the kernel."

--
Jakub Wilk

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release
To: [email protected]
To: [email protected] (Debian Release Team)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------3l3Rn0jwzx032FXRR0C0VkrY
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

SGkgU2FudGlhZ28NCg0KU29ycnkgZm9yIGRyb3BwaW5nIHRoZSBiYWxsIG9uIHRoaXMuDQoN Ck9uIDA1LTAxLTIwMjUgMTc6NTYsIFNhbnRpYWdvIFZpbGEgd3JvdGU6DQo+IEkgd2FzIHRv bGQgdGhhdCBpdCB3YXMgb2sgdG8gY29uc2lkZXIgdGhvc2UgYnVncyBhcyAiUkMgZm9yIHRy aXhpZSINCj4gYnV0IEkgd2FzIGFsc28gcmVxdWVzdGVkIHRvIGJlIG5pY2Ugd2hlbiByZXBv cnRpbmcgdGhvc2UgYnVncywgc28gSSBoYXZlDQo+IGJlZW4gcmVwb3J0aW5nIHRoZW0gYXMg c2V2ZXJpdHk6bm9ybWFsIChleGNlcHQgd2hlbiB0aGUgZnV0dXJlDQo+IHN1ZGRlbmx5IGFy cml2ZXMsIGxpa2UgdGhlIGZldyBvbmVzIHRoYXQgc3RhcnRlZCB0byBmYWlsIG9uIDIwMjUt MDEtMDEpLg0KPiANCj4gQ2FuIHRoZSBSZWxlYXNlIE1hbmFnZXJzIHN1Z2dlc3QgYSBjYWxl bmRhciBmb3IgcmFpc2luZyB0aG9zZSBidWdzLA0KPiBmaXJzdCB0byBpbXBvcnRhbnQsIHRo ZW4gdG8gc2VyaW91cz8NCg0KV2hhdCBJIGhhZCBpbiBtaW5kIHdhcyB0aGF0IHlvdSdkIGZp bGUgdGhlIGJ1Z3MgYW5kIGFmdGVyIHNvbWUgdGltZSANCihzYXksIG9uZSBvciB0d28gbW9u dGhzKSByYWlzZWQgdGhlbSwgZ2l2aW5nIG1haW50YWluZXJzIGEgYml0IG1vcmUgdGltZSAN CnRoYW4gdXN1YWwgdG8gcmVhY3QgdG8gdGhpcyBub3ZlbCBjbGFzcyBvZiBSQyBidWdzIGFz IHlvdSd2ZSBub3cgc3RhcnRlZCANCnRvIGFjdGl2ZWx5IHRlc3QuIEkgY29uc2lkZXIgdGhl c2UgYnVncyBSQyBhcyB0aGV5IHdpbGwgZXhoaWJpdCANCnRoZW1zZWx2ZXMgYXMgRlRCRlMg ZHVyaW5nIHRoZSBzdGFibGUgcmVsZWFzZSBzdXBwb3J0IHBlcmlvZC4gU28gSSANCnN1Z2dl c3QgeW91IG1hcmsgdGhlc2UgYnVncyBhcyBSQyBub3csIHN1Y2ggdGhhdCB0aGV5IGNhbiBn ZXQgZml4ZWQgaW4gDQp0aW1lIGZvciB0aGUgdHJpeGllIHJlbGVhc2UuDQoNClBhdWwNCg0K


--------------3l3Rn0jwzx032FXRR0C0VkrY--

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmewYf0FAwAAAAAACgkQnFyZ6wW9dQp8 RQf+PtDQGax71/RAXZ2QxTEIhtsEBa7rAKQQnIGenzuKLifVt5MomTwCa6XBSHw0TFS3a3yOJVNR 8WlX9HrUJS0OAOPJvbPBjfUP2f8qZNds6H2hSw96MhHnMz/P9jplRYC1RkWBqF6mj6T78OSbLUCD tRe47b+9MMdvtbHc5ns7yKthQ6x9fI6sKc8QMJNP089+gl5SaIrDtjCyoUnHf9HXSszRmTpDarLP ohAzR/qAmFkglqMesc3ktpdHwcrvzeLDstHrIwA8FIddrvLXvpGcQaVCynEqGyzQ73uGYK3meKgt qZaw362W6v5v0sfQlEuI4acb6cJutO6B+8yugvrDUg==
=9k/H
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

El 15/2/25 a las 10:44, Paul Gevers escribió:

Can the Release Managers suggest a calendar for raising those bugs,
first to important, then to serious?

What I had in mind was that you'd file the bugs and after some time (say, one or two months) raised them, giving maintainers a bit more time than usual to react to this novel class of RC bugs as you've now started to actively test. I consider these

bugs RC as they will exhibit themselves as FTBFS during the stable release support period. So I suggest you mark these bugs as RC now, such that they can get fixed in time for the trixie release.

Thanks a lot. I filed a first round of bugs on 2024-08 and a second
round on 2024-12, then raised to important on 2025-01-27 as a reminder/ping.

Considering the average time all those bugs have been open (some on 2024-08, some on 2024-12), I think it fits the idea of waiting a little bit more time than usual, so I've just raised all of them to serious now.

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

On Sun, Jan 05, 2025 at 11:58:40PM +0100, Chris Hofstaedtler wrote:

Maybe you can consider using a time namespace (unshare -T) and
change the system date/time in that namespace.

As those jobs already run in throw away VM, just change the system time.
You have to change it back to be able to talk TLS later, but well.

Bastian

--
Genius doesn't work on an assembly line basis. You can't simply say,
"Today I will be brilliant."
-- Kirk, "The Ultimate Computer", stardate 4731.3

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Jan 5, 2025 at 11:56 AM Santiago Vila <[email protected]> wrote:

This is an update for my previous MBF announcement here:

Thank you for this wonderful project and for raising the severity to
serious since it's clearly easier to fix the bugs in Unstable now
rather than as Stable Updates later.

I think your next iteration of this could go further. The ELTS project
aims to provide security support for 10 years for a given Debian
release. While not all packages are included in its scope, it makes
sense that many of the packages that have test SSL certificates could
be security-sensitive packages.

Thank you,
Jeremy Bícha

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

El 20/3/25 a las 15:29, Jeremy Bícha escribió:

Thank you for this wonderful project and for raising the severity to
serious since it's clearly easier to fix the bugs in Unstable now
rather than as Stable Updates later.

Thanks go to the Release Managers, more specifically Paul Gevers,
who allowed me to consider this as RC. You know, Release Managers
are the ones who ultimately decide about RC-ness of bugs.

I think your next iteration of this could go further. The ELTS project
aims to provide security support for 10 years for a given Debian
release. While not all packages are included in its scope, it makes
sense that many of the packages that have test SSL certificates could
be security-sensitive packages.

This was a Debian-specific thing, and I don't work for the ELTS project
(nor I'm planning to do so), but of course they are free to do their
own tests and fix packages before they start to FTBFS in the LTS
distributions.

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)