[06:06] <didrocks> 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] <Mirv> didrocks: infinity should have it under radar, hopefully there's no obstacles for the reviews to happen this week
[06:13] <didrocks> ok, let's cross fingers :)
[07:02] <mlankhorst> ty
[08:14] <infinity> 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] <infinity> didrocks: s/won't/can't/
[08:15] <didrocks> infinity: yeah, that would be helpful, not sure how though
[08:17] <seb128> why would we loose files?
[08:18] <infinity> 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] <infinity> seb128: PPA history isn't forever, superseded uploads go away after a while.
[08:18] <seb128> oh, I see
[08:18] <infinity> seb128: And copies in the queue aren't actually copies, they're just pointers back to the original until they're accepted.
[08:18] <seb128> ok
[08:18] <didrocks> infinity: well, but we still want to know if the newest commits are building
[08:18] <didrocks> and not introducing regressions in the tests
[08:19] <seb128> well, if we take over a month to accept SRUs for you main desktop component we have another issue
[08:19] <seb128> for our main*
[08:19] <infinity> 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] <infinity> didrocks: And don't delete/supersede them until they're accepted (or until you want a new version instead).
[08:19] <didrocks> 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] <infinity> 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] <seb128> infinity, ppa copies should do an actual copy, it would give us a diff to review in the queue and persistance ;-)
[08:21] <infinity> 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] <didrocks> 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] <infinity> 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] <xnox> infinity: please demote boost1.49 to universe =)
[08:23] <infinity> xnox: Done.
[08:24] <xnox> infinity: thanks.
[08:24] <infinity> (And yay)
[08:25] <infinity> 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] <xnox> 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] <infinity> And by "collapse", you mean "remove the Ubuntu delta"?
[08:27] <xnox> infinity: well, checking if it can be synced.
[08:28] <infinity> xnox: I'm heading to bed, but poke me when you've done that, so I can remove the -mpi source package.
[08:28] <xnox> infinity: sure. thanks.
[08:38] <xnox> infinity: bug 1187299
[08:38] <ubot2> 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] <infinity> 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] <xnox> infinity: cool, thanks. Will remember the timing. (I guess if removed early the binaries will end up in the new queue again...)
[08:41] <infinity> xnox: Well, more to the point, it would render a bunch of stuff unbuildable/uninstallable.
[08:42] <xnox> =)
[09:01] <rsalveti> seb128: didrocks: any of you want to take it ^? :-)
[09:02] <seb128> rsalveti, \o/
[09:02] <seb128> rsalveti, I can have a look
[09:02] <didrocks> thanks rsalveti, seb128 :)
[09:02] <infinity> Why do I have a feeling that'll be a "fun" review, if one's thorough?
[09:02] <seb128> rsalveti, what are you doing up? did you work all night to get it uploaded?
[09:02] <rsalveti> 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] <seb128> ok
[09:02] <rsalveti> seb128: well, had to review copyright and fix a few other things :-)
[09:03] <rsalveti> don't want to be the blocker :-)
[09:03] <rsalveti> infinity: fun indeed :-)
[09:04] <rsalveti> 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] <didrocks> rsalveti: ok, and about ofono, apart from telepathy-ofono that we add ourself, anything else?
[09:05] <rsalveti> didrocks: guess that would be all, ofono-qt and telepathy-qt5 only, which will be available in a few
[09:05] <didrocks> rsalveti: perfect, it seems everything is arriving at the right and same time
[09:05] <didrocks> rsalveti: jibel and I are continuing deploying otto instead of UTAH
[09:05] <rsalveti> didrocks: right
[09:08] <rsalveti> infinity: don't you ever sleep as well?
[09:09] <infinity> rsalveti: No one waiting in bed for me.  What's your excuse, young man?
[09:10] <rsalveti> infinity: haha, just to get stuff done :-)
[09:11] <infinity> rsalveti: Well, your stuff is done.  Shoo.
[09:11] <rsalveti> infinity: :-)
[09:12] <rsalveti> seb128: the copyright file is a bit scary as well
[09:12] <rsalveti> tried my best to put everything in there
[09:12] <seb128> rsalveti, don't worry, after the qt5 stack I'm sure that one is going to be fine :p
[09:12] <rsalveti> haha, ok :-)
[09:13] <seb128> 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] <rsalveti> seb128: sure, np
[09:23] <rsalveti> seb128: 5 patches just got accepted: https://github.com/libhybris/libhybris/commits/master
[09:23] <infinity> rsalveti: Is upstream done being mad at us, then?
[09:24] <rsalveti> infinity: yup
[09:24] <infinity> \o/
[09:25] <tseliot> can an admin please approve nvidia-persistenced and nvidia-modprobe in saucy?
[09:26] <seb128> rsalveti, great ;-)
[09:27] <infinity> tseliot: nvidia-modprobe confuses me.  Doesn't the X driver do that automagically?
[09:27] <infinity> tseliot: Err, and persistenced claims to do the same thing...
[09:27] <infinity> I suspect one of those descriptions is a lie. :P
[09:30] <tseliot> infinity: oops, I forgot to update the description of nvidia-persistenced. I guess I used the same packaging scripts as a base
[09:31] <infinity> 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] <tseliot> 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] <infinity> 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] <tseliot> infinity: the daemon interface was generated by rpcgen. It doesn't say it will install its own version of rpcgen
[09:35] <infinity> tseliot: Oh, nevermind, I misread.  They're just saying they pregenerated the rpcgen output.
[09:35] <infinity> tseliot: Yeah. :P
[09:35] <tseliot> yep
[09:38] <tseliot> 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] <infinity> tseliot: Isn't this what udev is for?
[09:41] <tseliot> infinity: it's NVIDIA's distro agnostic way to do it. Shall I use udev instead?
[09:41] <infinity> distro-agnostic doesn't mean correct. :)
[09:42] <infinity> 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] <tseliot> heh
[09:46] <tseliot> 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] <tseliot> infinity: funny thing, on some systems the GPU will lock up if persistence mode is disabled
[09:48] <tseliot> (and it's disabled by default in the driver)
[09:48] <infinity> 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] <infinity> 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] <tseliot> infinity: yes, as soon as the package is in main/restricted.
[09:50] <tseliot> in the meantime I'll correct the description
[09:50] <infinity> 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] <tseliot> infinity: sure
[09:51] <tseliot> and right, it's gpl
[09:52] <infinity> It's mostly MIT/Expat/X11ish, actually.  Just a few GPL bits they cargo-culted that made the whole thing GPL.
[09:52] <infinity> I wonder if they changed their default free license.
[09:52] <infinity> And if so, why they didn't relicense their old code.
[09:52]  * infinity shrugs.
[09:53] <infinity> I should probably not expect NVIDIA to make sense.
[09:53] <infinity> Especially not at 4am.
[09:56] <tseliot> hahaha
[09:56] <tseliot> caffeine hasn't kicked in here yet either...
[10:52] <rsalveti> seb128: ^
[10:53] <seb128> rsalveti, ^ ;-)
[10:53] <rsalveti> seb128: awesome, thanks!
[10:54] <seb128> rsalveti, thanks for the work you put in it, nice to see that finally in the archive ;-)
[10:54] <rsalveti> yeah, /me happy
[10:55] <rsalveti> seb128: thanks for the review btw
[10:55] <infinity> rsalveti: Aren't you supposed to be asleep?
[10:55] <rsalveti> infinity: I believe so
[10:56] <seb128> infinity, in fact that's not real, you are both asleep and dreaming that conversation
[10:56] <seb128> rsalveti, yw for the review ;-) have a good night!
[10:56] <infinity> Seems fair.
[11:20] <rsalveti> seb128: last one for the day ^ :-)
[11:21] <rsalveti> seb128: this should be easier, if you want to help with another review
[11:21] <seb128> rsalveti, looking
[11:21] <rsalveti> seb128: gone for real now, will check your review in a few hours :-)
[11:21] <rsalveti> cya
[11:21] <seb128> rsalveti, night
[14:34] <cjwatson> oops, bad override on libpackagekit-qt2-5/powerpc I suspect, sorry
[14:34] <cjwatson> will fix up later
[14:57] <rsalveti> seb128: thanks for accepting ofono-qt
[15:11] <seb128> rsalveti, yw
[15:24] <Riddell> can I move kde 4.10.3 from raring-proposed to raring-updates?  it's tested just nobody done the copying yet
[15:33] <infinity> Riddell: Fairly sure ScottK will get to it.
[15:33] <Riddell> that doesn't answer my question :)
[15:34] <infinity> Riddell: (generally, we prefer that only people in ~ubuntu-sru release SRUs, hence the redirection to Scott)
[15:35] <Riddell> ok suspected so
[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] <bdmurray> 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] <seb128> ogra, NEWed
[17:41] <seb128> ogra, happy to see that you used the current copyright format ;-)
[17:43] <adam_g> Anyone know what the blue bug links signify @ http://people.canonical.com/~ubuntu-archive/pending-sru.html ?
[17:43] <bdmurray> adam_g: that it is a link
[17:43] <bdmurray> adam_g: that is the default color
[17:43] <adam_g> bdmurray, heh. okay
[17:45] <ogra> seb128, hahaha, that was already there ... i fixed my last package already though
[18:08] <cjwatson> bdmurray: My preference would be ubuntu-sru :)
[18:08] <bdmurray> cjwatson: okay, thanks
[18:49] <jbicha> why is kylin missing from http://people.canonical.com/~ubuntu-archive/germinate-output/ ?
[20:27] <slangasek> jbicha: I believe it's because kylin uses a metapackage as a delta on top of Ubuntu desktop, not a seed
[20:27] <slangasek> (assuming nothing's changed since I last looked)
[20:32] <jbicha> slangasek: but doesn't Edubuntu do something like that too?
[20:33] <slangasek> jbicha: not exactly
[20:34] <slangasek> 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] <slangasek> because it's simpler and a better fit for their needs
[22:24] <ScottK> Riddell (and infinity): KDE SC 4.10.3 released to -updates.
[22:43] <Riddell> ScottK: lovely thanks