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.
