Re: 64-bit time_t: an update
Hi all, Quoting Steve Langasek (2023-07-19 23:27:21) [snip] > The "good" news is that, although there are over 1500 -dev packages yet to > be analyzed, we have prioritized libraries based on the number of > reverse-dependencies and therefore these 1500 -dev packages have among them > less than 300 reverse-build-dependencies that have not already been > identified as part of the transition (800 of these -dev packages have no > reverse-build-dependencies at all). > > Therefore, I would like to propose the following. > > - Assume the remaining 1500 -dev packages are affected by the ABI breakage. > This will increase the number of library packages included in the > transition requiring sourceful uploads from < 500 to 2000[1], but will > only increase the number of packages requiring rebuilds from 5300 to 5600. > > - Agree a target window together with the Release Team for when the > transition will be uploaded to unstable; and based on this, set a deadline > beforehand for finalizing the list of library packages whose binary > package names will be changed. > > - We in Ubuntu Foundations will continue on a best effort basis to drive > down the list of -dev packages which cannot be analyzed, until that > deadline. > > - Any party (maintainer or otherwise) interested in having some of these > library packages excluded from the transition is welcome to contribute > fixes up to that deadline that will let us analyze them and show that the > ABI has not changed. In order to avoid duplicating efforts, I've created a wiki page listing all the packages that are still to be dealt with: https://wiki.debian.org/ArmhfTimeTTodo It's fairly crude, but hopefully enough for the purpose. I'll be working the entire week on reducing that list, so if anyone joining in the fun wants to discuss it, feel free to ping me on IRC (schopin). Cheers -- Simon Chopin Foundations TeamUbuntu MOTU/Core Dev simon.cho...@canonical.comscho...@ubuntu.com
Re: 64-bit time_t: an update
On Thu, Jul 20, 2023 at 12:30:50AM +0100, Simon McVittie wrote: > On Wed, 19 Jul 2023 at 14:27:21 -0700, Steve Langasek wrote: > > to understand the impact that a change to the size of > > time_t will have on a library's ABI, it must be possible to compile the > > headers that expose that API > Would the results of this analysis also be suitable for telling > interested maintainers whether it's safe to opt-in a library to LFS > and/or 64-bit time_t on i386, so that it will use 64-bit-time_t-safe > glibc functions internally? > (For example libdbus is already opted-in to LFS, and I'm reasonably > sure it doesn't break public ABI under 64-bit time_t either, because it > has a policy of avoiding most inclusions of system headers in its own > public API) Yes, there's sufficient information in the analysis to determine this. > > The Ubuntu Foundations team have been putting in effort over the past two > > months, package-by-package, to figure out how to make them compile so that > > we know if their ABI is affected. > Is there a reasonably simple way that interested developers can try this > process for a package that they maintain? Thanks for the PR[0] :) > I realise your analysis has been done on armhf, but i386 would probably be > an easier (and faster!) 32-bit architecture to deal with for many > developers, even though we don't intend to do the 64-bit time_t transition > systematically on i386. Yes, for individual package analysis in Debian, i386 is likely better. If we're not actually doing 64-bit time_t for i386, it's better to use armhf for the list of -dev packages to analyze - second to i386, it's going to have the highest number of arch-specific -dev packages of any 32-bit arch. And in Ubuntu of course, we've already dropped the vast majority of these packages on i386 so there's nothing to analyze against. But in Debian, given a list of -dev packages that are applicable to armhf, it's almost certainly faster for folks to do the analysis against i386. > > The "good" news is that, although there are over 1500 -dev packages yet to > > be analyzed, we have prioritized libraries based on the number of > > reverse-dependencies > Is the list you attached already in descending order by number of rdeps? It was not. I've attached that list now. (And eventually I'll dd-list-ify it if there's agreement on this path forward.) > > libsdl1.2-compat-dev > The source package src:sdl12-compat recently took over libsdl1.2-dev > and libsdl1.2debian from the older src:libsdl1.2, which gives it quite > a lot of rdeps (I know because I did a mass bug filing for them!), > so having an answer for that one might reduce the rebuilds better than > you might think. I suspect it actually won't have time_t in its ABI, > although I could be wrong. Thanks. I didn't mention, but there are definitely some false-negatives in this list, because of e.g. all of the packages actually build-depend on a metapackage -dev which doesn't actually contain the headers. libboost-dev is an example, which is prominent enough that we noticed it and manually prioritized it. I'll have a look at sdl as well for sure. It would probably give us a more precise count if, instead of looking at reverse-build-deps on associated -dev packages, we scanned the archive for all packages shipping .shlibs and/or .symbols files and then looked at reverse-dependencies of the packages named in those control files. That would take rather a bit more effort however since it would involve unpacking the whole archive, and it doesn't matter for the actual transition which will be based on binary package revdeps regardless, it only matters for the question of prioritizing fails-to-compile headers for analysis. -- 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 [0] https://salsa.debian.org/vorlon/armhf-time_t/-/merge_requests/96 7 qtwayland5-private-dev 4 libogre-1.12-dev 4 android-libbase-dev 3 tcl-itcl4-dev 3 libplacebo-dev 3 libosp-dev 3 libopenvdb-dev 3 libkpipewire-dev 3 libini-config-dev 3 libgom-1.0-dev 3 libgnome-bluetooth-dev 3 libgirara-dev 3 libflatbuffers-dev 3 libfftw3-mpi-dev 3 libfcft-dev 3 libdrilbo-dev 3 libdpkg-dev 3 libcec-dev 3 libccp4-dev 3 libc-client2007e-dev 3 libapogee-dev 3 libapache2-mod-perl2-dev 3 libagg2-dev 3 libafflib-dev 3 libadplug-dev 3 iraf-noao-dev 3 guile-2.2-dev 3 gemmi-dev 3 coinor-libcbc-dev 3 casacore-dev 3 android-libziparchive-dev 3 android-libcutils-dev 3 ableton-link-dev 2 xserver-xorg-input-synaptics-dev 2 tao-json-dev 2 signond-dev 2 sfftw-dev 2 samba-dev 2 retroarch-dev 2 qttools5-private-dev 2 python3-cxx-dev 2 pinball-dev 2 pd-flext-dev 2 opencollada-dev 2 ofono-dev 2 nim-hts-dev 2 moarvm-dev 2 mirtest-dev 2 llvm-16-dev 2 libxorg-gtest-dev 2 libxlsxwriter-
Re: 64-bit time_t: an update
On Wed, 19 Jul 2023 at 14:27:21 -0700, Steve Langasek wrote: > to understand the impact that a change to the size of > time_t will have on a library's ABI, it must be possible to compile the > headers that expose that API Would the results of this analysis also be suitable for telling interested maintainers whether it's safe to opt-in a library to LFS and/or 64-bit time_t on i386, so that it will use 64-bit-time_t-safe glibc functions internally? (For example libdbus is already opted-in to LFS, and I'm reasonably sure it doesn't break public ABI under 64-bit time_t either, because it has a policy of avoiding most inclusions of system headers in its own public API) > The Ubuntu Foundations team have been putting in effort over the past two > months, package-by-package, to figure out how to make them compile so that > we know if their ABI is affected. Is there a reasonably simple way that interested developers can try this process for a package that they maintain? I realise your analysis has been done on armhf, but i386 would probably be an easier (and faster!) 32-bit architecture to deal with for many developers, even though we don't intend to do the 64-bit time_t transition systematically on i386. > The "good" news is that, although there are over 1500 -dev packages yet to > be analyzed, we have prioritized libraries based on the number of > reverse-dependencies Is the list you attached already in descending order by number of rdeps? > libsdl1.2-compat-dev The source package src:sdl12-compat recently took over libsdl1.2-dev and libsdl1.2debian from the older src:libsdl1.2, which gives it quite a lot of rdeps (I know because I did a mass bug filing for them!), so having an answer for that one might reduce the rebuilds better than you might think. I suspect it actually won't have time_t in its ABI, although I could be wrong. smcv
64-bit time_t: an update
Hi folks, Two months ago, I posted with a proposal for how to handle a transition to 64-bit time_t on 32-bit archs in the trixie cycle. https://lists.debian.org/debian-devel/2023/05/msg00168.html We have pretty good consensus on the path forward; however, at the time I posted I had hoped to have an archive analysis done within a month, so that this could be staged as the first major transition after trixie opened. This timeline proved to be very optimistic. The problem is that, to understand the impact that a change to the size of time_t will have on a library's ABI, it must be possible to compile the headers that expose that API; and we have a significant number of -dev packages in the archive that for one reason or another don't straightforwardly compile out of the box. The Ubuntu Foundations team have been putting in effort over the past two months, package-by-package, to figure out how to make them compile so that we know if their ABI is affected. However, despite a significant investment of effort, we still have roughly 1500 -dev packages still in need of analysis, and have sustained a rate of processing only around 50 -dev packages a week. The "good" news is that, although there are over 1500 -dev packages yet to be analyzed, we have prioritized libraries based on the number of reverse-dependencies and therefore these 1500 -dev packages have among them less than 300 reverse-build-dependencies that have not already been identified as part of the transition (800 of these -dev packages have no reverse-build-dependencies at all). Therefore, I would like to propose the following. - Assume the remaining 1500 -dev packages are affected by the ABI breakage. This will increase the number of library packages included in the transition requiring sourceful uploads from < 500 to 2000[1], but will only increase the number of packages requiring rebuilds from 5300 to 5600. - Agree a target window together with the Release Team for when the transition will be uploaded to unstable; and based on this, set a deadline beforehand for finalizing the list of library packages whose binary package names will be changed. - We in Ubuntu Foundations will continue on a best effort basis to drive down the list of -dev packages which cannot be analyzed, until that deadline. - Any party (maintainer or otherwise) interested in having some of these library packages excluded from the transition is welcome to contribute fixes up to that deadline that will let us analyze them and show that the ABI has not changed. Your thoughts? -- 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 [1] All numbers approximate: the analysis that has been completed so far has been done against Ubuntu lunar as a stable reference base. The Debian transition will of course be done based on a complete analysis of unstable, which is in progress separately. libgnome-rr-4-dev libhfsp-dev libhx-dev libibnetdisc-dev libip6tc-dev libipmiconsole-dev libipset-dev libisns-dev libisoburn-dev libixion-dev libjpeg-turbo8-dev libklibc-dev libkrad-dev libksba-dev liblasso3-dev libldacbt-abr-dev libldb-dev liblouisutdml-dev liblrm2-dev libmaa-dev libmircommon-dev libmiroil-dev libmirplatform-dev libmirwayland-dev libmlir-14-dev libmozjs-102-dev libmutter-11-dev libnetplan-dev libntirpc-dev libnutscan-dev liborcus-dev libotf-dev libpils2-dev libportal-dev libpskc-dev libptexenc-dev libpython3.10-dev libpython3.11-dev libradosstriper-dev libreoffice-dev libsource-highlight-dev libsss-certmap-dev libsss-simpleifp-dev libstdc++-11-dev libstdc++-12-dev libstonith1-dev libsysmetrics-dev libtotem-dev libunwind-14-dev libunwind-15-dev libusbredirhost-dev libuwac0-dev libverto-dev libvolume-key-dev libwhoopsie-dev libwhoopsie-preferences-dev lua-rrd-dev python3-ldb-dev python3-talloc-dev rhythmbox-dev ruby3.0-dev ruby3.1-dev samba-dev slapi-dev libblimps3-dev libfishcamp-dev libopenvr-dev libparmetis-dev libtestu01-0-dev libttspico-dev 389-ds-base-dev android-libandroidfw-dev android-libselinux-dev android-libsepol-dev android-libunwind-dev angelscript-dev atfs-dev cairo-dock-dev casacore-dev cauchy-dev codeblocks-dev coinor-libbonmin-dev coinor-libcbc-dev libfprint-2-tod-dev dovecot-dev irssi-dev isc-dhcp-dev libaal-dev libapache2-mod-perl2-dev bind9-dev libcanberra-gtk-common-dev libclc-14-dev libclc-15-dev libd3dadapter9-mesa-dev libdpkg-dev libfreeradius-dev libglvnd-core-dev libmirrenderer-dev libpinyin-common-dev libpolly-15-dev libradospp-dev libreiser4-dev libreofficekit-dev libubi-dev mir-renderer-gl-dev ocfs2-tools-dev php8.1-dev rados-objclass-dev remmina-dev zsh-dev libamgcl-dev libjulius-dev libthrust-dev notion-dev ableton-link-dev android-libbase-dev android-libcutils-dev android-lib
