ricotz | so do we want a dedicated nvidia ppa? aka "ppa:graphics-drivers/nvidia" | 13:51 |
---|---|---|
mamarley | I set that version a long time ago to keep my own packages ahead of other packages of the same driver version so I didn't need to recompile and reboot multiple times when a new driver was released. | 13:51 |
mamarley | Back then, it was just a personal thing and I never expected anyone else to actually use it. | 13:51 |
mamarley | ricotz: I think so. | 13:52 |
tjaalton | why driver specific ppa's? | 13:52 |
ricotz | not sure, that is why I am asking ;) | 13:52 |
tjaalton | I don't see a point | 13:52 |
ricotz | "ppa:graphics-drivers/ppa" is fine for me | 13:53 |
mamarley | I guess I don't have any logic behind my opinion, so just one PPA is fine. | 13:53 |
tseliot | ricotz, mamarley: I've just pushed my 355 code | 13:53 |
mamarley | I had also been packaging the latest version of libvdpau and vdpauinfo. Should that go in the same PPA or a different one? Or not under this team at all? | 13:54 |
tjaalton | if this place will also get backported mesa + llvm, then I hope we could ditch the stupid renaming business on lts-stacks | 13:54 |
tseliot | still on github | 13:54 |
tjaalton | which is nothing but pain | 13:54 |
tjaalton | assuming enough people use it and file issues which get fixed early enough for "blessed" backports in the main lts repo | 13:55 |
tseliot | mamarley: where does come from? (debian?) | 13:55 |
mamarley | tseliot: The VDPAU packages? I based those on what is already in Ubuntu, just new upstream releases. | 13:56 |
tseliot | and yes, a non-driver-specific ppa would be better | 13:56 |
ricotz | I am going to copy libvdpau from edgers too | 13:56 |
mamarley | So should I create a separate PPA under this team for VDPAU stuff then? | 13:57 |
ricotz | tseliot, vdpau is pretty much connected since it will be removed from the blob soon | 13:57 |
tjaalton | mamarley: imo no | 13:57 |
ricotz | mamarley, no | 13:57 |
mamarley | OK | 13:57 |
tjaalton | if it's supposed to be a one-stop place for "everything" driver related | 13:57 |
tseliot | yes, using the same PPA makes sense | 13:57 |
mamarley | OK, that works. | 13:57 |
tseliot | ricotz: https://github.com/tseliot/nvidia-graphics-drivers/tree/355 | 13:59 |
ricotz | tseliot, got it | 13:59 |
tseliot | ricotz: you might want to rebase on that | 13:59 |
ricotz | i know | 13:59 |
ricotz | jcastro, could you ask for more ppa space and armhf support? | 14:01 |
ricotz | https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa/+packages | 14:01 |
jcastro | sure, how does that work, I file a bug? | 14:01 |
tseliot | 352 is still stuck in NEW in wily... | 14:01 |
ricotz | jcastro, a question against "launchpad" | 14:02 |
ricotz | jcastro, or ask wgrant ;) | 14:02 |
jcastro | ack | 14:02 |
jcastro | on it! | 14:02 |
ricotz | thanks | 14:02 |
jcastro | feel free to task me with all the administrative work | 14:02 |
mamarley | Are we going to keep using the "-0ubuntu0~xedgers15.10.1"-style version string? (Just wondering for when I upload new versions.) | 14:03 |
ricotz | jcastro, a nice ppa desciption too? ;P | 14:03 |
jcastro | ok, I'm on it | 14:04 |
ricotz | mamarley, no, i guess "-0ubuntu0~gpu15.10.1", to simplify is a bit | 14:05 |
mamarley | ricotz: OK, got it. Thanks! | 14:05 |
mamarley | If you guys want me to handle the day-to-day uploads of new driver releases, that would be fine. I check for updates every morning, so my response time is quite fast. | 14:07 |
tseliot | that would be nice | 14:07 |
jcastro | https://answers.launchpad.net/launchpad/+question/270278 | 14:07 |
mamarley | OK, great. I will handle that then. | 14:08 |
tseliot | thanks | 14:08 |
ricotz | mamarley, alright, let us know when you before you start to avoid clashes | 14:09 |
mamarley | ricotz: OK, sure thing. | 14:10 |
tseliot | good | 14:10 |
ricotz | mamarley, you know how to create a proper package? | 14:10 |
mamarley | ricotz: I think so, but now I am doubting. | 14:11 |
tseliot | do you mean a new flavour? | 14:11 |
ricotz | mamarley, you didnt use a orig-tarball iirc | 14:11 |
tseliot | as in -355, -390, etc | 14:11 |
tseliot | oh, that (.orig) would save bandwidth | 14:12 |
mamarley | ricotz: I wasn't. What is the procedure for that? I had only used .orig tarballs before when upstream actually shipped one. | 14:12 |
ricotz | look into one e.g. for 355 and recreate it like that, and use it as usual | 14:13 |
ricotz | of course include amd64, i386 and armhf bins | 14:14 |
ricotz | bbl | 14:14 |
mamarley | But PPA uploads are source-only right? | 14:15 |
tseliot | what do you mean? | 14:15 |
ricotz | the "bins" provided by nvidia should be in the orig tarball | 14:15 |
tseliot | the .run installers | 14:15 |
mamarley | OK | 14:16 |
mamarley | But the current packages don't include armhf, do they? | 14:16 |
tseliot | they do | 14:16 |
tseliot | there's an easy way to do it | 14:16 |
tseliot | 1) enter the directory with the source (e.g. nvidia-graphics-drivers-355) | 14:17 |
tseliot | 2) download the installers by doing: debian/rules get-orig-source | 14:17 |
tseliot | 3) create a tarball that only contains the 3 installers and excludes the debian and .git directory | 14:18 |
mamarley | So the .run files should be in the root directory of the archive? | 14:18 |
tseliot | the archive will contain a directory e.g. nvidia-graphics-drivers, which, in turn, contains the .run files | 14:20 |
mamarley | OK | 14:20 |
tseliot | mamarley: follow the name scheme of the other orig tarballs and you'll be all set | 14:21 |
mamarley | Thanks! That does sound easier than what I was doing. | 14:22 |
tseliot | :) | 14:22 |
mamarley | And soon I will likely be getting Google Fiber so I won't have to wait hours for the packages to upload either! | 14:22 |
jcastro | rub it in! | 14:22 |
jcastro | so hey guys, where's the git source to the packages? I'd like to refer them in the description | 14:23 |
tseliot | mamarley: then, only for your first upload, build with "debuild -S -sa" (so as to include the orig tarball). For the next uploads that use the same tarball you can create the sources using just "debuild -S", so that you won't have to reupload the orig tarball | 14:23 |
mamarley | tseliot: OK, but I will still need to reupload the orig.tar for new upstream releases, right? | 14:23 |
tseliot | my sources are here: https://github.com/tseliot/nvidia-graphics-drivers (look for the different heads, not master) | 14:24 |
tseliot | mamarley: correct | 14:24 |
tseliot | mamarley, ricotz: you might want to set up a git repository (you choose where) for the packaging scripts, so that you can pull in my changes and add yours | 14:25 |
mamarley | Sure, I can just fork that repository. | 14:28 |
mamarley | tseliot: ricotz: OK, I forked it to https://github.com/mamarley/nvidia-graphics-drivers/ and added push access for ricotz. | 14:31 |
tseliot | mamarley: thanks | 14:32 |
mamarley | tseliot: Should I put my vdpauinfo 1.0 package in ppa:graphics-driver/ppa too? | 14:44 |
tseliot | mamarley: sure | 14:45 |
mamarley | OK, will do. | 14:46 |
ricotz | tseliot, did you tested and built the kernel module of 355 on i386? | 14:46 |
ricotz | (with you packaging) | 14:46 |
tseliot | ricotz: probably not (I can't remember) but those changes mostly come from NVIDIA | 14:46 |
ricotz | tseliot, i could be wrong but this likely fails | 14:47 |
tseliot | ricotz: where exactly? | 14:47 |
ricotz | while it will try to build the uvm module on i386 too | 14:47 |
jcastro | ricotz: space sorted, thanks to wgrant | 14:47 |
ricotz | jcastro, great | 14:47 |
tseliot | ricotz: let me check | 14:48 |
ricotz | tseliot, the module source is taken from the amd64 pack | 14:48 |
ricotz | passing -jX isnt useful imo | 14:49 |
ricotz | tseliot, also please tweak the kernel 3.18 patch as i suggested | 14:50 |
tseliot | ricotz: right, the new build system builds all modules by default. I need to use NV_EXCLUDE_BUILD_MODULES='' | 14:52 |
tseliot | ricotz: can you point me to that change (for 3.18) again, please? (too much stuff on my plate...) | 14:53 |
ricotz | tseliot, look at the edgers package | 14:53 |
tseliot | ricotz: ok | 14:53 |
ricotz | regarding the uvm problem too | 14:54 |
tseliot | ok | 14:55 |
tseliot | ricotz: do you have a git repository too? | 14:56 |
ricotz | tseliot, just a local private one | 14:58 |
tseliot | ok | 14:59 |
ricotz | I won't rebase/update the 355 packages then ;) | 14:59 |
mamarley | Also, were we going to make some sort of staging PPA to upload things to initially and then copy them once they are built and tested? | 15:03 |
tseliot | ricotz: I've just downloaded nvidia-graphics-drivers-355 (355.06-0ubuntu0~xedgers15.10.1), and I don't see the uvm work | 15:04 |
tseliot | mamarley: a staging ppa sounds like a good idea | 15:05 |
mamarley | Is there any way to make it hidden so people don't try to use it? | 15:05 |
tseliot | that would have to be a private PPA. jcastro ^^ | 15:06 |
jcastro | is private the best thing to do? | 15:06 |
jcastro | or just really big warnings? | 15:06 |
tseliot | whatever you're more comfortable with, guys | 15:07 |
mamarley | Either one is fine with me. | 15:07 |
jcastro | I would prefer to keep everything open, with just clear warnings that the staging area is for developers and not end users | 15:07 |
mamarley | Sure | 15:08 |
tseliot | ricotz: oh, you meant to say that you didn't do that kind of work, and that pulling in the new work will break it. I'll fix and test that soon | 15:08 |
ricotz | tseliot, a plain diff http://paste.debian.net/plain/291679 | 15:08 |
ricotz | "nv-kernel.o_binary" is correct I think | 15:09 |
ricotz | mamarley, jcastro, warnings dont help | 15:09 |
jcastro | yeah that's fine | 15:10 |
ricotz | mamarley, testing things locally as good as possible | 15:10 |
jcastro | unless you really think the other way is better | 15:10 |
tseliot | ricotz: ok, I'll have a look at it tomorrow, thanks | 15:10 |
jcastro | I don't feel strongly about it either way | 15:10 |
mamarley | ricotz: Of course, but I don't have much in the way of hardware on which to test yet. | 15:10 |
ricotz | maybe disable ppa publishing before starting a new upload | 15:10 |
mamarley | That would make it harder to test on my own systems. | 15:11 |
ricotz | mamarley, meaning check the kernel modules and such, and a runtime check | 15:11 |
mamarley | I always install them on my laptop before uploading. | 15:11 |
ricotz | much more isn't possible and this ppa is meant to get things tested | 15:12 |
ricotz | user won't be automatically transitioned to newer beta series | 15:12 |
mamarley | So no staging PPA then? | 15:12 |
ricotz | e.g. make sure to drop all "transitional" packages before uploading | 15:13 |
ricotz | mamarley, i dont see much of a point for one | 15:13 |
mamarley | OK. I never put transitional packages between major releases. | 15:13 |
ricotz | the ubuntu package contains some, so those should be stripped | 15:14 |
mamarley | OK. | 15:14 |
ricotz | tseliot, alright | 15:14 |
mamarley | Which are they? I am looking at 346 and 352 and not seeing any transitional packages. | 15:15 |
ricotz | mamarley, http://launchpadlibrarian.net/212442914/nvidia-graphics-drivers-352_352.21-0ubuntu1_source.changes | 15:17 |
ricotz | tseliot, make sure those don't land in the archive http://launchpadlibrarian.net/214273992/nvidia-graphics-drivers-legacy-340xx_340.76-6_amd64.changes | 15:17 |
mamarley | Ah, OK. It looks like those have already been removed for the PPA builds though. | 15:17 |
ricotz | right, as I said | 15:18 |
mamarley | Sorry | 15:18 |
ricotz | alright, so much for x stuff today | 15:18 |
tseliot | ricotz: I don't see how they could end up in the archive, since I'm not going to upload 355, and I'm the only maintainer ;) | 15:22 |
tseliot | ricotz: oh, that | 15:22 |
ricotz | tseliot, I am talking about the syncs from debian | 15:22 |
tseliot | :/ | 15:22 |
ricotz | mamarley, use https://launchpad.net/ubuntu/+source/vdpauinfo/1.0-1 | 15:24 |
tseliot | ricotz: I've just asked in #ubuntu-release | 15:24 |
mamarley | ricotz: Yeah, I just realized my dependencies are goofed up. Just a sec... | 15:24 |
* ricotz really gone now | 15:25 | |
ricotz | mamarley, :\ dont override existing ubuntu packages | 15:34 |
ricotz | in this case "1.0-1~gpu14.04.1" | 15:35 |
ricotz | mamarley, don't hesitate to ask and wait a bit | 15:36 |
mamarley | I'm really sorry. | 15:36 |
ricotz | and still there is also precise ;) | 15:37 |
mamarley | OK, I will fix the version and upload for Precise. | 15:38 |
ricotz | mamarley, you cant fix the version | 15:38 |
ricotz | it would be lower which doesnt work anymore now | 15:38 |
mamarley | I should be able to for precise because I haven't uploaded the incorrect version yet. | 15:38 |
ricotz | for precise yes | 15:39 |
mamarley | So I have "vdpauinfo (1.0-1~gpu12.04.1) precise; urgency=medium", is that OK to upload? | 15:39 |
ricotz | yes, and still works in regard of the other versions | 15:39 |
ricotz | but wait until the libvdpau is published to avoid a failure/dep-wait | 15:40 |
mamarley | OK, I will upload it after lunch. Sorry for the trouble. | 15:40 |
ricotz | https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa/+packages?field.name_filter=vdpau&field.status_filter=published&field.series_filter= | 15:40 |
jcastro | so hey guys, will kind of brings up a good point | 15:40 |
jcastro | if we want to convince the TB to allow a GUI hook from the driver tool to a PPA, they're going to want to know it's tested | 15:41 |
jcastro | so maybe doing a staging thing would be a good idea, if anything to show that we break there first? | 15:41 |
mamarley | That's fine with me; I don't have a strong opinion one way or another. | 15:59 |
tjaalton | filed https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1484279 | 21:37 |
ubottu | Launchpad bug 1484279 in mesa (Ubuntu) "[FFe] Mesa 11.0.0" [Medium,Triaged] | 21:37 |
tjaalton | feel free to modify [Changes] | 21:37 |
tjaalton | or anything really | 21:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!