Hi Santiago, Adding debian-release in Cc: as the discussion concerns more than just the glibc maintainers.
On 2026-09-13 20:56, Santiago Vila wrote: > > > It is possible that glibc may have something to do with this? > > > (note that gcc-14 has not been updated for trixie). > > > > Yes, this is due to this commit [2] that got backported in order to > > support the linux-libc-dev package provided by the trixie-backport > > kernel [2]: > > > > commit 419245719ccbc7dad6a97f24465e7f09c090327a > > Author: DJ Delorie <[email protected]> > > Date: Mon Jan 26 22:24:42 2026 -0500 > > > > include: isolate __O_CLOEXEC flag for sys/mount.h and fcntl.h > > > > Including sys/mount.h should not implicitly include fcntl.h > > as that causes namespace pollution and conflicts with kernel > > headers. It only needs O_CLOEXEC for OPEN_TREE_CLOEXEC > > (although it shouldn't need that, but it's defined that way) > > so we provide that define (via a private version) separately. > > > > Reviewed-by: Adhemerval Zanella <[email protected]> > > Tested-by: Florian Weimer <[email protected]> > > > > That means that <fcntl.h> is not included anymore when including > > <sys/mount.h>. POSIX is clear that open() is defined in <fcntl.h>, so > > while this is unfortunate to introduce a bug in trixie, the bug is > > really on the ascdc package. > > Thanks a lot for the quick reply. > > I'm concerned about the stability of stable. So far I've found already > four packages failing in a similar way, and some of the bugs were > already fixed and archived: > > ascdc_0.3-15.1 #1136759 > asmixer_0.5-16.1 #1136761 > oar_2.6.1-1 #1136780 > switchsh_0~20070801-5 #1136783 That's unfortunate we only detect that now, but all of those are just broken, using open() without include <fcntl.h>. > Did anybody try to estimate how many packages would be affected in > trixie before making the glibc change? We probably can fix those for Definitely not. Maintaining glibc is already a hard work with the reverse dependencies basically being the whole archive. Having to deal with preparing update for (old)stable release is also significant work, especially now with the high number of incoming CVE. I definitely do not have the resources to do an archive rebuild and analyzing the result for each upload (i.e. determining if it is a glibc bug or a bug in the package). Doing that for every major release is already a huge effort. At the end half of the people just ignore the bugs until they are upgraded to serious (well and still half of the remaining are just ignored). And note that in many cases I provided patches. I really doubt that, for stable, maintainers will be more active (actually I think it will be quite the contrary). And to be fair there, as a glibc maintainer, I have never been informed that the corresponding change in *sid* causes those 4 failures. Knowing that I would have taken more care with the backport. > the next point release, but: What if the number of affected packages > had been 50 or 100? Well in that case we could have reverted the change, or added another fix. That's not really different than the Python issue you mentioned below. Anyway here this commit has been backported to fix a real issue for with linux-libc-dev from trixie-backports, which many users with recent hardware have installed, now that newer apt versions ensure that all binary packages built from the same source package are upgraded at the same time. I'll still believe that backporting this commit was the right thing to do. > If we want to keep the promise that stable is buildable from source, > what we are currently doing is not working. Maybe, but please do not put the burden on the maintainers. We also promise to fix issues in stable, but if it becomes more complicated than it is now, I'll just stop doing so, at the end putting more burden on the security team. > Note that I'm not asking you to fix any of the new problems, I just > wanted to raise awareness about the stability of stable. Stability is the wrong word here. The affected packages are still usable and stable, it's just they are not buildable from source anymore. > (On the positive side, Debian 13.7 fixed at least 24 FTBFS issues, but > that's mainly because we finally fixed python3.13, which broke most of > those issues in the previous point release). Did anybody tried to estimate how many packages would be affected in trixie before making the python3.13 change? What if the number of affected packages had been 50 or 100? Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://aurel32.net
signature.asc
Description: PGP signature
