Hi,
Am 05.01.24 um 09:17 schrieb Steve Langasek:
- 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