[00:00]  * ScottK ^^^
[00:01] <ScottK> That was me.
[00:01] <cjwatson> cool, was waiting for that
[00:02] <cjwatson> glib2.0 looks OK for precise; last call for objections before I copy
[00:24] <ScottK> ^^^ There was already a sync in queue, so the direct upload was unnecessary.
[00:54] <cjwatson> copied glib2.0 to precise
[00:55]  * ScottK reviewed apport
[01:01] <slangasek> partman-auto accepted
[01:09] <micahg> do I need an FFe to switch from python-gobject to python-gi?
[01:24] <ScottK> ^^^ was me.
[01:29] <ScottK> infinity: It might not be a bad time to start to rebalance back towards armel from armhf.
[01:56] <micahg> ScottK: do I need an FFe for the python-gi conversion?
[01:56] <ScottK> Dunno.
[01:57] <ScottK> I'd say do whatever you need to do and I'll sprinkle holy water on it as needed.
[01:57] <ScottK> Don't screw up.
[02:50] <infinity> The nux upload I just sponsored for rsalveti is necessary to make all the work done for compiz/unity GLES support on ARM not be a complete waste of time.
[02:50] <infinity> If someone who isn't me wants to poke it and let it in, since I sponsored it.
[02:51] <rsalveti> that will finally allow (once the compiz changes are in place by ogra_) to have a working unity 3d experience on ARM
[02:51] <rsalveti> infinity: thanks for the upload btw
[02:58] <infinity> rsalveti: "once the compiz changes are in place"?  Is 1:<IP_ADDRESS>-0ubuntu3 still not good enough?
[02:58] <rsalveti> infinity: iirc ogra_ was updating compiz-plugins-main
[02:59] <rsalveti> and I remember he was also fighting with a newer upstream update/rebase
[02:59] <rsalveti> so not yet sure if current compiz version will be the one used at the release
[03:00] <infinity> I should hope so.
[03:00] <rsalveti> or if it might just be something for -updates
[03:00] <infinity> Final freeze is tomorrow. :P
[03:00] <rsalveti> yeah, then we should be good :-)
[03:11] <jdstrand> can someone approve that ^
[03:11] <jdstrand> it fixes bug #978297 (and by extension bug #978147)
[03:11] <ubot2> Launchpad bug 978297 in apparmor "apparmor should quietly return success in a container" [High,In progress] https://launchpad.net/bugs/978297
[03:11] <ubot2> Launchpad bug 978147 in lxc "rsyslogd fails to start in cloud template " [High,Confirmed] https://launchpad.net/bugs/978147
[03:12] <jdstrand> so my comment in 978297 on testing performed. it is a simple patch
[03:14] <jdstrand> s/so my/see me/
[03:14] <jdstrand> meh
[03:14] <jdstrand> see my
[03:20] <skaet> jdstrand,  looks reasonable.  Thanks for getting the fix in.   approved.
[03:21] <jdstrand> \o/
[03:21] <jdstrand> skaet: thanks
[03:22] <skaet> jdstrand,  is there an outlook on bug 969299?
[03:22] <ubot2> Launchpad bug 969299 in apparmor "apparmor prevents dpkg-divert and localedef from working in a container" [Critical,Confirmed] https://launchpad.net/bugs/969299
[03:23] <jdstrand> skaet: fyi, I will be sponsoring an upload for sbeattie for apparmor
[03:23] <jdstrand> skaet: he will be able to answer questions on the bugs, but he'll contact you
[03:23] <jdstrand> skaet: let me look
[03:24] <skaet> thanks jdstrand.    could you please add the rls-p-tracking tag to it, if appropriate.
[03:24] <jdstrand> skaet: to which, 969299?
[03:25] <jdstrand> skaet: I think the workaround in lxc is what we will go with for precise. jjohansen was looking at this-- he should comment
[03:26] <jjohansen> jdstrand, skaet: right basically the two patches serge came up with, that disables apparmor load scripts inside the container
[03:26] <jjohansen> since apparmor does not support loading policy in the container for precise this is the cleanest solution
[03:26] <jdstrand> jjohansen: this is the mediate_deleted bug
[03:27] <jjohansen> no
[03:27] <jdstrand> (969299)
[03:27] <jdstrand> yes :)
[03:27] <jdstrand> jjohansen: not talking about upstart. skaet asked about 969299 separately
[03:28] <skaet> jdstrand, jjohansen,  understanding if we'll be fixing this or not, is what I'm trying to understand.  :)
[03:28] <jjohansen> jdstrand: err, which bug did you want me to comment on? ah
[03:28] <jdstrand> jjohansen: 969299/970647
[03:28] <skaet> 969299
[03:28] <jjohansen> skaet: no. The lxc adding the mediate_deleted flag to the profile is the work around for precise.
[03:28] <jjohansen> so the lxc work around
[03:29] <skaet> jjohansen, ok, can the bug milestone and priority for upstart be updated then to reflect this?
[03:29] <jjohansen> jdstrand: I am still trying to figure out bug#970647
[03:29] <skaet> Right now its critical,  which catches my attention ;)
[03:30] <jjohansen> I expect to sru it, but it isn't release critical, it can make figuring failures tricky but does not cause failures
[03:30] <infinity> s/upstart/apparmor/
[03:30] <skaet> fair nuf,  milestone target should be precise-updates then.   Importance shouldn't be critical.
[03:31] <jjohansen> skaet: bug#970647 isn't marked critical, 969299 is but we can not do anything more than the workaround lxc is using for precise
[03:31] <skaet> for 969299.  :)
[03:31] <jdstrand> infinity: the upstart bug is dealt with. we are talking about a different bug
[03:31] <jdstrand> I'm going to mark the 969299 as wontfix for apparmor
[03:32] <infinity> jdstrand: Yes, I know.  Hence the correction to someone mentioning milestone and priority for an upstart bug. :P
[03:32] <jdstrand> we can sru 970647
[03:32] <jjohansen> jdstrand: yes please
[03:32] <jjohansen> jdstrand: I think we should be able to
[03:32] <jdstrand> infinity: ah, read that the other way around
[03:32] <jjohansen> it will be a kernel patch, and it will be something pushed upstream too
[03:33] <infinity> jdstrand: Your sed runs backwards? ;)
[03:34] <jdstrand> infinity: more that I read confusion in general and assumed you were confused too. I apologize
[03:34] <infinity> ;)
[03:34] <jdstrand> skaet: 969299 should fall off your list now
[03:34] <skaet> :)
[03:34] <infinity> rsalveti: Say, speaking of sponsored uploads, whatever happened to xbmc?
[03:34] <skaet> thanks jdstrand, jjohansen.
[03:35] <rsalveti> infinity: pull request sent to upstream by the debian maintainer, avik is working on getting the new patch set/debdiff tomorrow
[03:35] <infinity> Mmkay.
[03:36] <rsalveti> superm1 also knows the current status of that, hopefully we'll get it sorted over the next few days
[03:36] <rsalveti> might be still good to get as sru
[03:36] <infinity> rsalveti: Sure, it's unseeded universe, so there's a bit of wiggle room.  I'd *prefer* not to enable new arches as an SRU, but there's no technical reason we can't.
[03:37] <rsalveti> yeah, should know better tomorrow, once avik updates the merge proposal
[03:37] <rsalveti> will keep you updated
[03:37] <infinity> Danke.
[03:42]  * ScottK looks at nux
[03:43] <ScottK> infinity: I'd appreciate it if you'd look at strigi.  It's a trivial diff.
[03:44] <infinity> ScottK: I was waiting on an appserver to feed me a diff, cause I'm lazy. ;)
[03:44] <infinity> ScottK: But I intend to look through the whole queue tonight, I'm up for a while working.
[03:44] <ScottK> OK.  Thanks.
[03:44] <ScottK> Strigi was uploaded 5 hours ago.  If you don't have a diff by now, I don't think you'll get it.
[03:45] <infinity> Yeah.  I'm getting that impression. :P
[03:45]  * infinity grabs the source.
[03:45] <ScottK> In any case, nux is in.
[03:45] <infinity> Thanks.
[03:46] <ScottK> Part of the reason I want to get strigi in is that the previous upload isn't built on armel and powerpc yet, so if it can get in, it'll save doing it twice on the slow archs.
[03:46] <infinity> Heh.
[03:46] <infinity> Uhm.
[03:47] <infinity> Maybe I'm just going cross-eyes, but this looks like the same symbol is being listed twice.
[03:47] <infinity> Oh, no.  I'm just going cross-eyed.
[03:47] <infinity> But.
[03:47] <infinity> (optional=templinst|arch=i386 powerpc)_ZN10QDBusReplyI5QListI5QPairIb7QStringEEEC2ERK12QDBusMessage@Base 0.7.7
[03:47] <infinity> ^-- Doesn't that nees the same s/i386 powerpc/!armel !armhf/ treatment?
[03:47] <infinity> need, too.
[03:48] <infinity> I can't type tonight, apparently.
[03:49] <infinity> ScottK: I'm happy to be proven wrong, but the diff looks a bit suspect.
[03:50] <ScottK> It should change from i386 powerpc to !armel !armhf (i.e. add amd64)
[03:50] <infinity> ScottK: Yes, but it doesn't. :P
[03:50] <infinity> ScottK: (My point is that that construct is in two symbols in a row, the diff only changes one of those)
[03:51] <ScottK> Looking
[03:51] <jdstrand> skaet: btw, what is the final freeze deadline? I know it is tomorrow, but what hour?
[03:52] <infinity> My bet's 2100UTC, people seem fond of that hour.
[03:52] <skaet> 2100 UTC
[03:52] <ScottK> They aren't the same.
[03:52] <infinity> ScottK: No, I know they're not the same symbol.
[03:52] <ScottK> OK.
[03:52] <ScottK> Only one of them came up in the build log with a change.
[03:52] <jdstrand> infinity: they are fond of that, aren't they? :)
[03:52] <jdstrand> skaet: thanks
[03:53] <infinity> ScottK: I'm questioning that two nearly identically-named symbols are represented on a strange venn diagram of arches.
[03:53] <skaet> infinity,  yup,  that gives enough time for builds to complete before the overnight build, and catch in the work day, without lots of requests for extensions.
[03:53] <infinity> ScottK: But I guess we can let it in and see. :P
[03:53] <ScottK> infinity: No, you're right.
[03:54] <ScottK> infinity: Please reject and I'll upload again.
[03:56] <ScottK> I can't tell you how many times I looked at that.  Thanks for a careful check.
[03:56] <ScottK> Re-uploaded.
[03:56] <infinity> symbols files hurt my head too, don't feel bad.
[03:56] <infinity> Especially since I always stupidly edit them by hand.
[03:57] <slangasek> cf. Russ's recent indictment of symbols files for C++ libs on debian-devel
[03:58] <infinity> slangasek: Define recent?
[03:58] <slangasek> last three months
[03:58] <RAOF> Longish thread; ‘Do symbols make sense for C++’
[03:59] <slangasek> http://lists.debian.org/debian-devel/2012/01/msg00671.html
[03:59] <slangasek> rather, http://lists.debian.org/debian-devel/2012/01/msg00727.html
[04:02] <infinity> ScottK: Looks gooder.
[04:02] <ScottK> Great.
[04:02] <ScottK> infinity: I did edit that one by hand too.
[04:03] <infinity> And I reviewed by eye.
[04:03] <infinity> Software be damned.
[04:03] <slangasek> I use gimp for diffing
[04:03]  * infinity mails magnets to London and marks the envelope "eglibc upload".
[04:04] <infinity> But first, to Subway to fuel my evening.
[04:28]  * ScottK took care of ^^^
[04:43] <micahg> do flavors need UIFe's for their own packages?
[05:00] <pitti> micahg: that's somewhat underspecified; but I'd say, it depends on the leads of that derivative being okay with it
[05:00] <micahg> pitti: he made the commit ;), should I just remind them to update their docs as necessary?
[05:01] <pitti> at some point we just need to update https://wiki.ubuntu.com/UserInterfaceFreeze
[05:47] <didrocks> grrrrr at linaro again for not using the vcs…
[05:47] <didrocks> 3 times in less than a week,
[05:49] <cjwatson> ^- ubiquity - giant diff, but mostly d-i stuff that's been approved already
[05:49] <pitti> cjwatson: will wait a bit to get a diff, then review
[05:49] <infinity> didrocks: Oh, for nux?
[05:50] <didrocks> infinity: yeah, no coordination with us, and of course, the ppa for unity 5.10 release is now not working at all
[05:50] <infinity> didrocks: How did it break your PPA?
[05:50] <didrocks> infinity: well, newer version with a version incompatible for the ABI…
[05:50] <infinity> didrocks: (You can probably blame me for not committing to your branch, though... I can clean that up now)
[05:51] <didrocks> infinity: I'm doing that, I'll then apt-get source from the ppa and copy the changes over
[05:51] <infinity> Oh, you're already fixing it up?  Kay.  Sorry for the noise.
[05:52] <pitti> didrocks: does that mean we'll need another full round of PPA builds and testing? Or can that happen in -proposed?
[05:52] <didrocks> infinity: no worry, but between that and compiz/compiz-plugins-main on Friday, I'm tired of fixing linaro's breaking the ppa :)
[05:53] <didrocks> pitti: no, the switch is only building on armel, but I doubt of how the change good is, knowing that unity has no support for opengles
[05:53] <infinity> It works fine, AFAIK.
[05:53] <pitti> didrocks: if that's causing too much trouble, we could also just revert the nux upload
[05:53] <infinity> That was the whole drive for the compiz and nux changes.
[05:54] <didrocks> infinity: it doesn't apparently, they have a huge branch that is under review upstream
[05:54] <didrocks> infinity: so I doubt it's working :)
[05:54] <cjwatson> urgh, forgot to bump installer seed to 3.2.0-23
[05:54] <slangasek> "under review upstream"> should've landed last week?
[05:54] <slangasek> (in Ubuntu)
[05:54] <cjwatson> done, but it's possible jenkins will hate us and require alternate/server respins, depending on exactly how it works out
[05:54] <infinity> didrocks: The backported stuff in Ubuntu works.
[05:54] <didrocks> slangasek: no, we told them that we take compiz and compiz-plugins-main this cycle, but not nux nor unity
[05:54] <didrocks> slangasek: as it was too late
[05:54] <slangasek> ah
[05:55] <didrocks> ok Vcs fixed, now fixing the ppa
[05:59] <didrocks> infinity: so if they come with a bug unity patch for opengles, please ping me first ;)
[05:59] <didrocks> (all fixed now, let's wait for newer testing)
[05:59] <infinity> didrocks: Check.
[06:00] <infinity> didrocks: This one wasn't particularly intrusive, and there were claims it actually made things work.
[06:00] <didrocks> infinity: yeah, this one is fine, it's just a pity that it screwed the ppa for a while, but fortunatly, the upload was recent
[06:01] <RAOF> Hm.  How come this https://launchpad.net/ubuntu/+source/mysql-dfsg-5.1/5.1.62-0ubuntu<IP_ADDRESS> mysql-dfsg-5.1 update has ended up in -proposed, not -updates or -security?
[06:02] <infinity> RAOF: You'd have to ask the security team, I imagine.
[06:03]  * cjwatson -> Millbank
[06:04] <micahg> RAOF: it needs more testing
[06:04] <micahg> RAOF: https://lists.ubuntu.com/archives/ubuntu-devel/2012-April/035035.html
[06:05] <RAOF> micahg: Ta.
[06:31] <astraljava> Anyone from the release team able to look at three bugs with debdiffs on them? I understand they'd need to get in today before final freeze. Or is this the wrong place to ask?
[06:32] <infinity> This is the right place.
[06:32] <infinity> Are they large changes?
[06:32] <astraljava> Thank you. Bugs are: bug #972749, bug #972781 and bug #973373
[06:32] <ubot2> Launchpad bug 972749 in indicator-sound "Prefer pavucontrol over xfce4-mixer in ubuntustudio session" [Undecided,Fix committed] https://launchpad.net/bugs/972749
[06:32] <ubot2> Launchpad bug 972781 in xfce4-volumed "Prefer PulseAudio when XF86AudioMute is used for ubuntustudio session" [Undecided,Fix committed] https://launchpad.net/bugs/972781
[06:32] <ubot2> Launchpad bug 973373 in ubuntustudio-meta "package ubuntustudio-audio 0.90 failed to install/upgrade: subprocess new pre-installation script returned error exit status 1" [Undecided,Confirmed] https://launchpad.net/bugs/973373
[06:33] <astraljava> infinity: No, quite trivial each.
[06:34] <micahg> astraljava: you should've caught infinity when he was piloting earlier
[06:35] <infinity> Indeed.
[06:35] <infinity> But, as it turns out, I'm still capable of doing all the same things. :P
[06:35] <astraljava> Oh? Why's that?
[06:35] <infinity> Now, that said.  Reading just the bug titles, while the patches may be trivial, the changes aren't.
[06:36] <astraljava> infinity: Right, anything particular you want to talk about, or are you rejecting some|all of them off-hand?
[06:38] <infinity> astraljava: I haven't had a chance to actually look at the diffs or think about impact, I'll get back to you.
[06:38] <infinity> astraljava: But things like changing default mixer applets and whatnot are pretty major changes, even if it's a 1-line code change. :P
[06:39] <astraljava> infinity: Sure, I get that. I'll be around if you want to have a chat. :)
[07:26] <pitti> ^ review appreciated (I uploaded)
[07:26]  * pitti reviews the other queue items
[07:28] <didrocks> so starting to push the whole unity stack (we will maybe have a bamf release a little bit later) including compiz and c-p-m. There is no ABI break for those, so I can push them directly
[07:28] <didrocks> then, for nux/unity/unity-2d I will use -proposed once the release is ready
[07:31] <infinity> pitti: Looking.
[07:34] <infinity> pitti: Accepted.
[07:42] <pitti> infinity: thanks
[07:47] <micahg> pitti: can you give back the g* failures here: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20120328-precise.html#ubuntustudio
[07:48] <pitti> micahg: what do you mean with "give back"? they all built fine
[07:49] <pitti> oh, I suppose the test rebuilds, yes
[07:49] <micahg> pitti: huh? they failed in the rebuild
[07:49] <pitti> I tried the archive
[07:49] <micahg> no, rebuild :), I can do archive give backs
[07:49]  * infinity does it.
[07:49] <pitti> micahg: done
[07:50] <pitti> infinity: ^
[07:50] <micahg> thanks
[07:50] <infinity> Or, pitti will beat me to it. :P
[07:50] <micahg> still not sure what to do with the goffice rebuild failure, will have to think about it over the weekend
[07:50]  * micahg delegates
[07:52] <infinity> micahg: If our PCRE is UTF-8 clean, just patch that test out of goffice's configure?
[07:52] <micahg> infinity: that's one option :)
[07:52] <micahg> the weird thing is that it works in Debian
[07:53] <micahg> and Debian doesn't have the test binary either, so I figure I'm missing something
[07:53] <infinity> micahg: Really?
[07:53] <infinity> micahg: That is weird...
[07:54] <micahg> and it built the first time when the binary didn't exist either
[07:54] <infinity> Well, maybe you're misreading the test, and it doesn't require pcretest at all?
[07:54] <infinity> And maybe we really do have an issue the test is tripping on?
[07:55] <infinity> That check is pretty straightforward, though...
[07:57] <micahg> infinity: this is ugly, it's conditional on other tests failing which is probably why it works in Debian and worked in Oneiric
[07:57] <infinity> micahg: Yeah, I'm seeing that the Debian buildds don't even run the pcre tests...
[07:58] <micahg> neither did the oneiric build
[07:58] <infinity> (Does that mean they also don't end up linking pcre?)
[07:58] <infinity> That sounds like a bug.
[07:58] <infinity> Oh, I see, it wants pcre iff some glib feature isn't there.
[07:59] <micahg> yeah, not linked against pcre in Debian or Oneiric
[07:59]  * micahg thinks we should switch channels
[07:59] <infinity> So, the question is why does glib no longer have that feature?
[08:07] <stgraber> skaet: We just found a critical bug in LTSP (ldm actually), caused by a typo in one of the scripts ending up breaking the environment of the thin client session. Fix has been commited upstream and we're expecting a bugfix release to land in Debian later today/tomorrow which we'll then sync in Ubuntu
[08:08] <stgraber> skaet: so won't make it before final freeze but should be there shortly after. The fix is a trivial one liner.
[08:15] <micahg> infinity: please give back goffice in the rebuild (or someone else)
[08:16] <stgraber> micahg: looking at it
[08:17] <stgraber> micahg: done
[08:17] <stgraber> micahg: do you need the rebuild result quickly?
[08:17] <micahg> stgraber: no, just not to show up (it should be fine now) as it's on the xubuntu and lubuntu ISOs
[08:17] <stgraber> k
[08:32] <doko> wie baue ich die treiber nochmal manuell?
[08:36] <didrocks> slangasek: the gnome-session upload is just for you ^ ;)
[08:44] <Riddell> so it seems KDE .pot translation templates haven't been generated for the whole of the cycle
[08:44] <Riddell> this means we are missing lots of strings
[08:44] <Riddell> to fix it I need to do a mass upload of everything KDE
[08:45] <Riddell> and then a mass upload of all the language packs
[08:45] <Riddell> any problems?  (besides taking up the build daemons for ages)
[08:45] <seb128> Riddell, why do you need uploads? you can upload the pot directly to launchpad without a source upload
[08:46] <Riddell> hmm
[08:46] <seb128> Riddell, https://translations.launchpad.net/ubuntu/precise/+source/YOURSOURCE/+pots/YOURSOURCE/+upload
[08:47] <Riddell> that's a million clicks rather than just scripting it
[08:47] <Riddell> I'm asking dpm if it's possible in an easier way
[08:48] <seb128> Riddell, well it's easier a million clicks or a millions builds and updates throwing at the archive,buildds,users
[08:48] <seb128> easier->either
[08:51] <Riddell> seb128: automated work >> manual work
[08:52] <seb128> Riddell, annoyance for thousand of users >> annoyance for 1 devel
[08:53] <seb128> Riddell, throwing ton of updates has a cost on buildd time, download time for users, etc
[08:53] <Riddell> that's the price of using a development version
[08:53] <micahg> bandwidth for everyone...
[08:53] <seb128> Riddell, that devel is pre release frozen though
[08:53] <infinity> Riddell: I'd rather not rebuild all of KDE if there's no actual sane reason.
[08:54] <Riddell> infinity: translations are a sane reason
[08:54] <seb128> Riddell, I would consider now is a time where you should rather script the pot upload to launchpad that abuse users and buildds
[08:54] <infinity> Riddell: But, by your own admission, the rebuilds are just to get them into rosetta, and into langpacks.
[08:54] <seb128> Riddell, you don't need source uploads for updating the templates
[08:54] <Riddell> seb128: it can't be scripted
[08:55] <Riddell> seb128: there is no other sane way to update the templates
[08:55] <seb128> Riddell, it can easily be scripted to call $webbrowser $uri for you and be one click by pot
[08:55] <seb128> it's like an half an hour job
[08:56] <seb128> Riddell, just get the list of source, iterate the url I gave you before replace YOURSOURCE by the template name
[08:56] <Riddell> < dpm> it would take me a whole day to manually upload them into Launchpad
[08:56] <seb128> how many sources,templates are we talking about?
[08:57] <seb128> come on, iterating over your sources list with a script calling https://translations.launchpad.net/ubuntu/precise/+source/YOURSOURCE/+pots/YOURSOURCE/+upload
[08:57] <seb128> and doing 2 clicks
[08:57] <Riddell> 50-150 sources, 100-1000 templates?
[08:57] <seb128> if you do it for 100 sources it's less than an hour
[08:57] <Riddell> no it's a lot more than an hour
[08:57] <seb128> it takes you more than a minute to click 2 buttons?
[08:57] <dpm> there are a *lot* of templates
[08:57] <seb128> like pick the file, click the "upload" button
[08:58] <dpm> Riddell, seb128, I've actually got a script to do uploads, but I haven't been using it in a while and so it remains untested. But perhaps we could use it: http://bazaar.launchpad.net/~dpm/ubuntu-l10n-tools/trunk/view/head:/ubuntu_l10n_tools/lp_l10n_upload/__init__.py
[08:58] <dpm> it's part of the ubuntu-l10n-tools PPA
[08:58] <seb128> well not my call, but I think throwing 150 KDE builds to the builders and to users on hard freeze day is not 0 cost either
[08:59] <seb128> it might take a week for the armel builders to catch up
[08:59] <Riddell> dpm: able to test it?
[09:00] <dpm> Riddell, sure, but even if it works, I'll need some help with the list of templates/source packages. Do you have a source package with a single template I could test it against?
[09:01] <bulldog98> dpm: rekonq?
[09:02] <dpm> Riddell, bulldog98, if you tell me the source package (I assume it's rekonq) and give me an up-to-date .pot file, I can test it straight away
[09:03]  * Riddell grabs
[09:03] <Riddell> dpm: http://people.canonical.com/~jriddell/tmp/rekonq.pot
[09:04] <Riddell> source: rekonq
[09:07] <dpm> Riddell, ok, thanks, give me a few minutes to see if the uploader script still works and can be used
[09:08] <stgraber> argh ... I specifically poked the ubiquity slideshow guy about getting UIFe before doing any slideshow change... and now that I'm ready to do a translation upload I see they changed a bunch of screenshots without documentation
[09:08] <Riddell> stgraber: just reject them?
[09:11] <stgraber> Riddell: well, I'm the one uploading the package ;) so I need to go through the changes extract the actual bugfixes, revert the rest, then merge the translations and upload
[09:11] <stgraber> so quite a bit more than the 2 minutes I was hoping for it to take
[09:14] <Riddell> yes manual operations are no fun to do
[09:17] <pitti> infinity, stgraber, Riddell: I left a blurb about the gnome-session upload in https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/771896/comments/27, FTR
[09:17] <ubot2> Launchpad bug 771896 in gnome-session "No way to save current session" [Low,Triaged]
[09:20] <pitti> I also reviewed pkg-kde-tools, please don't accept yet
[09:20] <pitti> (see pad)
[09:22] <Riddell> pitti: right enough, rejecting pkg-kde-tools
[09:23] <pitti> Riddell: cheers
[09:24] <infinity> pitti: Yeah, I'm not really sure how anyone would even inject that variable into the environment.  Well, any "normal" user who doesn't understand how X/dm/session startup works.
[09:25] <pitti> didrocks: ah, you're back
[09:25] <pitti> didrocks: FYI, I left a comment in bug 771896
[09:25] <ubot2> Launchpad bug 771896 in gnome-session "No way to save current session" [Low,Triaged] https://launchpad.net/bugs/771896
[09:25] <didrocks> pitti: yeah, I was logging out/in to test the plumbings
[09:25] <infinity> What was so wrong with have a UI tickbox that's off by default and warns against use?
[09:25] <didrocks> pitti: looking
[09:25] <infinity> So the "power users" can break what they like?
[09:26] <pitti> session saving has never really worked the way it is implemented in g-session
[09:26] <infinity> Yeah, it's never worked well, and I don't use it.
[09:26] <pitti> it's spelled s-u-s-p-e-n-d
[09:26] <infinity> But clearly, lots of people prefer a broken solution to no solution.
[09:26] <didrocks> pitti: well, we discused it at UDS
[09:26] <didrocks> pitti: slangasek made a session at the last minute for it and was fine with a hidden way to get it back for people wanting it
[09:26] <pitti> and this causes so many weird bugs that we should just declare this broken and bury it for good IMHO
[09:27] <infinity> pitti: To be fair, without ksplice, and with our 2-week kernel update schedule, suspend isn't a great option to many either. :)
[09:27] <pitti> but *shrug*, as I said I won't veto it, but that env var approach seems rather undiscoverable
[09:27] <RAOF> Do people *actually* prefer a broken solution, or do they *say* they'd prefer a broken solution? :)
[09:27] <infinity> RAOF: I dunno, have you read the bug log?
[09:27] <infinity> RAOF: There are a ton of people who talk about how awesome GNOME session saving was before we took it away.
[09:27] <RAOF> Yes, but not recently.
[09:28] <infinity> And, since I know it was always crap.
[09:28] <infinity> They must like crap.
[09:28] <infinity> The end.
[09:28] <didrocks> pitti: well, I don't mind, it's not for me and I don't use it. slangasek was pretty willing to have a way to get it back and we really don't want to expose as it's completely broken if you switch between session for instance
[09:28] <seb128> what didrocks said
[09:28] <infinity> didrocks: I think the environment thing is a bit of a joke, TBH.  It's going to lead to weird forum HOWTOs on editing dm startup files in perverse ways that people will follow without knowing what they're doing.
[09:29] <seb128> slangasek find the current gnome-session saving good enough that's it's make him spare time and be useful so he asked for a way to be able to turn it back on
[09:29] <infinity> didrocks: If we're going to let them do it, just let them do it.
[09:29] <didrocks> infinity: so, let's push it back. I did what was planned at UDS, that's all ;)
[09:29] <seb128> yeah, that no option, too bad for Steve ;-)
[09:30] <seb128> that->then
[09:30] <infinity> I'm just saying that a mystery environment key isn't exactly an option. :)
[09:30] <didrocks> infinity: what do you propose then?
[09:30] <infinity> didrocks: Like I said, restore the tickbox to the UI, and add a "don't use this" warning?
[09:31] <seb128> infinity, it's a secret "make slangasek happy" option :p
[09:31] <seb128> infinity, we could change it by an username check :p
[09:31] <didrocks> infinity: hum, not really, people will still use it without knowing and we will have even more people getting a broken state
[09:31] <infinity> seb128: And a ton of people in the forums, apparently.  And following up to that bug.  And...
[09:31] <infinity> didrocks: They'll use it anyway.
[09:31] <didrocks> less user will use an env variable that the option I guess ;)
[09:32] <infinity> didrocks: Look at the number of people who muck around to turn off global menus.
[09:32] <infinity> didrocks: And the odds that even 2% of them know what they're doing in those conffiles seems slim.
[09:32] <didrocks> but again, I don't care and don't have time to argue over it, I just did what we planned, reject if you want ;) now on unity
[09:32]  * infinity shrugs.
[09:32] <infinity> I'm passing on it, pitti's a desktop guy. :P
[09:32] <infinity> Or, he can make vorlon have the final say.
[09:33] <pitti> didrocks: as I said, I'm not vetoing it, I just question how useful it is
[09:33] <infinity> I don't use GNOME session saving anyway, so it's moot for me, I'm just trying to figure out the best way to solve things for people who think it's "good enough".
[09:33] <infinity> (Telling them they're wrong, while a GNOMEish answer, probably isn't helpful)
[09:34] <didrocks> I really don't have the time to argue over it. I'll just have the filling I didn't promess something and didn't try to do it :)
[09:34] <didrocks> feeling*
[09:35] <seb128> infinity, slangasek's point is that the session saving is "good enough" that he spares him 5 minutes or reopening and replacing windows on screen when he needs to restart
[09:35] <infinity> seb128: Yes, and lots of others agree.
[09:35] <seb128> so he really wanted a way to opt in for users who really want
[09:35] <infinity> seb128: (cf: the bug, and forum threads)
[09:36] <infinity> seb128: I'm saying that a magical environment key isn't really helpful to any but the most technical users (or people who routinely copy and paste from random forum threads)
[09:36] <seb128> we wouldn't give him an ui option though because we consider we shouldn't offer ui option for things we don't consider working well enough to be at that level
[09:36] <seb128> well, at least if you deal with environment option we can claim you did stuff in an hackish way non supported
[09:36] <infinity> seb128: If you can prove that the subset of "people who like the crappy session support" mostly overlaps with the set of "very technical people", then maybe it's a non-issue.
[09:37] <seb128> when it's us who provide a checkbox we have an harder time to bail out
[09:37] <micahg> ^^ pfb2t1c2pfb - debs match, drops dpatch in favor of source format 3.0
[09:37] <infinity> That's the worst source package name ever...
[09:40] <pitti> is that in base64 or something?
[09:42] <micahg> pfb2t1c2pfb: convert pfb into more compressible format and back
[09:42] <cjwatson> pfb to t1c to pfb
[09:42] <infinity> Yeah, I can read the 2s.
[09:42] <stgraber> uploaded ubiquity-slideshow-ubuntu, good luck to whoever reviews it... it took me md5sums to confirm the changes in the upstream branch were sane (for these I didn't revert)
[09:42] <infinity> It's still an awful name. :P
[09:42] <cjwatson> golang: that's for bug 979390
[09:42] <ubot2> Launchpad bug 979390 in golang "[FFe] Update golang to 2:1-3 in Precise" [Undecided,New] https://launchpad.net/bugs/979390
[09:43] <cjwatson> (not actually FFe, as ScottK said)
[09:43] <ogra> someone should tell the maintainer that in dh_make -p the -p doesnt stand for password but for packagename :P
[09:54] <ara> pitti, rickspencer3: have we made any decisions about whether we are going to recommend i386 or amd64 in the ubuntu.com/download page for Ubuntu Desktop?
[09:55] <infinity> Didn't we have a bunch of sessions and a spec about switching to amd64 as the recommended default?
[09:56] <didrocks> pitti: infinity: cjwatson: so all unity plumbings now uploaded (with libgnomedesktop3). What remains is nux/unity/unity-2d (and gnome-control-center for the hud configuration depending on unity-2d). So I'm just waiting a little bit to see if we can sneak a focus fix in unity first. Anyway, all this will be uploaded to -proposed
[09:56] <pitti> ara: I'm not aware of an official decision
[09:56] <cjwatson> we had a session about that, whose work items mostly haven't been done
[09:56] <pitti> FWIW, I've run amd64 since hoary
[09:57] <cjwatson> so I think status quo wins
[09:57] <ara> :)
[09:57] <cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-64bit-by-default
[09:58] <infinity> Oh, yeah.
[09:58] <infinity> None of that's solved.
[09:58] <infinity> Cross-grades?  Really?
[09:58] <infinity> That was an ambitious session.  I'm glad I didn't go :)
[09:58] <pitti> didrocks: ok, I guess the lenses etc. are not API sensitive and can go already
[09:58] <cjwatson> it mostly works in ubiquity, modulo bugs
[09:58] <didrocks> pitti: right, they work with the older unity
[09:58] <cjwatson> where "crossgrade" is "install over the top and bodge"
[09:59] <infinity> Heh.
[10:00] <pitti> didrocks: erk @ gnome-desktop3
[10:01] <pitti> didrocks: does that "just" add that new API, or does it change the functionality of libgnome-desktop itself?
[10:02] <didrocks> pitti: it doesn't add it as an API in fact, it set on the root window the right color as an X property
[10:02] <didrocks> pitti: the patch was reviewed by desrt last week
[10:02] <pitti> it looks quite expensive
[10:03] <pitti> didrocks: libunity removes API, can you please confirm that this shouldn't go via -proposed?
[10:03] <didrocks> pitti: well, it's the code that was in unity in fact
[10:03] <didrocks> pitti: no, that's private headers (see changelog)
[10:04] <didrocks> pitti: so the code in gnome-desktop was the one in unity, it just has been moved around and now set on the X root window. It's even possibly going upstream
[10:04] <didrocks> and we avoid the race where everyone can get an orange color on all unity with the background
[10:04] <pitti> didrocks: ok, thanks; would be nice to send it upstream, as it's quite large
[10:05] <didrocks> pitti: yeah, desrt is on it, he wants to use it for gnome-shell :)
[10:05] <pitti> and it's really looking like clutter like that
[10:05] <pitti> ah :)
[10:05] <seb128> didrocks, pitti: that can't really go upstream I think
[10:05] <didrocks> seb128: he told so on Monday though?
[10:05] <pitti> if that's unity specific, it should rather stay in unity
[10:06] <seb128> didrocks, pitti: well, the set the x property stuff is upstream, but the maths are biased on the launcher side and quite an unity design choice
[10:06] <seb128> so I'm not sure how much the computation can go upstream
[10:06] <seb128> or if we need to keep the tweaks
[10:06] <pitti> right, and that computation looks very expensive
[10:07] <didrocks> seb128: right, but he wanted to give different option on the math in the upstream code
[10:07] <didrocks> seb128: like unity, gnome-shell, from what I understood
[10:07] <seb128> pitti, having it in unity means you get 2 code loading the same images and computing it
[10:07] <seb128> so you increase your login time
[10:07] <didrocks> pitti: well, we already have the computation in unity for 3 monthes
[10:07] <didrocks> pitti: the issue is that it's not the place to have it as we can get the image from libgnome-desktop when we shouldn't
[10:07] <didrocks> and so end up with blue indicators
[10:07] <pitti> yes, but that doesn't help to convince upstream to take a much more expensive one :)
[10:07] <didrocks> or blue colors
[10:08] <seb128> didrocks, pitti: let's sort that after release
[10:08] <seb128> desrt is on it in any case
[10:08] <seb128> he wrote most that and upstream quite some bits already
[10:10] <didrocks> thanks pitti :)
[10:31] <savvas> Hi, is there any chance linux 3.3 to be included in precise? The updated acpi patches <http://tinyurl.com/7krlqgv> should be a good reason to do that. But the kernel is an important package and I have my doubts that anyone would approve such a change so late in development. :)
[10:32] <Riddell> savvas: we're not the linux team, I think they're in #ubuntu-kernel
[10:33] <savvas> ah, thanks :)
[10:33] <pitti> savvas: FTR, not for precise final
[10:33] <pitti> savvas: there are 3.3 packages which you can run, and 12.04.1 or .2 will have newer kernel releases optionally available for install
[10:34] <savvas> ah good enough for me :)
[10:35] <savvas> thank you!
[10:41] <pitti> ^ review appreciated, I uploaded this
[10:42] <stgraber> looking
[10:42] <pitti> no diff yet
[10:54] <stgraber> pitti: I think I'll go get some lunch and check udisk afterwards ;) still no diff
[11:06] <stgraber> pitti: your version number seems a bit odd (lower than the previous changelog entry), though can be explained by -6 being UNRELEASED in Debian
[11:07] <stgraber> rest looks good
[11:07] <pitti> stgraber: yes, I don't want to make it higher than -6, as -6 is not released yet
[11:09] <tjaalton> i'd like to push a newer gstreamer-vaapi (0.3.4 -> 0.3.6), which makes it work for cedartrail enablement
[11:09] <tjaalton> still time before the freeze?
[11:09] <tjaalton> should I file a ffe etc
[11:10] <infinity> tjaalton: Toss a diff somewhere.
[11:10] <infinity> tjaalton: Don't care about a formal paper trail as much as I do a proper review.
[11:11] <tjaalton> infinity: ok, I'll put a changelog diff and diffstat firt
[11:11] <tjaalton> first
[11:12] <tjaalton> http://paste.ubuntu.com/926244/
[11:12] <tjaalton> it's not exactly a small diff :/
[11:12] <tjaalton> but this is somewhat fast moving code
[11:15] <infinity> Oh dear.
[11:15] <tjaalton> the package is new, added a couple of months ago
[11:15] <tjaalton> so no fear of regressions compared to earlier releases :)
[11:16] <infinity> tjaalton: Oh, yeah, nothing depends on it, just go for it.
[11:16] <tjaalton> infinity: right, thanks
[11:23] <tjaalton> and let's add "!!!", since it'll make vanhoof & jmleddy happy :)
[12:16]  * pitti investigates our recent CD overflow
[12:17] <pitti> ubuntu-wallpapers grew by 0.2 MB
[12:17] <pitti> linux-firmware (Δ 1.0 MB - 1.74: 26.7 MB   1.78: 27.7 MB)
[12:17] <pitti> gvfs-backends (Δ 0.7 MB - 1.11.5-1ubuntu1: 0.4 MB   1.12.0-0ubuntu5: 1.0 MB)
[12:17] <pitti> gvfs-daemons (Δ 0.2 MB - 1.11.5-1ubuntu1: 0.1 MB   1.12.0-0ubuntu5: 0.4 MB)
[12:18] <pitti> seb128: ^ I guess those are due to dropping the patch for shared lib?
[12:18] <seb128> pitti, likely
[12:19] <pitti> apw: would you happen to know anything in linux-firmware which could be dropped or moved someplace else? this thing keeps growing..
[12:19] <apw> pitti, it is likely to ... hmmm ... more and more drivers are pulling the firmware out
[12:19] <apw> pitti, is this for CD space ?
[12:20] <pitti> apw: yes, after beta-2 we broke the limit again
[12:21] <pitti> we could perhaps also squeeze the wallpapers a bit again, but that alone won't suffice
[12:21] <pitti> the alternates will get back into the limit with a fresh langpack build
[12:21] <pitti> but that won't help the desktops
[12:22] <infinity> What's this about gvfs not using shared libs?
[12:22] <pitti> it was a workaround for bug 899858
[12:22] <ubot2> Launchpad bug 899858 in oem-priority/precise "regression in gvfs to connect/browse using obex" [High,In progress] https://launchpad.net/bugs/899858
[12:23] <pitti> or rather, that patch for the shared lib was buggy
[12:23] <seb128> pitti, infinity: it's not a workaround, it's dropping a debian hack
[12:24] <seb128> infinity, basically upstream override dbus-glib functions with a local copy, debian made a patch to make the local copy a shared lib, but that lead the random symbol resolution issues and having the non overwritten version loaded
[12:24] <seb128> infinity, that code is going away next cycle
[12:24] <infinity> Check.
[12:24] <pitti> we need to reclaim 1.23 MB
[12:24] <apw> pitti, unsure, we may have some older firmware in here that perhaps could move to a separate package, but i'll have to poke it to be sure
[12:25] <pitti> apw: for example, it seems to have firmware for some old graphics cards, and we actually dropped some drivers in precise
[12:36] <tgardner> ogasawara, infinity: looks like ti-omap4 is cooked and ready for promotion.
[12:59] <apw> pgraner, who would know if we have machines with bnx2 cards in them in the la
[12:59] <apw> lab ?
[13:08] <pgraner> apw, no idea, I doubt anything does most of our nics are e1000e
[13:09] <apw> pitti, tgardner is going to look at ripping some of the older firmware into a new package
[13:09] <ogasawara> apw: you could maybe check hexr?
[13:09] <apw> pgraner, i am sure it was QA who was complaining when the firmware was missing ... hmmm
[13:10] <pitti> apw: cool, thanks; we found 0.6 MB of stuff to get rid of for now, so we'll still need some 600 kB
[13:13] <tgardner> pitti, I think I can use modinfo to filter out unused legacy firmware. I think linux-firmware is getting sort of large with unused firmware anyways. its time to split it into a legacy and a current binary package.
[13:15] <pitti> tgardner: if there is firmware which is not loaded by any module any more, I suppose we could just drop that?
[13:15] <tgardner> pitti, right, but the trick is to figure out _which_ files are unused.
[13:16] <pitti> tgardner: out of interest, how do you use modinfo for that? e. g. "modinfo phantom" does not show me that it wants phanfw.bin
[13:18] <apw> apw@dm$ modinfo phantom | grep firmware
[13:18] <apw> tgardner, damn
[13:19] <tgardner> pitti, should n't that be 'modinfo be2net' ? though it doesn't show the firmware filename.
[13:19] <pitti> tgardner: oh, I just guessed that it was phantom.ko that uses phanfw.bin
[13:20] <infinity> pitti: "modinfo ipw2200 | grep firmware" for an example of it being useful.
[13:20] <tgardner> pitti, try 'modinfo iwlwifi'
[13:20] <infinity> So, walking the tree and collecting modinfo on everything should be simple enough.
[13:20] <pitti> yes, I know that
[13:20] <pitti> I was just wondering if that's sufficient
[13:21] <tgardner> pitti, there is clearly some missing modinfo , but that will just provide opportunities to send patches upstream.
[13:21] <apw> tgardner, so perhaps only if there is a firmware list for a module, we can use the prefix to reap similar ones
[13:22] <tgardner> apw, that assumes a homogeneous naming scheme.
[13:23] <apw> tgardner, yeah but i suspect we do if we only reap things with a common prefix
[13:24] <pitti> yay, we found another 400 kB, so 200 kB to go
[13:24] <seb128> pitti, you can probably kill 200k worth of changelogs or NEWS in gtk or something if really needed
[13:29] <jelmer> thanks
[13:33] <ScottK> Looking at bind9
[13:41] <pitti> tgardner: so, please don't waste too much effort on this; if you find an obsolete firmware or two with a relevatn size (i. e. >= 100 kB), that's sufficient
[13:42] <pitti> the more the better, of course, but no need to spend a day on this, or introduce a package split, etc.
[13:42] <tgardner> pitti, well, it'll keep coming up in the future unless we decide to just abandon the standard CDROM size limit.
[13:42] <pitti> tgardner: we already did
[13:42] <pitti> tgardner: sabdfl approved 750 MB USB media next cycle
[13:43] <tgardner> pitti, um, so its only an issue for this cycle ?
[13:43] <pitti> tgardner: but we need to make the 12.04 images fit
[13:43] <pitti> tgardner: that's the most pressing one, anyway
[13:43] <pitti> tgardner: that's not to say that it wouldn't be useful to put a script into l-f that checks for obsolete firmware files
[13:44] <tgardner> pitti, I've already got the infrastructure script in the kernel package that I can use to list firmware files, so I'll spend a couple hours on it at least.
[13:46] <cjwatson> I'd say that for precise we don't have much time to debug hardware support breadth issues caused by dropping firmware, so it'd be better not to do anything non-trivial there for precise ...
[13:48] <pitti> yes
[13:49] <tgardner> there are some obvious candidates just among the iwlwifi ucode files. at least 3 400K files could be dropped.
[13:49] <pitti> tgardner: wow
[13:50] <pitti> tgardner: if these are not used by any module any more, we are back in the game already
[13:50] <tgardner> pitti, since I don't have to worry about older kernel support, I think we're pretty safe removing them.
[13:51] <pitti> tgardner: ah, you mean supporting running precise with e. g. a lucid kernel?
[13:51] <tgardner> pitti, right.
[13:52] <tgardner> pitti, I only have to support newer kernels, e.g., the LTS backports going forward
[13:52] <cjwatson> ah, yes, indeed
[13:52] <pitti> tgardner: perfect
[13:52] <tgardner> is there a bug already created about oversize linux-firmware ?
[13:53] <pitti> tgardner: no, but I can create one if you need it for bookkeeping
[13:53] <tgardner> I'll need it for the upload. skaet likes to see things tracked :)
[13:55] <pitti> tgardner: filed bug 979887
[13:55] <ubot2> Launchpad bug 979887 in linux-firmware "Remove some obsolete firmware to reduce package size" [Undecided,New] https://launchpad.net/bugs/979887
[13:55] <tgardner> pitti, ack
[13:56] <pitti> ^ shrinks from 412 kB to 80 kB
[13:56] <pitti> if someone can review in a bit?
[13:56] <pitti> (it'll probably get smaller after pkgbinarymangler even)
[13:57] <pitti> so that's ~ 300 kB from hwdata, 400 kB from dropping rarian-compat, and we should get back 600 kB with the next LibO upload
[13:57] <stgraber> pitti: I'll take your hwdata and you take my edubuntu-live? :)
[13:57] <pitti> if we also shrink linux-firmware by 1 MB, we can get tomorrow's images back in size, and have a safety margin with LibO
[13:57] <pitti> stgraber: deal!
[14:13] <stgraber> I posted some details in bug 966294 as there's a decision that the release team needs to make there
[14:13] <ubot2> Launchpad bug 966294 in gstreamer0.10 "gstreamer hangs when accessing webcam (on specific hardware)" [High,In progress] https://launchpad.net/bugs/966294
[14:13] <stgraber> skaet: ^
[14:13] <pitti> I thought slomo OKed reverting the patch?
[14:13]  * ScottK looks at postfix
[14:14] <seb128> pitti, he said he want to have a look
[14:14] <seb128> pitti, he didn't really gave an opinion on reverting part of that commit, he said he needs to understand the issue first
[14:16] <stgraber> right, I didn't get a definitive opinion from it on whether I'd break stuff by reverting it
[14:16] <stgraber> and I don't know gstreamer so I'm assuming I very well might break some stuff by doing it
[14:17] <cjwatson> I'm inclined to agree that any regression there will be easier to fix than busted installation media
[14:17] <cjwatson> it's a tough one though, I wonder how long we can get away with waiting
[14:18] <seb128> well slomo just got pinged for the first time an hour ago
[14:18] <seb128> let him a bit of time maybe?
[14:18] <pitti> would be interesting to check when we got the commit that is to be reverted
[14:18] <seb128> pitti, you mean?
[14:19] <seb128> pitti, we have the commit which created the issue
[14:19] <pitti> seb128: if we only got that offending patch into the distro three weeks ago, then it can't hurt much to revert it
[14:19] <seb128> oh
[14:19] <stgraber> pitti: Looking at hwdata, is pci* only matching pci.ids?
[14:22] <stgraber> seb128, pitti: The bug appeared in the archive in December
[14:22] <slangasek> seb128: he wants a couple of days; that's time that certain folks in QA can't do manual testing, and leaves us less time to /detect/ any regressions that happen...  surely it would be better to take it sooner rather than later to get the extra time to smoke test?
[14:22] <stgraber> when we switched from 0.10.35-1ubuntu1 to <IP_ADDRESS>-1
[14:24] <seb128> slangasek, your call, I feel uncomfortable backing out a commit we have no understanding about without having somebody who knows gstreamer saying he feels ok with it
[14:25] <seb128> other commits might depends on it and it might break video player or rhythmbox or whatever else for what we know about
[14:25] <seb128> -about
[14:25] <slangasek> certainly
[14:25] <seb128> slangasek, I've pinged slomo to try to figure how he feels about reverting that commit or part of it
[14:25] <slangasek> but we'll at least know what breaks and can revert those... and as cjwatson says, it's unlikely anything breaks as bad as the installer hanging
[14:26] <slangasek> er, can revert the change again if necessary
[14:26] <seb128> sure
[14:27] <seb128> I would rather have somebody who understand the code and the issue come with a suggestion, than a random guess stab reverting a commit without having a clue of what sideffects that might have
[14:28] <seb128> and yes I appreciate that doesn't give us a good solution or way out :-(
[14:28] <seb128> slangasek, let's wait for slomo to comment at least and try the revert if he's ok with it?
[14:28] <slangasek> ok
[14:29] <stgraber> pitti: I'm happy with hwdata (confirmed that the pci* only matches pci.ids so we're not dropping random files with the change)
[14:33] <pitti> stgraber: thanks, I'll accept
[14:34] <pitti> seb128, slangasek: so in the worst case we could back it out from final, and reintroduce it in -updates ?
[14:40] <pitti> btw, if we ever need another 1.5 MB of CD space, we could drop libc-dev-bin's Recommends: manpages-dev
[14:40] <pitti> we currently install that by default
[14:40] <pitti> infinity: ^ as you are about to do an eglibc upload..
[14:44] <scott-work> i've been told there are some concerns about the ubuntustudio-default-settings package?  specifically about the inclusion of an *.svg
[14:45] <scott-work> i am very anxious and motivated to resolve this issue as soon as possible
[14:45] <scott-work> does anyone know about this situation?
[14:46]  * skaet catching up on the backscroll of the gstreamer issue.
[14:46] <seb128> ^ that disable the "report a bug" entry for release
[14:47] <seb128> slangasek, pitti: ok, slomo says to revert the commit, though the whole commit not only the part suggested on the bug since that would break stuff
[14:47] <pitti> skaet: FAOD, I planned to turn off apport and kerneloops next Tuesday or Wednesday, together with the final langpack upload; sounds ok?
[14:54] <skaet> thanks slangasek, stgraber, pitti, seb128 re: gstreamer.
[14:54] <stgraber> seb128: ok, I'm digging my other debdiff (full revert of the commit), will re-test (I know it worked when I tried earlier, but still) and will upload
[14:54] <skaet> pitti, next Tuesday witht he final langpack upload sounds good.
[14:54] <skaet> thanks.
[14:54] <seb128> stgraber, thanks
[14:55] <skaet> stgraber,  possibly send email to kan hu (linaro), who has some expertise on gstreamer, and might be able to provide a sanity check/watch out for... comments.
[15:04] <seb128> wth? why does the queue has "diff from 1:3.4.0-0ubuntu2 to 1:3.4.0-0ubuntu7" for g-c-c
[15:05] <seb128> i.e not with the current revision but 5 revisions back
[15:10] <ScottK> quickly accepted quickly.
[15:11] <skaet> :)
[15:15] <didrocks> skaet: unity is just checking we fixed a last crash and then, pushing unity and unity-2d which are the latest in the stack
[15:16] <didrocks> gnome-control-center (above ^) is also part of the unity changes btw, if someone can review it :)
[15:16] <skaet> didrocks,  please push to -proposed when they're ready.  Definitely want to get this built and included as soon as possible.
[15:17] <didrocks> skaet: yeah, I want the crash to be confirmed to be fixed by 3 person on the 3 who got it
[15:17] <didrocks> skaet: but all seems fine, we are already after a week of testing :)
[15:18] <didrocks> nux should be ready in -proposed, so then, we can fire off unity and unity-2d ASAP
[15:18] <didrocks> the rest of the stack is already in precise (was not ABI break)
[15:19] <skaet> thanks didrocks. :)
[15:19] <didrocks> yw :)
[15:26] <jdstrand> skaet: fyi, tseliot will be uploading a fix for bug #959842 sometime today. it is likely something you want to track
[15:26] <ubot2> Launchpad bug 959842 in nvidia-graphics-drivers "root escalation via /dev/nvidia0" [Critical,In progress] https://launchpad.net/bugs/959842
[15:26] <skaet> thanks jdstrand
[15:27] <jdstrand> skaet: also, tyhicks will be uploading a security fix for samba later today
[15:27] <SpamapS> Hey canwe squeeze in a FFE for kvm linked to librbd?
[15:27] <skaet> is there a bug number for the SAMBA one?
[15:27] <jdstrand> yeah, getting it
[15:27]  * SpamapS will file the FFE bug momentarily
[15:28] <jdstrand> skaet: 978458
[15:28] <skaet> SpamapS,  depends on scope of impact and regression potential.
[15:28] <SpamapS> regression potential is near zero
[15:29] <SpamapS> literally just links a new library
[15:29] <ogra_> hmm, given i'm patch piloting today, should my uploads go to proposed rather than to the archive for the sponsored bits ?
[15:29] <SpamapS> hallyn: would you say there is any risk to linking to librbd?
[15:30] <hallyn> SpamapS: I would say I'd like to test it!
[15:30] <hallyn> Ideally, answer is no
[15:30] <hallyn> link against it, but the library won't mess with you unless you're using it
[15:30] <SpamapS> hallyn: didn't you upload to a PPA?
[15:30] <hallyn> but we'll be change the source coverage a bit with configure flags presumably
[15:30] <hallyn> SpamapS: no
[15:30] <hallyn> I uploaded the patches the rbd folks wanted, and that's in the archive
[15:31]  * SpamapS goes afk for a moment
[15:31] <hallyn> SpamapS: I thought you were doing the patch to link against rbd and enable it?
[15:37] <stgraber> skaet, seb128: right, full revert of the commit built and works here. I'll give the diff to slomo as it's a manual revert (too many changes for a reverse diff to apply)
[15:38] <seb128> ok
[15:39] <SpamapS> hallyn: I have one, yes :)
[15:40] <jdstrand> skaet: fyi, I just sponsored apparmor for sbeattie that should fix all the rls-p-tracking bugs, LXC fixes and updating some documentation
[15:41] <Riddell> skaet: I need to upload 32 packages to fix their translations
[15:41] <Riddell> dpm can confirm
[15:41]  * ScottK will review.
[15:41] <skaet> thanks jdstrand
[15:42]  * skaet smiles to see some of those off the list... :)
[15:42] <skaet> thanks ScottK for handling the translation reviews.
[15:42] <jdstrand> skaet: yes-- we are smiling too :)
[15:42] <stgraber> jdstrand: lxc fixes, yay!
[15:43] <cjwatson> Riddell: I'm sure I've done uploads to Launchpad Translations recently without having to do package uploads
[15:43] <jdstrand> :)
[15:43] <stgraber> speaking of lxc, hallyn is planning a bugfix lxc upload for before-final-freeze. I'll do the review when it hits the queue.
[15:43] <cjwatson> I did debian-installer translation uploads this way a month or two ago
[15:44] <ScottK> Riddell: I think we want Bug 979824, but since it would involve a plymouth upload, I think it should have some discussion here.
[15:44] <ubot2> Launchpad bug 979824 in plymouth "UI Freeze exception for kubuntu splash theme" [Undecided,Confirmed] https://launchpad.net/bugs/979824
[15:44] <hallyn> stgraber: and there is one more new one which i'm hoping utlemming will have a fix for, though that one is probably ok to sru
[15:44] <dpm> Riddell, ack, plus the subsequent kde-l10n-* uploads
[15:44] <cjwatson> There's likely to be a plymouth upload at some point, one way or another
[15:44] <hallyn> (bug 979996)
[15:44] <cjwatson> dpm: couldn't you get the upload tools to work?
[15:44] <ubot2> Launchpad bug 979996 in lxc "ubuntu-cloud template can't find .img" [Undecided,New] https://launchpad.net/bugs/979996
[15:45] <cjwatson> I'm using lp:~jtv/lp-translations-tools/trunk
[15:45] <dpm> cjwatson, I did, and I could upload ~700 out of ~800 templates, but LP only allows uploading templates that are already in LP, for new ones to be created, the source package needs to be uploaded
[15:45] <Riddell> dpm: I think I'll do kde-l10n tomorrow to make sure the packages are all through launchpad?
[15:46] <dpm> ok
[15:46] <cjwatson> dpm: hmm, ok
[15:46] <cjwatson> at least that cuts the number down
[15:46] <cjwatson> Riddell: err, can't these go through -propossed?
[15:46] <cjwatson> -s
[15:46] <Riddell> cjwatson: precise-proposed rather than just precise?
[15:47] <cjwatson> yes
[15:47] <skaet> yes
[15:47] <cjwatson> that way arch all/any skew in the builds doesn't leave us with uninstallable packages on some architectures
[15:47] <cjwatson> kdepim for instance will have that problem if i386 builds before the rest
[15:48] <Riddell> ok I'll do a mass reject then
[15:48] <cjwatson> sorry, but I do think it will make life more reliable
[15:48] <cjwatson> I suppose I should just check that translations work right for -proposed
[15:49] <SpamapS> ok, so I need an approval on this FFE: https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/932896
[15:49] <ubot2> Launchpad bug 932896 in ceph "[FFE] Should use libnss instead of libcrypto++" [High,Fix committed]
[15:49] <SpamapS> so I can upload a new version of ceph so we can pull librbd and librados into main, so that kvm can be linked against them
[15:50] <cjwatson>         valid_pockets = (
[15:50] <cjwatson>             PackagePublishingPocket.RELEASE, PackagePublishingPocket.SECURITY,
[15:50] <cjwatson>             PackagePublishingPocket.UPDATES, PackagePublishingPocket.PROPOSED)
[15:51] <cjwatson> cheesy, but yeah, translations in -proposed should work
[15:51] <SpamapS> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/904834
[15:51] <ubot2> Launchpad bug 904834 in qemu-kvm "[FFE] Build qemu-kvm with RBD support" [High,In progress]
[15:52] <SpamapS> Just an FYI, still working on the patch/upload but wanted to make sure you guys know its incoming
[15:53] <hallyn> SpamapS: shall i fire up my testbed?  Do you have a patch I should test?
[15:53] <SpamapS> hallyn: It would be great if you could. I'm about ready to start my own sbuild
[15:54] <skaet> SpamapS, thanks.   If testing proves it safe,  and scope is as you say,  yeah should be ok.
[15:54] <SpamapS> Packaging branch status: OUT-OF-DATE
[15:54] <SpamapS> *argh*
[15:55]  * skaet --> shifting locations, biab
[15:59] <stgraber> I'll be off for dinner soon and back a bit later to look at lxc.
[15:59] <stgraber> I uploaded gstreamer to the queue now, haven't heard from slomo yet though
[16:00] <hallyn> stgraber: ok, package pushed fwiw
[16:00] <ScottK> micahg: I see in Bug 979986 that opensc has a firefox module. Is mozillateam aware and OK with us shipping that?
[16:00] <ubot2> Launchpad bug 979986 in opensc "[FFe] Please merge opensc 0.12.2-2 (universe) from debian unstable" [Undecided,Triaged] https://launchpad.net/bugs/979986
[16:00] <stgraber> hallyn: ok, might even have a look before dinner then :)
[16:01] <SpamapS> while I work on the kvm build, I still need approval for FFE bug 932896
[16:01] <ubot2> Launchpad bug 932896 in ceph "[FFE] Should use libnss instead of libcrypto++" [High,Fix committed] https://launchpad.net/bugs/932896
[16:04] <tgardner> pitti, I was able to shrink nic-firmware a bit as well:
[16:04] <tgardner> -rw-rw-r--  1 rtg rtg  27M Apr  3 12:54 linux-firmware_1.78_all.deb
[16:04] <tgardner> -rw-r--r--  1 rtg rtg  22M Apr 12 09:59 linux-firmware_1.79_all.deb
[16:04] <tgardner> -rw-rw-r--  1 rtg rtg 6.6M Apr  3 12:54 nic-firmware_1.78_all.udeb
[16:04] <tgardner> -rw-r--r--  1 rtg rtg 5.7M Apr 12 09:59 nic-firmware_1.79_all.udeb
[16:04] <tgardner> -rw-rw-r--  1 rtg rtg 324K Apr  3 12:54 scsi-firmware_1.78_all.udeb
[16:04] <tgardner> -rw-r--r--  1 rtg rtg 324K Apr 12 09:59 scsi-firmware_1.79_all.udeb
[16:06] <Riddell> ScottK: packages for your reviewing pleasure
[16:06] <ScottK> Thanks.
[16:06]  * Riddell out for a few hours, text or phone me if you need me
[16:07] <ScottK> Riddell: I think the plymouth theme is the one big thing left.
[16:08] <micahg> ScottK: looking
[16:10] <stgraber> can an archive admin reject lxc? an improved version will be uploaded by hallyn very soon
[16:10] <jdstrand> I'll do it
[16:10] <jdstrand> be chance, I was reading the diff :)
[16:10] <jdstrand> s/be/by/
[16:11] <stgraber> cool
[16:11] <jdstrand> stgraber: done
[16:11] <stgraber> the current one isn't wrong but would show an error message to the user that may interpret it as a bug, so better add some checks in there
[16:13] <zul> can someone review swift please?
[16:14] <doko> could the release team please have a look at bug 979923? I'd like to schedule no-change uploads for universe before the weekend
[16:14] <ubot2> Launchpad bug 979923 in python2.6 "Python 2.6 and several virtual packages are still available in 12.04" [High,Confirmed] https://launchpad.net/bugs/979923
[16:17] <pitti> doko: sounds fine to me
[16:17] <pitti> doko: we still have a large buildd lag, so over the weekend sounds better than starting it now
[16:17] <tgardner> pitti, cjwatson: uploaded linux-firmware
[16:17] <doko> pitti: then I'll self-approve these when I do these on Sat or Sun
[16:17] <pitti> doko: although they are mostly universe, so mostly shouldn't get in the way
[16:17] <pitti> doko: WFM
[16:17] <pitti> tgardner: \o/, thanks
[16:20] <pitti> Riddell: why are all these .pot rebuilds in -proposed?
[16:23] <stgraber> pitti: see 15:46 UTC
[16:23] <pitti> stgraber: ack
[16:25] <pitti> -proposed has a higher build prio, though, so if we accept the lot now, we'll also starve other builds
[16:30] <hallyn> SpamapS: patch url?
[16:31] <SpamapS> https://bugs.launchpad.net/ubuntu/precise/+source/qemu-kvm/+bug/904834/+attachment/3053871/+files/enable-rbd.debdiff
[16:31] <ubot2> Launchpad bug 904834 in qemu-kvm "[FFE] Build qemu-kvm with RBD support" [High,In progress]
[16:31] <SpamapS> hallyn: ^^
[16:31] <hallyn> thanks
[16:31] <SpamapS> still waiting on FFE approval for the CEPH switch from crypto++ to libnss
[16:32] <SpamapS> bug 932896 .. please?
[16:32] <ubot2> Launchpad bug 932896 in ceph "[FFE] Should use libnss instead of libcrypto++" [High,Fix committed] https://launchpad.net/bugs/932896
[16:32] <hallyn> heh, will shut up about tabs/spaces
[16:32] <SpamapS> hallyn: I know.. I hate that
[16:38] <ScottK> Done.
[16:40] <stgraber> wow, I'm really impressed at how well that hackish flood protection works, no more kick for excess flood!
[16:40] <SpamapS> hallyn: Supported formats: vvfat vpc vmdk vdi sheepdog rbd raw host_cdrom host_floppy host_device file qed qcow2 qcow parallels nbd dmg tftp ftps ftp https http cow cloop bochs blkverify blkdebug
[16:40] <SpamapS> hallyn: it at least thinks it can do rbd :)
[16:40] <pitti> stgraber: does it rate-limit itself?
[16:40] <hallyn> SpamapS: still rebooting before building with your patch
[16:41] <pitti> good night
[16:44] <stgraber> pitti: yeah, it sleeps for 2s after it pasted 5 items in less than 5s (IIRC)
[16:44] <stgraber> pitti: that's not technically following the IRC spec but it's apparently limiting it enough that it doesn't hit the server flood detection code anymore :)
[16:45] <stgraber> pitti: good night
[16:45] <skaet> good night pitti,  thanks.
[16:47] <stgraber> lxc looks good, can an archive admin please accept?
[16:50]  * ScottK looks
[16:50] <ScottK> stgraber: Done.
[16:50] <stgraber> ScottK: thanks
[16:52] <zul> can someone reject the nova upload please
[16:53] <ScottK> zul: I don't see one in queue.
[16:53] <zul> it should be there soon i think
[16:53] <ScottK> OK
[16:54] <tseliot> can anybody approve nvidia-graphics-drivers, please? (it contains a security update)
[16:55] <ScottK> Sure.
[16:55] <ScottK> It's not like we have a real choice on that one.
[16:55] <micahg> ScottK: mozilla plugin doesn't appear to be built for opensc
[16:56] <ScottK> micahg: OK.  There was a mention of it in the FFe for opensc that just got approved. It might be worth a check to make sure it didn't suddenly grow one.
[16:56] <micahg> yeah, I built the package, one isn't installed anywhere
[16:56] <tseliot> thanks!
[16:56] <ScottK> tseliot: Done
[16:57] <ScottK> micahg: OK.  Great.
[16:57] <zul> ScottK: there it is
[16:57] <tseliot> ScottK: thanks
[16:57] <ScottK> zul: rejected.
[16:57] <micahg> ScottK: thanks for flagging
[16:57] <ScottK> No problem.
[16:57] <zul> ScottK: thanks
[16:57] <skaet> thanks ScottK, tseliot
[16:57] <ScottK> You're welcome.
[17:00] <cyphermox> please reject the evolution-exchange upload, something went wrong
[17:00] <ScottK> Looking
[17:00] <ScottK> cyphermox: Done
[17:00] <cyphermox> ScottK: thanks.
[17:00] <ScottK> You're welcome
[17:20] <hallyn> SpamapS: no regressions found in test-qemu.py or test-libvirt.py on my box \o/
[17:21] <hallyn> i'll do a long guest install now too
[17:21] <SpamapS> hallyn: awesome! I got qemu-image create to create an RBD based image at least.. haven't tried to do much else though.
[17:22] <SpamapS> Now if only somebody could please look at the CEPH FFE bug 932898
[17:22] <ubot2> Launchpad bug 932898 in ceph "[MIR] ceph" [Undecided,In progress] https://launchpad.net/bugs/932898
[17:22] <SpamapS> err bug 932896
[17:22] <ubot2> Launchpad bug 932896 in ceph "[FFE] Should use libnss instead of libcrypto++" [High,Fix committed] https://launchpad.net/bugs/932896
[17:22] <SpamapS> sorry that was the MIR bug blocked on the FFE
[17:25] <skaet> slangasek, infinity - could one of you look at 932896?
[17:36] <hallyn> SpamapS: don't suppose you have plans to write a short rbd howto (for serverguide or wiki inclusion)?
[17:39] <SpamapS> hallyn: http://ceph.newdream.net/wiki/QEMU-RBD
[17:46] <ScottK> slangasek: If I upload the proposed plymouth change for the Kubuntu splash update, can you review it?
[17:50] <slangasek> ScottK: can do, though fyi there's another plymouth upload in the works for tomorrow - maybe it's better to just commit for now and have a single upload?
[17:50] <ScottK> Yes.  Sounds good.
[17:52] <ScottK> slangasek: I'm sending yofel over to chat with you about it (I don't have the code and I don't know if he has rights to the branch.
[17:52] <slangasek> ok
[17:55] <slangasek> SpamapS: question for you on bug #932896
[17:55] <ubot2> Launchpad bug 932896 in ceph "[FFE] Should use libnss instead of libcrypto++" [High,Fix committed] https://launchpad.net/bugs/932896
[17:55] <SpamapS> slangasek: yes?
[17:56] <slangasek> no, I mean there's a question for you /on/ bug #932896 ;)
[17:56] <slangasek> sorry for my ambiguous preposition up on
[17:59] <didrocks> unity and unity-2d uploaded (do not forget metacity as well which is waiting) all that in -proposed.
[18:07] <ScottK> zul: Is there an FFe for the package split in quantum?
[18:07] <zul> ScottK:  no should there be?
[18:07] <ScottK> Yes.
[18:07] <zul> ScottK: k
[18:08] <ScottK> zul: Mostly what it needs is a documentation trail and an archive admin to volunteer to do the binar New review (not me).
[18:09] <zul> ScottK: cool gimme a sec
[18:10] <zul> ScottK:  https://bugs.launchpad.net/ubuntu/+source/quantum/+bug/979192
[18:10] <ubot2> Launchpad bug 979192 in quantum "FFE: Separate agent binaries in different packages" [Medium,New]
[18:11] <ScottK> Daviey: ^^^ would you please look at 979192?
[18:44] <SpamapS> slangasek: answer for you on bug 932896 (from Sage Weil, author of CEPH ;)
[18:44] <ubot2> Launchpad bug 932896 in ceph "[FFE] Should use libnss instead of libcrypto++" [High,Fix committed] https://launchpad.net/bugs/932896
[18:45] <slangasek> SpamapS: FFe granted
[18:46] <SpamapS> slangasek: yaaaay
[19:04] <SpamapS> slangasek: you're on a roll, want to also approve this one?: https://bugs.launchpad.net/ubuntu/precise/+source/qemu-kvm/+bug/904834 ?
[19:04] <ubot2> Launchpad bug 904834 in qemu-kvm "[FFE] Build qemu-kvm with RBD support" [High,Fix committed]
[19:05] <SpamapS> slangasek: 932896 was a blocker for librbd going into main.. so pending jdstrand's final approval, ceph should enter main, and 904834 can then be uploaded. :)
[19:05]  * jdstrand looks
[19:11] <tyhicks> slangasek: Hello
[19:11] <tyhicks> slangasek: Have a bit to chat about getting an updated samba into Precise?
[19:12] <jdstrand> fyi, ceph looks fine to me
[19:12] <jdstrand> (commented in the bug)
[19:12] <tyhicks> I've attached a (tested) debdiff for Precise to bug 978458
[19:12] <ubot2> Launchpad bug 978458 in samba "CVE-2012-1182: "root" credential remote code execution" [High,In progress] https://launchpad.net/bugs/978458
[19:14] <tyhicks> jdstrand has sponsored the debdiff and jelmer has +1'ed it
[19:15] <tyhicks> If someone from the release team can find the time to take a look and accept it for Precise, I think it would be very worthwhile since it closes a large security hole
[19:15] <jdstrand> slangasek, SpamapS: ^ (fyi, ceph looks fine to me)
[19:27] <slangasek> SpamapS: qemu-kvm acked
[19:29] <slangasek> tyhicks: please upload the samba package if you haven't already; should  go to -proposed
[19:30] <slangasek> oh, it's in unapproved -release
[19:30] <tyhicks> slangasek: right
[19:30] <highvoltage> yay
[19:30] <slangasek> hmm, will cause installability due to build skew... let me see
[19:30]  * micahg suggests rejecting and reuploading to -proposed
[19:30]  * highvoltage 's collueges has been bugging him for new samba
[19:31] <jdstrand> slangasek: I can delete and retarget
[19:31] <slangasek> jdstrand: yes please
[19:32] <jdstrand> slangasek: I figured since we didn't hit final freeze yet 'precise' was ok
[19:32] <jdstrand> rejected
[19:32] <tyhicks> thanks jdstrand
[19:32] <slangasek> jdstrand: cf. kate's last announce mail about using -proposed for things that cause archive uninstallabilites
[19:32] <slangasek> this qualifies :)
[19:41] <jdstrand> slangasek, tyhicks: ok, samba uploaded to precise-proposed
[19:42] <jdstrand> and there is your proof :)
[19:42] <tyhicks> thanks, jdstrand :)
[19:42] <jdstrand> slangasek: assuming this goes through, does the release team do a pocket copy or should we be watching for it?
[19:43] <jdstrand> (for the builds to finish)
[19:43] <maxb> Hi release team. I've just ended up in the middle of a conversation in #svn-dev about whether it's still plausible to update subversion from 1.6.17 to 1.6.18 in precise. The rationale is repository corruption fixes. There *are* other changes in the upstream point release, but they appear pretty conservative. Details are in bug 980087. If someone has a moment, could you offer an initial "Yes if you move quickly" or "No way, we insist on a
[19:43] <ubot2> Launchpad bug 980087 in subversion "Update to 1.6.18 to fix fsfs repository corruption issues" [Undecided,New] https://launchpad.net/bugs/980087
[19:43] <maxb> targeted backport if anything" prognosis?
[19:43] <slangasek> jdstrand: release team should take it
[19:43] <jdstrand> cool
[19:43]  * jdstrand hands conversation off to tyhicks
[19:44] <micahg> maxb: I just sent someone to #ubuntu-server to look for someone to do the update (assuming it's bug fix only)
[19:44] <tyhicks> I'll be around, so ping me if/when you have questions
[19:44] <micahg> and there he is :)
[19:45] <maxb> micahg: Right, so updating to 1.6.18 is still within the realms of acceptability at this stage?
[19:45] <maxb> It's bugfix only, but the bugfixes vary in criticality
[19:46] <maxb> As far as actually preparing the package goes, I could do that
[19:46] <micahg> maxb: IANA release team member, but there seems to be some severe fixes in there and we're before final freeze (for another hour or so), Daviey would probably be the best person to ask
[19:48] <maxb> Right. Well, there's not going to be a package by final freeze, but I'll see if I can sort one out in the next 24h if no-one else does or tells me it's too late
[19:49] <maxb> (but I'm not a developer, so I'd still need a sponsor)
[19:49] <micahg> maxb: it impacts the server image most, so you'll want to talk to Daviey about it
[19:49] <maxb> I imagine he's been pinged enough by this conversation, I'll wait and see :-)
[19:49] <micahg> also on Kubuntu dvd
[19:50]  * micahg wonders if infinity has a Daviey incantation
[20:08] <slangasek> can anyone here explain to me what rosetta's doing in bug #978724?
[20:08] <ubot2> Launchpad bug 978724 in update-notifier "update-notifier needs to build translation template" [Undecided,Incomplete] https://launchpad.net/bugs/978724
[20:08] <slangasek> I thought it looked at all .pot files present in the build tree
[20:08] <slangasek> having to rebuild the .pot file that's already built is definitely wrong
[20:09] <Daviey> ScottK: looking
[20:15]  * skaet ^ did the reject,  risk too high for the possible return (low priority bug too)
[20:19] <slangasek> skaet: of which one?
[20:19] <skaet> gnome-session
[20:19] <slangasek> hmm
[20:20] <skaet> slangasek, see comments in bug.
[20:21] <gilir> could someone review lubuntu-meta please, it adds missing packages for usb and 3G modems to the ISO, and remove a problematic package on armel ?
[20:22] <slangasek> skaet: so this was something that was discussed at UDS, the desktop team agreed to reintroduce this option
[20:22] <slangasek> I don't agree at all that this is high risk
[20:22] <slangasek> the risk of regression is non-existent; the only risk is that users will /use/ the feature
[20:23] <skaet> slangasek, was thinking that by using the feature it might cause problems, based on what I was reading.
[20:23] <skaet> why was it only a low priority bug if it was that important?
[20:24] <slangasek> well, having the feature ripped out because GNOME upstream wouldn't commit to providing a working session management solution also caused problems
[20:24] <slangasek> I don't know, I didn't set the bug severity - I filed my bug report in person with didrocks :)
[20:24] <skaet> https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/771896/comments/27
[20:24] <ubot2> Launchpad bug 771896 in gnome-session "No way to save current session" [Undecided,New]
[20:25] <slangasek> yes - pitti's position there fundamentally contradicts what was agreed at the UDS session
[20:25] <slangasek> i.e., we agreed that an option, not discoverable in the GUI, would be a reasonable compromise
[20:25] <skaet> slangasek,  if you feel strongly about it,  and have more context to assess from.   Fish it out of the reject queue, review and let it through if it looks ok.
[20:26] <slangasek> I *do* feel strongly about it, I waste 5-10 minutes of time every time I reboot getting my desktop set back up because of this dropped feature
[20:26] <skaet> :)
[20:26] <skaet> fair 'nuf then.
[20:27]  * skaet saw it lingering in the +queue, and on the pad, and trying to get things cleaned up before final freeze.
[20:27] <slangasek> so are you happy for me to un-reject?
[20:27] <skaet> yes
[20:27] <slangasek> yep, understood
[20:27] <skaet> :)
[20:27] <slangasek> it was on my TODO list still for today :)
[20:30] <skaet> gilir,  I'll look at lubuntu-meta as soon as the diff is generated.
[20:31] <micahg> ummm, not good, bug 980205
[20:31] <ubot2> Launchpad bug 980205 in openjdk-6 "package openjdk-6-jre 6b24-1.11.1-4ubuntu1 failed to install/upgrade: './usr/share/applications/openjdk-6-policytool.desktop' is different from the same file on the system" [Undecided,New] https://launchpad.net/bugs/980205
[20:31] <micahg> doko: ^^
[20:31] <slangasek> um?  I know openjdk6 has multiarch support, but I didn't realize people were using it now?
[20:32] <slangasek> micahg: is this a regression?
[20:33] <roaksoax> Hi all, can someone please review bug #980240 (https://bugs.launchpad.net/ubuntu/+source/maas/+bug/980240/+attachment/3055431/+files/maas_0.1%2Bbzr462.debdiff)
[20:33] <micahg> slangasek: the .desktop files were removed because of this issue, but were added back as it was supposedly fixed
[20:33] <ubot2> Launchpad bug 980240 in maas "[FFe] New maas upstream release" [Critical,Confirmed] https://launchpad.net/bugs/980240
[20:33] <ubot2> Launchpad bug 980240 in maas "[FFe] New maas upstream release" [Critical,Confirmed]
[20:33] <slangasek> ah
[20:34] <micahg> bug 969322
[20:34] <ubot2> Launchpad bug 969322 in openjdk-6 "OpenJDK issues in 12.04 (dup-of: 946736)" [Undecided,Fix released] https://launchpad.net/bugs/969322
[20:34] <ubot2> Launchpad bug 946736 in openjdk-6 "missing openjdk-6-java.desktop file" [Medium,Triaged] https://launchpad.net/bugs/946736
[20:37] <Daviey> roaksoax: please upload, will review from the queue
[20:37] <skaet> gilir,  lubuntu-meta looks fine,  its approved
[20:37] <roaksoax> Daviey: alright, cool
[20:37] <roaksoax> thanks
[20:37] <gilir> thanks skaet :)
[20:38] <skaet> Daviey,  can you add nova's review to your list?
[20:40] <SpamapS> can we get ceph accepted from the queue? It takes quite a while to build
[20:40] <ScottK> Does it need to be promoted at the same time?
[20:41] <SpamapS> jdstrand: ^^ ?
[20:42] <jdstrand> it doesn't, but it can be. I'm happy to do the promotion if someone accepts it
[20:43] <ScottK> I can promote the source when I accept it.  It seems fine.
[20:43] <jdstrand> ScottK: note some binaries will be denoted
[20:43] <Daviey> skaet: ack.. i just want to make sure everything is in the queue first.
[20:43] <jdstrand> demoted
[20:44] <ScottK> jdstrand: OK.  I'm not sure if they'll all land in Main or all land in Universe.  Either way, I guess c-m will let someone know.
[20:44] <ScottK> SpamapS: Done.
[20:44] <SpamapS> ScottK: thanks!
[20:45] <ScottK> You're welcome.
[20:45] <SpamapS> queuebot is cool
[20:49] <zul> can someone binary new quantum please
[20:50] <doko> micahg, I'll have a look tomorrow, maybe another upload this weekend when the buildds are idle
[21:03] <skaet> bdmurray,  update-manager contains other fixes than those listed in the change log, based on scanning the diff.   can you please update to include them all?
[21:04] <skaet> +  * Backport from upstream (Joey Hess):
[21:04] <skaet> +    - Add missing semicolon to /etc/apt/apt.conf.d/00CDMountPoint.
[21:05] <doko> micahg, bah, missed one desktop file :-(
[21:07] <micahg> doko: ok, you might want to use -proposed for the upload as it takes a while to build (unless this .desktop impact is high as arm* will still take quite a while)
[21:07] <doko> yeah, sounds better
[21:07] <jdstrand> I went ahead and promoted librados-dev librados2 librbd-dev librbd1 for the qemu-kvm SpamapS is preparing
[21:08] <jdstrand> (as per the MIR)
[21:08] <skaet> thanks jdstrand
[21:09] <jdstrand> so depending on when qemu-kvm gets uploaded/accepted, those might show up on component-mismatches
[21:09] <jdstrand> skaet: np
[21:10] <jdstrand> I'll be heading out though, so if there is a problem, SpamapS knows what is ok to promote
[21:10] <SpamapS> jdstrand: many thanks
[21:10] <ScottK> zul: ^^^ is just your first upload.  The second one is still in queue.
[21:10] <jdstrand> sure thing! :)
[21:12] <SpamapS> ScottK: would you mind accepting qemu-kvm as well? Then I'm done bugging you guys for anything seeded...
[21:13] <ScottK> Looking
[21:15] <doko> micahg, arm builds fast, it doesn't run the jdk tests
[21:16] <ScottK> SpamapS: accepted.  It may need some retrying since ceph in Main isn't built except on amd64.
[21:16] <bdmurray> skaet: are you talking about the base-installer change which is included in update-manager?
[21:16] <micahg> doko: yeah, powerpc and arm* were about the same
[21:17] <skaet> bdmurray,  spotted the lines I was pasting above, that didn't correspond to the changelog, and wanted to make sure it was all as expected.  translations were there too.
[21:17] <micahg> doko: but IANA release team member :), it's at their discretion
[21:17] <Daviey> why was quantum rejected?
[21:17] <Daviey> ScottK: ^^
[21:17] <slangasek> Daviey: < ScottK> zul: ^^^ is just your first upload.  The second one is still in queue.
[21:17] <ScottK> Daviey: There were two uploads. I just rejected one of them.
[21:18]  * slangasek goes all meta
[21:18] <skaet> :)
[21:22] <SpamapS> ScottK: alright, I'll tend to any build retries
[21:24] <skaet> ScottK,  are you planning on handling the kubuntu-default-settings?
[21:24] <ScottK> skaet: Waiting for plymouth tomorrow (per the note on the pad)
[21:24] <slangasek> ScottK: I would think those could go in independently?
[21:25] <ScottK> It may be that I made a false assumption, but I thought they were connected.
[21:26] <slangasek> TTBOMK the two themes are independent of one another
[21:27] <ScottK> OK.
[21:27] <ScottK> I'm at EOD, so if I do it won't be until late tonight or tomorrow.
[21:28] <doko> what is the final date when the archive should be in sync for all archs?
[21:29] <Daviey> doko: seeded?
[21:29] <slangasek> accepting mountall
[21:29] <doko> Daviey, yeah, openjdk-6 on the dvd images, just a path in a .desktop file
[21:31] <Daviey> skaet: 19th ^^, right?
[21:32] <SpamapS> ow.. poor armel.. "start in 21 hours"
[21:32] <skaet> Daviey, final freeze is today,  we should have release candidates with all the translations in hand by the 19th.
[21:33] <doko> so I do have 28 minutes ...
[21:33] <doko> infinity, why is nasl on manual?
[21:34] <Daviey> skaet: Right, but archive skew should be resolved by the 19th, right?
[21:34] <Daviey> that is the *absoloute* deadline for skew, right?
[21:34] <skaet> Daviey, resolved is going to depend on what fixes are going in.   Expect the bulk of it should be resolved before then.
[21:35] <infinity> doko: Because every time we take it off manual, it explodes.  Headless chickening too much to look into it.
[21:35] <doko> ok
[21:36] <infinity> Oo, IS finally located rusalka physically?
[21:36] <infinity> Shiny.
[21:40]  * skaet rejected quantum per request,  issue noticed.
[21:43] <skaet> hmm... has something happened to our queuebot?
[21:44] <Daviey> 22:15 -!- queuebot<EMAIL_ADDRESS>has quit [Read error: Connection reset by peer]
[21:44] <skaet> thanks!
[21:44] <stgraber> I need to get the bot to poke me when it dies ;)
[21:45] <stgraber> (or just write code so it auto-reconnect on freenode failure)
[21:45] <skaet> auto-reconnect seems like the way to go...;)
[21:45] <Daviey> while true ; do ./queuebot.sh ; done \o/
[21:46] <stgraber> Daviey: that's the idea but first I need to change my exception handling so that it exits when it gets an IRClib exception but not when it gets an LPlib or xmlrpc exception :)
[21:48] <Daviey> astraljava: exception handling, what is this?  Ah, it's like unit tests.. or some other foreign language.
[21:48] <Daviey> err, stgraber
[21:48] <stgraber> ;)
[21:52] <skaet> infinity, could you review the ndiswrapper one (looks basically sane to me, but would rather a more knowledgable set of eyes on it)
[21:53] <infinity> skaet: Sure.
[21:55] <infinity> Is that a patch we dropped at some point, or has ndiswrapper been broken ever since oneiric?
[21:55]  * infinity looks.
[21:55] <infinity> The latter.
[21:55] <infinity> Special.
[21:56] <skaet> SRU worthy?
[21:56] <skaet> oneiric that is?
[21:57] <infinity> Probably, but it seems no one's complaining.
[21:57] <infinity> Which, I guess, proves that our mainline network drivers suck less than they used to.  That's something.
[21:57] <infinity> 5 years ago, breaking ndiswrapper would have led to bloodshed. :P
[21:57] <skaet> :)
[22:04] <slangasek> stgraber: fyi, gstreamer out-of-syncness has broken ia32-libs installability for the moment (fixing itself w/ next publisher run); if there are further uploads of this, -proposed would be best
[22:04] <skaet> oooh... utouch-geis - fixing crashes and adding regression testing in the same patch,  nice.
[22:06] <skaet> hmm... another copy of glance uploaded.   removing the older one.
[22:07] <Daviey> skaet: yep, that new one fixes the oppsy
[22:07] <Daviey> oopsie ?
[22:07] <stgraber> slangasek: oops, sorry for that. I remember noticing after it was accepted that I pushed it to release and not to proposed, bumped some of the build scores to avoid the skew but that wasn't enough apparently...
[22:08] <Daviey> Please can squid3 be accepted purely a doc fix.
[22:11] <slangasek> rejecting eglibc, needs to go to -proposed per discussion with infinity
[22:32] <Daviey> skaet: My assignments are all reviewed, and good to go.  Thanks.
[22:32] <skaet> Thanks Daviey.  :)
[22:37] <doko> openjdk-6, openjdk-7, python-defaults are pending, let me know if you need anything else. afk in 20min
[22:38] <skaet> infinity, ^ can you look at doko's
[22:39] <skaet> ?
[22:39] <doko> and same thing for python3-defaults, but I have to wait until python3.2 is built on all archs
[22:42] <infinity> skaet: I will in two seconds, just working on an irresponsible last minute upload of my own. :P
[22:43] <skaet> ack
[22:44] <infinity> Or two...
[22:44]  * skaet starts to get worried....
[22:44] <infinity> ;)
[22:46] <skaet> *sigh*  launchpad keeps timing out on me when I'm going to accept those that Daviey reviewed... :P
[22:48] <doko> I wouldn't trust Daviey either ... ;p
[22:51] <Daviey> a what now?
[22:53] <cjwatson> skaet: that 00CDMountPoint change in update-manager is not in the part of the included base-installer source package that's actually used by update-manager, so there is no point in changelogging it
[22:57] <skaet> cjwatson,  ah,  fair enough.   Thank you.
[22:58] <skaet> interesting,  going one by one, got 2 through, but it really doesn't like maas and nova.
[23:05] <infinity> slangasek: Care to review my apt and dpkg uploads?  (Both are in proposed, don't let the changelogs fool you)
[23:07]  * skaet has learned her lesson,  don't try to select multiple complex packages then ask them to be accepted.  1 by 1 seems to be what it will tollerate.  :P
[23:09] <cjwatson> There are still timeout problems with +queue.
[23:10] <cjwatson> Should be fixable with an API client, since we'll be making one transaction per PackageUpload no matter how many you ask for in one go.
[23:11] <cjwatson> PackageUpload.acceptFromQueue() handles things like notifications, so I'm not too surprised that it scales poorly.
[23:11] <doko> slangasek, infinity: I'm a bit confused about the eglibc rejection. these things look worth fixing for the final. I was just objecting to change the dynamic linker name for armhf for the final
[23:12] <cjwatson> doko: you know we're using -proposed for pre-release work, right?
[23:12] <doko> cjwatson, including copying to release?
[23:12] <cjwatson> yes
[23:12] <doko> ahh, ok
[23:12] <cjwatson> per my mail to, er, somewhere a week or two back
[23:12] <cjwatson> ubuntu-release maybe
[23:12] <skaet> bug collecting info on timeout problems:  https://bugs.launchpad.net/launchpad/+bug/745799
[23:12] <ubot2> Launchpad bug 745799 in launchpad "DistroSeries:+queue Timeout accepting packages (bug structural subscriptions)" [Critical,Triaged]
[23:13] <doko> sorry for my ignorance
[23:13] <micahg> doko: FYI, https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-April/000949.html
[23:13] <cjwatson> skaet: *shrug* the fix that matters to us won't fix that bug :-)
[23:13] <skaet> thanks cjwatson for the background.
[23:14] <cjwatson> skaet: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-replace-archive-admin-shell-access
[23:14]  * infinity grabs some breakfast before getting back to the queue.
[23:15] <cjwatson> making PackageUpload.acceptFromQueue faster wouldn't hurt, but for the API it won't be necessary to make multiple accepts fit inside a single hard timeout
[23:15] <cjwatson> whereas if you check multiple things in the web UI, that has to be the case
[23:16] <Riddell> should I upload to precise or precise-proposed?
[23:16] <cjwatson> so I don't really think there's much point pushing on 745799 - it's Critical because it's an oops per LP policy, but (while I'd be happy to be wrong) I doubt anyone's going to fix it before I finish the API wor
[23:16] <cjwatson> k
[23:17] <skaet> Riddell,  depends on what you're uploading and impact on archive,  https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-April/000949.html
[23:18] <skaet> cjwatson,  ok,  will make a note of that.   :)
[23:19] <Riddell> "we'll promote your package to precise once
[23:19] <Riddell> it's built everywhere"
[23:19] <Riddell> is someone doing that manually?
[23:19] <cjwatson> yes, from time to time
[23:20] <cjwatson> speaking of which, in goes linux-{,meta-}lowlatency
[23:20] <skaet> thanks cjwatson.
[23:22] <cjwatson> is there anything in -proposed at the moment with special testing instructions attached to it?
[23:24] <maxb> Apologies for bothering here with something only barely on topic: could someone moderate through my ubuntu-devel@ post "Request for advice - subversion FTBFS in precise", since it's about a potential option for fixing that FTBFS before release ?
[23:26] <cjwatson> maxb: done
[23:27] <maxb> thanks :-)
[23:29] <infinity> cjwatson: Or, since you seem to be around, want to review my apt/dpkg uploads?
[23:29] <cjwatson> sure, few minutes
[23:30] <cjwatson> ah yes, that dselect fix, that one is fine
[23:30] <infinity> skaet: openjdk* are fine, unless you wanted doko to reupload them to proposed?
[23:30] <skaet> infinity, given the potential impact that would be safer.
[23:31] <skaet> doko,  can you reupload to -proposed?
[23:31] <infinity> Well, the impact of the changes is nil, but the impact of building could be arch skew, I dunno.
[23:31] <skaet> arch skew
[23:31] <infinity> doko: Does openjdk do any/all skew?
[23:33] <infinity> Same story with python-defaults, upload's fine, might cause temporary skew, if I recall.
[23:33] <cjwatson> There's no any/all skew problem in openjdk-6 that I can see.
[23:34] <cjwatson> Oh, wait, openjdk-6-source might have
[23:34] <cjwatson> Depends: openjdk-6-jre (>= 6b24-1.11.1-3ubuntu3), openjdk-6-jdk (>= 6b24-1.11.1-3ubuntu3)
[23:34] <cjwatson> So, yeah, that should be -proposed
[23:35] <cjwatson> looks like >= ${source:Version} or similar
[23:35] <infinity> doko: Want to just s/Distribution: precise/Distribution: precise-proposed/ in your openjdk and python-defaults changes files, re-sign, and re-upload?
[23:35] <infinity> Or, I could do the same.
[23:35] <infinity> Would be nice if the queue just let me do that. :/
[23:36] <cjwatson> hm, yeah
[23:36] <cjwatson> acceptFromQueue(pocket=None)
[23:36] <cjwatson> I mean hypothetically ...
[23:37] <cjwatson> oh, somebody else did apt.  but it looked fine to me.
[23:37] <slangasek> yeah, just did it
[23:37] <slangasek> I'm surprised to see plymouth showing up today
[23:37] <slangasek> looking
[23:38]  * skaet --> dinner, l8r
[23:38]  * infinity reuploads openjdk to proposed.
[23:38] <cjwatson> infi	though do use bzr bd -S next time, to reduce noise in the diff
[23:38] <slangasek> yeah... it was just the .bzr-builddeb.conf, so I didn't heckle him about it
[23:40] <slangasek> Riddell: per prior discussion with ScottK, I'm going to reject this plymouth upload since there's another one coming tomorrow
[23:40] <Riddell> ok
[23:40] <infinity> And same -proposed treatment for python-defaults.
[23:42]  * infinity wonders which of these kubuntu-default-settings uploads is authoritative...
[23:45] <infinity> Riddell: Are you going to take care of the k-d-s upload(s)?
[23:46] <skaet> infinity,  see pad
[23:46] <skaet> and backscroll
[23:46] <skaet>  :)   ScottK's comments about coord.
[23:46] <slangasek> Riddell: and yodel's branch merged to lp:ubuntu/plymouth now, so it won't get overlooked tomorrow
[23:46]  * infinity curses the pad and it's 403s...
[23:49] <slangasek> cjwatson: btw, the importer unhelpfully moved https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/plymouth/precise-201204112052 aside and shoved its own import on top when there was already a perfectly good branch there; I've now returned the favor.  So if you or James happen to get merge weirdness tomorrow, that's why :P
[23:50] <cjwatson> slangasek: sigh, not again.  usual problem is that it's picky about .pc contents
[23:50] <slangasek> oh, well
[23:50] <slangasek> we have no .pc on that branch for some reason :P
[23:50] <cjwatson> slangasek: and I bet that will require maxb intervention again
[23:51] <slangasek> mmk
[23:51] <maxb> hmm, was plymouth the one I did stuff to a couple of days ago?
[23:52] <slangasek> yeah :)
[23:53] <maxb> 75.054  Found changes between<EMAIL_ADDRESS>and<EMAIL_ADDRESS>[23:53] <maxb> (massive list of python tuples follows)
[23:54] <maxb> yeah, it sulked because you didn't have a .pc with all the content that it wanted
[23:56] <maxb> This is really annoying, I've tried to convince people that we should just bin the concept of keeping patches applied in vcs on a couple of occasions now, but never been successful. But it just doesn't work :-/
[23:57] <cjwatson> patches applied doesn't have to imply .pc in vcs; it's unfortunate that the importer took that particular decision
[23:57] <slangasek> maxb: proper serialization of bzr topic branches to quilt files on bzr bd -S please :)
[23:58] <cjwatson> (I've been using patches-applied-in-bzr since well before the importer did, *without* .pc)
[23:58] <maxb> cjwatson: how do you then get the branch into a state where quilt will do the right thing, after branching fresh from the server?
[23:59] <cjwatson> maxb: a mere client problem