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