On Sat, Jan 06, 2024 at 09:07:15AM +0100, Rene Engelhard wrote:
> 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?
> build failures/test failures.
> > As mentioned in other 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
> :)
Well, yes; though I hope we would see some help from e.g. arm porters if
there were actually breakage of this nature. Alternatively, maybe it would
be better to stop shipping libreoffice on 32-bit archs, in that case? I'm
not sure how usable libreoffice is these days on such archs.
popcon.debian.org doesn't appear to have the granularity to tell us if there
actually *are* users; and with only 615 armhf popcon reports (vs 215,562 on
amd64) we don't exactly have a statistically significant sample there.
> > > > - 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.
Most of these packages that are staged in experimental are going to be there
because of library transitions... so I think we definitely don't want to be
renaming those binary packages, they should just drop the t64 suffix when
they move to unstable.
> 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.)
Ok. I don't think there would be any need for you to wait before uploading
24.2. It might have to wait for time_t for testing migration, but <crossing
fingers> I don't think that should really be long.
> > > > 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)
Ah! These are packages that have been omitted from the analysis because
they've been manually identified as packages that don't have C or
C++-compatible header files related to a shared library, and therefore even
if they do need updated for 64-bit time_t, they are not affected by CPPFLAGS
and are not part of this transition. (I am not 100% sure this is accurate
for ObjC; in any case ObjC headers are impossible to analyze using
abi-compliance-checker so if ObjC libraries are possibly affected, someone
would have to figure out what to do with them.)
I'm not sure precisely why Adrien found it necessary/useful to add
libreoffice-dev to this exclude list, but I can confirm that it's
reasonable, as this particular package contains only a single header file
with #define's and no function prototypes; so in effect it has been manually
analyzed and determined to be unaffected.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: PGP signature