splitting off nvidia-graphics-drivers-legacy-340xx

[Luca Boccassi]

On Mon, 2015-08-03 at 11:23 +0200, Andreas Beckmann wrote:
> On 2015-08-03 02:26, Luca Boccassi wrote:
> 
> >> * renaming the nvidia-uvm.ko module
> >>
> >> These shouldn't be cherry-picked into experimental until they are
> >> finished and working. Especially for renaming the kernel module I could
> >> need some help for testing that this works properly ...
> > 
> > I'll gladly help out, I have 2 machines with Nvidia hardware and one
> > is a laptop,
> > so very handy for testing the nvidia uvm + cuda + bumblebee combination.
> 
> I commited something, that could (should) work theoretically :-)
> 
> To be tested would be 'modprobe' and 'modprobe -r' on the real and alias
> names of the modules:
> * nvidia
> * nvidia-current
> * nvidia-uvm
> * nvidia-current-uvm
> Check with lsmod whether that causes the correct module(s) to be loaded.
> Despite of the filename that was changed to nvidia-current{,-uvm}.ko the
> internal name of the module has not been changed (that would break
> expectations elsewhere) [note to self: document this :-)], so lsmod will
> only show 'nvidia' and 'nvidia-uvm'.

Perfect, will try later tonight or tomorrow night.

> Which raises the question: on non-uvm architectures (e.g. experimental
> driver (or just >= 346) on i386), does the modprobe remove hook cause
> errors since it tries to rmmod a module that's not loaded?

Very good point. I do not have an i386 install with Nvidia HW. I have
never tried, can the modules be loaded in a VM where there is no HW
available? I'll give it a try later tonight or tomorrow.

> >> Regarding conftest.h: there shall be exactly one version being used for
> >> all packages (current and legacy, sid and unstable), otherwise
> >> maintaining it becomes even more hell :-)
> > 
> > Makes sense, I agree. I will backport the fix I've done in
> > branches/352 to branches/340.
> 
> That would be fine.
> 
> > Should I backport to trunk as well?
> 
> I'll just merge the 340 branch before uploading ... and thereafter I'll
> probably merge trunk through all the other branches until I reach
> experimental :-)

Ok, perfect.

> >> Regarding patches: I usually don't refresh patches as long as they still
> >> apply, that reduces the noise in the diff between branches (including
> >> current vs. legacy).
> > 
> > Ops, sorry :-)
> 
> No problem.
> 
> >> PS: @Luca: are you subscribed tp pkg-nvidia-devel@? So I can stop Cc:ing
> >> you :-)
> > 
> > I am, thanks for the concern :-)
> 
> Good. No need to Cc: me either on posts to the list (or a bug to one of
> the team maintained packages, as that goes to the list, too).
> Note that when replying to bugs and want the bug submitter to get the
> reply, you need to explicitly Cc: him, since the BTS does not forward to
> the submitter automatically.

Got it, thanks!

> I'm not sure what you wanted to achieve with your notfound commands for
> bug #794435. notfound/notfixed remove a version from the corresponding
> list, they don't add a 'negative' entry. found/fixed add versions to
> their lists, but it's usually wrong to use 'fixed #xxxxxx "first version
> ever"'.
> Also an 'experimental' tag is usually superfluous if that information
> can be represented by the found version. It's more intended if there are
> external causes for failure in experimental only. I.e. the bug would not
> manifest if the package gets uploaded to sid.
> I don't have a good example for the 'experimental' tag (which stems from
> a time where version handling in the bts was not as advanced as it is
> today, maybe not even present), but for using the sid/stretch release
> tags: package foobar has the same version (1.2-3) in jessie and sid, and
> FTBFS with GCC5 (which is not in jessie, so no problem there) which is
> RC (release critical - severity serious+) in sid/stretch. Filing the RC
> bug with version 1.2-3 and tagging it sid+stretch prevents it from
> showing up on the list of RC bugs in jessie.

Sorry, still learning :-)

Basically when I opened the bug I made a mistake in the report (was
using reportbug from within a chroot) and used a bogus version, so it
looked like from the graph at the top that BTS marked it as found on
every version. I was trying to make it understand that it only applies
to the version in experimental. It appears it's now in the desired
state, even though it required a few tries :-)

> BTW, can the kernel module even be built on armhf in jessie?

I have tried on a Sid chroot only, where the 4.0 module builds fine
(after the CONFIG_XEN hack). I will create a Jessie one and try again
later tonight or tomorrow and report back, but building for 3.16 on Sid
does not work due to this error:

FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol
'xen_start_info'

> I prefer testing with the nvidia-kernel-source package, since that is
> more controllable than dkms and errors out properly:
> * minimal chroot
> * install some kernel header (meta-)packages
> (linux-headers-3.16.0-4-all) (in my sid amd64 modbuild schroot chroot I
> have squeeze/wheezy/jessie/testing/sid/experimental header packages plus
> the corresponding backports and even most of the kernel versions that
> were in testing/experimental at some time)
> * install nvidia-kernel-source
> * sh /usr/share/doc/nvidia-kernel-source/build-module-packages.sh
> * wait :-)
> [ hmm, should document this, too, and you could document your qemu armhf
> setup as well ]

That's very useful, and faster as well, thanks!

Where should we document this? I'm happy to write about the armhf setup,
it's a very simple setup using cowbuilder and qemu-debootstrap (and the
qemu-user-static package).

Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/attachments/20150803/d4ce49eb/attachment.sig>