[06:06] infinity: Mirv: hey! what's the status on raring unity SRU? It's seem it's again under review. I don't want us to have to reupload again because after a month, the build files are lost… [06:12] didrocks: infinity should have it under radar, hopefully there's no obstacles for the reviews to happen this week [06:13] ok, let's cross fingers :) [07:02] ty === greyback|away is now known as greyback [08:14] didrocks: I'll get to it this week. I still think we should change that process to one that won't lose files, mind you. [08:14] didrocks: s/won't/can't/ [08:15] infinity: yeah, that would be helpful, not sure how though [08:17] why would we loose files? [08:18] didrocks: I recommended to Mirv that you stage SRUs in an interim PPA where you're not constantly re-uploading dailies, so things won't time out while they're pending review/copy. [08:18] seb128: PPA history isn't forever, superseded uploads go away after a while. [08:18] oh, I see [08:18] seb128: And copies in the queue aren't actually copies, they're just pointers back to the original until they're accepted. [08:18] ok [08:18] infinity: well, but we still want to know if the newest commits are building [08:18] and not introducing regressions in the tests [08:19] well, if we take over a month to accept SRUs for you main desktop component we have another issue [08:19] for our main* [08:19] didrocks: Right, hence the SRU PPA. So, you keep doing the daily thing as always, but when you have a "blessed" set you want to SRU, you copy-with-binaries to the SRU PPA, and then copy to foo-proposed from there. [08:19] didrocks: And don't delete/supersede them until they're accepted (or until you want a new version instead). [08:19] infinity: yeah, that's an option, I will need to hack around, not on top of the list, but that's an acceptable worfklow IMHO [08:20] seb128: Taking too long to review it was a problem, and I'll fix that, but it's still not ideal to have a source that can go away (there's no service guarantee for superseded PPA packages, nor should there be). [08:21] infinity, ppa copies should do an actual copy, it would give us a diff to review in the queue and persistance ;-) [08:21] didrocks: Anyhow, for now, these ones shouldn't disappear before I review them. We'll be good. But we *should* treat superseded packages as if they don't exist. [08:22] infinity: yeah, understood, I didn't know that the copy binaries was just a pointer and not a real one, but with the sru ppa workflow, that should be fine [08:23] seb128: That's debatable. The diff bit, we'll get via other means. The persistance thing is irksome, but I'm not sure it's worth the code changes to fix/change that. [08:23] infinity: please demote boost1.49 to universe =) [08:23] xnox: Done. [08:24] infinity: thanks. [08:24] (And yay) [08:25] xnox: I still have a bunch of boost1.53 stuff that's in main because I just promoted the lot to make the transition easier. Now that you're done transitioning, does that mean the 1.53 stuff listed on component-mismatches should be safe to demote? [08:26] infinity: I would think so, however you choose. all of these are build from the source package which is in main, the mpi half is all in universe. [08:27] * xnox goes to collapse boost1.49 universe+main source package into one. [08:27] And by "collapse", you mean "remove the Ubuntu delta"? [08:27] infinity: well, checking if it can be synced. [08:28] xnox: I'm heading to bed, but poke me when you've done that, so I can remove the -mpi source package. [08:28] infinity: sure. thanks. [08:38] infinity: bug 1187299 [08:38] Launchpad bug 1187299 in boost-mpi-source1.49 (Ubuntu) "Please remove boost-mpi-source1.49 from the archive" [Medium,Triaged] https://launchpad.net/bugs/1187299 [08:40] xnox: Sure, can't remove the source until all the binaries change lineage (ie: once the synced source builds everywhere), but I'll do it later. [08:40] infinity: cool, thanks. Will remember the timing. (I guess if removed early the binaries will end up in the new queue again...) [08:41] xnox: Well, more to the point, it would render a bunch of stuff unbuildable/uninstallable. [08:42] =) [09:01] seb128: didrocks: any of you want to take it ^? :-) [09:02] rsalveti, \o/ [09:02] rsalveti, I can have a look [09:02] thanks rsalveti, seb128 :) [09:02] Why do I have a feeling that'll be a "fun" review, if one's thorough? [09:02] rsalveti, what are you doing up? did you work all night to get it uploaded? [09:02] seb128: there are quite a few patches there, which I already did most of the clean up, and working to get them upstream [09:02] ok [09:02] seb128: well, had to review copyright and fix a few other things :-) [09:03] don't want to be the blocker :-) [09:03] infinity: fun indeed :-) [09:04] didrocks: I believe qtubuntu-media will fail, due change in the lib name, so I'll be fixing as soon we start landing the new packages [09:04] rsalveti: ok, and about ofono, apart from telepathy-ofono that we add ourself, anything else? [09:05] didrocks: guess that would be all, ofono-qt and telepathy-qt5 only, which will be available in a few [09:05] rsalveti: perfect, it seems everything is arriving at the right and same time [09:05] rsalveti: jibel and I are continuing deploying otto instead of UTAH [09:05] didrocks: right [09:08] infinity: don't you ever sleep as well? [09:09] rsalveti: No one waiting in bed for me. What's your excuse, young man? [09:10] infinity: haha, just to get stuff done :-) [09:11] rsalveti: Well, your stuff is done. Shoo. [09:11] infinity: :-) [09:12] seb128: the copyright file is a bit scary as well [09:12] tried my best to put everything in there [09:12] rsalveti, don't worry, after the qt5 stack I'm sure that one is going to be fine :p [09:12] haha, ok :-) [09:13] rsalveti, anyway I will review it today but don't block on that to go get some sleep, I will have my review comments by the time you wake up tomorrow (or later today rather) [09:13] seb128: sure, np [09:23] seb128: 5 patches just got accepted: https://github.com/libhybris/libhybris/commits/master [09:23] rsalveti: Is upstream done being mad at us, then? [09:24] infinity: yup [09:24] \o/ [09:25] can an admin please approve nvidia-persistenced and nvidia-modprobe in saucy? [09:26] rsalveti, great ;-) [09:27] tseliot: nvidia-modprobe confuses me. Doesn't the X driver do that automagically? [09:27] tseliot: Err, and persistenced claims to do the same thing... [09:27] I suspect one of those descriptions is a lie. :P [09:30] infinity: oops, I forgot to update the description of nvidia-persistenced. I guess I used the same packaging scripts as a base [09:31] tseliot: Right, well. I should be asleep, so won't do a full review tonight, but I'll poke tomorrow. And if you want to explain to me in backscroll why we need something that loads modules when we never did before, that would be great. [09:31] infinity: please reject nvidia-persistenced and I'll correct it. Here's the readme in case you're interested: https://github.com/NVIDIA/nvidia-persistenced#readme [09:32] tseliot: That README tells me nothing about what it does, though it does tell me it intends to install its own copy of rpcgen, which I hope you don't do. [09:35] infinity: the daemon interface was generated by rpcgen. It doesn't say it will install its own version of rpcgen [09:35] tseliot: Oh, nevermind, I misread. They're just saying they pregenerated the rpcgen output. [09:35] tseliot: Yeah. :P [09:35] yep [09:38] infinity: as for nvidia-modprobe, it loads the NVIDIA driver and creates the device nodes, and setuid root, allowing unprivileged users to create the device nodes. If one of the NVIDIA driver's userspace components needs access to the kernel module and device nodes, but they're not loaded/created yet, that driver component can use nvidia-modprobe. [09:40] tseliot: Isn't this what udev is for? [09:41] infinity: it's NVIDIA's distro agnostic way to do it. Shall I use udev instead? [09:41] distro-agnostic doesn't mean correct. :) [09:42] I can look at it again when I'm awake, but I suspect my answer will be "this is crackful when we have udev to handle this very thing, and so does every other distro from this century". [09:42] heh [09:46] infinity: nvidia-persistenced sets persistence mode to the GPU. Quoting NVIDIA: "When persistence mode is enabled the NVIDIA driver remains loaded even when no active clients, such as X11 or nvidia-smi, exist. This minimizes the driver load latency associated with running dependent apps, such as CUDA programs" [09:47] infinity: funny thing, on some systems the GPU will lock up if persistence mode is disabled [09:48] (and it's disabled by default in the driver) [09:48] tseliot: Curious. I wonder if this was their answer to "we can't do KMS, due to taint, but we'll still stick around." [09:49] tseliot: I'll review that one in the morning, but as weird as it sounds, I don't see any reason to not let it in. I assume you'll be making the newer drivers depend on it? [09:50] infinity: yes, as soon as the package is in main/restricted. [09:50] in the meantime I'll correct the description [09:50] tseliot: main, looks like. It's GPL. If you intend to throw it at main, you might want to ask #security for a quick review too. [09:51] infinity: sure [09:51] and right, it's gpl [09:52] It's mostly MIT/Expat/X11ish, actually. Just a few GPL bits they cargo-culted that made the whole thing GPL. [09:52] I wonder if they changed their default free license. [09:52] And if so, why they didn't relicense their old code. [09:52] * infinity shrugs. [09:53] I should probably not expect NVIDIA to make sense. [09:53] Especially not at 4am. [09:56] hahaha [09:56] caffeine hasn't kicked in here yet either... [10:52] seb128: ^ [10:53] rsalveti, ^ ;-) [10:53] seb128: awesome, thanks! [10:54] rsalveti, thanks for the work you put in it, nice to see that finally in the archive ;-) [10:54] yeah, /me happy [10:55] seb128: thanks for the review btw [10:55] rsalveti: Aren't you supposed to be asleep? [10:55] infinity: I believe so [10:56] infinity, in fact that's not real, you are both asleep and dreaming that conversation [10:56] rsalveti, yw for the review ;-) have a good night! [10:56] Seems fair. === mmrazik is now known as mmrazik|lunch [11:20] seb128: last one for the day ^ :-) [11:21] seb128: this should be easier, if you want to help with another review [11:21] rsalveti, looking [11:21] seb128: gone for real now, will check your review in a few hours :-) [11:21] cya [11:21] rsalveti, night === mmrazik|lunch is now known as mmrazik [14:34] oops, bad override on libpackagekit-qt2-5/powerpc I suspect, sorry [14:34] will fix up later === mmrazik is now known as mmrazik|otp [14:57] seb128: thanks for accepting ofono-qt === mmrazik|otp is now known as mmrazik [15:11] rsalveti, yw [15:24] can I move kde 4.10.3 from raring-proposed to raring-updates? it's tested just nobody done the copying yet [15:33] Riddell: Fairly sure ScottK will get to it. [15:33] that doesn't answer my question :) [15:34] Riddell: (generally, we prefer that only people in ~ubuntu-sru release SRUs, hence the redirection to Scott) [15:35] ok suspected so === Ursinha is now known as Ursinha-afk === mmrazik is now known as mmrazik|afk === Ursinha-afk is now known as Ursinha === bjf[afk] is now known as bjf [17:27] * ogra would appreciate isf an archive admin could let ubuntu-touch-session in soon ... thats the last blocker for getting a working UI up on the flipped container images [17:40] cjwatson: you'd suggested ubuntu-sru or ubuntu-release for the phased updates overrides file. I'm inclined to use ubuntu-sru since I'm a member. Do you have a preference? [17:40] ogra, NEWed [17:41] ogra, happy to see that you used the current copyright format ;-) [17:43] Anyone know what the blue bug links signify @ http://people.canonical.com/~ubuntu-archive/pending-sru.html ? [17:43] adam_g: that it is a link [17:43] adam_g: that is the default color [17:43] bdmurray, heh. okay [17:45] seb128, hahaha, that was already there ... i fixed my last package already though === sergiuse1s is now known as sergiusens [18:08] bdmurray: My preference would be ubuntu-sru :) [18:08] cjwatson: okay, thanks === jokerdino_ is now known as jokerdino === NCommander is now known as Guest14386 === TheDrums is now known as Guest48798 === Guest14386 is now known as NCommander === tumbleweed_ is now known as tumbleweed === Daviey_ is now known as Daviey [18:49] why is kylin missing from http://people.canonical.com/~ubuntu-archive/germinate-output/ ? === mmrazik|afk is now known as mmraazik === mmraazik is now known as mmrazik === Ursinha is now known as Ursinha-afk === ochosi_ is now known as ochosi === Ursinha-afk is now known as Ursinha === doko_ is now known as doko === kees_ is now known as kees === SpamapS_ is now known as SpamapS === chuck_ is now known as zul === TheDrums_ is now known as TheDrums [20:27] jbicha: I believe it's because kylin uses a metapackage as a delta on top of Ubuntu desktop, not a seed [20:27] (assuming nothing's changed since I last looked) === Adri2000_ is now known as Adri2000 === Termana is now known as Guest49908 [20:32] slangasek: but doesn't Edubuntu do something like that too? === mapreri is now known as Guest67995 [20:33] jbicha: not exactly [20:34] edubuntu pulls in the Ubuntu and Kubuntu seeds (or metapackages?) but also has seeds in its own right; but kylin uses the ubuntu-defaults package infrastructure [20:34] because it's simpler and a better fit for their needs === cjwatson_ is now known as cjwatson [22:24] Riddell (and infinity): KDE SC 4.10.3 released to -updates. [22:43] ScottK: lovely thanks