Re: Upcoming changes to Debian Linux kernel packages
On 03/10/2023 19.30, Bastian Blank wrote: thread. Or freak out because meta packages remain uninstallable in backports for days. ... plus gcc or we change how backports works. If uninstallable packages in backports are a problem, perhaps backports needs something like britney to migrate packages from an uploading area to the publishing area (once a package set is installable, no need for delays). That should solve the problem where several source packages need to be updated together. (It would also solve problems with unsatisfiable dependencies where the backporter-uploaded binaries were built by accident in sid instead of stable, requiring a binNMU before migration.) (but this should be discussed elsewhere) Andreas
Re: Upcoming changes to Debian Linux kernel packages
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. This is what I expect not to work. 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). Unfortunately 6.7 breaks some exotic in-tree driver (which I desperately need), so I need to go back to 6.6. Oops, there is no gpu driver module any more. Recovery now needs manual intervention. I'm not sure which class of bugs you are trying to solve with this proposed unversioned linux-headers change. IMO the current scheme of linux-headers-$version-$abi-$flavor matching linux-image-$version-$abi-$flavor works well. But perhaps something could be improved on the metapackage side. Ideally a user should install either meta-linux-image-without-headers-$flavor OR meta-linux-image-with-headers-$flavor (and ideally installing dkms should "automatically switch" to the with-headers variant, not sure how this could be done). The current scheme of having to install linux-image-$flavor AND linux-headers-$flavor is a bit tricky. I'm open to implement improvements on the dkms side. Andreas PS: the proposed "more versioning in the linux-image packages" will solve some rare dkms issues where modules didn't get rebuilt after linux-headers-* was upgraded but $(uname -r) didn't change
Re: Upcoming changes to Debian Linux kernel packages
On 24/09/2023 15.01, Bastian Blank wrote: ## Kernel modules will be signed with an ephemeral key The modules will not longer be signed using the Secure Boot CA like the EFI kernel image itself. Instead a key will be created during the build and thrown away after. Do I correctly assume that change only affects the modules shipped by the linux-image packages and not third-party modules built with dkms? ## Header and tool packages will not longer contain version This means that only headers of one single version can be available on the system at one time. This might be a bit inconvinient for dkms, as it can't longer build modules for multiple versions. That sounds problematic in case of third party modules. If it is possible to have multiple linux-image-* packages installed, but only headers for one of them, the third-party modules will only be available for one of the kernel versions for sure (maybe there are still old module builds available, but no guarantee especially after the third-party module got updated). This will make switching between different kernel versions difficult to impossible, e.g. it may be hard to go back to a working older kernel version in case the new one does not work properly (or the third-party module cannot be built or does not work for the new version). Regarding getting the correct linux-header-* packages installed for the installed linux-image-* packages: Maybe linux-image-* could have Recommends: linux-headers-* | no-linux-headers s.t. the correct linux-headers-* are installed by default (installation of recommends is enabled by default) for all installed linux-image-* packages. no-linux-headers would be an opt-out package that can be installed manually if someone does not want to get linux-headers-* installed at all. It should never be installed automatically. For dkms it is hard recommend the correct linux-header-* package, right now we have Recommends: linux-headers-generic | linux-headers-686-pae | linux-headers-amd64 | linux-headers which does not really work for the non-default kernel flavor, e.g. the -cloud or -i386 kernel. So some improvement on the kernel side would be nice here. Andreas
Re: Reintroducing openjdk-8 for Bullseye?
On 09/04/2020 22.12, Graham Inggs wrote: > I don't know about the AdoptOpenJDK builds, but Visual Profiler and > Nsight do work with openjdk-8 8u252-b07-1 from unstable. > > [1] > https://docs.nvidia.com/cuda/archive/10.1/cuda-toolkit-release-notes/index.html The version previously bundled by nvidia with nvidia-cuda-toolkit (up to 10.1.168) is an ancient 8u77 amd64 build, packaged as nvidia-openjdk-8-jre in non-free. For the purposes of src:nvidia-cuda-toolkit, a stripped down version of openjdk-8 should be sufficient: only amd64 and ppc64el builds, only -jre (no -jdk), and it could be moved to contrib to reduce exposure even further. Andreas
