FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 08-06-2012, 05:03 PM
Philipp Kern
 
Default autobuilding src:nvidia-*

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
 
Old 08-06-2012, 05:32 PM
Ben Hutchings
 
Default autobuilding src:nvidia-*

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120806173230.GK1894@decadent.org.uk">http://lists.debian.org/20120806173230.GK1894@decadent.org.uk
 
Old 08-06-2012, 06:42 PM
Russ Allbery
 
Default autobuilding src:nvidia-*

Philipp Kern <pkern@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 874noflv4u.fsf@windlord.stanford.edu">http://lists.debian.org/874noflv4u.fsf@windlord.stanford.edu
 
Old 08-06-2012, 09:28 PM
Philipp Kern
 
Default autobuilding src:nvidia-*

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
 
Old 08-06-2012, 10:31 PM
Andreas Beckmann
 
Default autobuilding src:nvidia-*

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 502045D7.6000404@abeckmann.de">http://lists.debian.org/502045D7.6000404@abeckmann.de
 
Old 08-06-2012, 10:44 PM
Andreas Beckmann
 
Default autobuilding src:nvidia-*

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 502048D9.6060704@abeckmann.de">http://lists.debian.org/502048D9.6060704@abeckmann.de
 
Old 08-06-2012, 10:57 PM
Russ Allbery
 
Default autobuilding src:nvidia-*

Philipp Kern <pkern@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ehnj1vdz.fsf@windlord.stanford.edu">http://lists.debian.org/87ehnj1vdz.fsf@windlord.stanford.edu
 
Old 08-06-2012, 11:02 PM
Russ Allbery
 
Default autobuilding src:nvidia-*

Andreas Beckmann <debian@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87628v1v5x.fsf@windlord.stanford.edu">http://lists.debian.org/87628v1v5x.fsf@windlord.stanford.edu
 
Old 08-07-2012, 09:59 AM
Bastian Blank
 
Default autobuilding src:nvidia-*

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120807095940.GA13776@wavehammer.waldi.eu.org">ht tp://lists.debian.org/20120807095940.GA13776@wavehammer.waldi.eu.org
 
Old 10-03-2012, 11:41 PM
Philipp Kern
 
Default autobuilding src:nvidia-*

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
 

Thread Tools




All times are GMT. The time now is 04:40 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org