n-g-d post-squeeze plans

[Russ Allbery]

Andreas Beckmann <debian at abeckmann.de> writes:

> what are our plans for n-g-d to now that squeeze has been released?

> Do we want to try to make a security update for 195xx
> #609338: cuda: uninitialized memory infoleak
> Someone sent a link to the upstream patch, but I didn't try it, yet.

It would be a good idea if we can, although getting the updated drivers
into unstable is probably a higher priority.

> I can try to prepare a minimal 195.36.31-7 with the security fix. I'd
> like to keep the README updates and the bug script updates currently in
> -7, the manpage can be postponed to -8. Would this be OK for a squeeze
> update?

I think it probably would be, yes.  The README and bug script updates
might be iffy, but I think that sort of documentation fix should be
relatively uncontroversial and the stable update policy isn't as tight as
it used to be.

> Before uploading 260.xx to unstable I'd like to cherry-pick the general
> packaging changes into 195.36.31-8, so that they can be merged into the
> legacy variants.

Good idea.

> We can update 260xx in experimental in the meantime, but first we need
> nvidia-common uploaded to experimental (or better directly to unstable,
> since squeeze is out and it won't break the packages currently in
> unstable).

I asked separately about that -- sounds like unstable is the right
target.  I can do that tomorrow morning.

> What are our long term goals for wheezy?
> * use debconf to create /etc/X11/xorg.conf (or another way of
> semi-"auto"-configuration)
> * allow parallel installation of n-g-d, n-g-d-legacy-*, fglrx
> * ...

Those two both sound like great goals to me.  I probably won't have much
time to look at things until May or so, but I can hopefully at least get
uploads done for you now that things have calmed down a bit.

> We wanted to provide squeeze-backports of the current drivers (once we
> have 260xx+ in unstable/testing) - what has to be done for this?

Not much as long as they build in a squeeze chroot.  I just need to do the
backport and upload it.

> How regularily do we want to update the prebuilt modules for the kernel
> in unstable?

Do we want to maintain these going forward or have people use either dkms
or module-assistant?  We're one of the very few packages still building
those separate kernel packages, and while dkms has some problems, it seems
to be the direction everyone is going.  The problem with maintaining them
is that they have to go through NEW every time, which gets somewhat
tedious, and the kernel tends to change a lot during unstable.

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>