Re: Upcoming changes to Debian Linux kernel packages
> "Bastian" == Bastian Blank writes: Bastian> The same as now: nowhere, because those packages have been Bastian> removed from the archive already. Bastian> And sadly you did not answer the question why a second Bastian> degree error must not be worse then a worked around first Bastian> degree error? I'll admit that I find that phrasing difficult enough that I had to read it a couple of times and I'm still not sure I've got it. Let me see if I understand what you are saying. 1) kernel headers will be removed from the archive. So people complain if they have an old kernel and wish to get kernel headers for it, but those headers have been removed. 2) If the kernel header version changes but the kernel header package name does not change (version changed but not uname -r in the new scheme?), you can have what you think is the right kernel headers but they do not work with the binaries you have installed. 3) you can run into trouble between testing and backports. I think that's what you mean by the first-level error. If not, I'm still confused. In the second level error case you are talking about is: 1) there is a regression in the kernel 2) someone needs kernel headers for an old kernel they want to downgrade to. I don't actually see how this is a second level error. It appears to be a different first-level error (a regression), and the downgrade appears to follow naturally from that. You point out that someone may not be able to get kernel headers for the downgraded kernel. a) They might. In the window between a new kernel being introduced into unstable and the same kernel being introduced into testing there is an old kernel available with kernel headers. Similarly if someone needs to downgrade as far as stable, there is a kernel with headers available in stable. B) They might already have headers installed. Imagine someone who installs headers at the same time they install the kernel. Unless they managed to upgrade the same version of their kernel without also upgrading their headers, they will still have headers. They can still build modules against that kernel, either because they installed a new dkms package, or because one of their dkms packages upgraded. I think what you are saying is that 1) the current system is fragile: sometimes you want a kernel headers that is not available and sometimes you have version skew between the kernel headers and kernel even though you have both installed. 2) In your system, fewer things are possible, but the combination that is possible is more likely to work. And I think people's response is that they care enough about some of the things you are breaking that they are willing to accept the fragility. Bastian> -- Each kiss is as the first. -- Miramanee, Kirk's wife, Bastian> "The Paradise Syndrome", stardate 4842.6
Re: Upcoming changes to Debian Linux kernel packages
> "Bastian" == Bastian Blank writes: Bastian> On Mon, Sep 25, 2023 at 04:35:08AM +0200, Andreas Beckmann wrote: >> On 25/09/2023 00.50, Bastian Blank wrote: >> > Already built modules remain until someone deletes it. So you >> can also > switch back to the still installed older kernel >> version and it will have > the still working module available. >> Assume I have Linux 6.6 and a third-party gpu driver module >> installed (so there are dkms and the Linux 6.6 headers as well) >> and everything is working fine. Then I upgrade the system, which >> brings Linux 6.7 (along linux-image-6.6 which is kept installed) >> and a new version of the gpu driver (which adds support for >> 6.7). So the old gpu module for 6.6 gets removed and a new one is >> built for 6.7 only (since there are only 6.7 headers now). Bastian> Ah, here lays the missconception. No, the 6.6 ones are not Bastian> removed. Why should they be? The system knows it can't Bastian> rebuild them. Bastian> If the current implementation would remove them, it is a Bastian> problem there, not in the concept. I still think it would help if you would work more on articulating what problem you are trying to solve with the linux-headers versioning change. I have read multiple versions of this proposal, and your follow-ups, and I still do not understand what is prompting the linux-headers change. My intuition mirrors others in the conversation that it is problematic to support multiple kernel versions without also supporting multiple header versions.
Re: Should singularity-container make it to next release?
> "Nilesh" == Nilesh Patra writes: Nilesh> Since I had done quite a bit of work on this, I'm a sad to Nilesh> see this happen, as fasttrack still has much less visibility Nilesh> / availability than an official stable release, or even Nilesh> backports. Well, if you and a group of people believe you can maintain it in stable given the additional discussions ith upstream, then explicitly say you're ready to sign up to maintaining in stable. I think that's the kind of sing-up-to-do-the-work that the security and release team are waiting for. signature.asc Description: PGP signature
Re: Bug #149436 (was: `SSH log weirdness')
> "Jeff" == Jeff Bonner <[EMAIL PROTECTED]> writes: Jeff> Christian Kurz was kind enough to file a bug report for me, Jeff> at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=149436, Jeff> which describes this problem. Jeff> There is already a response to this report, and the Jeff> maintainer (I think?) is asking for confirmation, because he Jeff> isn't seeing the same errors. I assume it's okay with Jeff> everyone involved, so I have put together a list of those of Jeff> us for whom commenting out "noenv" has fixed the problem: O, I can easily believe that noenv gets you this error; I'll look at fixing. Christian's original bug report implied that you could also get rid of the error by commenting out pam_env.so. That seems unlikely to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
