Greetings.
After we make a stable release, there is usually a constant flow
of packages which start to FTBFS due to "time bombs", i.e. expired
SSL certificates used in tests and other similar reasons.
This is not fun for anybody trying to keep stable free of FTBFS bugs,
but fortunately we can do better than that.
According to Paul Gevers, who allowed me to quote him on this, if we
know for sure that a package will FTBFS during the support time of
the release, then it's RC.
So, if we aim at releasing stable every two years, and we released bookworm
at 2023-06-10, then the estimated support timeframe for trixie will be approximately from 2025-06-10 to 2028-06-10 (two years as stable plus one
year as oldstable).
Therefore, I set my clock at 2028-06-10 and built trixie/sid on such date,
and found around 50 packages with time bomb issues of all kinds. A preliminary list of build logs is available here:
https://people.debian.org/~sanvila/build-logs/trixie-time-bomb/
Note that the above list of build logs does not necessarily match
1:1 with bugs that I will report. For example, in some cases the package tries to access Internet during build, which is usually already reported as a bug, but the build fails because in the future-setup the SSL certificate appears
as expired.
My plan is to file bug reports for the causing packages, initially
as severity:important bugs as a "grace period". (Paul asked me not to
report this as RC yet, because the t64 transition has not finished yet.
On the other hand, he also pointed out that now is the appropriate
time to report those bugs).
Some additional remarks:
* We should probably encourage upstream authors to avoid time-bombs in
general, either by generating test SSL certificates at build time, or by
other means.
* It would be wonderful if reproducible-builds people could set the time-to-build-in-future for trixie and sid to three years after the
estimated release date of trixie (I believe they use six months ahead
of time, which imo it's not enough).
* Implementation details, for anybody willing to do the same: There
are several ways to build packages in the future. The way it worked
for me, since I'm using sbuild and virtual machines, was like this:
- Uninstall packages like ntpsec or systemd-timesyncd which try to keep the clock in sync with reality.
- Use timedatectl to set the system clock to a future date.
- Create /etc/apt/apt.conf.d/check-valid-until-false with "Acquire::Check-Valid-Until false;" as its contents, using
the copyfiles mechanism of sbuild, so that apt does not complain
about Release files being expired (we know that it will not be
after the release of trixie).
(In either case, I can provide a virtual machine already configured
for this purpose to anybody who can't reproduce it easily, as I
already do for any other FTBFS bug I report).
Thanks.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)