Hi,
- Packages that could not be analyzed for whatever reason are still assumed to have an ABI that's sensitive to time_t and have to be included in the transition. Happily, due to improvements in this run of the number of packages that could successfully be analyzed, the number of libraries in this category has dropped from 1541 to 929, of which 69 have no reverse-dependencies at all. The final list of these header packages that could not be analyzed is attached, in case anyone still wants to identify that a library on this list whose ABI is not affected by time_t and should therefore be excluded from the transition. Note, however, that no effort has been made to filter out dev packages from this list that come from source packages containing OTHER dev packages that are known to have ABI breakage; for a number of the packages listed, further analysis would not change the outcome. (e.g. qt5-qmake failed to be analyzed, but qtbase-opensource-src also ships qtbase5-private-dev which shows time_t ABI sensitivity.)
[...]
My strawman proposal is to give this thread 2 weeks from today for feedback and further refinement, and also to further reduce the number of false-positives included in the transition. Then, starting on Jan 18: - dpkg will be uploaded to experimental with 64-bit time_t in the default flags
I think at that point in time one should know what breaks and whatnot. Archive rebuild?
(Probably in stages....)
- the source packages which need an ABI change
("source-packages"+"lfs-and-depends-time_t" will have sourceful NMUs to
I get that you probably want NMUs for not needing to ping every maintainer, but this is bad.
That e.g. would cause me to upload libreoffice 24.2 rc2 to sid
immediately when tagged end of next week to not have this caught
in the transition. (see also below for the comment about new
upstream versions in experimental.)
experimental with the new binary package names in order to clear binary NEW, in coordination
And what about skipped ones? When will those be tried?
Those also will need clear NEW if needed.
(And they might even FTBFS because the ABI did change and
ABI-assuming test break? Though I don't assume so for time_t, but
if time is passed around... I don't assume so, but...
At least that would be the case for libreoffice (and libreoffice-dev-common is in the affected set, which means some stuff relies on it...))
(Maybe even needing asm fixes)
- once these packages have all cleared binary NEW, the new dpkg defaults will be uploaded to unstable - the sourceful NMUs of the libraries will be reuploaded to unstable (without binaries, so that they can be promoted to testing without additional uploads).
Please let me know of any problems with this plan.
Also a problem is that experimental also might already contain totally unrelated updates like new upstream versions...
Regards,
Rene