Hi Steve,
Am 06.01.24 um 06:51 schrieb Steve Langasek:
- 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....)
What kind of breakage are you looking to avoid here? As mentioned in other
build failures/test failures.
points in the thread, regressions as a result of this change should be rare
and easy to fix. I do not think it's a good use of time / CPU power to do
test rebuilds for this instead of just landing the transition.
Here especially LibreOffices bridge code worries me.
That one is tied to ABI and calling conventions. I don't see time_t
mentioned there but "just" in the public libraries (sal), but I am not
sure what making a type bigger will cause.
(And since already
- i386 needs gcc-12 to build since otherwise the test fails
- armhf (and other archs like ppc64el and s390x) need Java disabled[1]
- without any help from any porter to prevent this - I *do* want to
avoid breakage here.
If you say you are going to fix eventual breakage (and not ignoring the
test results!) and if that means fixing asm on all affected archs, then
it's OK :)
- 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.)
What about the suggestion to not push changes to experimental for packages
that already have new versions in experimental, and do the binary package
renames in unstable instead, leaving the package in experimental alone?
If at all - *both*. At the same time.
But yes, that could work.
(In this specific case I an worrying that the transition will take some
time, and that I am stuck with 7.6.x instead of uploading 24.2 when it
is released.)
libreoffice libs only have one reverse-dep, zemberek-ooo; so the risk of
entanglement here is small anyway.
Except in poppler etc. transitions.. But yeah, nothing really uses the
C++ libs nowadays.
I think the above proposal, to skip packages already in experimental from
the set of uploads to experimental, would address your concern. It's not as
if there is going to be any time that it's ok to tell maintainers they can't
use experimental at all because we're doing this transition.
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?
What do you mean here by "skipped ones"?
https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/results_skipped.txt
(which incidentially contains libreoffice)
Regards,
Rene
[1] Ubuntu just ignores the test failures. No, not an option.
