Hi Andreas, On Mon, Feb 12, 2024 at 12:37:44AM +0100, Andreas Beckmann wrote: > On 11/02/2024 21.36, Salvatore Bonaccorso wrote: > > If I can add a comment: I (but note I'm not wearing a > > nvidia-graphics-drivers maintainer hat) would support that, as there > > are enough people affected by this. This is quite unfortunate and I'm > > open to hear ideas how we can try to avoid such fallouts. > > I was aware of the bug (#1062932) but not of the fact a point release was > upcoming. Even if I had been aware of the point release I'm not sure if I > had realized the impact of this bug to make me yell ;-) > Perhaps once point release dates have been choosen, this could be announced > to d-d-a@ as well. > I'm not following debian-release@ ... -ENOTIME > > > As you know we are strictly following upstream stable series (and > > trying our best to keep an eye on as well regression reports upstream, > > but OOT modules are not explicitly tested, so neither the nvidia ones) > > Are autopkgtests being run for proposed-updates? That should have shown the > issue.
Yes there are in fact autopkgtests being run, so this should have been catched (and at least decided what to do, i.e. not release 6.1.76-1, nod ideal, or deal during the still allowed window with the nvidia drivers as well). But to be very honest: I did miss this regression report on the overview page. At least according to Paul on IRC the test should have been run. > It was unfortunate that this upstream backported change appeared in > proposed-updates first and in sid only a few days later. And the > metapackages from linux-signed-amd64 are still depending on the version > before this change was introduced ... so I only could reproduce the issue > (and verify fixes) manually. (The module build test done during the package > build did not use the regressing headers.) Right, 6.6.15 upload to unstable had a couple of issues, first failing to build the arch:all packages then the linux-signed-amd64 were waiting to be processed, and once that happened, we have now a FTBFS due to interaction with a new kmod upload (Filled #1063804). It is not that usual that otherwise we would have that change in bookworm (queued in proposed-updates) before we had a similar change in unstable (or experimental). > Then I had to spent quite some time verifying that the issue only happened > on amd64 and since the 460 series (despite of ppc64el having even more calls > to pfn_valid() dating back to the 418 series). I would like to thank you again for the time you invested here to deal with that issue! > Andreas > > PS: @Salvatore: Looking forward to see some linux 6.8 packages in > experimental s.t. I can throw them in my module build chroot to see what > breaks next :-) Or do you already have some early build available somewhere > while experimental is still preparing 6.7? We have to move 6.7.y next to unstable. But I'm not completely sure if we are there yet, need to ask Bastian Blank about the plan. After that experimental is freed we can go aehad with 6.8.y for experimental, but there are yet no packages to test with :( Regards, Salvatore
