Re: autobuilding src:nvidia-* [non-free]
On Mon, Aug 06, 2012 at 04:02:30PM +0200, Philipp Kern wrote: am Mon, Aug 06, 2012 at 11:47:21AM +0200 hast du folgendes geschrieben: nvidia-cg-toolkit nvidia-cuda-toolkit nvidia-graphics-drivers nvidia-graphics-drivers-legacy-173xx nvidia-graphics-drivers-legacy-96xx nvidia-graphics-drivers-legacy-71xx nvidia-graphics-modules Done for all of them. nvidia-graphics-modules, if it stays in testing, needs to be updated for every new kernel ABI and be unblocked when linux is unblocked. Otherwise it becomes useless. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: autobuilding src:nvidia-* [non-free]
On Mon, Aug 06, 2012 at 03:57:28PM -0700, Russ Allbery wrote: [ providing prebuilt modules ] I'm not sure if that work is a strong argument against doing this. The kernel team does not seem to be overly happy, especially given the fact that it's the last package to do so. But there was only one member voicing an objection and one other commenting that an ABI change within stable would be extremely unlikely (especially through a security update, for which we would not issue a corresponding nvidia update in time). I'll give this another week on -release and -kernel for people to speak up, but I cannot hold this package hostage on the non-free autobuilding side even though I'm extremely unhappy with it from a release team point of view. I.e. I'll go and do a final review for the remaining packages by then and will enable autobuilding if they satisfy the criteria. Sorry for this taking so long… Kind regards Philipp Kern signature.asc Description: Digital signature
Re: autobuilding src:nvidia-* [non-free]
On Mon, Aug 06, 2012 at 07:03:16PM +0200, Philipp Kern wrote: Copying debian-release@ and debian-kernel@ on what they think. To provide context (it seems that pkg-nvidia-devel@ dropped my mails or put it into a queue, hence they're not in a list archive): nvidia-graphics-modules seems to be the last package to provide pre-built kernel modules. Do we still want this for wheezy given the maintenance hassle if there's an ABI bump? I think it is time to drop them. We have other mechanisms to do that. Bastian -- The idea of male and female are universal constants. -- Kirk, Metamorphosis, stardate 3219.8 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120807095940.ga13...@wavehammer.waldi.eu.org
Re: autobuilding src:nvidia-* [non-free]
On Mon, Aug 06, 2012 at 06:49:11PM +0200, Andreas Beckmann wrote: On 2012-08-06 17:07, Philipp Kern wrote: I gathered. That doesn't answer my point, though. It is the *last* package in the archive doing so, instead of using dkms. There is nvidia-kernel-dkms, too. But for historic reasons we always provided prebuilt modules for stable and I don't want to change this. Copying debian-release@ and debian-kernel@ on what they think. To provide context (it seems that pkg-nvidia-devel@ dropped my mails or put it into a queue, hence they're not in a list archive): nvidia-graphics-modules seems to be the last package to provide pre-built kernel modules. Do we still want this for wheezy given the maintenance hassle if there's an ABI bump? Or is an ABI bump (e.g. through a security update) completely unlikely for wheezy, given that we managed to keep squeeze stable? It does mean that it needs to be updated on every kernel ABI bump. Right, but that hopefully does not happen too often for stable (but the next ABI bump is already scheduled, as I heard). (Also in theory the ABI compatibility guarantee of the Debian Linux packages is that they can add new symbols at any time, they just won't drop old ones. But I guess that's not as relevant for the nvidia packages. I recently needed to rebuild it for 3.2.0-3 again because of mismatching symbol versioning without ABI-bump (#683365), that should be doable by a plain binNMU in the future. It could at least be compatible one-way by specifying strict dependencies onto the package it was compiled against. But if kernel upgrades randomly break it, that concerns me even more and somehow points to it being unsuitable as a mechanism for a stable distribution. Yes, we could possibly update the modules through a stable update at point release time (or maybe through stable-updates), but if there's already a solution that solves it: Why shouldn't we use it? Kind regards Philipp Kern signature.asc Description: Digital signature
Re: autobuilding src:nvidia-* [non-free]
On Mon, Aug 06, 2012 at 07:03:16PM +0200, Philipp Kern wrote: On Mon, Aug 06, 2012 at 06:49:11PM +0200, Andreas Beckmann wrote: On 2012-08-06 17:07, Philipp Kern wrote: I gathered. That doesn't answer my point, though. It is the *last* package in the archive doing so, instead of using dkms. There is nvidia-kernel-dkms, too. But for historic reasons we always provided prebuilt modules for stable and I don't want to change this. Copying debian-release@ and debian-kernel@ on what they think. To provide context (it seems that pkg-nvidia-devel@ dropped my mails or put it into a queue, hence they're not in a list archive): nvidia-graphics-modules seems to be the last package to provide pre-built kernel modules. Do we still want this for wheezy given the maintenance hassle if there's an ABI bump? Or is an ABI bump (e.g. through a security update) completely unlikely for wheezy, given that we managed to keep squeeze stable? No promises, but I think it's quite unlikely that we will have to change ABI for the standard (non-rt) configurations after release. It does mean that it needs to be updated on every kernel ABI bump. Right, but that hopefully does not happen too often for stable (but the next ABI bump is already scheduled, as I heard). (Also in theory the ABI compatibility guarantee of the Debian Linux packages is that they can add new symbols at any time, they just won't drop old ones. But I guess that's not as relevant for the nvidia packages. I recently needed to rebuild it for 3.2.0-3 again because of mismatching symbol versioning without ABI-bump (#683365), that should be doable by a plain binNMU in the future. It could at least be compatible one-way by specifying strict dependencies onto the package it was compiled against. But if kernel upgrades randomly break it, that concerns me even more and somehow points to it being unsuitable as a mechanism for a stable distribution. Yes, we could possibly update the modules through a stable update at point release time (or maybe through stable-updates), but if there's already a solution that solves it: Why shouldn't we use it? There is actually no attempt to check or maintain ABI stability for packages with the rt featureset (or openvz or vserver, in squeeze), as their stable updates have been comparatively less stable. This fact hasn't been advertised nearly as widely as it should be. I think we should do better and actually change the ABI numbers per-featureset, as the current arrangement obviously works really badly with OOT modules. But it will require more trips through NEW and more linux-latest updates. (I'm a little sceptical that many OOT modules work properly with rt, but let's assume some of them do.) Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120806173230.gk1...@decadent.org.uk
Re: autobuilding src:nvidia-* [non-free]
Philipp Kern pk...@debian.org writes: Copying debian-release@ and debian-kernel@ on what they think. To provide context (it seems that pkg-nvidia-devel@ dropped my mails or put it into a queue, hence they're not in a list archive): Sorry, they're all approved now. We get unbelievable amounts of spam, so the list moderates messages from people who aren't subscribed with the normal whitelisting for Debian administrative mail, and sometimes I don't get to that right away (like this time). The folks participating in this thread are also now whitelisted. nvidia-graphics-modules seems to be the last package to provide pre-built kernel modules. Do we still want this for wheezy given the maintenance hassle if there's an ABI bump? Or is an ABI bump (e.g. through a security update) completely unlikely for wheezy, given that we managed to keep squeeze stable? I've personally dropped the non-dkms methods from the other package that I have with kernel modules, but I'll note in defense of providing prebuilt modules that it's somewhat simpler for users and the non-free video drivers are often used by the least sophisticated Debian users. What Andreas has been doing, which I think is fairly reasonable, is keeping them out of testing until shortly before the freeze and then updating them for the freeze, which means only doing new uploads for ABI changes that happen during the freeze or in stable (relatively rare). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874noflv4u@windlord.stanford.edu
Re: autobuilding src:nvidia-* [non-free]
Hey Russ, On Mon, Aug 06, 2012 at 11:42:41AM -0700, Russ Allbery wrote: Sorry, they're all approved now. thank you. nvidia-graphics-modules seems to be the last package to provide pre-built kernel modules. Do we still want this for wheezy given the maintenance hassle if there's an ABI bump? Or is an ABI bump (e.g. through a security update) completely unlikely for wheezy, given that we managed to keep squeeze stable? I've personally dropped the non-dkms methods from the other package that I have with kernel modules, but I'll note in defense of providing prebuilt modules that it's somewhat simpler for users and the non-free video drivers are often used by the least sophisticated Debian users. I'm a bit confused why that is. If I'm installing a nvidia-graphics-driver package that does all the magic using dkms at install time, how is that more sophisticated than providing pre-built module packages, especially in the light that it's the only one left doing it that way? (Why isn't it the same for fglrx? Where's that 3.2.0-3 module for virtualbox?) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: autobuilding src:nvidia-* [non-free]
I'm afraid, this is getting a bit off-topic ... On 2012-08-06 23:28, Philipp Kern wrote: I'm a bit confused why that is. If I'm installing a nvidia-graphics-driver package that does all the magic using dkms at install time, how is that more sophisticated than providing pre-built module packages, There are a few people that don't like the dkms way (to many dependencies: compiler, kernel headers; leaves cruft around (I tried to fix a bit of this in my dkms NMU); ) and prefer to take the responsibility to provide their own kernel module packages for local deployment. So with the current state a foo-dkms package is an alternative to foo-source, but not a replacement for it. But I think there were enough threads about this topic already, no need to start a new one ... especially in the light that it's the only one left doing it that way? (Why isn't it the same for fglrx? unfortunately the license does not permit distribution of precompiled kernel modules Where's that 3.2.0-3 module for virtualbox?) in my private repository :-) I have a generic branch of nvidia-graphics-modules.git with all the nvidia specific bits made configurable that can be used to quickly build module packages with module-assistant for any foo-source package (tested with fglrx-source and virtualbox-source on i386 and amd64), if anyone is interested, I can push this somewhere. Nice way for getting prebuilt modules (+ corresponding meta-packages) into a local repository. Andreas PS: I also maintain r8168-dkms which is dkms only (and only in sid) - primarily to get some more experience with dkms ... -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/502045d7.6000...@abeckmann.de
Re: autobuilding src:nvidia-* [non-free]
On 2012-08-06 19:32, Ben Hutchings wrote: There is actually no attempt to check or maintain ABI stability for packages with the rt featureset (or openvz or vserver, in squeeze), as their stable updates have been comparatively less stable. This fact hasn't been advertised nearly as widely as it should be. In that case we should probably drop the RT prebuilt modules (like we did for openvz and xen in squeeze) - or do semi-automatic binNMUs whenever a new linux_3.2* gets out. I think we should do better and actually change the ABI numbers per-featureset, as the current arrangement obviously works really badly with OOT modules. But it will require more trips through NEW and more linux-latest updates. (I'm a little sceptical that many OOT modules work properly with rt, but let's assume some of them do.) I think nvidia works with RT, although I haven't tried this myself. I picked up a patch from arch linux earlier this year that worked around some GPL-only symbols getting pulled in by the RT patch, but that is no longer neccessary. Andreas -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/502048d9.6060...@abeckmann.de
Re: autobuilding src:nvidia-* [non-free]
Philipp Kern pk...@debian.org writes: I'm a bit confused why that is. If I'm installing a nvidia-graphics-driver package that does all the magic using dkms at install time, how is that more sophisticated than providing pre-built module packages, especially in the light that it's the only one left doing it that way? The main problem with the DKMS approach is that you have to have a version of the kernel headers installed that matches the version of the kernel that you have. If you don't, you just don't get the module, and then stuff doesn't work. People seem to really struggle with this when they don't understand what's going on under the hood, and our dependency system is not powerful enough to clearly express this dependency. With the prebuilt modules, you can just install the meta tracking package for the nvidia modules and from the perspective of the user it just works, since the packaging takes care of keeping the dependencies in sync with the kernel module versions. It's more fragile from a Debian perspective, but within a stable release it means the user doesn't have to notice that they need the header package installed. (Admittedly, with the DKMS approach, you can just install the header tracking package and once you have that installed, similarly everything will just work. The confusion seems to come from people not realizing that they need to also install the header tracking package; they find the NVIDIA DKMS package and then don't realize that's not enough.) It's a relatively minor benefit, I'll grant. If I were doing all the NVIDIA stuff by myself, I wouldn't bother, but I can see some benefit as long as Andreas wants to keep doing the work. I think what we're currently doing doesn't put a lot of work on anyone else, other than some work for ftp-master approving the new packages after an ABI update and the release team approving freeze exceptions for the new packages after an ABI update. I'm not sure if that work is a strong argument against doing this. I noticed that dkms now Recommends the tracking kernel header package, so maybe that makes this somewhat more obsolete. That means that the average user should, through the dependency tree, get the header package installed when they install nvidia-modules-dkms, which in turn they should get via Recommends from nvidia-graphics-modules. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehnj1vdz@windlord.stanford.edu
Re: autobuilding src:nvidia-* [non-free]
Andreas Beckmann deb...@abeckmann.de writes: There are a few people that don't like the dkms way (to many dependencies: compiler, kernel headers; leaves cruft around (I tried to fix a bit of this in my dkms NMU); ) and prefer to take the responsibility to provide their own kernel module packages for local deployment. So with the current state a foo-dkms package is an alternative to foo-source, but not a replacement for it. The other benefit for having the -source package is that it works somewhat more smoothly with self-built kernels that don't use the Debian layout. The last time I looked at this, the things that you have to do when you're building your own Linux kernel to get the DKMS support to work are more complex than what you have to do to get the module-assistant or kernel-package stuff to work. This is all fairly dated information, though; I stopped building my own kernel a long time ago, so most of my understanding is hearsay. I keep maintaining -source packages for other packages with kernel modules mostly because I keep getting a small number of bug reports for them, so people are clearly still using them. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87628v1v5x@windlord.stanford.edu
