On Sun, Jan 07, 2024 at 09:30:37AM +0100, Rene Engelhard wrote: > Am 07.01.24 um 02:01 schrieb Steve Langasek:
> > 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.
> Hope doesn't help when it got to the actual problem and this doesn't happen.
Relying on me or any *other* non-ARM porter to fix (hypothetical)
ARM-specific asm issues is also aspirational.
But also, I don't know what else you would propose here. We can't
practically hold libreoffice back from the time_t transition with
dpkg-buildflags overrides, it depends on other libraries that are also
affected (e.g. poppler); and 32-bit time_t is already on borrowed time. It
fails not when the *current* date reaches 2038, but when *any dates you want
to work with on the system* reach 2038. There are known instances already
of software failures due to this limitation, and this will only accelerate
with time. I don't think it's reasonable to postpone the transition.
(Also, the intention here was first posted to debian-devel 6 months ago, and
you didn't raise any objections then? So I don't think a hypothetical
concern in libreoffice asm should block things now.)
> > Alternatively, maybe it would
> > be better to stop shipping libreoffice on 32-bit archs, in that case? I'm
> I'd like to avoid this. Getting rid of i386 is fine, noone needs it, armhf
> is a bit different.
> (rpis etc - even though they could run arm64, but..)
I understand wanting to avoid it, but I think that should be the fallback
position if there are intractable porting problems. Losing libreoffice on
armhf is better than carrying 32-bit time_t forward.
As a data point, Ubuntu will only ship arm64 for raspi in 24.04, not armhf.
> > > > > > - 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...
> And ignore those who use experimental as a testbed of major new upstreams?
> Doesn't sound good.
The purpose of uploading to experimental is twofold.
- to clear binary NEW in an orderly fashion, and minimize the window of
possible misbuilds in unstable once dpkg lands there
- to let the usrmerge tooling run against the packages in experimental and
check for any issues there.
Of course, the second of these doesn't apply to libreoffice.
I hear you that you would like libreoffice to be included because of the
second point.
In another subthread I identified that 130 of the binary packages currently
in experimental are runtime libraries requiring name changes (from 64 source
packages). Since these are explicitly runtime library packages staged in
experimental whose binary package names have NOT changed, they do all need
source NMUs (i.e.: we can't simply promote these packages from experimental
to unstable and rebuild with new dpkg without changing the binary package
names).
This is enough packages that it seems fair to expect them to also have the
binary NEW handling done in experimental, not in unstable.
So I am convinced that we should do NMUs of these to experimental as well,
rather than uploading them straight to unstable.
Packages that already have new sonames in experimental should still NOT have
NMUs uploaded to experimental, because we don't want to add package name
annotations for the new not-yet-in-unstable soname.
So I think an algorithm for deciding the uploads to experimental looks like
this:
- download source from unstable.
- apply the packagename conversion to the source.
- grab the debdiff.
- submit the NMU diff to the BTS.
- download the source again from experimental (possibly a no-op).
- apply the debdiff to the source.
- if it fails to apply (meaning: debian/control has changed), skip.
otherwise, build and upload to experimental.
- after packages have cleared binary NEW, upload sourceful NMUs to unstable
for all these packages with the same debdiff as before.
- if there are any packages included in the uploads to unstable that were
skipped for experimental because of different sonames there, deal with
binary NEW then in unstable.
> > 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 have no idea on how you indentified it In the libreoffice case that is not
> true.
> libreoffice-dev-(common) *does* contain C/C++ header files.
> And most of them *do* correspond to the libuno* shared packages.
> Just that they are not split per library because that wouldn't really make
> sense since you need any of them anyway.
> And I definitely see
> e.g. /usr/include/libreoffice/osl/time.h (libuno-sal3)
> No idea whether it actually will be broken by the change, but...
> > I'm not sure precisely why Adrien found it necessary/useful to add
> > libreoffice-dev to this exclude list,
> Probably because he didn't look at the whole but just at the package
> > 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.
> But libreoffice-dev-common not (on which libreoffice-dev depends) which
> contains all the arch-indep headers. Just libreoffice-dev contains one
> header diferent between archs.
The determination for *libreoffice-dev* is correct. That's one particular
header package that was skipped because it was determined that the headers
contained within included no public function declarations.
The overall picture for libreoffice looks like:
results/results_dumped.txt:libreofficekit-dev
results/results_failed.txt:libreoffice-dev-common
results/results_none.txt:libreofficekit-dev
results/results_skipped.txt:libreoffice-dev
results/results_skipped.txt:libreoffice-dev-doc
and libreoffice the *source* package is included in the list of packages to
be handled in this transition. (Not because we've confirmed that the
library ABI is broken, but because libreoffice-dev-common failed to
analyze.)
--
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/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
