Hi Guillem, Coming back to this after a hiatus. (In the intervening time the focus has been getting the library ABI analysis right; now coming back around to looking at the toolchain.)
On Sun, Jul 09, 2023 at 08:06:56PM +0200, Guillem Jover wrote: > > There is analysis pending, unfortunately 90% of the -dev packages have been > > analyzed leaving 90% to go (~1600 -dev packages that require fixes to be > Ack, thanks. Is that last % supposed to be 10%? Otherwise I think I'm > missing something :). A reference to https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule > > > > From 5a861d19b1610ae82bf95e6c5142a3365436fbd2 Mon Sep 17 00:00:00 2001 > > > > From: Steve Langasek <steve.langa...@ubuntu.com> > > > > Date: Fri, 2 Jun 2023 14:30:20 +0000 > > > > Subject: [PATCH 1/3] lfs and time64 are no longer "future", call them > > > > "feature" instead > > > Ah, I actually had implemented locally the alias with your original > > > suggestion of "abi"! :) Using "feature" here seems would be rather > > > more confusing as these are called feature flags, and feature areas. > > > I'll try to push the stuff I've got queued locally during the weekend, > > > then I can rebase these patches on a branch or similar. > > As far as I can tell, this hasn't been pushed anywhere yet? > Right, sorry got entangled in a local branch with random stuff, but > rebased that and added on top now several other fixes including these > changes or ones similar in intention. See at: > https://git.hadrons.org/git/debian/dpkg/dpkg.git/log/?h=next/time64-default > (Beware that I might rebase that branch, before merging it, although I > think I'll start pushing some of the foundation work into main already.) > > Did you reach a decision here? Anything you'd like from me to move this > > forward? > I realized now that this cannot be set for CXXFLAGS as at least g++ > will warn about that. And I've gone for now by depending on qa=+bug, > but I'm not sure whether that would cause too many regressions. OTOH > and AFAIK any such problem should be considered a genuine bug anyway, > so… > But if this is too much I guess I could split that warning into its > own feature and make both the qa=+bug and abi=+time64 depend on it > instead. Now that I've had a chance to look at the implementation, I am concerned about abi=+time64 implying qa=+bug, because I see that this turns on additional -Werror options beyond implicit-function-declaration: my @cfamilyflags = qw( array-bounds clobbered volatile-register-var ); foreach my $warnflag (@cfamilyflags) { $flags->append('CFLAGS', "-Werror=$warnflag"); $flags->append('CXXFLAGS', "-Werror=$warnflag"); } While these may all be bugs, forcing the fixing of bugs unrelated to the time_t transition during the transition will inevitably slow down Debian development, so I am concerned about having such a dependency. We unfortunately also haven't done any archive rebuild analysis on this to understand how large the actual impact is (again, the focus has been on just getting the analysis right of which packages do have an ABI change). And while there's no specific timeline required on the Debian side yet, on the Ubuntu side we have a tight timeline to get this all done in the next couple of months so that it can be included in the 24.04 LTS release. The idea of splitting it into a separate feature seems ok, to avoid turning on unrelated -Werror options. We still don't have a slot from the Release Team for when this can be landed, but following up to debian-devel with a complete analysis of the library ABIs is my next step before the end of year. Is this a change you think could be uploaded to dpkg on short notice? Or would you be amenable to an NMU, if you're unavailable for an upload? -- 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
