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

[Andreas Beckmann]

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'.

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?

>> 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 :-)

>> 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.

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.


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

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 ]


Andreas