Hi,
If you say you are going to fix eventual breakage (and not ignoring the testHope doesn't help when it got to the actual problem and this doesn't happen.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
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..)
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.
Only recently I got https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059158. Maybe UI is not used much, but I can imagine people using it in paperless-ngx or other stuff.
I don't really want to bastardize those uses.
- the source packages which need an ABI change ("source-packages"+"lfs-and-depends-time_t" will have sourceful NMUs toI 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.
experimental with the new binary package names in order to clear binary NEW, in coordinationAnd 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 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...
Probably because he didn't look at the whole but just at the packageI'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.
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.
Regards,
Rene