Please block glj....@gmail.com from Debian lists [Re: UOC and Britsh Council lawsuit]
On Mon, Apr 22, 2024 at 05:11:39PM +0200, José Luis González González wrote: > I sent 5 minutes ago an email to "Plaza de Castilla *courts*" setting > it crystal clear that it was a long time ago the lawsuit to Universitat > Oberta de Catalunya and British Council had to be solved. > > "Kinda or not" > -- 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
Re: Package marked for autoremoval due to closed bug?
On Fri, Mar 15, 2024 at 05:03:55AM +, Scott Kitterman wrote: > On March 15, 2024 3:54:05 AM UTC, Steven Robbins wrote: > >According to the "action needed" section for nifticlib [1], it is: > >Marked for autoremoval on 31 March: #1063178 > >But that bug is fixed for the version in unstable. > >Why does that cause the package to be removed? > >[1] https://tracker.debian.org/pkg/nifticlib > Because the bug still exists in Testing. Once the package in Unstable > migrates, all is well. Migration to testing is largely out of control of the maintainers at this point, it's very much dependent on folks rebootstrapping armel and armhf against the new library names. Should these bugs be downgraded again to important severity? -- 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
Re: time_t progress report
Hi, On Thu, Mar 14, 2024 at 10:47:02PM +0100, Micha Lenk wrote: > The time_t transition seems to be stalled due to issues on armel/armhf > architecture. My understanding is, as long as this transition isn't over, > uploaders of affected packages are discouraged to upload anything > unrelated to this transition (to avoid any delays to get it through). > Do we have an updated rough idea for how long this transition will take? > Is it in the range of day, weeks or months? I have no clue... Well, I think I should send an update about this probably, because I don't think you should be discouraged from uploading right now. The source packages with the renames have landed in unstable, and will take a while (probably weeks) to get all of the build-dependency loops worked out and the binNMUs all done. There's no real need to hold off on other uploads at this point in the face of that, I don't expect it to significantly change the timeline. There may be some rare cases of pending transitions that would add to the set of packages that need to migrate to testing all at once (though this seems unlikely to me when there are already so many!), so those should still be coordinated with the Release Team. > Am 27. Februar 2024 08:19:21 MEZ schrieb Steve Langasek : > >Hi Simon, > > > >On Mon, Feb 26, 2024 at 11:40:56AM +, Simon McVittie wrote: > >> > glib2.0 # already in experimental > > > >> The upstream version in experimental is unsuitable for unstable, but it's > >> "the same shape" as the version in unstable in all the places that matter, > >> and we ack'd the earlier NMU to experimental already, so I'm confident > >> that similar changes will apply cleanly to the version in unstable. The > >> GNOME team can probably handle this one when the time comes, if that > >> would help (I know your Canonical colleague Jeremy Bícha was asking to > >> let the GNOME team do coordinated team-uploads rather than NMUs, I'm not > >> sure what the resolution of that was). > > > >Yes, this is on the list to flag that it is a package for which we do not > >have a guarantee of dumat coverage in experimental prior to uploading to > >unstable, and thus we might hit usrmerge problems for the first time in > >unstable. > > > >In this particular case the t64 NMU sat in experimental for 2 weeks > >(31Jan-13Feb) before being replaced by a maintainer upload. So I trust that > >Helmut would have screamed at me if glib2.0 had gone pear-shaped. > > > >But that is a finer level of investigation than we have the capacity for at > >this stage for each of these 50+ packages. > > > >> Also, if it's valid to apply this reasoning: > > > >> - libhigh0 depends on liblow0 > >> - liblow0 will transition to liblow0t64 > >> - libhigh0 does not really need to change its name because we know that the > >> version built against liblow0 is the old ABI, the version built against > >> liblow0t64 is the new ABI, and they cannot be co-installable > > > >> then we can cross all of the GLib-based packages off the list > >> immediately, and handle them by transitioning glib2.0 from libglib2.0-0 > >> to libglib2.0-0t64. That covers at least these: > > > >> > evolution# no sane ABI info, but maintainer handling via > >> > e-d-s > >> > gimp # already in experimental > >> > gtk+2.0 # false positive > >> > gtk+3.0 # false positive > >> > libvirt-glib # ftbfs > >> > mutter # already in experimental > >> > telepathy-farstream # known ftbfs > > > >> ... and similar logic could be applied to in the Qt ecosystem, with Qt > >> as the low-level package. Does that help to reduce the numbers? > > > >Special-casing these stacks because they don't "need" to be renamed is, on > >our side, more work and more prone to mistakes than if we just include them > >in the mass NMU. *Not* renaming is not meaningfully better as a user > >experience than renaming, so I don't think it's valuable from the > >perspective of the overall transition to carve out these exceptions. > > > >If maintainers are confident that the renames are unnecessary and want to > >remove the 'pending' tag from the bug reports to exclude them, or want to > >revert the renames after upload, that's their choice. > > > >The only caveat I would raise is that on the Ubuntu side, we're working to a > >very tight deadline now: Feature Freeze for Ubuntu 24.04 LTS is this > &g
Re: 64-bit time_t transition: cargo needs manual intervention
On Mon, Mar 11, 2024 at 09:07:17PM -0500, Steven Robbins wrote: > Peter convincingly argues (details in bug) that manual intervention is needed > for package "cargo": > On Sun, 10 Mar 2024 00:48:32 + Peter Michael Green > wrote: > > This will require manual intervention to resolve, either through > > cross-building or through building manually in a hacked-up build > > environment. > > I've certainly seen mention of rustc on #debian-devel recently, > > so I think the people handling the time_t transition are already > > aware of this. > I'm wondering if the time_t people or the rust people could comment on this? > This build failure has a surprisingly (to me) long chain of casualties. Is > this an easy thing to fix or is going to take weeks? The quickest fix for this based on what we've done in Ubuntu is: - unpack cargo and libstd-rust debs to the root via dpkg-deb -x - use equivs to mock up packages by these names with no dependencies and install those - bootstrap - enjoy -- 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
Re: Requesting help with the t64 transition
On Fri, Mar 08, 2024 at 01:58:22PM +0100, John Paul Adrian Glaubitz wrote: > debbootstrap first downloads perl-modules-5.38_5.38.2-3_all.deb, then later > tries > to install perl_5.38.2-3.2_powerpc.deb which causes dpkg to bail out. It can > be > reproduced with: > # debootstrap --no-check-gpg --arch=powerpc --variant=buildd \ > --include=debian-ports-archive-keyring unstable sid-powerpc-sbuild \ > http://ftp.ports.debian.org/debian-ports > Thus, we need to get rid of perl-modules-5.38_5.38.2-3_all.deb from the > repositories in order to be able to create fresh chroots with debbootstrap > again. Since packages in Debian Ports are directly synced from the main > repos for arch:all, this needs to be done by the FTP masters. Why is debootstrap picking perl-modules-5.38_5.38.2-3_all.deb when perl-modules-5.38_5.38.2-3.2_all.deb is present in unstable for 2 days? I'm also not sure why it hasn't expired out of unstable given that it is superseded. -- 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
Re: 64-bit time_t transition in progress in unstable
On Thu, Mar 07, 2024 at 12:20:22AM -0500, Theodore Ts'o wrote: > > Aside from the libuuid1t64 revert, for which binNMUs have been scheduled, I > > actually would expect unstable to be dist-upgradeable on non-32-bit archs: > > either the existing non-t64 library will be kept installed because nothing > > yet needs the t64 version, or something does want the t64 version and apt > > will accept it as a replacement for the non-t64 version because it Provides: > > the non-t64 name. > > So once the libuuidt64 revert is done (later today?), if apt dist-upgrade is > > NOT working, I think we should want to see some apt output showing what's > > not working. > Sorry, I've been crazy busy so I didn't have time to object to > libuuid1t64 as bewing compltely unnecessary before it had rolled out > to unstable. Similarly, libcom-err2 and libss2 don't use time_t, so > the rename to ...t64 was completely unnecessary. Yes, apologies, we can't assume any particular mapping from -dev packages to runtime lib packages in packages that have multiple -dev packages, so libcom-err2 and libss2 were swept up in the renaming and I only noticed after the fact that this was unnecessary. -- 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
Re: Perl problem - loadable library and perl binaries are mismatched
On Tue, Mar 05, 2024 at 11:55:28PM +0100, John Paul Adrian Glaubitz wrote:
> > Thanks! You saved me a lot of headaches!
FWIW to do a bootstrap build of perl I had to:
- disable libdb and libgdbm build-deps
- disable build-time tests, which would pick up old ndbm module from
on-disk and break as a result
Not sure if your bootstrap path was similar.
> I have run into this issue again trying to rebuild libxs-parse-keyword-perl
> with a src:perl that was built with dpkg_1.22.5:
> powerpc-linux-gnu-gcc -Isrc/ -I/usr/lib/powerpc-linux-gnu/perl/5.38/CORE
> -DVERSION="0.39" -DXS_VERSION="0.39" -fPIC -I. -Ihax -c -D_REENTRANT
> -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe
> -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2
> -Werror=implicit-function-declaration
> -ffile-prefix-map=/home/glaubitz/perl-modules/libxs-parse-keyword-perl-0.39=.
> -fstack-
> protector-strong -Wformat -Werror=format-security -g -O2
> -Werror=implicit-function-declaration
> -ffile-prefix-map=/home/glaubitz/perl-modules/libxs-parse-keyword-perl-0.39=.
> -fstack-protector-strong -
> Wformat -Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -o lib/XS/Parse/Keyword.o
> lib/XS/Parse/Keyword.c
> ExtUtils::Mkbootstrap::Mkbootstrap('blib/arch/auto/XS/Parse/Keyword/Keyword.bs')
> powerpc-linux-gnu-gcc -g -O2 -Werror=implicit-function-declaration
> -ffile-prefix-map=/home/glaubitz/perl-modules/libxs-parse-keyword-perl-0.39=.
> -fstack-protector-strong -Wformat -Werror=format-
> security -Wl,-z,relro -Wl,-z,now -shared -L/usr/local/lib
> -fstack-protector-strong -o blib/arch/auto/XS/Parse/Keyword/Keyword.so
> lib/XS/Parse/Keyword.o src/infix.o src/keyword.o
> Parser.c: loadable library and perl binaries are mismatched (got first
> handshake key 0xb600080, needed 0xb700080)
> dh_auto_build: error: /usr/bin/perl Build returned exit code 1
> make: *** [debian/rules:6: binary-arch] Error 1
> dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit
> status 2
I did not run into this. Do you have a mix of old and new packages from
perl source installed?
> Also, I noticed that libxs-parse-keyword-perl build-depends on
> libextutils-cbuilder-perl which is apparently obsolete and also still
> depends on the old Perl API [1] which makes me wonder how
> libxs-parse-keyword-perl was built for armhf and armel [2].
When modules are incorporated into perl, perl declares a provides: for them.
There's no reason to install the libextutils-cbuilder-perl package anymore.
(which, btw, was an arch: all package, so in any case it wouldn't be
affected by the ABI transition.)
--
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
Re: 64-bit time_t transition in progress in unstable
On Thu, Mar 07, 2024 at 01:43:11AM +0500, Andrey Rahmatullin wrote: > On Wed, Mar 06, 2024 at 12:33:08PM -0800, Steve Langasek wrote: > > > > Are there instructions on how to progress an unstable system through > > > > this, or is the repo currently in a known inconsistent state? I have > > > > tried upgrading various packages to work through deps but I am unable > > > > to do a dist-upgrade for a while. > > > Being unable to do a dist-upgrade is expected and some packages can't be > > > installed or can't be upgraded, but in general on amd64 you should be able > > > to upgrade a majority of them with `apt upgrade` and then manual > > > installing/upgrading, if you wish so (as in theory most libfoo0t64 are > > > drop-in replacements for libfoo0, but in practice some packages have > > > additional abi deps for their plugins etc., plus the usual amd64-i386 > > > skews, plus some unique problems in some packages). > > > Also debootstrapping sid is broken, or may be broken from time to time. > > > Install testing instead if that's good enough. > > Aside from the libuuid1t64 revert, for which binNMUs have been scheduled, I > > actually would expect unstable to be dist-upgradeable on non-32-bit archs: > > either the existing non-t64 library will be kept installed because nothing > > yet needs the t64 version, or something does want the t64 version and apt > > will accept it as a replacement for the non-t64 version because it Provides: > > the non-t64 name. > > So once the libuuidt64 revert is done (later today?), if apt dist-upgrade is > > NOT working, I think we should want to see some apt output showing what's > > not working. > On my system there is currently only one problem not related to libuuid: > vlc-plugin-pipewire is not rebuilt for vlc-plugin-abi-3-0-0ft64. As for > uuid, I have several i386 libraries installed that depend on it. That seems like a case where the maintainer (cc:ed) could add the vlc-plugin-abi-3-0-0f Provides: on 64-bit archs for backwards-compatibility to unblock. Or someone can just request binNMUs for this package sooner rather than later. (It's premature to request mass binNMUs yet while arm* are still being re-bootstrapped.) -- 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
Re: 64-bit time_t transition in progress in unstable
On Thu, Mar 07, 2024 at 12:46:24AM +0500, Andrey Rahmatullin wrote: > On Wed, Mar 06, 2024 at 12:26:17PM -0700, Kevin Bowling wrote: > > Are there instructions on how to progress an unstable system through > > this, or is the repo currently in a known inconsistent state? I have > > tried upgrading various packages to work through deps but I am unable > > to do a dist-upgrade for a while. > Being unable to do a dist-upgrade is expected and some packages can't be > installed or can't be upgraded, but in general on amd64 you should be able > to upgrade a majority of them with `apt upgrade` and then manual > installing/upgrading, if you wish so (as in theory most libfoo0t64 are > drop-in replacements for libfoo0, but in practice some packages have > additional abi deps for their plugins etc., plus the usual amd64-i386 > skews, plus some unique problems in some packages). > Also debootstrapping sid is broken, or may be broken from time to time. > Install testing instead if that's good enough. Aside from the libuuid1t64 revert, for which binNMUs have been scheduled, I actually would expect unstable to be dist-upgradeable on non-32-bit archs: either the existing non-t64 library will be kept installed because nothing yet needs the t64 version, or something does want the t64 version and apt will accept it as a replacement for the non-t64 version because it Provides: the non-t64 name. So once the libuuidt64 revert is done (later today?), if apt dist-upgrade is NOT working, I think we should want to see some apt output showing what's not working. -- 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
Re: time_t transition and bugs
On Sat, Mar 02, 2024 at 10:37:33PM +0500, Andrey Rahmatullin wrote: > On Sat, Mar 02, 2024 at 06:34:43AM -0700, Antonio Russo wrote: > > There's a similar issue with versioned dependencies by un-transitioned > > packages have on non-t64 libraries (e.g., libqt5sql5). > It's not similar, it's caused by some t64 libraries having wrong Provides. > I've filed bugs about this on poppler, qt5 and curl, there may be more. As mentioned on IRC, I isolated the bug in the script that caused this, which allowed working out the full list of affected packages. https://paste.debian.net/1309262/ curl, nordugrid-arc, poppler, qtbase-opensource-src, and xmlrpc-c have been uploaded with the fix. petsc will take a little bit, as there are other bugs that need fixing at the same time. -- 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
Re: Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems
On Thu, Feb 29, 2024 at 06:53:56AM +0100, Paul Gevers wrote: > On 29-02-2024 4:47 a.m., Christoph Anton Mitterer wrote: > > @d-d: > > - How can it happen that purge *t64 packages and at the same time install > >the previous package, and then the so file is missing? > >I mean it's clear that they use the same name, but shouldn't DPKG handle > >the cleanly? > Well, officially downgrading isn't supported (although it typically works) > *and* losing files is one of the problems of our merged-/usr solution (see > [1]). I *suspect* this might be the cause. We're working hard (well, helmut > is) to protect us and our users from loosing files on upgrades. We don't > protect against downgrades. > Obviously there might be issues, but you are running unstable *during* a > transition. You have to expect some troubles. Thanks for the information, > let's see if this is a real issue or not. Furthermore, this is a downgrade from a replacing package to a replaced package. Unless you also --reinstall the package at the end, missing files are quite to be expected. -- 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
Re: time_t progress report
Hi Simon, On Mon, Feb 26, 2024 at 11:40:56AM +, Simon McVittie wrote: > > glib2.0 # already in experimental > The upstream version in experimental is unsuitable for unstable, but it's > "the same shape" as the version in unstable in all the places that matter, > and we ack'd the earlier NMU to experimental already, so I'm confident > that similar changes will apply cleanly to the version in unstable. The > GNOME team can probably handle this one when the time comes, if that > would help (I know your Canonical colleague Jeremy Bícha was asking to > let the GNOME team do coordinated team-uploads rather than NMUs, I'm not > sure what the resolution of that was). Yes, this is on the list to flag that it is a package for which we do not have a guarantee of dumat coverage in experimental prior to uploading to unstable, and thus we might hit usrmerge problems for the first time in unstable. In this particular case the t64 NMU sat in experimental for 2 weeks (31Jan-13Feb) before being replaced by a maintainer upload. So I trust that Helmut would have screamed at me if glib2.0 had gone pear-shaped. But that is a finer level of investigation than we have the capacity for at this stage for each of these 50+ packages. > Also, if it's valid to apply this reasoning: > - libhigh0 depends on liblow0 > - liblow0 will transition to liblow0t64 > - libhigh0 does not really need to change its name because we know that the > version built against liblow0 is the old ABI, the version built against > liblow0t64 is the new ABI, and they cannot be co-installable > then we can cross all of the GLib-based packages off the list > immediately, and handle them by transitioning glib2.0 from libglib2.0-0 > to libglib2.0-0t64. That covers at least these: > > evolution # no sane ABI info, but maintainer handling via e-d-s > > gimp# already in experimental > > gtk+2.0 # false positive > > gtk+3.0 # false positive > > libvirt-glib# ftbfs > > mutter # already in experimental > > telepathy-farstream # known ftbfs > ... and similar logic could be applied to in the Qt ecosystem, with Qt > as the low-level package. Does that help to reduce the numbers? Special-casing these stacks because they don't "need" to be renamed is, on our side, more work and more prone to mistakes than if we just include them in the mass NMU. *Not* renaming is not meaningfully better as a user experience than renaming, so I don't think it's valuable from the perspective of the overall transition to carve out these exceptions. If maintainers are confident that the renames are unnecessary and want to remove the 'pending' tag from the bug reports to exclude them, or want to revert the renames after upload, that's their choice. The only caveat I would raise is that on the Ubuntu side, we're working to a very tight deadline now: Feature Freeze for Ubuntu 24.04 LTS is this Thursday, and while I think we're going to vary our Debian Import Freeze in order to get the time_t transition through, we aren't going to vary it by much. So maintainer name reverts in unstable that happen after this are not guaranteed to be picked up, and whatever package names we have on the Ubuntu side are going to be locked in for a 10-year LTS cycle. So I think any maintainer who's concerned about dependency compatibility with third-party debs should bear this in mind. -- 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
Re: Another take on package relationship substvars
Hi Niels,
On Thu, Feb 22, 2024 at 07:32:21PM +0100, Niels Thykier wrote:
> When I am talking about package relationship substvars, I mean basically any
> substvar of the format ${*:} where Field is a relationship field such
> as Depends, Pre-Depends, etc.
[...]
> I think our package helper tooling should just automatically aggregate all
> provided substvars of the format ${*:Depends} and append it the Depends
> field. Rinse and repeat for other relationship fields.
> The list of fields where this is applied would be curated, so it only
> applies to known relationship fields where we feel it makes sense. My
> starting list would be:
> * Any dependency field, that is: Pre-Depends, Depends, Recommends, and
>Suggests
> * The Provides field.
> I am omitting Breaks, Conflicts, and Replaces because I am not aware of any
> users of these at the moment. I am open to adding them, if there is a strong
> use-case.
One generic case that this doesn't handle is Essential: yes packages. For
many of these, the ${shlibs:Depends} gets promoted in debian/control to
Pre-Depends, not to Depends.
Maybe it would make sense to auto-aggregate these substvars, *IFF* there is
not already a reference to the substvar in question in the package stanza in
debian/control? This would provide adequate flexibility for any other
exceptions that might be out there, beyond the Pre-Depends case.
Cheers,
--
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
Re: time_t progress report
On Fri, Feb 23, 2024 at 04:36:43PM +0100, Guillem Jover wrote: > Hi! > On Mon, 2024-02-19 at 19:48:38 -0800, Steve Langasek wrote: > > I have coordinated with the gcc maintainer so that we can have the default > > flags in gcc-13 changed this week. > > We are therefore targeting Friday for the mass NMUs to unstable though there > > is a possibility this won't start until as late as Monday depending on > > capacity. > Yesterday while trying to get a time for today's upload, I discussed > with Matthias, and it looks like today is not great for timing. There > are some things that might need to be hammered out in gcc, and Matthias > was not going to be available today until next week or so. I also just > realized the transition exceptions coverage does not match between > what some porters expect (f.ex. hurd-i386 which I'll discuss with them > later today), what dpkg and debhelper have implemented and what gcc > does, I'll discuss the latter with Matthias separately. > So as mentioned by Steve, this might need to be postponed a tiny bit > more. Yes, it looks like we're not quite ready to go. There are also some bad NMUs in experimental that need to be cleaned up, and also a few extra annotations we're going to have to add to some packages after belatedly realizing that debhelper magic isn't already DTRT as far as Provides: for all packages. So we'll use the time well until gcc is ready to go. In the meantime, another happy update on the statistics, showing that we've whittled away a few more libraries: - 1093+50=1143 source packages to be transitioned - 5261+180=5441 packages to be binNMUed -- 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
time_t progress report
# see https://salsa.debian.org/vorlon/armhf-time_t/-/merge_requests/128 gcc-12: failed # see https://salsa.debian.org/vorlon/armhf-time_t/-/merge_requests/128 gcc-13: failed # see https://salsa.debian.org/vorlon/armhf-time_t/-/merge_requests/128 gcc-14: failed # see https://salsa.debian.org/vorlon/armhf-time_t/-/merge_requests/128 gcc-9: failed # ftbfs in unstable, https://bugs.debian.org/984418 xqilla: failed # no sane ABI info, no revdeps yacas: failed # ftbfs in unstable, https://bugs.debian.org/1037908 yaramod: failed # already in experimental gpaste: failed # already in experimental htslib: failed # already in experimental ima-evm-utils: failed # no sane ABI info, no revdeps inn2: failed # ftbfs in unstable; https://bugs.debian.org/1002106 gr-dab: failed # ftbfs in unstable; https://bugs.debian.org/1064088 gutenprint: failed # already in experimental hdf5: failed # already in experimental lrcalc: failed # ftbfs in unstable mediastreamer2: failed # no sane ABI info; https://bugs.debian.org/1064193 lua-cqueues: failed # no sane ABI info; https://bugs.debian.org/1064187 luasocket: failed # false positive, has been resolved but results not yet updated mesa: failed # already in experimental mutter: failed # no sane ABI info, no revdeps nilfs-tools: failed # already in experimental nodejs: failed # no sane ABI info. still needs bug filed octave: failed # already in experimental opencascade: failed # already in experimental openimageio: failed # already in experimental openmm: failed # already in experimental opensubdiv: failed # already in experimental pam: failed # already in experimental poco: failed # no sane ABI info, no revdeps odin: failed # FTBFS in unstable, https://bugs.debian.org/1064139 ogre-1.12: failed # ftbs in unstable (#1019172) opengrm-ngram: failed # ftbfs in unstable (#1052380) opensm: failed # ftbfs in unstable (#1001528) purify: failed # already in experimental openmpi: failed # already in experimental poppler: failed # already in experimental protobuf: failed # already in experimental qt6-3d: failed # already in experimental qt6-base: failed # already in experimental qt6-declarative: failed # already in experimental qt6-tools: failed # already in experimental qt6-virtualkeyboard: failed # already in experimental qt6-wayland: failed # already in experimental qt6-webengine: failed # already in experimental qt6-websockets: failed # already in experimental qtbase-opensource-src-gles: failed # already in experimental qtbase-opensource-src: failed # already in experimental qtquickcontrols2-opensource-src: failed # already in experimental qttools-opensource-src: failed # already in experimental qtwayland-opensource-src: failed # already in experimental qtwebengine-opensource-src: failed # no sane ABI info, no revdeps quickplot: failed # already in experimental rem: failed # no sane ABI info, no revdeps regina-normal: failed # FTBFS in unstable, https://bugs.debian.org/1062880 saga: failed # FTBFS in unstable, https://bugs.debian.org/997264 seriousproton: failed # no sane ABI info, no revdeps sgb: failed # no sane ABI info, no revdeps sipxtapi: failed # no sane ABI info; https://bugs.debian.org/1064328 snort: failed # obsolete, skip it python3.10: failed # soon to be obsolete skip it python3.11: failed # has to be handled manually, mark failed temporarily python3.12: failed Thanks, -- 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] that can be [1] https://people.canonical.com/~vorlon/armhf-time_t/source-packages + https://people.canonical.com/~vorlon/armhf-time_t/lfs-source-packages [2] https://people.canonical.com/~vorlon/armhf-time_t/reverse-depends-sources + https://people.canonical.com/~vorlon/armhf-time_t/lfs-reverse-depends-sources [3] https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org;tag=time-t#_2_3_5 [4] https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org;tag=time-t#_0_3_2 + https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org;tag=time-t#_0_3_1 [5] https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org;tag=time-t#_0_2_4 [6] https://bugs.debian.org/1064298 [7] https://lists.debian.org/debian-devel/2024/02/msg00156.html signature.asc Description: PGP signature
Re: Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
Thanks for this patch. Based on the rest of the discussion I don't believe
this is something we need in Debian. Do you want to propose this to
upstream?
On Thu, Feb 08, 2024 at 08:27:00AM +0300, Michael Tokarev wrote:
> Attached is a sketch to make pam compatible.
> I had a more complete and *tested* fix 2 days ago but I forgot
> it was in /tmp and I rebooted the machine, so had to do it again
> yesterday.
>
> The idea is to have both die_time and die_time64, and keep them
> in sync (using minimum between two values which is !=0).
>
> This is a sketch using a #define, though better is to use symbol
> versioning here and have time32 compat stuff for old programs
> and 64bit time stuff for new, using redirection at the link time,
> instead of the #defines which makes whole thing rather difficult
> to read, - that's extra several lines of code, also to the .map
> file.
>
> What the whole thing needs is the criteria to use to enable the
> trick. Right now I used #ifdef NEED_TIME64_COMPAT which should
> be defined somehow, - since I don't know the precise list of
> architectures where this has to be done. This is an externally-
> controlled thing, there's no way to determine this directly from
> the .c code (short of using architecture list in the .h file),
> so it must be some symbol substituted at the package build time,
> like Provides: t64:Compat (or whatever it is) is substituted in
> d/control.
>
> This is a less-intrusve-to-original-code version of the sketch,
> ie, I tried to keep all changes outside of the original code as
> possible, keeping all the original logic as it is.
>
> /mjt
> diff --git a/libpam_misc/include/security/pam_misc.h
> b/libpam_misc/include/security/pam_misc.h
> index fca2422..922341c 100644
> --- a/libpam_misc/include/security/pam_misc.h
> +++ b/libpam_misc/include/security/pam_misc.h
> @@ -21,6 +21,15 @@ extern int misc_conv(int num_msg, const struct pam_message
> **msgm,
>
> #include
>
> +#if NEED_TIME64_COMPAT
> +
> +extern time32_t pam_misc_conv_warn_time;
> +extern time32_t pam_misc_conv_die_time;
> +#define pam_misc_conv_warn_time pam_misc_conv_warn_time64
> +#define pam_misc_conv_die_time pam_misc_conv_die_time64
> +
> +#endif
> +
> extern time_t pam_misc_conv_warn_time; /* time that we should warn user */
> extern time_t pam_misc_conv_die_time; /* cut-off time for input */
> extern const char *pam_misc_conv_warn_line; /* warning notice */
> diff --git a/libpam_misc/misc_conv.c b/libpam_misc/misc_conv.c
> index 908ee89..a02d491 100644
> --- a/libpam_misc/misc_conv.c
> +++ b/libpam_misc/misc_conv.c
> @@ -30,6 +30,9 @@
> time_t pam_misc_conv_warn_time = 0; /* time when we warn */
> time_t pam_misc_conv_die_time = 0; /* time when we timeout */
>
> +static void fixup_compat_time();
> +static void reset_warn_time();
> +
> const char *pam_misc_conv_warn_line = N_("...Time is running out...\n");
> const char *pam_misc_conv_die_line = N_("...Sorry, your time is up!\n");
>
> @@ -96,6 +99,8 @@ static int get_delay(void)
> expired = 0;/* reset flag */
> (void) time();
>
> +fixup_compat_time();
> +
> /* has the quit time past? */
> if (pam_misc_conv_die_time && now >= pam_misc_conv_die_time) {
> fprintf(stderr,"%s",pam_misc_conv_die_line);
> @@ -107,7 +112,7 @@ static int get_delay(void)
> /* has the warning time past? */
> if (pam_misc_conv_warn_time && now >= pam_misc_conv_warn_time) {
> fprintf(stderr, "%s", pam_misc_conv_warn_line);
> - pam_misc_conv_warn_time = 0;/* reset warn_time */
> + reset_warn_time();
>
> /* indicate remaining delay - if any */
>
> @@ -399,3 +404,36 @@ failed_conversation:
>
> return PAM_CONV_ERR;
> }
> +
> +#ifdef NEED_TIME64_COMPAT
> +
> +#undef pam_misc_conv_warn_time
> +#undef pam_misc_conv_die_time
> +
> +int pam_misc_conv_warn_time, pam_misc_conv_die_time;
> +
> +/* in compat 32/64 case, we have 2 values: time and time64.
> + We perform all operations with time64
> + But we try to keep them in sync, whiciever is smaller but !0 */
> +#define fixup(t, t32) \
> +if (t32 && (!t || t > t32)) t = t32; /* if t32 fires sooner */ \
> +if (t < 0x7fff) t32 = t /* only if t can fit in t32 */
> +
> +static void fixup_compat_time() {
> +fixup(pam_misc_conv_warn_time64, pam_misc_conv_warn_time);
> +fixup(pam_misc_conv_die_time64, pam_misc_conv_die_time);
> +}
> +static void reset_warn_time()
Re: 64-bit time_t transition in progressL
Hi Alastair, On Sat, Feb 03, 2024 at 08:11:21AM +, Alastair McKinstry wrote: > Since the time transition is going to require an openmpi transition, I > suggest that the mpi-defaults transition happen simultaneously; > ie mpi-defaults to move 32-bit builds to mpich; openmpi 4.1.6-6 with t64 > libs builds against 64-bit libs only. If I'm interpreting your message correctly, I believe these are relatively orthogonal: you can change mpi-defaults whenever you wish, the packages that depend on libopenmpi3 would still need binNMUing to make them depend on libopenmpi3t64 on armhf. If you arrange it so that at the same time mpi-defaults changes, so that any armhf packages build-depending on mpi-default-dev get rebuilt to depend on libmpich12 instead of either libopermpi3 or libopenmpi3t64, that's fine and would save a round of binNMUs of those same packages later; but that is not a transition that is going to require the same degree of tight coordination wrt unstable uploads and testing migration so I don't think we should block the t64 unstable uploads on an mpi-defaults change. (If you upload mpi-defaults to unstable *first* and get the binNMUs done before the t64 transition lands, that's great and just saves us on the number of binNMUs we will need to schedule.) > Note there is a 5.0.1-1 package in experimental for openmpi that is not > ready for primetime; for the t64 transition use 4.1.6 not 5.0.1. Of course. binary NEW changes are being staged in experimental where possible, but we will not be pulling experimental versions into unstable as part of this. -- 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
Re: 64-bit time_t transition in progress
On Tue, Feb 06, 2024 at 05:33:22PM +, Alberto Garcia wrote: > On Sun, Feb 04, 2024 at 11:05:46PM -0800, Steve Langasek wrote: > > In fact, none of the t64 binaries currently being uploaded > > to experimental have the final ABI either, we're just using > > experimental to clear binary NEW. > I was having a look at two of the packages that I maintain that have > t64 binaries in experimental and I noticed that while the binary > package does have a different name the .so files themselves are the > same. Is this expected when we're talking about an ABI break? Yes. There is longstanding precedent for this in Debian when doing toolchain-driven ABI transitions where the upstream soname of the library does not change (c102, c2, c2a, ldbl, v5...). It is also an important part of ensuring this transition is NOT disruptive on architectures where there is no ABI change (all 64-bit architectures + i386). -- 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
Re: 64-bit time_t transition in progress
Thank you for your rigorous scrutiny regarding the proposed plan. It was a blindspot on my part that dpkg-buildflags was not a policy mandate, because by this point I'm quite *used* to using dpkg-buildflags to manage transitions in the default build flags for the compiler. What I hadn't taken into account is that in those previous transitions, the consequence of failing to use dpkg-buildflags in a small number of packages was that those packages did not get certain improvements (in QA, performance, security, etc) - whereas in this case the consequence of missing these flags is instead a potentially critical crasher bug due to ABI skew. I am delayed in responding to this feedback in part because the realization pulled me up short and caused me to have to take stock internally of the overall transition plan. I think we do need to change the default gcc behavior on our 32-bit archs to correctly manage this transition. I believe the correct sequence now should be: - change (the default) gcc to emit the necessary preprocessor flags by default. - also change dpkg-buildflags to emit them by default (abi=+time64: -D[...]; abi=-time64: -U[...]). - do the mass uploads to unstable. (I don't think the critical path here should block on changing the default behavior of non-default compilers - either non-default gcc versions or llvm. Packages that *both* use a non-default C compiler to build *and* don't honor dpkg-buildflags are a corner case, and we can identify any affected packages retrospectively rather than having them delay the main event to the detriment of other development in unstable.) On Wed, Feb 07, 2024 at 10:12:33AM +, Bill Allombert wrote: > Le Fri, Feb 02, 2024 at 08:23:42PM +0100, Bill Allombert a écrit : > > > I don't see any practical reason why not. > > Because packages are not required to use dpkg-buildflags. > And more generally, does this scheme will require to build third-party > packages on 32bit Debian system to set > CFLAGS=D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 > or will this be made the default in gcc or glibc ? On Thu, Feb 08, 2024 at 08:07:19PM +0100, Ansgar wrote: > On Fri, 2024-02-02 at 08:21 -0800, Steve Langasek wrote: > > Once all of these packages have built in experimental and we have identified > > and addressed all adverse interactions with the usrmerge transition, the > > plan is: > > - dpkg uploaded to unstable with abi=time64 enabled by default[5] > How does this work when a user builds their own software using any > library build with abi=time64? They will still get a 32bit time_t & > others unless they use dpkg-buildflags as well, won't they? > If we already change ABI, why not change this in the toolchain (glibc, > gcc) so also user-build packages use the correct ABI? That was what > happened for other ABI changes like the C++ ABI change as far as I > remember. Right: addressing this in the default behavior of the default compiler sorts out the non-package build question also. I (and colleagues on the Ubuntu Foundations team) will work with the gcc maintainer to establish a timeline for when we can have such a change landed. -- 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
libselinux1t64 (et al): breaks system in upgrade from unstable
d use this as a forcing factor to complete the transition, rather than putting effort into fixing libfuse2. (the number of reverse-dependencies is unfortunately still quite large.) > Moreover, I don't see > any ACC report for libfuse3-dev. Did that fail to analyze? Yes: https://adrien.dcln.fr/misc/armhf-time_t/2024-02-09T15%3A12%3A00/logs/libfuse3-dev/time_t/log.txt looks like a bug in the quirking script. The same bug appears to be present for libhiredis-dev. > Also when looking into effort, please keep in mind that for every case > mentioned in this email, we're looking into adding a protective > diversion due to the package rename without so rename and then in forky > we'll have to clean up all those diversions, and in forky+1 we'll have > to delete the cleanup code, so while investing more now may seem more > expensive, it saves later. I think the cost of chasing upstreams about soname bumps and dual-abi'ing libraries swamps any savings for the maintainers having to do lazy cleanup of some lingering diversions. Thanks, -- 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
Re: Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
On Wed, Feb 07, 2024 at 09:06:58AM +0100, Helmut Grohne wrote:
> On Wed, Feb 07, 2024 at 04:32:45AM +0100, Guillem Jover wrote:
> > Yes, I'm not sure I understand either. This is what symbol versioning
> > makes possible, even providing different variants for the same symbol,
> > see for example glibc or libbsd.
> I think symbol versioning is subtly different and glibc does not use
> symbol versioning for e.g. gettimeofday selection. With symbol
> versioning, you select a default version at release time and stick to
> it. In other words, building against the updated libselinux does not
> allow you to use the older 32bit variant of the symbol even if you opt
> out of lfs and time64 and you always get the 64bit symbol. What glibc
> does is a little more fancy than my simplistic #define in that it uses
> asm("name") instead. Still this approach allows for selecting which
> symbol is being used via macros (e.g. _FILE_OFFSET_BITS). Please correct
> me if I am misrepresenting this as my experience with symbol versioning
> is fairly limited.
Agreed. libselinux as it happens does use a symbol version map so there is
symbol versioning involved in some sense? but not the sense you really mean.
(We could make the symbol map expose the two different function variants
under the same name but different symbols; that's fine but I'll leave that
for upstream to decide.)
> > In any case, if going the bi-ABI path, I think upstream should get
> > involved, and the shape of this decided with them. In addition
> > the library should also be built with LFS by the upstream build
> > system, which it does not currently, to control its ABI.
> I agree that involving upstream is a good idea and my understanding is
> that someone from Canonical is doing that already, which is why the
> schedule was delayed.
Well, "already" is not exactly correct, but the need to resolve this
critical showstopper bug in libselinux before making changes to the
toolchain behavior in unstable and breaking the world has affected the
timeline, yes.
I now have a tested patch that I've raised as an MP in salsa:
https://salsa.debian.org/selinux-team/libselinux/-/merge_requests/9
I welcome review from the Debian libselinux maintainers prior to opening a
discussion with upstream. (Which I will plan to do sometime Thursday
US/Pacific)
--
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
Re: postgresql-16; wrong NMU versions (Re: 64-bit time_t transition in progress)
On Sun, Feb 04, 2024 at 04:08:43PM -0800, Otto Kekäläinen wrote: > +1 for MariaDB for the above. Also I think the package name change was > done for the wrong package, it should probably have been done for > libmariadb3 and not for libmariabd19. > apt-cache rdepends --no-recommends --no-suggests libmariadb3 > = 120 packages > vs zero packages using libmariadbd (that library is useful mostly for > embedded systems doing custom binaries) $ grep mariadb results/* results/results_dumped.txt:libmariadb-dev results/results_failed.txt:libmariadbd-dev results/results_none.txt:libmariadb-dev $ There was nothing unintentional here. libmariadb-dev is clean wrt time_t. libmariadbd-dev failed to be analyzed because it has header ordering requirements which did not get resolved. https://adrien.dcln.fr/misc/armhf-time_t/2024-02-03T09:18:00/logs/libmariadbd-dev/base/log.txt Much better that there be a library transition only for the lesser-used library! -- 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
Re: 64-bit time_t transition in progress
On Mon, Feb 05, 2024 at 08:57:50AM +0200, Andrius Merkys wrote: > On 2024-02-02 19:46, Steve Langasek wrote: > > If there is no new version in experimental, or there is a new version BUT > > the patch against unstable applies cleanly to the version in experimental > > (no fuzz), we upload to experimental. > > Otherwise, patches are sent to the BTS but we skip uploading to experimental > > and will NMU directly to unstable at the next stage (handling binary NEW > > there). > Given libfoo1 in unstable and libfoo2 in experimental, I assume libfoo1t64 > will be NMU'd directly to unstable. After that happens, will it be OK to > upload libfoo2 to unstable (as part of libfoo transition), or will it have > to carry t64 suffix, i.e., libfoo2t64? In my view, it's fine then to upload libfoo2 to unstable without the t64 suffix as ABI compatibility with experimental is not really required. In fact, none of the t64 binaries currently being uploaded to experimental have the final ABI either, we're just using experimental to clear binary NEW. -- 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
Re: 64-bit time_t transition in progress
On Sat, Feb 03, 2024 at 12:04:49PM +0100, Fabio Fantoni wrote: > > debian-devel-announce wouldn't let me attach the file, but for those on > > debian-devel at least, you can find the dd-list of to-be-NMUed source > > packages attached. > From what I understand, for most of the packages involved a rebuild is > enough This list of packages are the packages that require sourceful changes because the runtime library packages must be renamed to declare the ABI incompatibility (or, if a package rename is not appropriate, then managed Breaks: against binaries built against the old ABI). We have a list of the packages that need no-change-rebuilds, but it's not this list. > but this rebuild must be done after that of all their dependencies > (dependencies of dependencies etc...) involved to avoid unexpected events > that could cause crashes on some architectures (in cases ABI changes > occurred in the underlying dependencies but the rebuild was done before > one of those). > Having a package that depends on many and that part of those are themselves > involved in various other chains, how do NMU (when needed) to unstable and > rebuilds of other packages happen? > A single NMU on unstable or rebuild (for each package involved) but with > such an order so that when it is done all dependencies are already rebuild, > or with multiple rebuilds between the various migration chains involved? Once all of the library packages have been uploaded to unstable and rebuilt, we will push no-change rebuilds of all packages depending on the old runtime library names. There should be no need for multiple rounds of uploads; *all* packages with dependencies on *any* of the renamed libraries will be triggered as a batch. There may be build failures if there are interdependencies between some of these packages because of unsatisfiable build dependencies, but those will be resolved semi-automatically in cooperation with the buildd maintainers and only one round of builds will actually be required. -- 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
Re: 64-bit time_t transition in progress
On Sat, Feb 03, 2024 at 03:22:33PM +0100, julien.pu...@gmail.com wrote: > Le samedi 03 février 2024 à 10:16 +0100, julien.pu...@gmail.com a > écrit : > > About flint: if you need anything done, don't hesitate to ask me. > In fact multi-arch is broken for flint and I can probably fix it: would > a new upload go in your way or on the contrary help you ? [I'll refrain > any move until you confirm I won't break your effort.] We are currently only uploading to experimental, for clearing NEW and for usrmerge analysis. Once that is all done and dpkg is uploaded to unstable, we will rebase all patches on whatever version of the library is in unstable at that time. You don't need to hold off on an upload to unstable for fear of conflicts. -- 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
Re: 64-bit time_t transition in progress
On Sat, Feb 03, 2024 at 10:16:48AM +0100, julien.pu...@gmail.com wrote: > Le vendredi 02 février 2024 à 08:21 -0800, Steve Langasek a écrit : > > The packages previously not reported are: > > flint > > flint-arb > About flint: if you need anything done, don't hesitate to ask me. > About flint-arb: its code has been merged into flint, so it's abandoned > upstream. The package is in FTBFS... only the sagemath package prevents > its removal. Don't get blocked by this mess, you already have enough on > your plate. Thanks. These were added because flint 2.9.0-5 which was the current version in December successfully analyzed and showed no ABI breakage, but flint 3.01-2 which is now current can't be analyzed due to compilation errors. https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09%3A53%3A00/logs/libflint-dev/base/log.txt So *maybe* a quirk could be added for a-c-c to let the headers be analyzed and show that no change is needed. Or maybe the analysis would show that the new version has introduced new entry points that do depend on time_t size. I can't tell from here. I'm not bothered either way, but by default we're going to wind up picking this up in the mass NMUs and libflint18 will change to libflint18t64, which will have no effect either way on users upgrading from stable releases since this is a new soname since bookworm. -- 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
Re: 64-bit time_t transition in progress
On Fri, Feb 02, 2024 at 07:34:46PM +0100, Bill Allombert wrote: > On Fri, Feb 02, 2024 at 08:21:57AM -0800, Steve Langasek wrote: > > Dear developers, > > As mentioned previously on debian-devel[6], we know that there are a number > > of library packages being included in this transition which we have not > > proven have an ABI affected by 64-bit time_t. This is because the > > engineering cost of analyzing the long tail of packages whose headers > > out-of-the-box fail ABI analysis under abi-compliance-checker is much higher > > than the cost of just changing the package name and moving forward with > > rebuilds. > Why not use reproducible build on a 32bit platform and see whether the new > library is different from the old one ? Well, if this suggestion had come 6 months ago when this plan was laid out on debian-devel, I think it would have been worth exploring. Though I would have still expected a large number of false-positives, because there would be differences for any library using time_t-derived types internally, *or* any filesystem access affected by LFS. > Do the libxxxt64 in experimental supposed to use the new ABI ? Because it > does not seem to be always the case. Is there a lintian test for that ? No. Earlier this had been the plan, but after discussing with Guillem we realized that wasn't actually relevant so we revised the plan on the fly and skipped dpkg in experimental. > Relying on dpkg-buildflags alone cannot be sufficient. I don't see any practical reason why not. -- 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
Re: 64-bit time_t transition in progress
Sorry, I mean to add: in the specific case of clamav, the source in
experimental has a new soname. So the patch will definitely not apply; and
we will want to NMU clamav to unstable, with a rename of whatever runtime
library package is there at the time the NMUs happen; so the version of
clamav in experimental can ignore this transition and just use the new
soname once it finally lands (is superseded by the next LTS version?)
On Fri, Feb 02, 2024 at 09:46:10AM -0800, Steve Langasek wrote:
> On Fri, Feb 02, 2024 at 05:27:02PM +, Scott Kitterman wrote:
> > On February 2, 2024 4:43:52 PM UTC, Steve Langasek
> > wrote:
> > >Hello,
>
> > >debian-devel-announce wouldn't let me attach the file, but for those on
> > >debian-devel at least, you can find the dd-list of to-be-NMUed source
> > >packages attached.
>
> > Thanks,
>
> > How are you handling the case where there's already a version of the
> > package in experimental (this applies to clamav where we are tracking the
> > latest, non-LTS version in experimental)?
>
> If there is no new version in experimental, or there is a new version BUT
> the patch against unstable applies cleanly to the version in experimental
> (no fuzz), we upload to experimental.
>
> Otherwise, patches are sent to the BTS but we skip uploading to experimental
> and will NMU directly to unstable at the next stage (handling binary NEW
> there).
>
>
> Abridged citation from the code used, which probably explains as clearly as
> anything:
>
> apt-get source --only-source "$src"/unstable
> cd "$src"-*
> oldsrcver=$(dpkg-parsechangelog -S Version)
> "$toolsdir"/time-t-me
> dch -n 'Rename libraries for 64-bit time_t transition.'
> dch -r -D experimental ''
> sudo env APT_CONFIG=$APT_CONFIG mk-build-deps -i -r
> dpkg-buildpackage -S -uc -us
> srcver=$(dpkg-parsechangelog -S Version)
> # make sure the package from unstable builds with the patch
> # before we send it to the BTS
> DEB_BUILD_OPTIONS="$DEB_BUILD_OPTIONS nocheck" \
> dpkg-buildpackage -uc -us
> cd ..
> debdiff "$src"_${oldsrcver#*:}.dsc "$src"_${srcver#*:}.dsc \
> > nmu_"$src".debdiff || true
>
> # maybe there's a new version, or maybe we fall back to
> # unstable
> apt-get source --only-source "$src"/experimental \
> || apt-get source --only-source "$src"/unstable
> cd "$src"-*
>
> # we filter out debian/changelog and regenerate it with
> # matching content, because if there is a new version then
> # that part of the diff will fail to apply; but if everything
> # else applies we should just upload to experimental anyway
> # with an appropriate bumped version.
> if ! filterdiff -x '*/debian/changelog' ../nmu_"$src".debdiff \
> | patch -p1 -f -F0
> then
> cd ..
> echo "$src: failed" >> upload-nmus.log
> rm -f nmu_"$src".debdiff
> rm -rf "$src"[_-]*
> continue
> fi
>
> --
> 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
--
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
Re: 64-bit time_t transition in progress
On Fri, Feb 02, 2024 at 05:27:02PM +, Scott Kitterman wrote:
> On February 2, 2024 4:43:52 PM UTC, Steve Langasek wrote:
> >Hello,
> >debian-devel-announce wouldn't let me attach the file, but for those on
> >debian-devel at least, you can find the dd-list of to-be-NMUed source
> >packages attached.
> Thanks,
> How are you handling the case where there's already a version of the
> package in experimental (this applies to clamav where we are tracking the
> latest, non-LTS version in experimental)?
If there is no new version in experimental, or there is a new version BUT
the patch against unstable applies cleanly to the version in experimental
(no fuzz), we upload to experimental.
Otherwise, patches are sent to the BTS but we skip uploading to experimental
and will NMU directly to unstable at the next stage (handling binary NEW
there).
Abridged citation from the code used, which probably explains as clearly as
anything:
apt-get source --only-source "$src"/unstable
cd "$src"-*
oldsrcver=$(dpkg-parsechangelog -S Version)
"$toolsdir"/time-t-me
dch -n 'Rename libraries for 64-bit time_t transition.'
dch -r -D experimental ''
sudo env APT_CONFIG=$APT_CONFIG mk-build-deps -i -r
dpkg-buildpackage -S -uc -us
srcver=$(dpkg-parsechangelog -S Version)
# make sure the package from unstable builds with the patch
# before we send it to the BTS
DEB_BUILD_OPTIONS="$DEB_BUILD_OPTIONS nocheck" \
dpkg-buildpackage -uc -us
cd ..
debdiff "$src"_${oldsrcver#*:}.dsc "$src"_${srcver#*:}.dsc \
> nmu_"$src".debdiff || true
# maybe there's a new version, or maybe we fall back to
# unstable
apt-get source --only-source "$src"/experimental \
|| apt-get source --only-source "$src"/unstable
cd "$src"-*
# we filter out debian/changelog and regenerate it with
# matching content, because if there is a new version then
# that part of the diff will fail to apply; but if everything
# else applies we should just upload to experimental anyway
# with an appropriate bumped version.
if ! filterdiff -x '*/debian/changelog' ../nmu_"$src".debdiff \
| patch -p1 -f -F0
then
cd ..
echo "$src: failed" >> upload-nmus.log
rm -f nmu_"$src".debdiff
rm -rf "$src"[_-]*
continue
fi
--
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
Re: [Debian-iot-maintainers] Bug#1062257: libcoap3: NMU diff for 64-bit time_t transition
On Thu, Feb 01, 2024 at 07:45:57AM +0100, Carsten Schoenert wrote: > Hello Steve, > Am 31.01.24 um 21:59 schrieb Steve Langasek: > ... > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. > ^^ > > Although > > this package will be uploaded to experimental immediately, there will be a > > period of several days before we begin uploads to unstable; so if > > information > > becomes available that your package should not be included in the > > transition, > > there is time for us to amend the planned uploads. > I'm a bit puzzled and disappointed. > libcopap3 isn't a package that is within the QA group nor is it bit rotting. > What is the rationale behind rising a bug report at 9:51pm my time and > firing a *direct* NMU upload just 11min later (according to the time stamps > from the emails)? There are 1200+ source packages that require NMUing and the Debian archive is a moving target. In the past 3 days the list of packages requiring uploads has been regenerated 3 times with changes each time due to archive removals, new sonames in unstable, etc. Churning through the list of 1200 packages is at this rate going to take at least a week (after 4 days we've gotten bugs filed and NMUs to experimental completed for less than 400 of the 1200 packages). It is not practical to leave a gap of any significant length of time between the filing of bugs in patches and the uploads to experimental. There will be a pause between the uploads to experimental, and the uploads to unstable, which gives space for maintainer feedback while we run analysis against the contents of experimental with regards to usrmerge. > I as the uploader for libcoap have no chance to do any action on this bug > report! This behavior I'm not expecting within Debian. > What are the plans now with forwarding the underlying issue to upstream? > Upstream is very responsive and I've good contacts to the upstream authors, > but who is doing this work now? This is an ABI change resulting from a change to compiler flags. You will see the diff includes no changes to upstream source. There is nothing to forward. > I read the wiki page mentioned from the initial email again, also there I > can't find a written plan that would explain me why the bug reporting > together with a direct upload did happen. I see no plan there what will > happen on what time. > Why no usual muss bug filling did happen so groups and maintainers would > have some knowledge about these planned changes? BTW: I've no problem with > the technical thing what is happen, but I need to deal also with other > things too like a CVE fix for libcopa3. Since this has only been uploaded to experimental, I would expect this does not interfere with your CVE handling? -- 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
Re: 64-bit time_t: package lists, counts du jour, dd-list for NMUs
In exercising scripts for the mass NMUs in a dry run, I've run into another little snag. $ grep -vEc '[0-9](c102|c2|g|ldbl|v5)?$' reports/runtime-libs 234 $ The package rename handling assumes that the affected runtime library packages have names matching a certain pattern (ends in a digit, plus a possible previous ABI qualifier). But 234 of the library patches don't match this pattern; some don't correspond to library sonames at all. Right off the bat, the first of these is 389-ds-base-libs. I don't want to rename it to '389-ds-base-libst64'. Also it turns out that there are no reverse-dependencies of this lib package. So I will omit this package from the transition. Others in this list have package names I don't understand, such as a 'd' suffix that doesn't correspond to anything in the soname, or libcoin80c. libdmtx0b and libvibrant6b at least have explanations in the changelog. So I guess I'll work on fleshing out a rename map for these. On Sun, Jan 21, 2024 at 12:57:17AM -0800, Steve Langasek wrote: > Hello, > > Here is an updated analysis of the transition. This is based on a full > rerun on Debian unstable as of 2024-01-17 and includes a number of > incremental fixes reducing the number of libraries to be transitioned. > Though this is not particularly significant; the number of source packages > to be NMUed drops from 1197+51=1248 to 1192+50=1242, and the number of > source packages to be binNMUed drops from 5442+170=5610 to 5415+170=5585. > > It also picks up a small number of source packages (5) that are new to > unstable since last month. I have no strong opinion about forcing a package > name change for these, since they likely don't have any reverse-dependencies > yet with a significant install base on 32-bit archs; but by default they're > included. > > > Output files from the new analysis can be found here: > > https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/ > > I am not making the same mistake as before and attempting to attach all of > the various supplementary files, thus hitting email size limits. Instead, I > have pushed them all to: > > https://people.canonical.com/~vorlon/armhf-time_t/ > > > You may have noticed that it is now past the original proposed date of > 2024-01-18. This was a knowingly aggressive target date on which to try to > converge; there are still discussion subthreads in flight on debian-devel > that I want to make sure settle out before we proceed, and also Guillem let > me know there was a dpkg upload planned that would conflict, pushing this > back to Monday, 22 Jan at minimum. Based on capacity and availability, I > would like to now start uploads to experimental this Friday, 26 Jan. > > I do not know how long it will take to build all 1200+ source packages and > upload them. I assume it will take a few days at least. Once the > transition has started, I will post again to debian-devel with projections > of when we might expect to start landing changes in unstable. > > Attached is the current dd-list for the packages that would have sourceful > NMUs. -- 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
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi Sebastian, On Tue, Jan 09, 2024 at 10:49:23AM +0100, Sebastian Ramacher wrote: > > > > > > 22 libobs-dev > > > > > That's a change to the plugin ABI only. > > > > Can you explain how you've reached that conclusion? This is a package > > > > that failed to be analyzed in the latest run; an earlier run against > > > > Ubuntu lunar showed no change in ABI at all. > > > libobs-dev and the shared library are an oddity of obs-studio. There > > > only purpose is to build plugins. > > Ok, but it appears there are a large number of reverse-dependencies on > > libobs0 from other source packages, and there is no OTHER encoding of > > information about plugin ABI aside from this (no Provides: field on > > obs-studio). So what do you suggest here with respect to ABI skew between > > obs-studio and its plugins on armhf? > I need some more time to check the current situation. Have you had enough time to check this out? Are we ok to proceed with handling libobs0 along with the other libraries, which would address the ABI skew despite it technically not being libobs0 whose ABI is changing? > > > > > > 9 libopenmpt-dev > > > > > > > Seems to be a false positive. > > > > > > > > > > > > Your responses here are to the contents of the `sorted-revdep-count` > > > > list. > > > > This is the list of header packages that *we were unable to analyze with > > > > abi-compliance-checker*, and so in the interest of avoiding ABI > > > > mismatches > > > > and broken systems for users when upgrading on 32-bit archs, would get a > > > > package rename to be safe. > > > > This is the plan I had outlined at: > > > > https://lists.debian.org/debian-devel/2023/07/msg00232.html > > > > I am happy for any help in the form of patches to > > > > https://salsa.debian.org/adrien-n/armhf-time_t that fix the failures of > > > > these header packages to be analyzed, or explanations for how a given > > > > header > > > > package's API changes cannot affect the ABI of the runtime libraries > > > > from > > > > the source package so that we can manually exclude those libraries from > > > > the > > > > transition. I am not sure I would *recommend* that maintainers spend a > > > > lot > > > > of time on proving one or another individual library does not have an > > > > ABI > > > > breakage, especially in the long tail of libraries with few > > > > reverse-dependencies whose involvement in the transition is unlikely to > > > > substantially slow down Debian development. > I was looking at the repo but it is unclear to me how packages that can > be skipped are handled there. What would a PR look like to exclude > specific packages? The skip handling is in the block starting at https://salsa.debian.org/vorlon/armhf-time_t/-/blob/main/check-armhf-time_t?ref_type=heads#L852 Thanks, -- 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
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
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 aga
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi again,
On Sun, Jan 07, 2024 at 01:09:48PM +0100, Rene Engelhard wrote:
> Am 07.01.24 um 04:38 schrieb Steve Langasek:
> > The ordering here would be:
> > - dpkg will be uploaded to experimental with 64-bit time_t in the default
> >flags
> > - the source packages which need an ABI change
> >("source-packages"+"lfs-and-depends-time_t") and do not already have
> >versions in experimental, will have sourceful NMUs to experimental with
> >the new binary package names in order to clear binary NEW, in
> > coordination
> > - once these packages have all cleared binary NEW, the new dpkg defaults
> >will be uploaded to unstable
> And in the meanwhile in experimental it will be built with the old time_t on
> other architectures.
> Since the new dpkg won't be picked up.
> Not in the experimental builders unstable+experimental chroots which only
> install experimental packages when Build-Depends: need them.
> (For an undefined time given how much the packages later in the chain wait
> in NEW)
> Especially on armhf which is affected. Or will you do the source NMUs on
> armhf/i386? (For some packages where some features are disabled on 32bit
> this is probably not a good idea)
There is no intention here to do the source NMUs on armhf/i386; they will be
done on amd64.
Yes, autobuilds of these packages in experimental would, in the naive
implementation, still build with the old ABI and the new name.
I am not overly concerned about this, experimental is a staging ground for
developers and not something that folks are intended to install from in
production. And there would be very few if any reverse-dependencies of
these packages uploaded to experimental to pick up the new name. The intent
is to work with the ftp team to batch-accept these through binary NEW once
all of the uploads are done, and then promptly proceed with upgrades to
experimental.
Do you have a different suggestion?
Note that even including a versioned build-dependency on dpkg-dev in the
uploads to experimental doesn't really address the possibility of ABI skew
if reverse-dependencies are uploaded during the critical window where dpkg
has not yet been uploaded to unstable, because *those* packages will not
have a versioned build-dependency on dpkg: so will link against the
libraries with the new names but will themselves be using the old ABI.
--
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
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timelineg
On Wed, Jan 17, 2024 at 09:33:12PM -0800, Steve Langasek wrote:
> And my proposal for checking that set, since we're only talking about
> runtime library packages, is to check whether any of the contents of these
> packages in bookworm match ^/lib - as a runtime library package NOT matching
> this pattern, but matching a pattern for one of the other aliased
> directories, would be something ... special.
Binary packages in bookworm shipping libs in /lib* (i.e. /lib, /lib32,
/lib64):
$ ssh -C coccia.debian.org zcat \
/srv/mirrors/debian/dists/bookworm/'*'/Contents-armhf.gz \
| awk -F/ '/^lib.*\.so/ { print $NF }' | sort -u | wc -l
222
$
Binary packages in experimental that are to be renamed:
$ for pkg in $(cat reports/lfs-and-depends-time_t reports/runtime-libs); do \
sed -n -e"s/Package: \($pkg\)$/\1/p" \
/var/lib/apt/lists/*experimental*Packages; \
done | sort -u | wc -l
130
$
$ join -j1 usrmerge-libs experimental-libs
libpam0g
$
I'll follow up on that.
--
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
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi Colin,
On Tue, Jan 09, 2024 at 01:32:11PM +, Colin Watson wrote:
> On Mon, Jan 08, 2024 at 03:01:11PM -0800, Steve Langasek wrote:
> > On Fri, Jan 05, 2024 at 09:17:52PM +0100, Paul Gevers wrote:
> > > On 05-01-2024 17:36, Rene Engelhard wrote:
> > > > Also a problem is that experimental also might already contain totally
> > > > unrelated updates like new upstream versions...
> > > I share this worry. Have you thought about how to handle the cases where
> > > you
> > > don't have experimental to upload to? How big is this problem?
> In the current situation, though, not having experimental available
> means that there's no opportunity for dumat to weigh in regarding
> usrmerge interactions, which seems problematic given Helmut's
> preliminary analysis.
I guess this is a reply to the bits of context I retained above rather than
directly a reply to my most immediate preceding message. In a separate
subthread, I laid out what I thought the process should be for handling the
transition of packages in that situation; but you are raising a separate
point.
Which parallels what Helmut had to say:
> Whenever you face files in aliased locations (other than systemd units),
> please go via experimental to let dumat judge your upload. Check the
> bookworm package for files in aliased locations, not the unstable one.
I have also had other out-of-band conversations with Helmut about the
overlapping issues between usrmerge and time_t, so this was generally
speaking on my radar although I didn't address it in my proposed transition
plan.
I think it is unrealistic to ask experimental to be otherwise quiesced of
transitions to ensure that we can stage all of the affected libraries in
experimental, and I also think that making false transitions for packages
that are ALREADY in experimental because of transitions would be
counterproductive. ("False" because if the library package has a different
soname between unstable and experimental, then renaming the runtime library
package in the *experimental* version is unnecessary because there's nothing
"in the wild" depending on that package name but with the old ABI for which
upgrade compatibility is of concern.)
My preferred path forward here would be, as Helmut suggests, to check which
libraries are in the intersection of (packages in experimental for which we
won't stage time_t uploads) and (packages that exist in bookworm and need
transitioning of aliased paths), and ensure that these packages are handled
carefully according to Helmut's own guidance. My optimistic expectation is
that the intersection will be null, or nearly; but in any case I will bring
data.
And my proposal for checking that set, since we're only talking about
runtime library packages, is to check whether any of the contents of these
packages in bookworm match ^/lib - as a runtime library package NOT matching
this pattern, but matching a pattern for one of the other aliased
directories, would be something ... special.
--
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
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Fri, Jan 05, 2024 at 09:17:52PM +0100, Paul Gevers wrote: > Hi Steve, > On 05-01-2024 17:36, Rene Engelhard wrote: > > Also a problem is that experimental also might already contain totally > > unrelated updates like new upstream versions... > I share this worry. Have you thought about how to handle the cases where you > don't have experimental to upload to? How big is this problem? > Another worry, how will you provide the required changes to the maintainers > of the packages? Via BTS? For those working on salsa: MR? Both? Something > else? Obviously we should not end in the situation that a new upload goes > back to the old name (or are the ftp-masters so keen on this transition that > that won't happen? But what about newer versions with the old name already > in experimental, conform the former worry?). I've seen NMU's being ignored > by subsequent uploads by the maintainer, even when they fixed RC issues > which were then reintroduced. I would intend to provide diffs via the BTS. This remains the standard policy for NMUs in Debian per the Developer's Reference, and as far as I know has worked effectively for all such previous ABI transitions. I think it is reasonable to expect maintainers to pay attention to their bug mail as our defined Debian process. I don't think it would be reasonable to expect people working on cross-archive toolchain transitions to cater to individual maintainer preference in this regard. If a maintainer ignores the NMU and drops the rename, they'll be introducing a new library transition again on 32-bit archs. Won't they also be caught again in binary NEW, for those packages that don't have the same runtime library package name in experimental? It seems to me there's ample opportunity to catch such mistakes if they happen. -- 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
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Mon, Jan 08, 2024 at 04:12:42PM +0100, Julian Andres Klode wrote: > > - once these packages have all cleared binary NEW, the new dpkg defaults > > will be uploaded to unstable > What happened to the plan to workaround this by doing dak database > shenanigans prior to uploading to avoid binary-NEW altogether, that > I chatted about with mhy/#debian-ftp and you? Did that not work out? That wasn't called out here but is part of the implementation details of the plan. The intention is still to go through binary NEW in experimental before copying to unstable, because it will take time to get all the binary uploads done (longer than it will take to get the sourceful uploads to unstable done), so it's better to stage in experimental to minimize the window in unstable when uploads can be broken. -- 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
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Sat, Jan 06, 2024 at 09:25:52AM +0100, Rene Engelhard wrote:
> Hi,
> 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
> > [...]
> > 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?
> How does that play together with the needed dpkg only in experimental?
> You can't build stuff for unstable involving experimental packages (except
> manually with binary upload, which would block testing migration)
The ordering here would be:
- dpkg will be uploaded to experimental with 64-bit time_t in the default
flags
- the source packages which need an ABI change
("source-packages"+"lfs-and-depends-time_t") and do not already have
versions in experimental, will have sourceful NMUs to experimental with
the new binary package names in order to clear binary NEW, in coordination
- once these packages have all cleared binary NEW, the new dpkg defaults
will be uploaded to unstable
- source packages which need an ABI change but already have versions in
experimental will be uploaded to unstable, with binaries, to clear binary
NEW
- sourceful NMUs of all the libraries will be reuploaded to unstable
(without binaries, so that they can be promoted to testing without
additional uploads).
- perl will also get a sourceful upload, to manually handle 'perlapi'
Provides.
- binNMUs will be scheduled for all of the reverse-dependencies.
--
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
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
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 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/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
Re: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Sat, Jan 06, 2024 at 10:01:30AM -0700, Sam Hartman wrote: > >>>>> "Steve" == Steve Langasek writes: > >> At one level, krb5-multidev only has an rdep of 5, but I suspect > >> the rdep count for libkrb5-dev is somewhat larger:-) I don't know > >> how many packages would be removed from the transition if we > >> decide most of the krb5 libraries do not need to transition. > Steve> If we determined only libkdb5-10 and libgssrpc4 were > Steve> affected, that does significantly reduce the number of > Steve> packages needing to be rebuilt because of krb5, though maybe > Steve> most of those packages also depend on other libraries that > Steve> are transitioning. > I confirm libgssrpc is also affected. > (It would be nice to get rid of libgssrpc entirely and just use the > system tli-rpc). > My bad; I was so focused on time_t I forgot about timeval. > However, I do think that we're limited only to libkdb5-10 and > libgssrpc4. > I would prefer not to change the abi of the other libraries, especially > libkrb5, libk5crypto3 and libgssapi-krb5-2. > What can I do to help facilitate that? I've updated the override list here. Reduces the count of revdeps to be rebuilt from 5450+168 to 5439+168. Thanks, -- 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
Re: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Fri, Jan 05, 2024 at 02:23:59PM -0700, Sam Hartman wrote: > >>>>> "Steve" == Steve Langasek writes: > Steve> - In multi-library packages, there is no reliable way to map > Steve> from a set of headers in a dev package to specific shared > Steve> libraries in a runtime library package that's not > Steve> additionally computationally prohibitive; we therefore > Steve> conservatively assume that if any headers from a source > Steve> package show time_t ABI changes, all the runtime library > Steve> packages from the source package are affected by the > Steve> transition. This seems sensible in general, but er, in the > Steve> pathological case we have Source: zlib that now ships both > Steve> zlib1g-dev and libminizip-dev, zlib1g-dev is confirmed to not > Steve> be ABI breaking, libminizip-dev has failed to analyze, and we > Steve> don't want to force a transition for zlib1g because of > Steve> libminizip (!). Current plan is to simply special case > Steve> zlib1g, but there could be other problem packages we haven't > Steve> identified. > I think krb5 may be in this category. > In particular, it looks like time_t is only exposed in the kdb.h API, > which appears to have no reverse depends outside of krb5. > I actually think that the freeIPA server may have a plugin that depends > on kdb.h, and Samba4 can be built in such a way that it depends on > kdb.h, but it looks like neither of those applies to the Debian archive. https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/compat_reports/libkrb5-dev/lfs_to_time_t/compat_report.html indicates that the CLIENT struct is affected because the cl_call function pointer takes a 'struct timeval' as an argument. So that's not internal to kdb, it looks like an actual ABI change? > At one level, krb5-multidev only has an rdep of 5, but I suspect the > rdep count for libkrb5-dev is somewhat larger:-) > I don't know how many packages would be removed from the transition if > we decide most of the krb5 libraries do not need to transition. If we determined only libkdb5-10 and libgssrpc4 were affected, that does significantly reduce the number of packages needing to be rebuilt because of krb5, though maybe most of those packages also depend on other libraries that are transitioning. -- 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
Re: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Fri, Jan 05, 2024 at 05:28:37PM +0100, Guillem Jover wrote: > > Guillem Jover > >libaio > >libmd > >liburing > I checked these, and it looks like libmd and liburing are > false-positives? > * libmd uses AC_SYS_LARGEFILE, and on 32-bit arches it is already built >with LFS, the problem is that the header exposes off_t which means >the code linking against it needs to match its build flags, >otherwise they would already be broken now. You might want to look >into this as a potential pattern for other false-positives probably. >(I should probably update upstream the .pc file to include the >-D_FILE_OFFSET_BITS=64 flags if enabled, but I don't think the >analysis used .pc files anyway.) Thanks - yes, the analysis didn't use .pc files, though I'm checking if that's something we could improve on. But as you say it doesn't help with the current libmd anyway, so I'm adding that to the manual exclusion list. Reduces the count of revdeps to be rebuilt from 5450+178 to 5450+169. > * liburing is marked as LFS-sensitive, but that comes from inline >functions using off_t which end up casting that into an u32 type, >so I don't think this should affect the ABI. It is also forcibly >built with -D_FILE_OFFSET_BITS=64 in the upstream build system >(and with future=+lfs for good measure in the packaging, which >I'll switch to abi=+lfs). io_uring_prep_fadvise and io_uring_prep_madvise appear to be symbols publicly exposed in the ABI of /usr/lib/x86_64-linux-gnu/liburing-ffi.so.2 so I don't think it's true that the marking is only because of inline functions? But as this is also already built with LFS and is a false-positive, I've removed this as well. Reduces the count of revdeps to be rebuilt from 5450+169 to 5450+168 (not much improvement :). -- 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
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Fri, Jan 05, 2024 at 05:36:10PM +0100, Rene Engelhard wrote:
> > My strawman proposal is to give this thread 2 weeks from today for feedback
> > and further refinement, and also to further reduce the number of
> > false-positives included in the transition. Then, starting on Jan 18:
> > - 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
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.
> > - 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?
libreoffice libs only have one reverse-dep, zemberek-ooo; so the risk of
entanglement here is small anyway.
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"?
--
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
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Fri, Jan 05, 2024 at 09:32:28PM +0100, Sebastian Ramacher wrote: > On 2024-01-05 11:06:09 -0800, Steve Langasek wrote: > > On Fri, Jan 05, 2024 at 06:53:50PM +0100, Sebastian Ramacher wrote: > > > Hi Steve > > > > - perl will also get a sourceful upload, to manually handle 'perlapi' > > > > Provides. > > > Can we combine this one with the upcoming perl transition? See #1055955. > > Pros and cons of combining: > > - it will save another rebuild of perl modules > > - new perl upstream versions usually break at least some > > reverse-dependencies in the archive, so this may slow down the time_t > > transition to testing for other packages by entangling it with sourceful > > perl changes. > > The release team has already suggested not entangling the two. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055955#10 > That was two months ago and we were expecting some progress. There was > however none so far. Sorry, what were you expecting exactly? I've had no communication from the Release Team until now about expectations, including on the debian-devel thread back in July. > As perl 5.38 is already staged in exeperimental, there are only two > options: time64_t waits until perl 5.38 is done or we entangle them. Rene and Paul raise this concern as well. However, there is another option. For any packages involved in this transition which currently have new versions staged in experimental which are not yet ready to go to unstable, we can simply exclude them from the upload to experimental, and do the NEW processing for this subset of packages directly in unstable as part of the second step. This should be an ABI change but not an API change; the rate of new build failures should be very small (small enough that I have not proposed any rebuild testing as part of this transition). As previously discussed, there may be some impact from -Werror=implicit-function-declaration but those can be quickly dealt with. Barring any existing testing migration blockages, I expect this whole assembly to be able to migrate to testing rather quickly. The main point is that we don't want to have a large window between landing dpkg in unstable, and uploading the libraries in unstable, due to NEW processing; because that will result in misbuilt and crashy combinations of packages on armhf until resolved. And if the time_t transition goes into unstable, has not yet migrated to testing, and some of the library transitions in question are ready to go to unstable, I don't mind; I'm happy to work with the maintainers of those libraries to get the transitions done, and also they can just ignore the previous NMUs because they're getting a new SONAME anyway. Does this seem practicable to you (and the release team generally)? > > > > 22 libobs-dev > > > That's a change to the plugin ABI only. > > Can you explain how you've reached that conclusion? This is a package > > that failed to be analyzed in the latest run; an earlier run against > > Ubuntu lunar showed no change in ABI at all. > libobs-dev and the shared library are an oddity of obs-studio. There > only purpose is to build plugins. Ok, but it appears there are a large number of reverse-dependencies on libobs0 from other source packages, and there is no OTHER encoding of information about plugin ABI aside from this (no Provides: field on obs-studio). So what do you suggest here with respect to ABI skew between obs-studio and its plugins on armhf? > > Looks like the failure to analyze should be easily fixable (maybe libobs-dev > > shouldn't be shipping this header?) > > https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/logs/libobs-dev/base/log.txt > > > > 14 gnuradio > > > gnuradio bump its SONAME every other month. > > And usually takes time, at least from what I've seen on the Ubuntu side, > > to settle all reverse-dependencies out into a consistent state where > > they can migrate to testing > I wouldn't waste my time with gnuradio. The maintainers does not > coordinate transitions. After January 10th assuming that AUTORM kicks > in, it won't be relevant any more. It wastes less of my time to *not* special-case it, then ;-) > > > > 9 libopenmpt-dev > > > Seems to be a false positive. > > > > Your responses here are to the contents of the `sorted-revdep-count` list. > > This is the list of header packages that *we were unable to analyze with > > abi-compliance-checker*, and so in the interest of avoiding ABI mismatches > > and broken systems for users when upgrading on 32-bit archs, would get a > > package rename to be safe. > > This is the plan I had outlined at: > > https://lists.debian.org/debian-devel/2023/07/msg00232.html > > I
Re: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Fri, Jan 05, 2024 at 06:59:20PM +0100, Sebastian Ramacher wrote: > > > > I am also attaching here the dd-list output for the packages that will > > > > need > > > > to be sourcefully NMUed for the transition, for your review. > > > Why do the need sourceful NMUs if they just need to be rebuilt? > > Sorry, if the original message hadn't been lost somewhere in the mail > > system before being delivered to debian-devel (I've now tried to resend it), > > this might have been clearer from context. Guillem points out the mail has > > been delivered to debian-release, so you can read the whole thing there: > > https://lists.debian.org/debian-release/2024/01/msg00033.html > > Anyway, this is the list of source packages containing libraries whose ABI > > will change. So the packages need to be renamed in order to expose the ABI > > incompatibility to reverse-dependencies. > I am confused. Above you say: > > these in turn have 174 additional > > reverse-dependencies that would need rebuilt (list attached). > This sounds to me like those are packages that are involved in the > transition and need rebuilds, but do not change their ABI. And in fact, > for most of packages that I maintain on the list, the ABI does not > change. > Can you please clarify which of the packages in your lists require > changes to the binary package names and which do not? Sorry for the confusion. The two lists requiring binary package name changes are the attachments named 'source-packages' and 'lfs-and-depends-time_t'. This is what I fed into dd-list, and encompass 1248 source packages (1195 + 53). -- 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
64-bit time_t: updated archive analysis, proposed transition plan with timeline
This seems to be at most about 600 additional packages to be included in the
transition.
In addition, Guillem pointed out that if there are libraries whose ABIs are
lfs-sensitive but not time_t-sensitive, and either they themselves depend on
libraries which are time_t-sensitive or they have reverse-dependencies that
do, so they will also need to be included in the transition. I have
identified a list of 53 packages in this category (list attached); these in
turn have 174 additional reverse-dependencies that would need rebuilt (list
attached).
== Migration plan ==
I have yet to receive any feedback from the Release Team on this bug
regarding finding a slot for this transition.
https://release.debian.org/transitions/ shows some ongoing transitions of
libraries that need to be included in the time64 transition (gmsh,
gnuradio...) and I have no opinion about whether these need to be resolved
first before proceeding with the mass rebuild.
My strawman proposal is to give this thread 2 weeks from today for feedback
and further refinement, and also to further reduce the number of
false-positives included in the transition. Then, starting on Jan 18:
- dpkg will be uploaded to experimental with 64-bit time_t in the default
flags
- the source packages which need an ABI change
("source-packages"+"lfs-and-depends-time_t" will have sourceful NMUs to
experimental with the new binary package names in order to clear binary
NEW, in coordination
- once these packages have all cleared binary NEW, the new dpkg defaults
will be uploaded to unstable
- the sourceful NMUs of the libraries will be reuploaded to unstable
(without binaries, so that they can be promoted to testing without
additional uploads).
- perl will also get a sourceful upload, to manually handle 'perlapi'
Provides.
- binNMUs will be scheduled for all of the reverse-dependencies.
Please let me know of any problems with this plan.
Thanks,
--
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://lists.debian.org/debian-devel/2023/07/msg00232.html
[1] https://lists.debian.org/debian-devel/2023/07/msg00302.html
[2] https://people.canonical.com/~vorlon/armhf-time_t/runtime-libs
[3] https://people.canonical.com/~vorlon/armhf-time_t/reverse-depends-sources
1260 qt5-qmake
1109 qtbase5-private-gles-dev
205 libpython3.11-dbg
178 ruby3.1-dev
145 libgfortran-13-dev
145 gfortran-13
138 postgresql-server-dev-16
138 libpq-dev
128 qt6-base-private-dev
128 qmake6
128 libqt6opengl6-dev
102 libhdf5-mpich-dev
94 wx3.2-headers
92 octave-dev
60 qtwebengine5-private-dev
60 cups-ppdc
57 libd3dadapter9-mesa-dev
57 libcanberra-gtk-common-dev
46 libperl5.36
44 libnetcdf-dev
41 libopencv-videoio-dev
41 libopencv-ml-dev
41 libopencv-imgproc-dev
41 libopencv-flann-dev
41 libopencv-core-dev
41 libopencv-contrib-dev
38 sudo-ldap
37 qtquickcontrols2-5-private-dev
35 libuv1-dev
34 htslib-test
33 libstdc++-12-dev
33 libgfortran-12-dev
33 libgccjit-12-dev
33 gnat-12
33 gfortran-12
32 libphonon4qt6experimental-dev
30 libhiredis-dev
28 samba-dev
28 libldb-dev
26 libpython3.12-dev
26 libpython3.12-dbg
26 libfuse3-dev
25 llvm-16-dev
25 libunwind-16-dev
25 libpolly-16-dev
25 libmlir-16-dev
25 libclc-16-dev
25 libclang-rt-16-dev
25 libclang-16-dev
25 libc++-16-dev
24 qttools5-private-dev
24 libboost1.83-dev
22 qtwayland5-private-dev
22 libobs-dev
22 libgeos++-dev
21 libvtk9-dev
21 libimath-dev
18 libloadpng4-dev
18 liballeggl4-dev
17 librosbag-storage-dev
16 libscotchmetis-dev
16 libnma-headers
14 libnode-dev
13 lua-socket-dev
13 libtss2-dev
12 libbpp-core-dev
11 libphobos2-ldc-shared-dev
11 libarpack2-dev
11 libanthyinput-dev
10 rados-objclass-dev
10 libvolk-dev
10 libradosstriper-dev
10 libmumps-headers-dev
10 libmagickcore-6-headers
10 libmagickcore-6-arch-config
9 qt6-webengine-private-dev
9 libwebsockets-dev
9 liborc-0.4-dev
9 android-platform-system-core-headers
9 android-libnativehelper-dev
9 android-libbase-dev
8 qt6-websockets-private-dev
8 libgegl-dev
8 gsoap
7 libzbargtk-dev
7 libstonith1-dev
7 libpskc-dev
7 libopenmpt-dev
7 liblrm2-dev
7 libkf5akonadisearch-dev
7 libgccjit-13-dev
7 libdune-common-dev
7 libbullet-extras-dev
7 heimdal-multidev
6 qt6-tools-private-dev
6 lxc-dev
6 libslepc64-real3.18-dev
6 libslepc64-complex3.18-dev
6 libslepc-real3.18-dev
6 libslepc-complex3.18-dev
6 libqpdf-dev
6 libplib-dev
6 libgirara-dev
6 libformsgl-dev
6 libefisec-dev
5 skalibs-dev
5 python3-pyopencolorio
5 llvm-14-dev
5 libxdp-dev
5 libunwind-14-dev
5 libstdc++-10-dev
5 libsource-highlight-dev
5 libsmpeg-dev
5 libopenmm-dev
5 libomniorb4-dev
5 libogre1.12.10
5 libogre-1.12-dev
5 libnauty2-dev
5 libmutter-test-12
5 libmono-2.0-dev
5 libmlir-14-dev
5 libmapnik-dev
5 libini-config-dev
5 libgulkan-d
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Fri, Jan 05, 2024 at 06:53:50PM +0100, Sebastian Ramacher wrote: > Hi Steve > > - perl will also get a sourceful upload, to manually handle 'perlapi' > > Provides. > Can we combine this one with the upcoming perl transition? See #1055955. Pros and cons of combining: - it will save another rebuild of perl modules - new perl upstream versions usually break at least some reverse-dependencies in the archive, so this may slow down the time_t transition to testing for other packages by entangling it with sourceful perl changes. The release team has already suggested not entangling the two. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055955#10 > Here are some more comments on individual packages. > > 22 libobs-dev > That's a change to the plugin ABI only. Can you explain how you've reached that conclusion? This is a package that failed to be analyzed in the latest run; an earlier run against Ubuntu lunar showed no change in ABI at all. Looks like the failure to analyze should be easily fixable (maybe libobs-dev shouldn't be shipping this header?) https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/logs/libobs-dev/base/log.txt > > 14 gnuradio > gnuradio bump its SONAME every other month. And usually takes time, at least from what I've seen on the Ubuntu side, to settle all reverse-dependencies out into a consistent state where they can migrate to testing > > 9 libopenmpt-dev > Seems to be a false positive. Your responses here are to the contents of the `sorted-revdep-count` list. This is the list of header packages that *we were unable to analyze with abi-compliance-checker*, and so in the interest of avoiding ABI mismatches and broken systems for users when upgrading on 32-bit archs, would get a package rename to be safe. This is the plan I had outlined at: https://lists.debian.org/debian-devel/2023/07/msg00232.html I am happy for any help in the form of patches to https://salsa.debian.org/adrien-n/armhf-time_t that fix the failures of these header packages to be analyzed, or explanations for how a given header package's API changes cannot affect the ABI of the runtime libraries from the source package so that we can manually exclude those libraries from the transition. I am not sure I would *recommend* that maintainers spend a lot of time on proving one or another individual library does not have an ABI breakage, especially in the long tail of libraries with few reverse-dependencies whose involvement in the transition is unlikely to substantially slow down Debian development. > > 5 gcc-10-plugin-dev > Can be skipped, not part of testing. Should be RMed from the archive > instead. Thanks, I had already manually excluded gcc-13-plugin-dev from the transition, but there are gcc-*-plugin-dev in the archive for 4 other versions of gcc. I've updated things here to exclude all of them now. I will not, in general, exclude a library from the transition only because it's currently not in testing; this could be a transient situation, and users' shouldn't wind up with broken partial upgrades of this library later if it returns to testing. > > 4 llvm-15-dev > llvm-toolchain-15 is scheduled for removal. Reverse dependencies should > get an RC bug instead. > > libavutil58 > av_timegm is not used by any package in the archive. I'd skip ffmpeg and > it's libraries. How did you determine that it's unused by any reverse-dependencies? I'd be happy to exclude it, but want to be sure we're not exposing users to bugs in the process. > > libpoppler-cpp0v5 > > libpoppler-glib8 > > libpoppler-qt5-1 > > libpoppler-qt6-3 > > libpoppler126 > Can be combined with the upcoming poppler transiton (see #1060019) Again, combining the time_t transition with transitions introducing sourceful changes (and possible API incompatibilities) to existing libraries risks slowing the transition down to Debian's detriment. > > libvlc5 > > libvlccore9 > Change to vlc plugin ABI. This does not require a change of the binary > package name. There are other reverse-dependencies of libvlccore9 in the archive that are not VLC plugins (phonon4qt5-backend-vlc etc). Are these packages simply mis-linked against that library? Thanks, -- 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
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Fri, Jan 05, 2024 at 12:05:57PM +, Simon McVittie wrote: > On Fri, 05 Jan 2024 at 00:17:04 -0800, Steve Langasek wrote: > > - In multi-library packages, there is no reliable way to map from a set of > > headers in a dev package to specific shared libraries in a runtime library > > package that's not additionally computationally prohibitive; we therefore > > conservatively assume that if any headers from a source package show > > time_t ABI changes, all the runtime library packages from the source > > package are affected by the transition. > > 0 dbus-tests > Please ignore this specific binary package. The only public API/ABI > of src:dbus is in libdbus-1-3 + libdbus-1-dev, so analyzing those two > is enough. (dbus-tests accidentally contains one header file, but that's > a minor bug.) > libdbus-1-dev is widely depended-on, so I hope that taking src:dbus off > your list will avoid some unnecessary rebuilds? > > 0 gobject-introspection > Similarly the only public API/ABI of src:gobject-introspection is in > libgirepository1.0-dev, libgirepository-1.0-1, and (in experimental) > libgirepository-1.0-dev. gobject-introspection contains some source > and header files that are used by other packages' regression tests, > but they are not public ABI. Yes, sorry - the way my scripts are set up to do the analysis right now, these packages still show up in the `sorted-revdep-count` list but there are manual overrides mapping both of these to an empty set of runtime libraries. So you'll see they don't show up in the `runtime-libs` or `source-packages` lists, and none of the reverse-dependencies of libdbus or libgirepository are tagged for rebuild. https://salsa.debian.org/adrien-n/armhf-time_t/-/blob/c62a594236374469b2181e9c5578ed124b57c48c/packagelist.py#L304 -- 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
Re: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi Sebastian,
On Fri, Jan 05, 2024 at 06:34:38PM +0100, Sebastian Ramacher wrote:
> On 2024-01-05 00:23:00 -0800, Steve Langasek wrote:
> > On Fri, Jan 05, 2024 at 12:17:04AM -0800, Steve Langasek wrote:
> > > == Results ==
> > > The overall findings of this analysis are 1,745 "dev" packages which
> > > either are confirmed to have ABI changes or could not be checked;
> > > mapping to 2,154 runtime libraries (list attached) from 1,195 source
> > > packages (list attached) and 5,477 reverse-dependencies requiring
> > > no-change rebuilds (list attached). This is within the previously
> > > calculated range of "5300 to 5600", but there are a number of
> > > newly-identified packages that fail to compile and have a large number
> > > of reverse-dependencies. I will continue to work to identify
> > > false-positives here in the hopes of bringing this count down before
> > > pulling the trigger on an actual transition.
> > [...]
> > > In addition, Guillem pointed out that if there are libraries whose
> > > ABIs are lfs-sensitive but not time_t-sensitive, and either they
> > > themselves depend on libraries which are time_t-sensitive or they have
> > > reverse-dependencies that do, so they will also need to be included in
> > > the transition. I have identified a list of 53 packages in this
> > > category (list attached); these in turn have 174 additional
> > > reverse-dependencies that would need rebuilt (list attached).
> > I am also attaching here the dd-list output for the packages that will need
> > to be sourcefully NMUed for the transition, for your review.
> Why do the need sourceful NMUs if they just need to be rebuilt?
Sorry, if the original message hadn't been lost somewhere in the mail
system before being delivered to debian-devel (I've now tried to resend it),
this might have been clearer from context. Guillem points out the mail has
been delivered to debian-release, so you can read the whole thing there:
https://lists.debian.org/debian-release/2024/01/msg00033.html
Anyway, this is the list of source packages containing libraries whose ABI
will change. So the packages need to be renamed in order to expose the ABI
incompatibility to reverse-dependencies. That's not a no-change rebuild.
This is consistent with historical practice in Debian for
toolchain-triggered ABI changes ('g' for libc5->glibc; c102; c2; v5; ldbl)
--
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
Re: debian/copyright format and SPDX
On Fri, Sep 22, 2023 at 12:58:10PM +0200, Stephan Lachnit wrote: > On Fri, Sep 22, 2023 at 11:11 AM Steve Langasek wrote: > > SPDX defines an xml format only. They lost before they'd even started. > > debian/copyright is supposed to be human-readable first and foremost. XML > > need not apply. > Not true. From [1]: > > Shall be in a human readable form. > > [...] > > Multiple serialization formats may be used to represent the information > > being exchanged. Current supported formats include: > > [...] > > tag:value flat text file as described in this specification So can you tell me where in that specification this "flat text file" format is actually described? The specification is not on the page that includes this quote. The text does not link to the place in the spec where this format is described. The site's search page (because it's reasonable for a spec to require a server-side search engine in order for users to be able to find information in it...) doesn't return any results for the string 'tag:value', and a search for 'tag value' points first to https://spdx.github.io/spdx-spec/v2.3/file-tags/ which describes embedding tags in a source file, not constructing a tag:value file. Frankly, the fact that the SPDX spec itself is as bad as it is should be disqualifying for using any file format specified within. But I would still be willing to give it a fair shake, if I could actually find it. -- 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
Re: debian/copyright format and SPDX
On Fri, Sep 22, 2023 at 08:43:25AM -, Sune Vuorela wrote: > On 2023-09-08, Jeremy Stanley wrote: > > Since Debian's machine-readable format has been around longer than > > either of the newer formats you mentioned, it seems like it would > > make more sense for the tools to incorporate a parser for it rather > I do think that this is another point of "we should kill our babies if > they don't take off". And preferably faster if/when "we lost" the race. > We carried around the debian menu for a decade or so after we failed to > gain traction and people centered on desktop files. > We failed to gain traction on the structure of the copyright file, and > spdx is the one who has won here. SPDX defines an xml format only. They lost before they'd even started. debian/copyright is supposed to be human-readable first and foremost. XML need not apply. -- 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
Re: Do not plan to support /usr/lib/pam.d for Debian pam
On Fri, Sep 15, 2023 at 03:17:42PM -0600, Sam Hartman wrote: > Luca> And we can have a > Luca> working, bootable Debian container with only /usr. > I'm not actually convinced this is a good thing. > (I don't think it's a bad thing--I just am not convinced it's something > we should be working toward). > I'd rather see project level discussion of this and a decision that is > something we want. > I have significant discomfort aligning what you say (pam is the last > blocker) with what several people said earlier in the week. > What I heard is that there was no project consensus to do this, and that > people were running experiments to see what is possible. > If I make a change in pam and we're suddenly at a place where there are > no blockers and we're moving forward, I think people in the project > would understandably feel disenfranchised. > To bystanders, "we're running experiments to see what's possible," means > a decision is far off. I agree with you that these sorts of changes should be discussed openly in debian-devel, and plans talked about, before we get too far down the path. Just as I advocated for when it came to DPKG_ROOT support in base packages. I do not want to see the fact that maintainers of base packages have individually decided it's worthwhile to support a thing, to be used to strong-arm other maintainers into feeling they also have to support a thing for which there may be no consensus. However, I do not think that *reaching* a consensus about this being a good thing needs to be a blocker for maintainers deciding to support it. As pointed out, there is nothing in Policy requiring any package to ship any files in /etc, it's only required that if a user wants to change the defaults for a package they should be able to do so via /etc (or /var). If it happens that all maintainers of base packages believe they can satisfactorily meet the needs of their users to configure those packages without shipping any default configs in /etc, those maintainers are free to make such changes to support this, without waiting for project consensus. Doing so doesn't penalize existing users and use cases of Debian (unless the maintainer is wrong about meeting users' needs, or makes a hash of the upgrade handling). And it would allow Debian to be used in contexts where it can't be today. It's basically a win-win. > I feel like if I were to fall in on this, I might be helping cause > something to happen at a technical level, bypassing discussion that I > believe would be healthy for the project. > I appreciate the value of doing work and having people who are willing > to do the work have a larger share of power in the decision making. I would like to see that discussion happen. I don't think this thread is that discussion, and I'm not stepping forward to drive it. -- 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
Re: /usr/-only image
On Fri, Sep 15, 2023 at 07:44:45PM +0100, Luca Boccassi wrote: > In fact, Marco yesterday told me the only blocker to boot a minimal > Debian image with only /usr is PAM, and that's exclusively because of > downstream-specific changes - upstream not only has supported the > hermetic-usr config model for years, but the upstream maintainer is > one of the main drivers of the generic effort at SUSE. That's not accurate at all. Debian carries no patches to the code for handling paths to pam config files. pam-auth-update is also not a "downstream change" to pam, it's integration with the OS that has been done in /etc. -- 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
Re: Do not plan to support /usr/lib/pam.d for Debian pam
On Fri, Sep 15, 2023 at 09:53:24PM +0100, Luca Boccassi wrote:
> With the provision that I know next to nothing about pam - if I
> understood correctly how it works, why not simply do both? Ship the
> default file in the package under both /usr and /etc. Then, you get
> the semantics you want with local changes tracking, and /etc wins over
> the defaults. And we can have a working, bootable Debian container
> with only /usr. As far as I've been told, pam is the only blocker
> there - for a minimal image of course, but that's still quite a good
> achievement. Wouldn't this work, or am I missing something?
While I have applications downstream which also care about empty /etc, the
current situation is that this wouldn't help because almost all the
PAM application configs in Debian reference one or more of
common-{account,auth,password,session,session-noninteractive} which are
constructed at package install time and therefore are inappropriate to ship
in /usr.
Shipping the same file in both /usr and /etc from application packages seems
like it would be a reasonable workaround as far as it goes, but doesn't let
us empty /etc/pam.d.
--
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
Re: armhf NEON exception for chromium
On Fri, Sep 15, 2023 at 10:15:53PM +0200, Paul Gevers wrote: > Hi Steve, > On 15-09-2023 21:54, Steve Langasek wrote: > > armel != armhf > Of course > > and nobody should be running armel on a NEON-capable CPU... > Not sure why you say it like that, I guess you don't meen CI purposes here. I mean "no user should be choosing armel as the architecture for software to run on a NEON-capable machine". CI is something different. > But anyways, it seems that also the arm64 host that runs our armel and armhf > VM's doesn't have NEON in the feature list. That sounds like a bug then since NEON is a required part of the ARMv8-A ISA.[1] -- 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] https://developer.arm.com/documentation/102525/0100/Compiling-for-Neon-with-Arm-Compiler-6 signature.asc Description: PGP signature
Re: armhf NEON exception for chromium
On Fri, Sep 15, 2023 at 08:30:20PM +0200, Paul Gevers wrote: > Hi, > On 15-09-2023 17:52, Andres Salomon wrote: > > Any thoughts on this? > Please be aware of bug #1036818 [1]. Currently /proc/cpuinfo is empty on > armel ci.debian.net workers. (I'm failing to spot neon in the list of > features of that machine.) armel != armhf and nobody should be running armel on a NEON-capable CPU... or chromium on an armel-only system. -- 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
Re: Questionable Package Present in Debian: fortune-mod
On Mon, Aug 21, 2023 at 06:55:03PM +, Andrew M.A. Cater wrote: > Ubuntu - our "downstream" has abandoned fortunes-off as incompatible with > their Code of Conduct (which is strikingly similar to ours). For the record, when I uploaded the change to drop this package from Ubuntu, what I said was that it was "inconsistent with Ubuntu values". The Ubuntu Code of Conduct is an *expression* of those values, but the CoC governs the actions of those in the Ubuntu community; it does not bind our upstreams, nor does it compel us to police either the words, or the views expressed, in all of the packages in the archive. An audit of that sort would certainly be unrealistic. -- 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
Re: Questionable Package Present in Debian: fortune-mod
On Mon, Aug 21, 2023 at 05:32:22PM +, Jeremy Stanley wrote: > On 2023-08-21 20:16:22 +0300 (+0300), Dmitry Baryshkov wrote: > [...] > > According to Debian's CoC we use non-offensive ways to communicate > > within the project, so that everybody is welcome to speak and > > contribute. But we should not censor software. If there is a > > misogynistic comment in GNU HURD sources, should we censor it out? > For that matter, if Debian was going to get into book burning over > racist, homophobic and misogynistic writing, all those packaged > versions of religious texts would presumably be the first things > tossed onto the pyre. Don't you think it's a bit hyperbolic to equate "not distributing a text in our archive" to "book burning"? -- 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
Re: Questionable Package Present in Debian: fortune-mod
On Fri, Aug 18, 2023 at 05:27:55PM -0400, Roberto C. Sánchez wrote: > Also, if quoting Mein Kampf or anything else from Hitler is problematic, > then perhaps fortune-anarchism (source package blag-fortune) should also > be considered for removal. It includes quotes from numerous individuals > who have themselves engaged in terrorism or other violence toward > individuals and groups, supported those who have engaged in such > activities, or been otherwise complicit in such. Lol bothsidesing anarchism and fascism -- 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
Re: Potential MBF: packages failing to build twice in a row
On Mon, Aug 14, 2023 at 08:28:15AM +0200, Johannes Schauer Marin Rodrigues wrote: > Quoting John Goerzen (2023-08-13 23:32:03) > > On Sat, Aug 05 2023, Lucas Nussbaum wrote: > > > I wonder what we should do, because 5000+ failing packages is a lot... > > Let's think about the level of trouble we cause trying to tackle something > > that has clearly not bothered anyone for years. > this is not the first time that is has been said in this thread that "this > hasn't bothered anybody for years". I wanted to come out and say that it has > bothered me. It just hasn't bothered me enough to investigate what the proper > way to solve it is. It hasn't bothered me enough to bother other people with > this issue. Agreed. -- 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
Re: Mini-DebConf in Cambridge, UK - November 23-26 2023
On Sun, Jul 23, 2023 at 06:36:21PM +0530, Nilesh Patra wrote:
> On Sun, Jul 23, 2023 at 12:50:06PM +0200, Luna Jernberg wrote:
> > Might come if the Debian project can help me pay for travel and
> > hotel/accommodation RattusRattus promised to email me when he have
> > time to i can apply (during the Debian 12.1 release ISO test yesterday
> > afternoon)
> Please keep replies to email sent on debian-devel-announce /
> {debconf,debian}-announce
> off those mailing lists. They are supposed to be only for announcements,
> and nothing else. It's quite annoying for me to see replies to announce
> emails on that kind of mailing list, and subsequently get into my more
> important (IMAP) folders.
The mail was not delivered to the announce list. In fact,
debian-devel-announce directs all mails with an In-Reply-To: header to
debian-devel.
So while it's best practice when replying to make sure you're sending to the
right address, the fact that it winds up in your announce imap folder is a
local configuration issue, not a question of where it was sent.
--
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
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Tue, Jul 11, 2023 at 03:06:57PM -0600, Sam Hartman wrote: > However, there are some significant disadvantages to netplan: > 1) It's an extra layer. You can ignore it when reading the config (at > least if you aren't too surprised by your config ending up in /run). > But it is extra complexity, especially in a situation like " run dhcp on > my ethernet" that is relatively simple. > 2) It's a layer that you cannot ignore when editing the config. Netplan > is one way. It takes in config in its format and spews out either > NetworkManager config or systemd-networkd config. You can generate > extra config on top of what netplan does, but in my experience if you > want to edit the config that netplan controls, you need to either do it > through netplan or remove netplan and generate those config chunks by > hand (possibly after looking at how netplan did it). > It's possible there are some netplan modes I missed and some other ways > of doing things. It's also possible netplan has evolved since I looked > at it. > In the non-wifi case I think d-i's networking is too simple to justify > netplan. > A simple .network unit for systemd-networkd sounds like a better option. I am not unbiased here, but I'd like to offer a counterargument: to a user, there is value in consistency. Yes, netplan is an additional layer. But having a layer that a user can rely on being present on any Debian system, whether it's a cloud instance, a server, or a desktop install with wifi, can be a big help. As someone who learned what a netmask is in 1997 or earlier, I have been surprised to learn over the course of netplan's development just how many people configuring networks on Linux systems - including on servers and routers - don't actually know thing #1 about IPv4 and are trying to configure their networks based on the recipes they find on the Internet. Which also means their lives are made significantly easier when the recipes they find are more broadly applicable across different types of installs, and significantly harder if they have to separately search how to configure networking for clouds, servers, or desktops. The design goal of netplan is that it's a layer that you shouldn't have to peek underneath, because it exposes everything you would need to configure in networkd or NetworkManager. Granted it's not *completely* there yet, but with the work to make NetworkManager use netplan as its config backend (which means: in the next release of Ubuntu you can happily use nmcli, nm-applet, etc. to manage your network connections and get human-editable netplan files out), it's certainly close. And I can say that I am a happy user of netplan across multiple systems, with no need to manage networkd configuration directly. -- 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
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
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-libcutil
Re: 64-bit time_t transition for 32-bit archs: a proposal
On Thu, Jul 06, 2023 at 04:49:34PM +, Thorsten Glaser wrote: > The Wanderer dixit: > >> snes emulator. last upstream release 2007 > >>> zsnes deb otherosfs optional arch=any-i386 > >FWIW: though I haven't touched it in quite some while, I recall from all > FWIW, I occasionally use zsnes and it works well. > But yes, hand-written assembly was part of that IIRC. = [Date: Wed, 28 Jun 2023 15:25:56 -] [ftpmaster: Scott Kitterman] Removed the following packages from unstable: zsnes | 1.510+bz2-10.2 | source, i386 Closed bugs: 1039568 --- Reason --- ROM; i386-only, abandoned upstream, alternatives exist -- Also closing bug(s): 510238 544313 609524 610313 680073 727781 792420 1038482 1039564 Also closing WNPP bug(s): ===== -- 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
Re: 64-bit time_t transition for 32-bit archs: a proposal
On Thu, Jun 08, 2023 at 04:06:08AM +0200, Guillem Jover wrote: > On Mon, 2023-05-22 at 18:17:44 -0700, Steve Langasek wrote: > > The difference in my view is that the changes to handle Provides: are > > something that should persist in the packaging (until the next soname > > change, at which point it's easy to handle as part of the overall renaming), > > whereas explicit changes to set DEB_BUILD_OPTIONS to the future default are > > something that ideally would be dropped immediately after dpkg-buildflags is > > updated, and could (though unlikely) be a source of bugs later. I'd prefer > > to avoid any transition plan which means I should be NMUing all of the > > affected library packages twice. > I think I understand where you are coming from, and I see how ideally > these would be dropped soon, but I also don't see this as a pressing > matter that would even need NMUs, as the explicit settings should map > to the then current defaults. Of course that precludes those defaults > then changing globally in the future, but if needed (!?) that could be > handled later on. But again, I think the flag day can potentially be > done in multiple other ways that might avoid the breakage w/o needing > these changes, and if so I'm happy with that as well. After thinking about it, I'd like to suggest the following approach. - dpkg with the new default behavior uploaded to experimental - libraries uploaded to experimental with the new package names (so, NEW processing gets done) and with a versioned build-dependency (easy to automate with sed on debian/control) - once all the libraries have cleared NEW, copy to unstable without dropping the versioned build-dependency; it will never be wrong, it will always at most be cruft that can be cleaned up lazily What do you think? > > > Hmm, rechecking the script, I think we'd want to at least > > > unconditionally add the Breaks and Replaces (no need for substvars > > > then), otherwise we'd get upgrade errors? > > > That would leave only the Provides as potentially conditional… > > You're absolutely right, thanks for catching this! Fixed in git. > As hinted above, I think the source:Version substvar should be > switched to a hardcoded version at the point the migration was done, > otherwise it will be floating forward and not catch older affected > versions? Oh ok, I didn't catch that this is what you meant. But it's not clear to me what you mean by "not catch older affected versions" - why would it be wrong to Breaks/Replaces against non-existent, newer versions of an obsolete binary package name? It's not a difficult change to make, I just don't understand why it's important. > > > > And btw, given the analysis that there are likely < 100 shared libraries > > > > overall whose ABI changes when enabling LFS, this might be a change we > > > > want > > > > to consider in the trixie cycle as well - just preferably not bundled > > > > with > > > > the time_t transition at the same time, as that would just cause more > > > > delays > > > > for testing migration vs splitting the two transitions. > > > If the plan is to go with a flag day by switching the default for > > > time64, then I don't see how the LFS change can be decoupled, as that > > > automatically will also forcibly enable LFS globally on glibc arches. > > > I've also in general been worried about automatically enabling LFS w/o > > > someone looking into each package, given the greater potential for > > > data loss. :/ > > I think in the case of LFS-sensitive libraries that aren't part of the > > dependency graph of packages affected by the time_t change, it's easy enough > > to patch them to not turn on the LFS flag and avoid a transition. > Just to try to understand whether we are on the same page. If these > libraries have no time_t usage at all, then disabling time64 should > then provoke no time_t issue and should stop implicitly enabling LFS. > But if the library contains internal time_t usage that is not part of > the exposed ABI, but part of its operation, then I'm not sure I see > how we can patch them to disable LFS w/o at the same time losing > time64 support (as the latter forces/requires the former). > I'm not sure whether you are talking about the first or second case? > And whether we have no libraries at all falling under the second case? I was only thinking about the first case, I had not previously considered the second case. We should be able to determine fairly easily whether there are any in the second case; for all ELF binaries which are built from the same source package as an LFS-sensitive library, check whether they have re
Re: 64-bit time_t transition for 32-bit archs: a proposal
On Thu, Jun 08, 2023 at 05:57:49PM +, Holger Levsen wrote: > RFC on d-d-a? That's at least less heavy than a GR and yet way more > visible than just a thread on d-d. The problem with doing an RFC on d-d-a is that it doesn't give us a clear, timeboxed path to converging on a decision if we find that there isn't consensus. If we need more assurance that the project supports the decision, I think it's better to go straight for a GR. I wouldn't like this to drag on too long into the trixie release cycle. -- 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
Re: 64-bit time_t transition for 32-bit archs: a proposal
Hi Helmut, On Tue, Jun 06, 2023 at 09:33:22AM +0200, Helmut Grohne wrote: > On Tue, May 16, 2023 at 09:04:10PM -0700, Steve Langasek wrote: > > * … but NOT on i386. Because i386 as an architecture is primarily of > > interest for running legacy binaries which cannot be rebuilt against a new > > ABI, changing the ABI on i386 would be counterproductive, as mentioned in > > https://wiki.debian.org/ReleaseGoals/64bit-time. > I've been reading the discussion around i386 a bit and found the > direction it has taken a little unproductive. I hope we can agree that > there is no consensus on keeping or changing the time ABI for i386 while > there is quite some consensus for your plan on changing the time ABI for > all other 32bit architectures in roughly the way you brought forward. I have a different read on the consensus here. While there has been a lot of discussion about whether to continue supporting i386 as a host arch, almost everyone participating in the thread who said they want this is not a voting member of Debian. The lone exception that I can recall from the thread was Guillem, who, as dpkg maintainer, is certainly a stakeholder in this decision (and since we don't really have an "i386 porting team", probably the most important individual stakeholder). Since my read is that Guillem was in the "rough" of "rough consensus", I asked him directly how we should move forward on a decision. A GR is one option, and I think it's definitely a better option than going through the TC: while there is a decision to be made here about a "technical" detail of what dpkg-buildflags will do, you're right to point out that it's really a decision about what we want to support as a project. > While the i386 discussion seemed a little unproductive at times, I think > there is one major argument that I feel is missing here. If keeping the > 32bit time ABI for i386, that effectively becomes a divergence from > every other architecture. i386 will be the one and only architecture to > be time32. As it happens, I have some experience with such divergence > from how bootstrapping interacted with other transitions such as PIE. > Maintaining this kind of divergence has a non-trivial cost. Over time it > becomes more and more difficult and less and less people are interested > in doing it. As such, I see the addition of this kind of divergence as a > way of killing i386. Hmm, I don't share this particular concern. PIE is a change to compiler behavior. 32-bit time_t is a change to defines that modify types (and prototypes) used in header files. Maintaining a compiler is hard, maintaining a library ABI is "easy" - glibc has avoided breaking ABI for 25 years so far. > Judging from the conversation, killing i386 quite obviously is desired > by some participants, but evidently not by all. How quickly we want to > kill it is not obvious to me. However, I think it is fair to say that > keeping time32 on i386 will kill it rather sooner than later. With > time32, we cannot reasonably extend i386 beyond forky as we'd be running > too close to the final deadline. As a reliable host OS, sure. As a compatibility layer, as Simon has pointed out, having a wrong idea of the time is not a big deal for a lot of applications. > Some of you may have been aware of that Debian Reunion in Hamburg > recently. There was a BoF on how Debian should decide about non-trivial > matters and one result of that BoF was "maybe we should GR more often". > I think the decision of what to do with time32 is not a really important > one despite some people being very opinionated about it. How about > settling it using a GR anyway? We perceive GRs as painful and there is a > saying that if something is difficult, let's do it more often. How about > trying to do GRs more often with this decision? I think it is pretty > clear that neither answer is wrong. It's a choice that we have make and > then to stick to. And we can learn something about whether GRs really > are painful. I think the worst of outcomes we could get here is going > into much further detail in a GR and adding lots of competing proposals > there. If that were to happen, I'd consider the experiment as failed. > Leaving the details to those who put up with the work (and that quite > obviously is Steve et al here) is important in my book. So unless we can > do it as simple as "i386 should keep being time32" vs "i386 should > become time64 by default", we probably shouldn't GR it. I am not keen to try to drive a GR on this, but if you raised one I'm likely to second it. -- 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
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)
On Wed, May 31, 2023 at 12:51:06AM +0200, Diederik de Haas wrote: > > >+1 for stopping publishing installers for i386, it has been mentioned > > >many times but it's always worth repeating: electricity costs to keep > > >running i386 hardware are already way higher than what it costs to buy > > >a cheap, low-power replacement like a raspberry pi, that also provides > > >better performance. > > Exactly. > > ... > > If people have strong opinions about that plan, let us know please. > I have *strong* opinions about this. > https://lists.debian.org/debian-kernel/2023/01/msg00372.html was a message/ > plea to not forget about supporting OLD systems. > While it may be a no-brainer for a person with a $/€ 1000 a month residual > income to just buy new hardware whenever they feel like it, that is not the > case for everyone. > To quote (a part) of that email: > > I happen to know of a few derivative projects that have been using > > Debian technology that have brought new life to some really aging equipment > > and some people in either Third World countries or in communities with low > > incomes and either limited or non-existent access to modern equipment. One > > such effort, the antiX distribution, has been effective in reaching poor > > communities in Brazil recently, and has long been able to reach people with > > scaled down Debian technology all over the world. > > > > I'm wondering if there is some way to provide a "hook" or a way for some of > > these ten to twenty year old systems to remain functional for those who may > > not otherwise have a way, other than to run insecure, out of date systems. > > If there is a way, even a "side project", I hope that the Debian community > > can help a few of these derivative distributions assist people worldwide to > > have access to modern technology, > > even from systems that are barely "modern" any more. > Besides people in 'third world countries' (I actually don't like such > qualifications at all), there are also people in the '1st world' who work > their asses off just to put food on the table, and thus also don't have > the money to buy new equipment. But if you want to interact with your own > government, you highly likely will need to have some PC (type) equipment. > It could also provide a way to learn/develop new skills. > It's absolutely true that modern machines are more energy efficient. What is > also true is that the production of new devices has a big environmental > impact. > https://mastodon.green/@gerrymcgovern/110329331475328263 said: > > The European Environmental Bureau has stated that extending the lifespan of > > smartphones and other electronics by just one year would save the EU as > > much carbon emissions as taking two million cars off the roads annually. > I would be VERY disappointed if Debian would abandon people who do NOT have > the means to just buy new equipment whenever they feel like it. > Especially when I see various proposals to make the 'life'/work of companies > who make BILLIONS a YEAR, easier. > (I'll leave my moral objections to several of those aside this time) For businesses, the transition from 32-bit to 64-bit was several depreciation cycles ago. In my city, there is a non-profit that accepts donations of old computers, refurbishes them, installs Linux, and both sells them and provides them free to people in need. They receive x86-64 systems that they determine are *too old to be worth refurbishing* and they e-cycle them. Hanging on to systems using power-hungry chips from 20 years ago instead of intercepting a system such as this is not reducing the number of computers that end up in the waste stream, it just keeps you stuck with a more power-hungry system. -- 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
Re: 64-bit time_t transition for 32-bit archs: a proposal
On Mon, May 22, 2023 at 06:24:53PM -0700, Steve Langasek wrote: > > We don't need to enable/fix it for everything though. A rebuild check of > > affected libraries to see how much work this adds would be a good idea. > Isn't it a problem not just for library ABIs but also for any other packages > rebuild with -D_TIME_BITS=64, because the code will be consuming the 64-bit > prototype from the headers but using the 32-bit symbol at runtime? To clarify: not every package will be affected by this because not every package is going to use the libc time_t functions. But enough will that I think the better path forward is to enable -Werror=implicit-function-declaration across the board and fix any build failures, which makes for better code in the long run anyway, than to enable this by hand only for affected libraries and then have to deal with a bunch of runtime bugs. -- 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
Re: 64-bit time_t transition for 32-bit archs: a proposal
On Sat, May 20, 2023 at 12:28:41PM +0100, Wookey wrote: > I was aware of it (the gentoo info is linked on the 64bit-time wiki > page), but had not yet looked into how significant an issue this actually > was, so had not documented it. (frankly, I was hoping we could avoid > tying yet another transition into this one). Thanks for the reminder. > So having re-read that, if I understand this correctly, we do need to > be mindful that software which looks up functions or function > parameters in unusual ways (e.g. cross-language Foreign Function > Interfaces, or using implicit declarations) is likely to get the > wrong-size definition (because glibc makes both versions available). > So we should enable -Wimplicit-function-declaration on libraries being > rebuilt because their ABIs changed. I guess this needs to be -Werror=implicit-function-declaration, to ensure it fails the build if used, regardless of whether -Werror is set elsewhere? > We don't need to enable/fix it for everything though. A rebuild check of > affected libraries to see how much work this adds would be a good idea. Isn't it a problem not just for library ABIs but also for any other packages rebuild with -D_TIME_BITS=64, because the code will be consuming the 64-bit prototype from the headers but using the 32-bit symbol at runtime? (Which is a better answer in terms of automation, because then we can just put it in dpkg-buildflags) -- 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
Re: 64-bit time_t transition for 32-bit archs: a proposal
go with a flag day by switching the default for > time64, then I don't see how the LFS change can be decoupled, as that > automatically will also forcibly enable LFS globally on glibc arches. > I've also in general been worried about automatically enabling LFS w/o > someone looking into each package, given the greater potential for > data loss. :/ I think in the case of LFS-sensitive libraries that aren't part of the dependency graph of packages affected by the time_t change, it's easy enough to patch them to not turn on the LFS flag and avoid a transition. You raise a valid concern about data loss. However, I fail to see any way that we can effectively mitigate this in advance - either now or by delaying the time_t transition. I don't see any way to avoid this via automated source analysis, so the only option (given that we can't avoid the time_t transition forever) is to rebuild and then find out what breaks, which I think is best done at the beginning of a release cycle - do you agree? -- 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
Re: 64-bit time_t transition for 32-bit archs: a proposal
On Tue, May 16, 2023 at 09:04:10PM -0700, Steve Langasek wrote: > Based on the analysis to date, we can say there is a lower bound of ~4900 > source packages which will need to be rebuilt for the transition, and an > upper bound of ~6200. I believe this is a manageable transition, and > propose that we proceed with it at the start of the trixie release cycle. With more progress on making the headers analyzable, the lower bound is now 5063 and the upper bound is 5975 (not counting any entanglement with lfs-sensitive libraries whose reverse-dependencies also depend on time_t-sensitive libraries, that's still to be worked out). In case that gives anyone more confidence in the plan :) -- 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
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)
On Fri, May 19, 2023 at 04:30:56PM +0100, Simon McVittie wrote: > On Fri, 19 May 2023 at 09:19:35 -0500, G. Branden Robinson wrote: > > I have to ask how someone would conduct an install to a 32-bit x86 machine > > running under emulation, assuming no OS on the simulated machine. > I see four levels of support that we could reasonably have for i386: > 1. same as in recent Ubuntu: just enough packages (mostly libraries) to >configure it as a multiarch foreign architecture on an amd64 system, >and run legacy Linux i386 binaries directly or legacy Windows i386 >binaries via Wine > 2. same as (1), plus basic utilities (coreutils, etc.) and optionally an >init system, to be able to make a pure i386 container or chroot >that can run on an externally-provided amd64 kernel 2. is actually closer to what we have in Ubuntu, because builds are still self-hosted on i386 userspace (with an amd64 kernel). However, this is *strictly* limited to the base install + build-dep enclosure for the packages we want to support; autopkgtests for instance are run in a cross-environment (and if it can't cross-install, then there's no reason to care about test results for it because it has no end-user application!) -- 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
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)
On Fri, May 19, 2023 at 09:19:35AM -0500, G. Branden Robinson wrote: > I think simulation of 32-bit x86 will get _more_ important as year 2038 > approaches, not less, because in about 2037, people will suddenly notice > they need to test things before deployment. Ah but if Debian doesn't support i386 as an architecture then the test for deployment is very simple: you can't deploy, game over ;) > [1] Running nroff and troff on an emulated PDP-11/45 running Version 7 > Unix, to resolve compatibility defects in groff and settle arguments > about "authentic" Unix *roff behavior. Dustin Kirkland once did a demo where he booted every 6-monthly Ubuntu release since the dawn of time in a VM (15+ at the time, I think). That's much more useful for software archaeology of this sort than providing i386 host support in *future* Debian releases. -- 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
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)
On Fri, May 19, 2023 at 12:42:32PM +0100, Steve McIntyre wrote: > >If the main reason is to support non-free binaries, at least to me > >that does not seem like a very compelling reason. And people can > >always use old chroots or similar I guess? > i386 is in a really awkward situation here, I think. Nobody is working > on it explicitly any more (AFAICS?), but its history as by far the > most common architecture means that: > * we still have a (very!) long tail of installations using it > * there are *massively* more old binaries available for it, free, >proprietary *and* locally-built FTR this includes wine, and 30 years of 32-bit Windows executables that people want to be able to run, including games. (for which inaccurate times are not going to be hugely important, in general.) And some of those games are going to require e.g. library packages for 3d acceleration that are in sync with kernel drivers (nvidia). This was ultimately what made "just use an older version in a chroot/container" untenable for Ubuntu and led to keeping i386 as a partial port. So one may not think that support for legacy, proprietary programs is a compelling reason to keep binary-compatibility on i386. But I counter that unless you care about this, there's no reason to keep i386 as an architecture *at all*. -- 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
Re: 64-bit time_t transition for 32-bit archs: a proposal
On Wed, May 17, 2023 at 01:45:10PM +0800, YunQiang Su wrote: > For mipsel, we have one more thing to do: > - NaN2008 vs NaN legacy > So I'd prefer rebootstrap (only for mipsel). > And In fact we did it: https://repo.oss.cipunited.com/debian/ Thanks for the info. What is the plan for landing the rebootstrapping in the Debian archive? The library package name change would happen across all architectures in unstable. Since the old library names will only exist in stable releases prior to the rebootstrap, and thus have different ABIs, I think it makes sense to have the same handling for mipsel as for other 32-bit archs wrt compatibility provides; do you agree? -- 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
Re: 64-bit time_t transition for 32-bit archs: a proposal
On Thu, May 18, 2023 at 03:04:30AM +0200, Guillem Jover wrote: > On Tue, 2023-05-16 at 21:04:10 -0700, Steve Langasek wrote: > > === Technical details === > > The proposed implementation of this transition is as follows: > > * Update dpkg-buildflags to emit -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64 > > by default on 32-bit archs. (Note that this enables LFS support, because > > glibc’s 64-bit time_t implementation is only available with LFS also > > turned on, to avoid a combinatorial explosion of entry points.) > As has been mentioned, there's future=+time64 support in dpkg git HEAD > targeted at 1.22.0. This gets automatically disabled on ports where > time_t is known to be 64-bits (even if the port is 32-bits). When time64 > is set it does indeed force future=+lfs. (But I've got locally a few > commits fixing and improving the logic for some of the ports which > will push out in a bit.) > I'm perhaps missing something, but the ordering here seems wrong/odd? > Enabling this by default globally before the shared libraries affected > by the ABI have been handled seems to me would mean a mess of ABIs > in unstable until the entire thing converges? The proposal is to treat this as a flag day, where the toolchain (in this case, dpkg-buildflags) changes, then we upload the affected libraries in a short period of time, then once they're built and through new we rebuild the reverse-dependencies. This is basically the same approach as was used for past ABI transitions (ldbl, c102, c2) with the only difference here that the change triggering the flag day would be in dpkg rather than gcc(-defaults). There could be some misbuilt binaries in unstable if the maintainer uploads them after dpkg is uploaded, but before the libraries are built. If we uploaded all of the library packages to set DEB_BUILD_MAINT_OPTIONS = feature=+time64 we would avoid this race, but it would mean more non-scriptable changes to debian/rules which I would rather avoid, and this didn't prove necessary in past transitions; the impact of any misbuilt binaries would be short-lived as they would be replaced ASAP with binNMUs. > > * … but NOT on i386. Because i386 as an architecture is primarily of > > interest for running legacy binaries which cannot be rebuilt against a new > > ABI, changing the ABI on i386 would be counterproductive, as mentioned in > > https://wiki.debian.org/ReleaseGoals/64bit-time. > Like Russ, I'm also dubious about this, and introduces a special case > and complexity that does not seem warranted TBH. If this was the case it > would seem to me it would disallow SOVERSION bumps for example, which we > have never been concerned with. I didn't see anything in Russ's email in this thread that implied he was dubious of this approach? He simply has a library he maintains for which he believes binary compatibility is uninteresting. FWIW in Ubuntu where we maintain i386 strictly as an architecture for compatibility with third-party binaries, we have 1034 source packages that build Arch: i386 debs. Not all of those source packages are shared libraries, but enough of them are that manually updating them to maintain ABI compatibility on i386 would be a substantial amount of work. In terms of overall complexity, I think the scales tip in favor of the toolchain not defaulting to _TIME_BITS=64 on i386. > > * For a small number of packages (~80) whose ABI is not sensitive to time_t > > but IS sensitive to LFS, along with their reverse-dependencies, filter out > > the above buildflags with DEB_BUILD_MAINT_OPTIONS=future=-lfs[1]. > > Maintainers may choose to introduce an ABI transition for LFS, but as this > > is not required for time_t, we should not force it as part of *this* > > transition. If there is a package that depends on both a time_t-sensitive > > library and an LFS-sensitive but time_t-insensitive library, however, then > > the LFS library will need to transition. > Hmm, I'm not sure whether I'm not understanding this point. Perhaps it > is assuming that future=-lfs will strip the LFS options from the > emitted flags? (If so that only disables the feature, but does no > stripping). Also as mentioned above when the +time64 feature is enabled > an -lfs would not be effective at all anyway, and should not! Because if > the time64 flags are emitted glibc will error out if the LFS ones are > not set. (See .) > So perhaps this means to say that in these cases we'd use: > DEB_BUILD_MAINT_OPTIONS=future=-time64 > ? Yes, my expectation was that future=-lfs would remove the LFS and time_t flags from the output (the latter, because time64 depends on lfs). But I'm not wedded to this particular interface! My only intent is that there be a simple, short interface for disabling time64+lfs when needed.
Re: 64-bit time_t transition for 32-bit archs: a proposal
On Wed, May 17, 2023 at 08:14:52PM -0500, Richard Laager wrote: > They mention, "We likely have to complete Modern C porting first to remove > any instances of -Wimplicit-function-declaration otherwise the redirects in > glibc for e.g. time->time64 won't actually work." That links to: > https://inbox.sourceware.org/libc-alpha/874js2iqlg@oldenburg.str.redhat.com/ > Has that issue been considered here? (I can't speak intelligently on it at > this time. I just want to make sure it's on your radar.) Thanks, I was unaware of this. Sounds like feature=+time64 should also emit -Wno-implicit-function-declaration; cc:ing the bug on dpkg regarding implementation of that interface. -- 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
Re: 64-bit time_t transition for 32-bit archs: a proposal
, we may also consider adding a time64 ABI to > existing libraries. A header can trivially detect whether time64 is > being requested by checking the relevant macros and in such cases divert > functions affected by time64 to 64bit-aware variants. Thus, a library > may become time64-compatible without breaking ABI with non-time64 users. > The obvious downside of this is that is quite a lot of effort and is > probably infeasible unless upstream cooperates, but I think this should > be considered as an option for difficult cases where we have both > non-lfs and time64 downstream users in large numbers. Do you agree? For such cases, yes, I agree that would be the sensible solution. I haven't done any analysis yet to see how many packages would be in this set. https://people.canonical.com/~vorlon/armhf-time_t/abi-breaks and https://people.canonical.com/~vorlon/armhf-time_t/lfs-sensitive would be the starting point, it would at least be easy to check for packages with direct build-dependencies on -dev packages in both sets. > > * For a small number of packages (~80) whose ABI is not sensitive to time_t > > but IS sensitive to LFS, along with their reverse-dependencies, filter > > out the above buildflags with DEB_BUILD_MAINT_OPTIONS=future=-lfs[1]. > > Maintainers may choose to introduce an ABI transition for LFS, but as > > this is not required for time_t, we should not force it as part of > > *this* transition. If there is a package that depends on both a > > time_t-sensitive library and an LFS-sensitive but time_t-insensitive > > library, however, then the LFS library will need to transition. > I note that this may pose problems with intra-library interaction. Say > we need to enable time64 on a higher level library and a lower level > library does not use time_t, but uses off_t. As such, you'd opt out of > lfs on the lower level library, but the upper one uses it with lfs by > having enabled time64. How do you intend to deal with such cases? In such a case the lower-level library should opt in to lfs and have a package name change as well. Up to this point I've casually assumed there weren't any such packages, but this can also be detected via static analysis of the archive. > > * In order to not unnecessarily break compatibility with third-party (or > > obsolete) packages on architectures where the ABI is not actually > > changing, on 64-bit archs + i386, emit a Provides/Replaces/Breaks of the > > old library package name. A sample implementation of the necessary > > packaging changes is at > > https://salsa.debian.org/vorlon/armhf-time_t/-/blob/main/time-t-me. > This is a nice way to minimize the effects on 64bit architectures. > Something that would help with this transition would be a > checker-as-a-service kind of thing that indicates: > * Is my package affected by time64? > * Does my package enable time64? >+ On i386? > * Do time64 changes affect downstream packages? >+ Which? > I understand that answering these questions on a per-package basis is > far from trivial. That much is evident from your analysis. I think this > is ok. Even if such a service says "unknown" 10% of the time, that'd > still be very useful. Do you think you could turn your analysis into a > continuous checking service? This sounds like a substantial amount of work (and computing resources, to enable this to "continuously" check) and I don't think I understand how it would help the transition, if all of the library transitions are being coordinated centrally. Could you elaborate? -- 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
Re: 64-bit time_t transition for 32-bit archs: a proposal
On Tue, May 16, 2023 at 09:31:05PM -0700, Russ Allbery wrote: > Steve Langasek writes: > > * Largely via NMU, add a “t64” suffix to the name of runtime library > > packages whose ABI changes on rebuild with the above flags. If an > > affected library already has a different suffix (c102, c2, ldbl, g…), drop > > it at this time. > This is possibly me being too fiddly (and also I'm not 100% sure that I'll > get to this in time), but ideally I'd like to do an upstream SONAME > transition for one of my shared libraries (and probably will go ahead and > change it for i386 as well, since I'm dubious of the need to run old > binaries with new libraries in this specific case). > What's the best way for me to do that such that I won't interfere with the > more automated general transition? Will you somehow automatically detect > packages that have already been transitioned? Or should I wait until the > package has been automatically transitioned and *then* do an upstream > transition? It would be possible to automatically detect that a package has been transitioned, by a combination of: - checking the date of the last source upload (if it's after dpkg-buildflags defaults have changed, or not) - inspecting the symbols referenced from glibc by the library to confirm whether it includes any 64-bit time_t variants It's doable, but I think it would be rather a lot of work for an edge case where the maintainers could simply revert the NMU if they determined it was unnecessary. > > Your thoughts? > The one additional wrinkle is that there are packages that, due to > historical error or unfortunate design choices, have on-disk data files > that also encode the width of time_t. (I know of inn2, which is partly my > fault, but presumably there are more.) Rebuilding that package with the > 64-bit time_t flags would essentially introduce an RC bug (data loss) > because it will treat its existing data files as corrupt. Do you have any > idea how to deal with this case? > (The LFS transition was kind of a mess and essentially required users to > do manual data migration. This time around, maybe we'll manage to write a > conversion program in time.) INN is called out on https://wiki.debian.org/ReleaseGoals/64bit-time. Unfortunately, I know it depends on at least one library package that has an ABI change (libpam0g), though it happens that only libpam_misc, which INN doesn't link to, has an ABI change; so we could adjust that source package to not do the time_t switch if that's the only blocker. But it also build-depends on libkrb5-dev and libssl-dev, both of which are affected by time_t. So maybe the best workaround in the short term, if there's no immediate data migration path, would be to change the inn2 source to use unsigned long in place of time_t in the data format? I don't have any inkling how widespread this problem will be nor do I see any path towards automatically detecting such issues (a codesearch on time_t would return far too many false-positives to be useful). It really depends on maintainers knowing what the code in their packages does. -- 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
Re: 64-bit time_t transition for 32-bit archs: a proposal
Hi Craig, On Wed, May 17, 2023 at 10:14:17PM +1000, Craig Small wrote: > On Wed, 17 May 2023 at 14:10, Steve Langasek wrote: > > Over on debian-arm@lists, there has been discussion on and off for several > > months now about the impending 32-bit timepocalypse. As many of you are > > aware, 32-bit time_t runs out of space in 2038; the exact date is now less > > than 15 years away. It is not too early to start addressing the question > > of > > 32-bit architecture compatibility, as there are already reports in the wild > > of calendar failures for future events on 32-bit archs. > Hi Steve, > Have they also considered the same issue with utmp? > https://github.com/thkukuk/utmpx/blob/main/Y2038.md > Some of it is reasonably easy to fix by changing the utmp-related calls > with the systemd equivalents, but not all fields are available. This isn't something that's specifically come up. I think there's general recognition that there will be other software that needs to be fixed in ways not addressed by simply turning on -D_TIME_BITS=64. I'm currently restricting my focus to the latter, since it's the part that will require distro-wide coordination. Thanks, -- 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
64-bit time_t transition for 32-bit archs: a proposal
Hi folks, Over on debian-arm@lists, there has been discussion on and off for several months now about the impending 32-bit timepocalypse. As many of you are aware, 32-bit time_t runs out of space in 2038; the exact date is now less than 15 years away. It is not too early to start addressing the question of 32-bit architecture compatibility, as there are already reports in the wild of calendar failures for future events on 32-bit archs. While it’s debatable whether most of the 32-bit archs in Debian (and as unofficial ports) will be in use long enough to worry about 2038, there’s at least substantial reason to believe that 32-bit ARM (armhf and possibly armel) will still be in use 15 years from now. Solving this problem has already been proposed as a release goal for trixie: https://wiki.debian.org/ReleaseGoals/64bit-time For those who prefer a primer in video form, Wookey gave a talk at FOSDEM about this: https://fosdem.org/2023/schedule/event/fixing_2038/ There are two basic ways to solve this. Either we can rebootstrap the ports that we want to keep; this makes upgrades unreliable, and doesn’t help any ports for which we don’t do this work. Or we can do library transitions for the set of all libraries that reference time_t in their ABI; this is a bit more work for everyone in the short term because it will impact testing migration across all archs rather than being isolated to a single port, but it’s on the order of 500 library packages which is comparable to other ABI transitions we’ve done in the past (e.g. ldbl https://lists.debian.org/debian-devel/2007/05/msg01173.html). The difficulty is, unlike the ldbl or c2 transitions of the past, time_t ABI compatibility can’t be worked out by static analysis of the exposed symbols, only by traversing the headers and mapping them to the library ABI. So when I say “on the order of 500 packages”, this is because at the moment we have about 1900 -dev packages that have failed to be analyzed because their headers don’t compile out of the box. I am currently working through getting these all analyzed, prioritized by number of reverse-dependencies, but this process will take at least a couple of months before we have a complete list of libraries to be transitioned. Help improving the scripts at https://salsa.debian.org/vorlon/armhf-time_t/ to complete this analysis is welcome. Based on the analysis to date, we can say there is a lower bound of ~4900 source packages which will need to be rebuilt for the transition, and an upper bound of ~6200. I believe this is a manageable transition, and propose that we proceed with it at the start of the trixie release cycle. === Technical details === The proposed implementation of this transition is as follows: * Update dpkg-buildflags to emit -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64 by default on 32-bit archs. (Note that this enables LFS support, because glibc’s 64-bit time_t implementation is only available with LFS also turned on, to avoid a combinatorial explosion of entry points.) * … but NOT on i386. Because i386 as an architecture is primarily of interest for running legacy binaries which cannot be rebuilt against a new ABI, changing the ABI on i386 would be counterproductive, as mentioned in https://wiki.debian.org/ReleaseGoals/64bit-time. * For a small number of packages (~80) whose ABI is not sensitive to time_t but IS sensitive to LFS, along with their reverse-dependencies, filter out the above buildflags with DEB_BUILD_MAINT_OPTIONS=future=-lfs[1]. Maintainers may choose to introduce an ABI transition for LFS, but as this is not required for time_t, we should not force it as part of *this* transition. If there is a package that depends on both a time_t-sensitive library and an LFS-sensitive but time_t-insensitive library, however, then the LFS library will need to transition. * Largely via NMU, add a “t64” suffix to the name of runtime library packages whose ABI changes on rebuild with the above flags. If an affected library already has a different suffix (c102, c2, ldbl, g…), drop it at this time. * In order to not unnecessarily break compatibility with third-party (or obsolete) packages on architectures where the ABI is not actually changing, on 64-bit archs + i386, emit a Provides/Replaces/Breaks of the old library package name. A sample implementation of the necessary packaging changes is at https://salsa.debian.org/vorlon/armhf-time_t/-/blob/main/time-t-me. * Once the renamed library packages have been built on all archs and accepted through binary NEW, issue binNMUs of the reverse-dependencies across *all* architectures, to ensure that users get upgraded to the current runtime library package and aren’t left with stale packages under the old name on upgrade. * In the future when the upstream SONAME changes, the t64 suffix should be dropped. Your thoughts? Thanks, -- Steve Langasek Give me
Bug#1034266: ITP: pam-session-timelimit -- permit configuring time limits for user sessions
Package: wnpp Severity: wishlist Owner: Steve Langasek * Package name: pam-session-timelimit Version : 0.5 Upstream Author : Steve Langasek * URL : https://github.com/vorlonofportland/pam_session_timelimit * License : LGPLv3 Programming Lang: C Description : PAM module to permit configuring time limits for user sessions This module lets you pass session time limit information to pam_systemd. -- 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
Re: DEB_BUILD_OPTIONS=nowerror
On Tue, Feb 28, 2023 at 06:05:13PM +0100, Sven Mueller wrote: > > It isn't clear to me from the discussion history that this is the actual > > use case at issue. But supposing it is, that's one use case; and it's a > > use case that can be addressed without having to make any per-package > > changes and without having to make any changes to dpkg-buildflags > > interfaces by exporting > > DEB_CFLAGS_APPEND=-Wno-error > > DEB_CXXFLAGS_APPEND=-Wno-error > > as part of the bootstrap build environment, for all packages. > Now, if all packages would just use the flags from dpkg-buildflags as is, > or as the final part of CFLAGS/CXXFLAGS, that would be nice. However, IME, > that is not always the case and some maintainers append -Werror in > particular. This situation is not improved by the proposed added flag, because in both cases all that changes is the output of dpkg-buildflags. Packages that are not respecting the dpkg-buildflags interface will be problematic independent of this proposal. > Following this discussion, I fear we might not reach consensus. But my ideal > (strong) suggestion to package maintainers would be: > 1) Don't use -Werror (or equivalent for your packages language) during > normal > builds (i.e. on buildd) > 2) Do use -Werror via some mechanism (DEB_CFLAGS_APPEND)? during CI builds > 3) Actually utilize CI builds to detect any breakages early. This is conceptually interesting to me. In practice, I don't see us using this in Ubuntu. We have per-architecture differences from Debian (ppc64el building with -O3 by default; riscv64 being a release architecture where it isn't in Debian) that make it interesting to pick up on per-architecture build failures caught by -Werror and not without. But it's not practical to do CI -Werror builds; when we do out-of-archive rebuilds for all architectures, it's a significant committment of resources and each rebuild takes about a month to complete (on the slowest archs). And to be able to effectively analyze build results to identify Werror-related failures with high signal would require two parallel builds, one with and without the flag, built against the same baseline. So since this is infeasible, if Debian decides to pass -Wno-error by default from dpkg-buildflags, we might find ourselves diverging in Ubuntu. -- 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
Re: DEB_BUILD_OPTIONS=nowerror
On Mon, Feb 27, 2023 at 03:06:25PM -0700, Sam Hartman wrote: > >>>>> "Steve" == Steve Langasek writes: > Steve> If this is for people doing out-of-archive builds who don't > Steve> want to deal with failures from -Werror, I can see how having > Steve> a single environment toggle is useful to them; but it doesn't > Steve> seem useful to *Debian* when such out-of-archive rebuilds > Steve> don't correspond to the official builds. E.g. if they're > Steve> test builds for new toolchains, knowing that the package > Steve> *could* build, with options Debian doesn't actually use, is > Steve> of limited use. (If you build twice, once with once without > Steve> and file bugs on packages where the results differ, I guess > Steve> that's one use, but involves a lot of manual labor.) > In the general case I agree. > But we have the specific case of cross-bootstrapping. > They want to be able to do builds to bootstrap and they want to have an > option they can pass into the build to ask debian/rules not to include > -Werror. > I suspect Helmut believes he can get patches accepted in the packages > where this is most important to honor the option. > Given his track record, I bet he's right. > So, we have a team in Debian wanting a interface sufficiently > standardized for them to do their work. > I think we have confidence that once we agree on a interface they can > produce appropriate consumers of the interface as well as > implementations of the interface. > I think we should have a high bar for standing in the way of this kind > of work. Well, I'm not seeking to stand in the way of the work, so much as trying to make sure this is the most useful work to be doing to meet the actual use cases. I can see that for bootstrapping a new architecture, it will sometimes be useful to use a toolchain newer than the one that is currently default in Debian, and as a result it is useful to also be able to bypass new stricter -Werror behavior from gcc upstream that breaks compatibility with existing code. It isn't clear to me from the discussion history that this is the actual use case at issue. But supposing it is, that's one use case; and it's a use case that can be addressed without having to make any per-package changes and without having to make any changes to dpkg-buildflags interfaces by exporting DEB_CFLAGS_APPEND=-Wno-error DEB_CXXFLAGS_APPEND=-Wno-error as part of the bootstrap build environment, for all packages. Of course, dpkg-buildflags also exports flags for other languages than C and C++ (and should do), so if you want to have full package coverage you would want your set of _APPEND variables to match the set of per-language flags that dpkg-buildflags already handles. Having to export 7 variables instead of 1 is annoying. But it also doesn't require reaching consensus on a new interface in dpkg. And I remain unconvinced that the particular proposed interface is the right way around for Debian at large. -- 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
Re: DEB_BUILD_OPTIONS=nowerror
On Mon, Feb 27, 2023 at 10:49:48AM -0700, Sam Hartman wrote: > Helmut> The problem here specifically arises, because we do not have > Helmut> consensus on -Werror being a bad idea in release builds. > I agree with your reading of consensus and for that reason support > registering an option to say do not use -Werror. Sorry if I've missed it in this thread, but who is this option supposed to be *for*? Generally speaking, DEB_BUILD_OPTIONS or DEB_BUILD_MAINT_OPTIONS flags are useful for permuting the output of dpkg-buildflags, when the default output of that command is unsuitable for a particular package or for a particular rebuild environment. But here, the output of dpkg-buildflags is not incorrect because it emits neither -Werror nor -Wno-error; we are talking about an interface to override upstream defaults, not Debian defaults. If this is for the maintainer, it seems an unnecessary indirection to define a flag for the maintainer to set, to configure dpkg-buildflags, to output the correct flag that you know you want to pass to your package's build system. (Maybe the reasoning here is that it's a simpler interface for maintainers that abstracts a lot of the reasoning about build systems and makes for a more compact expression in debian/rules? I'm not sure.) If this is for people doing out-of-archive builds who don't want to deal with failures from -Werror, I can see how having a single environment toggle is useful to them; but it doesn't seem useful to *Debian* when such out-of-archive rebuilds don't correspond to the official builds. E.g. if they're test builds for new toolchains, knowing that the package *could* build, with options Debian doesn't actually use, is of limited use. (If you build twice, once with once without and file bugs on packages where the results differ, I guess that's one use, but involves a lot of manual labor.) My understanding is that the argument here is that -Werror is not a sensible option to use for production builds, that it should only be used for upstream test builds. I'm not convinced this is true; I know we've more than once caught programming errors of various severities downstream by building on ports that upstreams would generally not be in a position to cover in their developer test builds. But if that's the argument, then I think the logical desired policy outcome would be for dpkg-buildflags to be changed to emit -Wno-error *by default*, with an option flag along the lines of DEB_BUILD_OPTIONS=Werror that lets you turn it on instead. -- 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
Re: OpenMPI 5.0 to be 32-bit only ?
On Mon, Feb 13, 2023 at 02:18:06PM +, Alastair McKinstry wrote: > On 13/02/2023 12:51, Adrian Bunk wrote: > > On Mon, Feb 13, 2023 at 10:59:18AM +, Alastair McKinstry wrote: > > > ... > > > > The case we should make is that "no one cares about 32-bit builds" from > > > > the starting post in the GitHub issue is not true for Debian. > > > > We do care that it *builds*, even if it might not be actually used. > > > I've been making this point, mostly in the context of avoiding a future > > > where no MPI is available on 32-bit > > > (and by implication, essentially forking Debian into a toy 32-bit world > > > and > > > a properly-supported 64-bit one). > > I don't see what important functionality for 32-bit today would be > > missing without MPI, it is just more work and breakages to have packages > > configured differently on different platforms to continue providing the > > functionality that is still important. > There are a significant number of science libraries dependent on MPI. > We would need to do MPI-free builds of these libraries; I'm not sure how > much breaks as we do. Would we, though? Or should we remove the 32-bit builds of those libraries as well? I think it's accurate that no one is using those scientific libraries in production (which is, basically: doing lots of matrix math) on 32-bit architectures, because all of the vector instructions you want for such work are only available on 64-bit CPUs. So the only application of those 32-bit binaries, really, is either a) letting users of those 32-bit archs learn the tools on the hardware they have available, so they can use them to advantage later on fit-for-purpose hardware; or b) using them to build other software in Debian. Is either of those a compelling reason to keep building those software stacks for 32-bit? I would argue not. But neither is it obvious at what point it's worth the effort to remove them, since this requires tracking the reverse-dependency tree, working out which of those reverse-dependencies are *not* scientific applications that should drop the build-dependency rather than being removed, and so forth. So it's a tradeoff between the maintenance work of keeping mpi working on 32-bit, and the one-time work of removing it. > > > ... > > > The point of going 64-bit only is to clean up data structures and remove > > > technical debt: Hence 5.x will start a cleanup and removal of 32-bit code. > > > > > > The next point release may work on 32-bit by just bypassing the > > > compilation flag; ongoing support starts meaning more invasive patches > > > need to be carried by us. -- 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
Re: setting sysctl net.ipv4.ping_group_range
On Tue, Jan 03, 2023 at 03:26:37AM +0100, Marco d'Itri wrote: > On Jan 03, Adam Borowski wrote: > > Debian's default sysctl settings should reside in procps (as it owns > > /sbin/sysctl and /etc/sysctl* settings) rather than some unrelated > > package. > Nowadays systemd is a source of common sysctl settings among different > distributions. Debian still supports other init systems in the archive besides systemd. Should ping fail to run on a Debian system that is not using systemd? We also recently ran into a bug with systemd in Ubuntu because the "common sysctl settings among different distributions" that they had added clobbered settings that had been shipped for years already in the Ubuntu procps package. No thank you. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962038 What would really be a great place for shipping common sysctl settings among different distributions would be in the Linux kernel, instead of diverging from the kernel defaults in userspace and representing this as "common". -- 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
Re: Firmware GR result - what happens next?
On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote: > >What's the plan for upgraded systems with an existing /etc/apt/sources.list. > >Will the new n-f-f section added on upgrades automatically(if non-free was > >enabled before)? > So this is the one bit that I don't think we currently have a good > answer for. We've never had a specific script to run on upgrades (like > Ubuntu do), so this kind of potentially breaking change doesn't really > have an obvious place to be fixed. > Obviously we'll need to mention this in the release notes for > bookworm. Should we maybe talk about adding an upgrade helper tool? I heartily endorse ubuntu-release-upgrader, it has been useful in addressing uncounted upgrade issues over the years and I think something like this would be a nice addition to Debian as well. Two caveats: - Despite this being the sanctioned upgrade path in Ubuntu for over a decade, every single cycle we get bug reports from users who have run into issues because they have bypassed it and done the manual sed /etc/apt/sources.list && apt dist-upgrade. So in Debian where this has been the norm for /two/ decades, I would not expect this to substantially reduce the error rate in the first release where such a mechanism is introduced. (After all, whether telling users to use a new upgrader tool or telling them to manually add a component to sources.list, they will have to read the release notes to know about it!) - There are always some users that end up with buggy systems after upgrade despite using the supported interface because they upgrade to the devel release, and the release-upgrader is still under development up until release so they miss out on quirks being applied - and there is no interface for users to replay the quirks that they missed out on. Don't repeat the same design mistake. In the absence of a release-upgrader, the only way I see to automate this on upgrade would be to handle it in the maintainer scripts of either base-files (which I don't think the base-files maintainer would like) or apt. -- 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
Re: ifupdown/dhcp
On Mon, May 16, 2022 at 08:46:04PM +0200, Ben Hutchings wrote: > On Sun, 2022-05-08 at 22:07 +0200, Steve Langasek wrote: > [...] > > Ubuntu no longer uses isc-dhcp by default, because it no longer uses > > ifupdown; NetworkManager and networkd both have their own implementations of > > dhcp clients which are used by preference. *However*, isc-dhcp is still > > installed as part of all Ubuntu systems, because it is the only client > > implementation that integrates with initramfs-tools > > (/usr/share/initramfs-tools/hooks/zz-dhclient) > Upstream initramfs-tools uses klibc ipconfig for DHCP, but that is > limited to IPv4. Is that why Ubuntu is not using it, or was there > another problem? IPv6 support was the main driver. We use it for both DHCP4 and DHCP6 though, for consistency. -- 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
Re: ifupdown/dhcp
On Sun, May 08, 2022 at 11:24:12AM -0400, Michael Stone wrote: > [apologies to package aliases getting this twice due to autocomplete fail] > I've been trying to make sense of the NEWS item in isc-dhcp-client (that > alternatives are needed) in combination with the functionality of ifupdown > and what the implications are for debian upgrades generally. > isc-dhcp-client as of the last upgrade is telling users to stop using it > (the default dhcp client for debian). > ifupdown (the traditional tool for managing networking on debian systems) > has a Recommends on "isc-dhcp-client | dhcp-client". "dhcp-client" is a > virtual package provided by "dhcpcanon" (version 0.8.5, which hasn't been > touched in 4 years), "isc-dhcp-client", and "dhcpcd5" (which will trash a > working configuration managed by ifupdown if installed, as it will try to > take over interfaces currently set, e.g., to manual). This seems suboptimal > at best. > I believe that ifupdown will attempt to use udhcpd if installed, which > should be a mostly-transparent change (except for the potential loss of > lease information and any customization of dhclient scripts) but it isn't > even on the ifupdown recommends list. > ifupdown also (used to?) use pump, but that package went away a long time > ago. > So what's the path forward, maintaining compatibility and not breaking > systems upgrading from current stable? Do we come up with a dhcpcd5 variant > that *only* touches interfaces it is directed to touch via > /etc/network/interfaces? Do we add udhcpcd to the "dhcp-client" virtual > package and/or make it the default for ifupdown? Do we fork isc's dhcp suite > and just continue to use dhclient? Revive pump? Something else? Not an answer to your question, but a related issue I'll mention here. Ubuntu no longer uses isc-dhcp by default, because it no longer uses ifupdown; NetworkManager and networkd both have their own implementations of dhcp clients which are used by preference. *However*, isc-dhcp is still installed as part of all Ubuntu systems, because it is the only client implementation that integrates with initramfs-tools (/usr/share/initramfs-tools/hooks/zz-dhclient) so if you are using nfsroot or any other network-based rootfs, it appears to still be the only game in town. It would be a good idea to make sure as part of the deprecation of isc-dhcp-client that we get initramfs integration of whatever is the preferred replacement. -- 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
Re: RFC: pam: dropping support for NIS/NIS+?
Hi Thomas, On Fri, Apr 22, 2022 at 10:07:52PM +0200, la...@debian.org wrote: > I'm using NIS since 20+ years in a small network with about 60 computers. > Since I manage all computers and the physical network can be seen as secure > (I know it's not perfect secure) I do not need the additional crypto > features of NIS+ or LDAP, which would be overkill. All my users use > yppasswd on the NIS master for changing their password. I guess I > still need pam support for this because I set things like this in > pam.d/common-password: > passwordrequisite pam_cracklib.so retry=3 > difok=3 minlen=14 > Yes, I surely would miss the NIS support. If your users are using yppasswd on the NIS master for changing passwords, then evidently you are not relying on support for NIS in PAM. (yppasswd doesn't even link against libpam.) -- 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
Re: RFC: pam: dropping support for NIS/NIS+?
On Thu, Apr 21, 2022 at 03:30:55PM +0300, Dmitry Baryshkov wrote: > > > Before any discussion takes place, I would like to point out a previous > > > attempt of Fedora trying to get rid of NIS/NIS+ back in 2021. Please > > > check out > > > the LWN article at https://lwn.net/Articles/874174/ , which would > > > definitely > > > be helpful for the condition in Debian. > > That discussion seems to be about removing NIS/NIS+ support from the > > entire distribution. This thread is about removing NIS support from PAM. > > That's an important distinction, because in practice, NIS/NIS+ support > > mostly means the NSS modules, and the tools/servers in the case of NIS. > > Dropping NIS support from PAM would mean losing only the ability to > > change the passwords of users coming from NIS. It would not affect user > > lookups, and password change would still be possible using yppasswd. > > There does not even seem to be any NIS+ support in PAM - nothing seems > > to include . > > Personlly, I think bundling NIS password changing capability in pam_unix > > was a design mistake. It should always have been a distinct module. > Can we provide a separately packaged pam_unix_nis which can be used > instead of pam_unix in cases where this functionality is still > required? Yes, that is technically possible and something I've already considered. I wasn't going to offer it up as a solution without some evidence of demand (which I would say this thread hasn't yet established), since it would require additional work on the package. -- 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
Re: RFC: pam: dropping support for NIS/NIS+?
On Wed, Apr 20, 2022 at 10:23:06PM +0200, Gabor Gombas wrote: > Doing a quick check, PAM only seems to rely on the RPC libraries for > changing NIS passwords. Personally, I think losing that would not be a > big deal. While I can still see NIS being useful in some corners of the > world, I cannot imagine such an environment wanting to enforce password > expiration. And if you don't expire passwords, then you don't need PAM > to be able to change passwords - running yppasswd should be fine for > voluntary password changes. Thanks, that's an important nuance that I'd forgotten about (or I would have mentioned it). Indeed, dropping support in PAM for NIS won't make the NSS modules go away - so a properly-configured /etc/nsswitch.conf will still give you user/group lookups via NIS or NIS+, and there are other ways to handle password changes. IMHO this further raises the bar for keeping support for these (insecure, obsolete) backends in pam. On Wed, Apr 20, 2022 at 04:26:02PM -0400, Boyuan Yang wrote: > Before any discussion takes place, I would like to point out a previous > attempt of Fedora trying to get rid of NIS/NIS+ back in 2021. Please > check out the LWN article at https://lwn.net/Articles/874174/ , which > would definitely be helpful for the condition in Debian. Thanks for the pointer. I think that's useful in terms of understanding the landscape in the abstract, but shouldn't be taken as a definitive answer because it doesn't really address whether any Debian users depend on this functionality today. NIS also dates from a period when rsh was considered acceptable, and unless I'm mistaken, has a comparable level of security. Allowing access to password hashes for users based on the IP of the machine you are querying from is not a sane security policy, and I don't think we should indefinitely make Debian worse for all other users (bigger minimal system == worse) to cater to users of these obsolete, insecure systems. -- 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
Re: Firmware - what are we going to do about it?
Thanks for starting this discussion, Steve, I appreciate the care you've put into laying out the options. On Tue, Apr 19, 2022 at 01:27:46AM +0100, Steve McIntyre wrote: > 3. We could stop pretending that the non-free images are unofficial, and > maybe move them alongside the normal free images so they're published > together. This would make them easier to find for people that need > them, but is likely to cause users to question why we still make any > images without firmware if they're otherwise identical. > 4. The images team technically could simply include non-free into the > official > images, and add firmware packages to the input lists for those images. > However, that would still leave us with problem 3 from above (non-free > generally enabled on most installations). > 5. We could split out the non-free firmware packages into a new > non-free-firmware component in the archive, and allow a specific exception > only to allow inclusion of those packages on our official media. We would > then generate only one set of official media, including those non-free > firmware packages. > (We've already seen various suggestions in recent years to split up the > non-free component of the archive like this, for example into > non-free-firmware, non-free-doc, non-free-drivers, etc. Disagreement > (bike-shedding?) about the split caused us to not make any progress on > this. I believe this project should be picked up and completed. We don't > have to make a perfect solution here immediately, just something that > works > well enough for our needs today. We can always tweak and improve the setup > incrementally if that's needed.) I am personally comfortable with your preferred option 5, for all the described reasons (does not reduce user net freedom vs. status quo ante when the firmware was both non-free and non-updatable, etc etc etc). However, and I know that I'm suggesting work for other people here: one thing that has surprised me over the years this question has been open is that no one who has strong feelings about this issue has taken it upon themselves to refactor the images so that the non-free firmware is distributed as an add-on image that could be discovered by the installer at runtime. This would preserve the ability to have entirely-free media under Debian's definition thereof, while also giving users a clearer path to installing any necessary firmware without having to re-download a separate image. And sometimes having 2 separate USB sticks for an install is an inconvenience, so perhaps someone wants to be particularly clever and give the installer an appropriately-sized empty partition in the partition table that the firmware bits could be blatted into. -- 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
RFC: pam: dropping support for NIS/NIS+?
Hi folks, As of glibc 2.32, upstream has split out RPC support; if you want RPC functionality, you now need to link against libtirpc instead, which is a superior, more featureful implementation. This is a good thing architecturally, but one of the side effects for us is that, via PAM, we are now pulling a large number of crypto libraries into the transitively-essential set, because pam_unix links against libtirpc for NIS / NIS+ support. Sam Hartman made a valiant attempt to make this an optional dynamic dependency, but ultimately abandoned the effort. So I'd like to take a step back and challenge an underlying assumption by asking: do any of our users actually *need* this functionality? The RPC functionality is only used for NIS and NIS+. NIS is historically quite insecure, and I'm not aware of any efforts to improve its security (AFAIK the linkage of the crypto libraries doesn't fix the fundamentally insecure interfaces of NIS). NIS+ is intended to be a more secure version of NIS, but to my knowledge there has never been a free implementation in the archive; this was a Sun-specific technology, which Sun deprecated two decades ago[1]. If we dropped support for NIS and NIS+ in the next Debian release, would anybody miss it? Or has everyone moved on to LDAP / AD by now? -- 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] "Prior to the release of Solaris 9 in 2002, Sun announced its intent to remove NIS+ from Solaris in a future release and now recommends that customers instead use an LDAP-based lookup scheme." https://en.wikipedia.org/wiki/NIS+ signature.asc Description: PGP signature
Re: Firmware - what are we going to do about it?
On Wed, Apr 20, 2022 at 09:51:01AM -0500, Devin Prater wrote: > Anyways, if we want to gatekeep Debian, then fine. The person you're replying to is not a member of the Debian Project and does not speak for us. We are not all accessibility experts, but Debian as a community has always supported the efforts of those who are, to make Debian as usable as possible with accessibility technologies. Please don't assume the hostility of the previous messages is in any way representative of Debian. (And, that being the case, I would suggest it's unnecessary to engage with.) > On Wed, Apr 20, 2022 at 8:08 AM Polyna-Maude Racicot-Summerside < > deb...@polynamaude.com> wrote: > > > Hi, > > > > On 2022-04-20 08:39, Samuel Thibault wrote: > > > Hello, > > > > > > Polyna-Maude Racicot-Summerside, le mer. 20 avril 2022 08:32:13 -0400, a > > ecrit: > > >> Answer bellow this awful piece of text from someone who doesn't know how > > >> to make a space between line. > > > > > > For information, reading mails with a speech synthesis doesn't > > > necessarily render spaces between lines. > > > > > > So yes, people using them don't actually "see" the need for such > > > spacing. > > > > > When you talk or read a text out loud, you make pauses ? > > Why wouldn't they apply then you write a text ? > > Are we again in the world of "Everyone must adapt because I'm different" ? > > > > We ain't gonna go back to this WOKE thinking and "positive > > discrimination bullshit", please no ! > > > Samuel > > > > > > > -- > > Polyna-Maude R.-Summerside > > -Be smart, Be wise, Support opensource development > > > > -- 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
Re: Seeking consensus for some changes in adduser
On Thu, Mar 10, 2022 at 06:37:58AM +0100, Marc Haber wrote: > On Thu, 10 Mar 2022 00:04:38 +0100, Ansgar wrote: > >On Wed, 2022-03-09 at 17:29 -0500, Michael Stone wrote: > >> Those are actually unrelated--the big reason for the more permissive > >> umask is to allow people to seamlessly work with other people in a > >> group, especially within setgid shared directories. Those shared > >> directories can be anywhere, and are likely *not* in a single user's > >> home. > >Setting a default ACL on project directories seems a technical better > >solution for this problem. It would only affect permissions of files > >that should intentionally be group-readable, not all files created > >anywhere. > Are we using ACLs bei Default already in other places of the Debian > system? We are using filesystem capabilities; and as far as I'm aware we have no filesystems that support fscaps extended attributes but NOT acls, nor am I aware of any archive formats that would preserve fscaps without also preserving acls. -- 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
