[00:24] <NCommander> skaet: you around? I need to confirm some things for precise SRU hardware enabelement
[00:33] <skaet> NCommander,  yup
[00:34] <NCommander> skaet: would this be a good time for a call?
[00:34] <skaet> NCommander, sure
[01:06] <skaet> slangasek, have updated MilestoneProcess and BetaProcess with the results of today's IRC discussions - could you (and any other member of the release team who's interested ;) ) give it a review?
[01:24] <micahg> could someone please let xubuntu-meta through?
[01:26] <infinity> micahg: Again?
[01:26] <micahg> this is the first upload today :)
[01:27] <infinity> micahg: Didn't I NEW... Oh, that was defaults.
[01:27] <micahg> yeah
[01:27] <micahg> it'll need binNEW in a while also
[01:27] <Riddell> hmm, I screwed up on my removals?
[01:27] <Riddell> sorry about that
[01:27] <infinity> Riddell: A lot. :P
[01:27] <infinity> micahg: Yeah, I'm watching for it.
[01:27] <micahg> infinity: thanks
[01:28] <infinity> Riddell: Do you have a list of everything you removed, perchance?
[01:28] <infinity> Riddell: Failing that, it's raw SQL to try to figure it all out.  Or guesswork.
[01:28] <micahg> infinity: how much longer will you be around?  I need to upload 2 ubuntustudio sources in a few hours before I can upload the meta again
[01:29] <Riddell> infinity: all that http://paste.kde.org/428138/
[01:29] <Riddell> hmm whyever did I do that?
[01:29] <infinity> micahg: I'll be idling.
[01:30]  * micahg pokes superm1 or Daviey to reupload mythbuntu-lightdm-theme
[01:31] <infinity> Riddell: Was it possible there was meth involved?
[01:31] <micahg> gilir took care of lubuntu and I've got xubuntu and ubuntustudio, so I think we'll be good
[01:31] <Riddell> infinity: no, just severe head trauma
[01:31]  * Riddell hangs head in shame
[01:32] <infinity> We'll get you a new skull.
[01:32] <infinity> I'll gift-wrap one for you for UDS.
[01:32] <Riddell> thanks
[01:39] <Riddell> I'm going to sleep, if you notice any other mess ups I've made do text (SMS) me
[01:42] <infinity> Riddell: Letting you sleep seems slightly less cruel.
[01:42] <infinity> Riddell: G'night.
[02:19] <superm1> micahg: what needs to be changed and uploaded?
[02:20] <micahg> superm1: just a no change rebuild unless you need other changes, the binaries were removed accidentally this morning
[02:20] <superm1> micahg: oh i see.
[02:20] <superm1> okay i'll take care of it
[02:20] <micahg> thanks
[02:49] <jbicha> I think I need to go to bed, making mistakes now, could someone go ahead and reject gnome-disk-utility?
[03:28] <skaet> mythbuntu-lightdm-theme no change rebuild passed through.
[03:30]  * skaet --> zzz time.
[03:33] <slangasek> skaet: process page changes look good to me
[03:39] <superm1> no change rebuild on mythbuntu-lightdm-theme is still in NEW?
[03:41] <micahg> superm1: the binaries were removed, so it needed binNEWing
[03:41] <superm1> oh, that's annoying
[03:42] <micahg> superm1: that was the whole point of the upload :)
[03:43] <superm1> i didn't realize they'd have to go through NEW again, but yeah makes sense
[03:44] <micahg> binary not in archive in release it's uploaded to requires binNEW
[04:16] <stgraber> ok, let's see how long that python script will work until it crashes ;) that's basically a 50 lines long script poking at the LP API and doing almost raw IRC (well, python-irclib), minimal but might do the trick
[04:17] <stgraber> actually, I'll add some more exception handling around the LP code, just in case LP doesn't answer for some reason ;)
[04:26] <stgraber> now it should be ready to deal with LP going offline sometimes
[04:27] <stgraber> will see if it's still around tomorrow morning ;)
[04:43] <stgraber> ok, and now we have package sets too
[04:46]  * micahg wonders who uploaded a PPA version to precise :)
[04:47] <ScottK> of?
[04:47] <micahg> gnome-disk-utility
[04:49] <stgraber> micahg: "02:49 < jbicha> I think I need to go to bed, making mistakes now, could someone go ahead and reject gnome-disk-utility?"
[04:49] <micahg> ah, right, I  actually saw that :)
[04:50]  * micahg figured someone would've done it by now :)
[04:51] <ScottK> Rejected then.
[04:54] <stgraber> I guess it'd be nice to put some of that germinate magic into the bot so instead of package sets it can tell you if it's on a media or if it's seeded or if it's a build-dep of something seeded
[04:57] <micahg> stgraber: we do have the seeded-in-ubuntu and reverse-dependency tools
[04:57] <micahg> *reverse-depends
[04:59] <stgraber> micahg: yep, would just need to make some caching as seeded-in-ubuntu takes longer than parsing the whole queue does ;)
[05:01] <micahg> if you check before posting it, does it matter with the amount of packages we gets?
[05:03] <stgraber> probably doesn't if run in a separate thread. Currently the function looking at the queue is fast enough that I shouldn't be missing any of the IRC PING/PONG but if it gets much slower, then the bot might get disconnected depending on the server's configuration
[10:01] <Riddell> that queue is filling up :)
[10:03] <pitti> I did a review round about two hours  or so ago
[10:03]  * pitti has another look
[10:04] <pitti> couple of nice FTBFS fixes
[10:05] <pitti> the other fixes look ok as well, and all unseeded/universe
[10:06] <pitti> ^ CVE fix, accepting too
[10:29] <ajmitch> pitti: sorry for filling up the queue, just trying to go for important fixes for unseeded packages :)
[10:42] <Riddell> pitti: when doing a review what are you looking for?
[10:42] <Riddell> working out if packages aren't on CDs?
[10:42] <Riddell> then of the ones that are what do you look for?
[10:43] <pitti> Riddell: mostly that it's safe at this point, i. e. very cautious for packages on install images
[10:43] <pitti> and not introducing new libraries/transitions etc. for universe
[10:43] <pitti> bug fixes, FTBFS fixes etc. are fine for universe
[10:43] <pitti> (and very welcome in fact)
[10:43] <Riddell> precise_probs.html looking so much nicer, thanks pitti :)
[10:48] <ajmitch> pitti: so something like augeas, which I think is seeded - should I sponsor the upload & have it sit in the queue until after beta 1?
[10:48] <pitti> ajmitch: depends on the kind of changes
[10:48] <pitti> the CDs are by far not finalized yet
[10:48] <pitti> for one, the ubuntu ones are all oversized
[10:48] <pitti> we might get a ffox/tbird upload to help there
[10:48] <ajmitch> just an added depends on the -dev package to libxml2-dev
[10:48] <ajmitch> change is by Laney, so I think it's sensible :)
[10:48] <pitti> ajmitch: that sounds like it'd fix FTBFS of other packages, and thus sonuds fine
[10:49] <pitti> anythign which doesn't change the structure of the packaging, library transisions, etc.
[10:49] <pitti> (or break FF/UIF, of course)
[10:49] <ajmitch> I'll upload & let you check then, I've test-built it
[10:49] <Laney> what is the 'daily' seed?
[10:50] <pitti> Laney: uh?
[10:50] <Laney> I ran: $ seeded-in-ubuntu augeas
[10:50] <Laney> augeas-lenses (from augeas) is seeded in: ubuntu-server: daily
[10:50] <pitti> nice tool
[10:50] <pitti> I ususally look at the Task: header in apt-cache show
[10:50] <Laney> yeah, tumbleweed wrote it
[10:51] <Laney> it can take a source package, which is helpful
[10:51] <pitti> Laney: so I guess it means it's on the alternate CD (daily-live is desktop)
[10:51] <Laney> ah
[10:51] <pitti> Laney: corresponding to http://cdimage.ubuntu.com/daily-live/
[10:51] <ajmitch> really, queuebot? ubuntu-desktop for augeas? :)
[10:52] <Laney> it's true
[10:52] <pitti> it's not on any image
[10:52] <pitti> not libaugeas0, anyway
[10:52] <ajmitch> ok
[10:57] <Riddell> pitti: you expect to get rid of the oversizing for this beta?
[10:58] <pitti> Riddell: we'll discuss it in today's release meeting
[10:58] <pitti> I hope we can land ffox/tbird, then it's either python3 or yet another langpack
[10:58] <pitti> I think we still have two
[11:52] <ajmitch> that looks a bit broken
[11:53]  * ajmitch wonders where it got that version info from, mana was 0.6.0-1, and in universe
[11:57] <infinity> Weird.
[11:58] <infinity> Maybe queuebot has issues parsing syncs sanely.
[12:10] <infinity> (That apr is just a revert of the previous upload)
[14:29] <ogasawara> skaet et al:  Hi, I'd like to request a beta freeze exception for the kernel...
[14:29] <ogasawara> Upstream notified us of a patch yesterday evening to fix up a bug with their original RC6 patch we have applied.  The RC6 patch in it's current form is incorrect and disables the wrong RC6 states.  This fix has been tested and confirmed to fix bug 935965 and will hopefully also resolve bug 937378 (testing feedback still pending).  I do consider this fix critical for the release and would like to see it make Beta.  Addition
[14:29] <ogasawara> ally, without the fix, all the testing we will receive for RC6 will be invalid.  The upload will only contain this single fix.
[14:29] <ubot2`> Launchpad bug 935965 in linux "RC6 enabled causes severe graphics corruption" [High,Triaged] https://launchpad.net/bugs/935965
[14:29] <ubot2`> Launchpad bug 937378 in linux "Patched kernel with rc6 enabled shutdowns" [High,Triaged] https://launchpad.net/bugs/937378
[14:44]  * stgraber looks at what happened with queuebot and mana's version...
[14:49] <ScottK> Is this OK for Restricted (I'm thinking not):
[14:49] <ScottK> + * This is UNPUBLISHED PROPRIETARY SOURCE CODE of Broadcom Corporation;
[14:49] <ScottK> + * the contents of this file may not be disclosed to third parties, copied
[14:49] <ScottK> + * or duplicated in any form, in whole or in part, without the prior
[14:49] <ScottK> + * written permission of Broadcom Corporation.
[14:50] <ScottK> In which case, the bcmwl upload in queue may be problematic.
[14:54] <ScottK> slangasek: ^^^
[15:02] <stgraber> ok, something is really wrong with my version number handling ;)
[15:06] <skaet> ogasawara, approved.     Can you get it in today?
[15:06] <ogasawara> skaet: I can do it now in fact
[15:06] <skaet> ogasawara, please do.
[15:07] <ogasawara> skaet: uploaded
[15:08]  * skaet continues on with the backscroll... :)
[15:10] <skaet> ScottK,  yeah those licensing terms make it a concern. :P
[15:10] <ScottK> skaet: I'll go ahead and reject it.  Would you please talk to Alberto about it so we can get it fixed post-beta?
[15:11] <stgraber> version handling in queuebot should be fixed now
[15:27] <Riddell> hmm, linux
[15:27] <ogra_> i think leann asked for a freeze exception before
[15:27] <ogra_> (like 10 lines above :) )
[15:29] <skaet> ScottK,  email sent,  couple of pings initiated.
[15:29] <ScottK> Thanks.
[15:30] <ScottK> Accepted lintian since it got an FFe and isn't on any images.
[15:31] <Riddell> ogasawara: that's the linux build you want?
[15:32] <ogasawara> Riddell: for the linux-3.2.0-17.27 package, contains a critical fix for RC6 enablement
[15:33] <Riddell> ooh you've got your buzzwords sorted, critical and enablement :)
[15:33] <ogra_> haha
[15:33] <pitti> Riddell: ok to upload a new LibO to fix the component-mismatches madness?
[15:34] <pitti> build time is < 2 days on arm, so well within the margin IMHO
[15:34] <ogra_> pitti, LibO isnt seeded on arm
[15:34] <pitti> ogra_: anyway, it's installable now
[15:34] <Riddell> pitti: sweetshark is happy that's the final fix?
[15:34] <ogra_> no worries about buildtime wrt images
[15:35] <Riddell> ogasawara: "SAUCE: drm/i915: fix operator precedence when enabling RC6p"?
[15:35] <pitti> Riddell: asking
[15:35] <ogasawara> Riddell: yep, that's it.  without the patch the RC6 states which we want enabled, aren't
[15:35] <Riddell> ogra_: yeah you guys want to get into calligra instead :)
[15:36] <Riddell> ogasawara: accepted!
[15:36] <ogasawara> Riddell: thanks!
[15:36]  * Riddell is taking archive admin stuff slowly for fear of another mess like yesterday
[15:37] <pitti> Riddell: yes; it mostly reverts to ubuntu2, except for the approved MIRs which are now in main
[15:44] <Riddell> pitti: cool, go for it
[15:46] <pitti> ooh, ffox/tbird in the queue
[15:46] <pitti> thanks chrisccoulson
[15:47] <ogra_> to keep the arm buildds busy :)
[15:47] <ogra_> and if Riddell lets my alsa-lib upload in, they can play music while building ;)
[15:47] <Riddell> ogra_: is that a hint? :)
[15:48] <ogra_> heh, just a small one ...
[15:48] <ogra_> its not super urgent though
[15:48] <Riddell> ogra_: /pandaES-naming-changes.patch the patch headers need fixed
[15:49] <ogra_> oh, i used edit-patch
[15:49] <ogra_> why doesnt that DTRT !
[15:49] <Riddell> ogra_: it needs you to use emacs too :)
[15:49] <Riddell> ogra_: can you fix those and reupload?
[15:49] <ogra_> geez !
[15:50] <ogra_> sigh, seriously, it should just dump my name in if i call edit-patch ... tsk... yeah, will re-upload
[15:53] <pitti> I keep the others in the queue for now until they get diffy
[15:54] <jdstrand> skaet: hi! I am preparing the apparmor userspace upload
[15:54] <ScottK> jdstrand: I think Riddell is driving today.
[15:54] <jdstrand> ok
[15:54] <jdstrand> Riddell: ^
[15:55] <skaet> jdstrand, ack.  :)
[15:55] <Riddell> skaet is too, you can either convince me or her
[15:55] <Riddell> jdstrand: what is it and why do we want it?
[15:55] <jdstrand> skaet, Riddell: I am preparing the FFe now, but this is in support of apparmor/LXC and is on the landing page
[15:55] <Riddell> jdstrand: but why is it important for the beta?
[15:56] <stgraber> Riddell: it's making stuff stop crashing in containers
[15:56] <stgraber> (where stuff currently is mostly udev upgrades and localegen for me, but I know there are more)
[15:57] <jdstrand> Riddell: there is that, and we would like to have as many people testing it as possible. It was supposed to be in before FF, but there were some last minute bugs that prevented that. it passes all upstream regression tests as well as our distro tests
[15:59] <Riddell> jdstrand: ok, get the FFe and upload and we'll see if it's suitable for beta (probably will be today but getting less so as the beta progresses)
[15:59] <jdstrand> Riddell: thanks
[16:25] <stgraber> skaet: it can't, I don't think we have an audit trail for these or if we do, it's not accessible over the API
[16:25] <stgraber> skaet: I also wanted to print the irc nick of whoever uploaded the package but that's also something missing in LP, I'd have to parse the .changes file for that which would be pretty ugly ;)
[16:25] <skaet> stgraber,  ah well.  Was hoping.   Thanks for getting it going.   Big help. :)
[16:26] <Riddell> Daviey: it's zul's uploads for swift and nova
[16:27] <Riddell> Daviey: all fine, what's the reason to upload during beta freeze?
[16:30] <Daviey> Riddell: As i said, in retrospect it could have been held back.
[16:30] <Riddell> pitti: hold out for longer and you'll get more beer!
[16:30] <Daviey> Riddell: i will not be upset if it's rejected.
[16:32] <pitti> Riddell: darn, missed my chance
[16:53] <jdstrand> skaet, ScottK, Riddell: fyi, apparmor FFe: bug #940422
[16:53] <ubot2`> Launchpad bug 940422 in apparmor "FFe for apparmor 2.8beta1" [High,Confirmed] https://launchpad.net/bugs/940422
[16:53] <ScottK> Right.
[16:54] <ScottK> I'd lean towards putting it in now, but will leave the decision to Riddell or skaet.
[16:55] <Riddell> skaet: the apparmour change?
[16:55] <Riddell> ScottK rather ^^
[16:55] <ScottK> Riddell: Yes.
[16:55] <skaet> Riddell, jdstrand I'd rather it go in now, if its tested and ready too.
[16:56] <jdstrand> it is ready
[16:56] <jdstrand> and tested
[16:56] <Riddell> skaet: ScottK: it needs the FFe reviewed in general, then we can decide on beta goodness
[16:56] <ScottK> I read the FFe.  I think it should go in and better now than later.
[16:56] <Riddell> jdstrand: just upload if it's ready, worst we can do is reject :)
[16:57] <jdstrand> Riddell: ok. it will need a binary deNEW for the dh-apparmor package, which I shouldn't do
[16:58]  * Riddell looks
[16:58] <jdstrand> Riddell: basically, this includes a merge with debian (as explained in the bug)
[16:59] <jdstrand> Riddell: debian didn't want our debhelper patch for dh_apparmor, so we created the dh-apparmor package as a part of the apparmor packaging
[16:59] <jdstrand> Riddell: on its own, it does nothing because nothing depends on it
[16:59] <Riddell> jdstrand: I don't see dh-apparmor in New
[17:00] <jdstrand> sometime after beta1 I will pursue uploading a debhelper which removes our apparmor delta and Depends on dh-apparmor
[17:00] <ScottK> Riddell: I think it'll just be binary New.
[17:00] <jdstrand> Riddell: well, I only did the source upload a moment ago
[17:00] <ScottK> After the source is accepted/built.
[17:00] <jdstrand> (what ScottK said)
[17:00] <Riddell> ok, I'm going out for the next three hours so you probably need to convince ScottK to do it
[17:03] <pitti> Riddell: ^ reversion to python2, if you are so kind? it's a straight patch -R from http://launchpadlibrarian.net/86333969/lsb_4.0-0ubuntu16_4.0-0ubuntu17.diff.gz
[17:03] <pitti> and I tested that lsb-release still works
[17:04]  * Riddell looks
[17:04] <ScottK> skaet: Any objection to apparmor?
[17:04] <ScottK> If not, I'll approve/accept it.
[17:04] <Riddell> ScottK: good with me
[17:05] <skaet> ScottK,  no objections
[17:05] <ScottK> OK.
[17:05] <Riddell> pitti: accepted!
[17:05] <pitti> cheer!
[17:06] <ScottK> jdstrand: Accepted.
[17:06] <jdstrand> \o/
[17:07] <jdstrand> skaet, ScottK, Riddell: thanks
[17:07] <jdstrand> ScottK: so, for the dh-apparmor binary deNEW, will you handle that or are you comfortable with me doing it since you reviewed it?
[17:08] <ScottK> I'll look at it.
[17:08] <jdstrand> cool thanks
[17:12] <seb128> so, question for you r-t people ;-)
[17:13] <ScottK> !ask
[17:13] <ubot2`> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
[17:13] <seb128> we want to drop a public api from gtk2 (distro specific api added in natty) for the lts
[17:13] <seb128> ScottK, sorry I'm typing and thinking how to formulate the question ;-)
[17:13] <ScottK> Sure.  No problem.
[17:14] <seb128> the api is the one for grip handles in the corner to resize windows
[17:14] <seb128> I expect that has a few rdepends
[17:15] <seb128> would it be reasonable to drop the public includes for beta1 which will ftbfs the stuff that use it, or better to try to fix rdepends first?
[17:15] <debfx> jdstrand: dh-apparmor Breaks: debhelper (<< 9.20120115ubuntu2) but ubuntu2 still contains dh_apparmor
[17:15] <seb128> also would you be ok with an upload which turns the function to a nop basically today or better after beta?
[17:17] <jdstrand> debfx: that's fine. nothing pulls in dh-apparmor yet
[17:17] <jdstrand> debfx: I will be doing a debhelper upload after beta1 to remove the apparmor delta
[17:18] <jdstrand> (but add a temporary Depends until everything that needs it Build-Depends on dh-apparmor, at which point we can drop the debhelper Depends)
[17:19] <jdstrand> that will happen probably in the 12.10 time-frame
[17:20] <debfx> jdstrand: hm still the breaks should be "<=", no?
[17:23] <jdstrand> debfx: I see what you mean. I can adjust that-- I guess 9.20120115ubuntu2 snuck in since kees' upload
[17:24] <jdstrand> (it still isn't a problem though, since nothing depends on dh-apparmor)
[17:27] <debfx> right, it's fine as long as it's done before the debhelper upload
[17:27] <jdstrand> ScottK, skaet: should I upload ubuntu2 based on debfx comment or wait til after beta1?
[17:27] <jdstrand> debfx: yes
[17:27]  * skaet looking
[17:29] <jdstrand> skaet: the new dh-apparmor Breaks/Replaces with the version of debhelper that is in the archive now. This isn't a problem unless someone Build-Depends on dh-apparmor, which nothing does
[17:29] <jdstrand> skaet: (a new debhelper upload snuck into Ubuntu since kees' Debian apparmor upload)
[17:30] <jdstrand> imho, it isn't needed until I update debhelper, which I won't do until after beta1
[17:31] <jdstrand> that said, I am ready to upload a new apparmor if you want
[17:31]  * skaet being slow -- sorry jdstrand
[17:34] <jdstrand> skaet: actually I said that wrong. dh-apparmor should Breaks/Replaces on what is in the archive now, but it doesn't (it does on the previous ubuntu version of debhelper)
[17:35] <jdstrand> skaet: but again. nothing in Ubuntu knows about dh-apparmor, so there is no problem until I upload debhelper, which I won't do until next week, at which time I would upload apparmor before
[17:36] <skaet> jdstrand,  ok,  thanks for clarifying.   lets leave it alone then for now.   If a critical bug shows up,  fold it in please.
[17:36] <jdstrand> skaet: sure, but that won't happen :)
[17:36] <jdstrand> skaet: thanks :)
[17:37] <skaet> thanks jdstrand :)
[17:47] <seb128> slangasek, there?
[17:49] <seb128> slangasek, I want to discuss gtk2 changes and strategy to get them out with you when you will be around ;-)
[17:50] <ScottK> seb128: My suggestion would be the best way is to fix the rdepends first.
[17:51] <seb128> ScottK, before or after beta?
[17:51] <ScottK> How many packages?
[17:51] <seb128> there is probably a couple of those only, I will need to grep through the archive to figure which ones though
[17:51] <ScottK> I'd think probably after, but until we know which/how many it's hard to say.
[17:52] <tumbleweed> stgraber: re the bot discussion earlier, seeded-in-ubuntu does use cached data, it's the source->binaries lookup that's slow
[17:54]  * skaet --> lunch,  biab.
[17:55] <stgraber> tumbleweed: yeah, I noticed that a bit later on, importing seeded-in-ubuntu from the bot would be really quick when then querying the binary packages
[17:55] <stgraber> tumbleweed: the build-dep part is tricky though as I didn't find a way of making it fast ;)
[17:55] <tumbleweed> yup, so if you have a local cache of those mappings...
[17:55] <stgraber> tumbleweed: the LP API give me these already I believe, so that part is fine
[17:56] <tumbleweed> build-dep part?
[17:56] <stgraber> tumbleweed: checking if a source package in the queue produces a binary that's a build-dep of something seeded
[17:56] <tumbleweed> ah
[17:57] <tumbleweed> that's not an enourmous amount of data either
[17:58] <tumbleweed> I almost made reverse-depensd use a similar pre-calculated json dump. But it was useful to have a lot more data than just build-deps, and that meant it had to be a webservice
[18:11] <slangasek> ScottK: hrmmmm, if that's the effective license then yes it's a problem; but I've seen that particular message before, I think it may not mean what it says?  No clarifications anywhere to be seen?
[18:11] <slangasek> seb128: hey, what's up with gtk2?
[18:11] <ScottK> slangasek: Not that I saw.  I rejected it and skaet emailed Alberto to look into it.
[18:12] <ScottK> If it's all good we can still get it in later.
[18:13] <slangasek> ok
[18:14] <ScottK> I get really nervous about leaving apparently undistributable stuff in the queue.
[18:14]  * slangasek nods
[18:18] <ScottK> jdstrand: apparmor accepted.
[18:18] <jdstrand> ScottK: thanks! :)
[18:18] <ScottK> You're welcome.
[18:20] <seb128> slangasek, I want to drop public apis we distro added in natty and which probably have a few rdepends, I was wondering the best way to deal with it
[18:20] <ralsina> nessita, gatox, dobey: maybe a couple of reviews? https://code.launchpad.net/~ralsina/ubuntuone-control-panel/opt-parsing/+merge/94599
[18:20] <ralsina> oops, wrong channel, sorry!
[18:20] <seb128> slangasek, well first I wanted to check if you think it's fine dropping distro specific apis if we fix our rdepends
[18:22] <seb128> slangasek, then I wanted to see if fixing the rdepends before beta1 is ok (there is probably a few) or if better after
[18:22] <seb128> slangasek, I was pondering dropping the includes so the test rebuild catch the api users, but we could as well grep through the archive in some way
[18:23] <slangasek> seb128: as long as the package dependencies properly tend to the upgrade path, and you're sure no one outside of Ubuntu is using them, I'm ok with them being dropped
[18:23] <seb128> slangasek, I've also a patch that turn those api to no-op for now to not break abi which might be another way to deal with it
[18:24] <slangasek> there's a community lintian lab running somewhere now, right?  That might be the quickest / most reliable way to locate packages using those symbols
[18:25] <seb128> ok
[18:25] <seb128> the functions are
[18:25] <seb128> gtk_window_get_resize_grip_area
[18:25] <seb128> gtk_window_resize_grip_is_visible
[18:25] <seb128> gtk_window_get_has_resize_grip
[18:25] <seb128> gtk_window_set_has_resize_grip
[18:25] <seb128>  
[18:25] <seb128> slangasek, do you know who I can talk to who is running the community lintian?
[18:25] <slangasek> broder knows
[18:26] <seb128> ok, thanks
[18:26] <seb128> no hurry to drop those I think I will wait after beta1
[18:26] <seb128> slangasek, they are basically the resize handle added in the bottom right corner of windows
[18:26] <seb128> the api is used by a few things to turn them off
[18:29]  * slangasek nods
[18:31] <broder> seb128: what's up?
[18:32] <seb128> broder, hey
[18:33] <seb128> broder, is there any way the lintian community install could be used to find gtk2 users of the "resize_grip" apis?
[18:34] <broder> seb128: yeah, probably. my guess is that grepping the binaries would be most reliable. i'll kick it off
[18:34] <broder> (will probably take a few hours)
[18:34] <seb128> broder, thanks
[18:34] <slangasek> objdump -T $allbinaries | grep gtk_window.*resize_grip, preferably
[18:34] <seb128> broder, gtk2 rdepends only would be good, that's a valid api in gtk3 and we will keep it there
[18:35] <broder> seb128: do you know of an example package that's using it currently so i can double-check my search is working, or has everything you know about been converted?
[18:39] <seb128> broder, I'm trying to think about one...
[18:47] <seb128> broder, I don't find any off hand, that's good sign for the rdepends that will need to be fixed but doesn't help you...
[18:47] <seb128>  
[18:47] <broder> seb128: ok. i'll just go ahead and start searching and we'll see what comes up
[18:47] <seb128> btw I just uploaded a gneary and smplayer reverting the unity quickly added earlier today, I talked to mhall119 and dholbach about that
[18:48] <seb128> they agreed to not patch universe things with new strings this cycle, we will have a session at UDS on how to deal with those
[18:49] <seb128>  
[18:49] <seb128> broder, thanks
[18:51] <dobey> can i get an upload approval to be able to fix bug #939797 for the beta?
[18:51] <ubot2`> Launchpad bug 939797 in ubuntuone-installer/trunk "Failed to execute child process "ubuntuone-control-panel-qt"" [High,In progress] https://launchpad.net/bugs/939797
[18:52]  * micahg hugs seb128
[18:53]  * seb128 hugs micahg back
[18:54] <broder> oh hey, we have hits. i guess it is working
[18:56] <seb128> broder, which ones?
[18:56] <broder> seb128: lxdm and lxlauncher so far. note that it's running in filesystem order, not alphabetical
[18:57] <seb128> broder, indeed, those are valid hits, great ;-)
[18:57] <seb128> broder, not sure how long the grepping will take but I closed IRC can you email me the result when it's done?
[18:57] <broder> seb128: sure, no problem
[18:57] <seb128> thanks
[19:12] <broder> seb128: oh, that actually finished much faster than expected
[19:12] <broder> seb128: lxdm, lxlauncher, and xfdesktop4 were the only hits
[19:28] <dobey> maybe i should e-mail or sub ~ubuntu-release to the bug instead?
[19:32] <slangasek> dobey: please go ahead
[19:33] <slangasek> dobey: fwiw, best practice during a milestone hard freeze (i.e., beta + final release) is to Just Upload and let the changes be reviewed in the freeze queue
[19:33] <dobey> slangasek: ok. thanks
[19:42] <seb128> broder, oh, excellent, thanks!
[19:45] <slangasek> pitti: do you know why procps/lucid doesn't show up green on http://people.canonical.com/~ubuntu-archive/pending-sru.html ?  the bug is tagged verification-done-lucid
[19:45] <slangasek> and has been for a while
[19:53] <micahg> FYI, I won't be able to get lightdm-gtk-greeter uploaded until Sat night
[19:56] <seb128> micahg, what's the issue with it?
[19:56] <seb128> micahg, it should basically be copying the debian dir from debian and uploading?
[20:00] <micahg> seb128: we were missing a diff for the flavors to override settings (I got the Debian version working last night, but mr_pouit caught this thing missing, so he updated the old lightdm packaging for the greeter, I'm going to try to consolidate the 2
[20:00] <seb128> micahg, ok, I was just wondering if there was an upstream issue
[20:00] <seb128> micahg, so mostly packaging
[20:00] <seb128> micahg, you guys should be able to handle it I guess ;-)
[20:01] <micahg> yeah, I'd like this to mainly be maintained in Debian, so I want to get us as close as possible to that
[20:16] <skaet> Riddell,  am not seeing the Precise Beta 1 milestone on the tracker,  just the dailies.    We probably should set up the milestone, and put a copy of the current dailies there, so folks can kick at them over the weekend.   thoughts?
[20:17] <skaet> or at least start redirecting dailies there once the new kernel is built into some images...
[20:39] <stgraber> skaet: whenever we have our first beta1 candidates someone should indeed update ~/.isotracker.conf, disable the Daily milestone on the tracker, create the Beta 1 milestone and mark it as "testing" (ideally before any auto-publishing happens of a beta 1 candidate, or manual work would be needed ...)
[20:40] <skaet> Riddell,  NCommander, http://pad.ubuntu.com/ubuntu-release  has been set up - please record any bugs that might trigger rebuilds on it,  and indicate which images affected.
[20:42] <skaet> stgraber,  if we don't hear back from Riddell in next hour or so,  I'll take a pass at switching it over (while folks are still around to help ;) ).
[20:42]  * skaet would like the images with the new kernel to start getting tested...
[20:46] <broder> slangasek: i think it needs to be verification-done - i think verification-done-lucid is an unofficial helper tag
[20:46] <slangasek> broder: well, that's unhelpful ;)
[20:47] <slangasek> because it's not verification-done everywhere yet, but we ought to get it published for lucid anyway...
[21:11] <stgraber> hmm, I guess I need to fix that packageset ^
[21:11] <stgraber> slangasek: moving resolvconf to core sounds good to you?
[21:12] <infinity> stgraber: Sounds right.
[21:12] <stgraber> done
[21:14]  * infinity loves that "beta freeze" means "upload every package with a build time >= $some_large_number"
[21:15]  * micahg is glad there's not another chromium upload pending
[21:15] <micahg> although, if we figure out armhf, I'm happy to do one
[21:16] <infinity> Well, I have a failed build tree sitting on my QuickStart.  Maybe I'll prod it with a stick over the weekend if I don't find a social life and/or nap.
[21:34] <NCommander> skaet: thanks, got the link handy
[21:35] <skaet> http://pad.ubuntu.com/ubuntu-release
[21:35] <skaet> :)
[21:35]  * skaet not sure to parse "got the link handy" as question or affirmation - so erring on side of overcommunicating it.  ;)
[21:39] <micahg> skaet: should I add the Ubuntustudio information to the pad?
[21:39] <skaet> micahg,  yes please
[21:40] <Riddell> evening
[21:41] <micahg> skaet: done
[21:57] <slangasek> the resolvconf in the queue would be very good to have before beta
[21:57] <slangasek> high-impact for upgrades from oneiric in some circumstances
[21:58] <Riddell> skaet: I can review it in 30 mins
[21:58] <skaet> Riddell,  thanks.
[21:59] <Riddell> um that was for slangasek
[21:59] <skaet> yup
[21:59] <slangasek> Riddell: ok, cheers :)
[22:07]  * skaet really likes seeing the package sets from the queuebot!
[22:09] <stgraber> will be even better once I get to add seeded-in-ubuntu and reverse build depends support to it
[22:09] <stgraber> so we'll have a magic "that package is affecting something that we ship" flag on IRC
[22:20] <infinity> ^-- fixes FTBFS with new libreoffice.
[22:23] <infinity> And syncpackage lies and thinks nlpsolver doesn't exist in Debian.  Grr.
[22:24] <infinity> Oh, or maybe the experimental upload is still in incoming.
[22:28] <micahg> infinity: probably, it's only been 3 hours :)
[22:28] <infinity> micahg: Yeah, yeah.
[22:28] <infinity> micahg: Rene's other upload made dinstall, I didn't really think about it.
[22:29] <micahg> openclipart?
[22:29] <infinity> (jodconverter and openclipart are both fixes to work with the new libreoffice, if someone other than me wants to accept them)
[22:37] <infinity> slangasek: Did you decide not to support "inet6 dhcp" intentionally?
[22:37] <infinity> slangasek: (Seems not, since your dns-ns regex looks for hex and colons...)
[22:45] <slangasek> infinity: didn't actually think about it too deeply - noticed when I was prepping the upload that inet6 wasn't in there, but this was just cleanup for the previous netcfg breakage
[22:46] <slangasek> stgraber: ^^ do you think resolvconf's "should tail be linked" handling needs to treat inet6 dhcp the same as inet dhcp?
[22:46] <infinity> slangasek: Alright.  Well, looks fine other than that.  Just seems like it's worth having the regex cover inet6, in case we care later and no one remembers why it doesn't work. :P
[22:47] <slangasek> there are rich bzr histories and bug logs ;)
[22:47] <slangasek> but yes, we can fix that quickly enough
[22:50] <stgraber> slangasek: "20:58 < stgraber> I think we could extend to cover "inet6 dhcp" too but it's not going to be a common use case"
[22:50] <stgraber> slangasek: I think it's easy enough to add and it should behave exactly like "inet dhcp" so that makes sense
[22:51] <slangasek> ah, missed that comment before, sorry
[22:51] <slangasek> ok, I'll stage that fix in bzr
[23:00] <Riddell> stgraber, skaet: uh oh, I broke the iso tracker http://iso.qa.ubuntu.com/qatracker/milestones/208/builds
[23:00] <skaet> Riddell,  define broke please
[23:00] <stgraber> Riddell: no you didn't ;) that's just my bad
[23:01] <stgraber> Riddell: it'll be all fine once the first build lands
[23:01] <stgraber> Riddell: I could actually just post the upgrade products that'll fix it
[23:01] <Riddell> stgraber: php error on that page
[23:01] <Riddell> stgraber: ok
[23:01] <stgraber> Riddell: fixed
[23:02] <stgraber> well, more like, fixed the reason why you were getting the crash ;)
[23:02] <stgraber> I'll fix the crash for good in trunk
[23:02] <stgraber> I thought I actually fixed that one, maybe I messed up or IS didn't pull the right version of the branch :)
[23:03] <Riddell> stgraber: voila
[23:03] <Riddell> stgraber: what's it written in?
[23:03] <stgraber> it's a Drupal plugin, so PHP
[23:04] <stgraber> or rather it's written in Drupal ;) considering how little raw PHP functions are actually called (kind of C++ vs Qt4-C++)
[23:06] <Riddell> I've done drupal modules before, it's all good until you can't work out the drupal way to do it and you're not sure if the raw PHP way is good enough
[23:06] <Riddell> which is just like drupal vs raw HTML for editing websites really
[23:07] <Riddell> ok who removed the trousers?  I know it's friday night but there's no call for that
[23:07] <infinity> Err, who mangled the preinstalled pipeline on the pad?
[23:08] <infinity> And dropped omap completely?
[23:08]  * infinity grumbles.
[23:08] <slangasek> not I
[23:08]  * Riddell is innocent this time
[23:10]  * infinity fixes.
[23:12] <stgraber> Riddell: yeah, the previous version of the tracker was meant for Drupal 4/5 and was an horrible mess with mixed raw html and raw php code ...
[23:12] <stgraber> Riddell: the new one is clean Drupal 7 using only Drupal functions and Drupal templating
[23:13] <stgraber> Riddell: so there's very very little html in the code and when that's the case, it's only as some prepend/append of some block in a standard Drupal form
[23:13] <stgraber> also the old Drupal didn't have an ORM so you had to do pretty much raw SQL :( that's all been dropped now and the current tracker is doing clean SQL queries through the ORM :)
[23:15] <Riddell> stgraber: ORM?
[23:16] <slangasek> object request manager
[23:16] <slangasek> not to be confused with ORLY
[23:17] <slangasek> oh, no, that's "object-relational mapping" in this context, isn't it :)
[23:18] <stgraber> yep
[23:18] <skaet> infinity,  I'm guilty
[23:18] <infinity> skaet: Tsk.
[23:18] <infinity> skaet: All fixed.
[23:18] <stgraber> Riddell: so that's basically something that gives you nice complete objects from database entries, doing all the joining for you
[23:18] <Riddell> skaet: pst, just blame it on brain damage, works every time for me
[23:19] <Riddell> infinity: how do I know if the live rootfs server has the latest livecd-rootfs ?
[23:19] <stgraber> Riddell: Drupal's isn't great to be honnest, I much prefer python-storm but it's still nice to have the abstraction layer and not have to care about the different DB engine or copy/pasting huge chunks of raw SQL :)
[23:19] <infinity> Riddell: They always do.
[23:19] <skaet> infinity,  omap images are in the manifest for this release, based on what I was hearing 2 days ago -- only for a couple of images,  and given the speed of the arm builds - fewer we're doing the better for the respins. :P
[23:19] <Riddell> infinity: hmm it's saying "bad project: kubuntu-active"
[23:19] <infinity> Riddell: Except if you had to update BuildLiveCD.
[23:19] <infinity> Riddell: Which you did. :)
[23:19] <infinity> Riddell: That requires manual intervention, since it lives outside the chroots.
[23:19] <Riddell> infinity: aah
[23:20] <Riddell> infinity: are you able to intervene manually?
[23:20] <infinity> Riddell: -> canonical/#{webops,is}
[23:20] <skaet> s/omap images/omap images for Ubuntu aren't/
[23:20] <Riddell> ok thanks
[23:20] <infinity> Riddell: I don't have access to those machines anymore.
[23:20] <infinity> skaet: I suspect there may have been some miscommunication.
[23:21]  * skaet was only aware of omap for ac100...
[23:21] <skaet> infinity,  likely
[23:21] <infinity> skaet: We dropped two images (armel+omap4 and armel+mx5), the rest are still being built currently.
[23:21] <slangasek> ac100 is not omap at all
[23:21] <skaet> slangasek, you're right.
[23:22] <infinity> Well, that amounts to 3 images, since it also affects ubuntu-server.
[23:22] <skaet> was thinking armel.... sigh.
[23:22] <slangasek> and my understanding is that we're keeping omap for now
[23:22] <infinity> armel+omap will be the one and only armel image we keep down the road.
[23:22] <infinity> Since the kernel comes from mainline, it's a decent one to keep for baseline smoketesting.
[23:22] <skaet> slangasek, inifinity,   stand by for an email to circulate amongst the parties so we can get the manifest cleaned up.
[23:23]  * skaet adds it to the todo
[23:23] <skaet> thanks for fixing inifinity - I won't touch until we get the manifest signed off on.
[23:23] <slangasek> note that the current pipeline there spits out images about as fast as they can get tested, anyway :)
[23:23] <infinity> skaet: This might be partially my fault.  I keep forgetting there's wiki documentation and manifests and such, as I just consider nusaskan's crontab to be authoritative. :/
[23:24]  * skaet chuckles and agrees
[23:24] <skaet> with slangasek's comments.
[23:24] <skaet> infinity,  np,  should have checked with you first before showing initiative.  ;)
[23:26]  * infinity goes to print a new t-shirt with "You should have checked with me before showing initiative."
[23:26] <infinity> It will go nicely with my "Let's assume I'm right, it'll save time."
[23:32] <slangasek> who here approved nova, swift, python-novaclient?  It looks like glance is supposed to go with that set
[23:33] <infinity> Not I.
[23:34]  * infinity wonders how that escalation of queue audit trails is going.
[23:35] <Riddell> slangasek: pitti I think, it was discussed at the release team meeting
[23:36]  * skaet is encouraging folks to comment on https://bugs.launchpad.net/launchpad/+bug/885739 and has pinged flacoste on it today
[23:36] <ubot2`> Launchpad bug 885739 in launchpad "queue and override manipulations should have an audit trail" [High,Triaged]
[23:37] <Riddell> can he fix the speed of queue while he's at it? :)
[23:37] <slangasek> Riddell: ah yes, thanks,
[23:38] <skaet> infinity,  looking forward to seeing you in those shirts.  :)
[23:38] <infinity> skaet: We have stakeholders from a few directions championing that bug, I'm a bit irked that it not gone past triaged since November.
[23:38] <skaet> infinity,  agreed
[23:40] <skaet> see comments encouraging other stakeholders to comment on the bug directly so the heat goes up.
[23:44]  * skaet plans on monitoring it daily now
[23:47] <skaet> slangasek,  any objections to a request to the rest of the release team members to start broadcasting in the channel when they approve something?
[23:48] <slangasek> seems reasonable tome
[23:48] <skaet> I see some do it,  and others not.   and agree its an overhead, but not sure we have other short term option for sanity.
[23:49] <Riddell> skaet: you mean when we queue accept something?
[23:49] <skaet> Riddell,  yes.
[23:49] <skaet> from unapproved or new
[23:49] <Riddell> skaet: just so you know who to blame?
[23:50] <skaet> Riddell,  so we can figure out who to ask questions of.
[23:50] <Riddell> that's a more polite way to put it :)
[23:50] <skaet> :)
[23:50] <Riddell> skaet: fine for beta freezes but I think general new processing has enough overhead as it is (as shown by nobody doing it for the last two weeks)
[23:51] <skaet> Riddell,  yes, its during the beta freezes and final freezes its important.
[23:51] <skaet> or rather most important/time critical
[23:51] <Riddell> that's fine
[23:51] <skaet> ScottK,  infinity, ^ any concerns?
[23:52] <infinity> Works for me.
[23:52] <skaet> NCommander, ^^ ?
[23:53]  * ScottK thought that's what the queuebot was for.
[23:53] <infinity> ScottK: Except the queuebot doesn't tell you who did the accept.
[23:53] <skaet> ScottK,  https://bugs.launchpad.net/launchpad/+bug/885739
[23:53] <ubot2`> Launchpad bug 885739 in launchpad "queue and override manipulations should have an audit trail" [High,Triaged]
[23:53] <ScottK> Sure.
[23:53] <infinity> (because it can't)
[23:53] <infinity> When it can, no more need to broadcast. ;)
[23:53] <skaet> +1
[23:54] <slangasek> skaet: oh, I agree with Riddell that we don't want to impose that overhead on NEW processing
[23:54]  * Riddell accepts alsa-utils
[23:55] <slangasek> since that's really quite separate from the freeze
[23:55] <slangasek> oh, and the glance accept above was me btw ;)
[23:55] <infinity> slangasek: Well, except for NEW during freezes, which can relate. :)
[23:56]  * ScottK doesn't understand why we need to know.
[23:57] <slangasek> infinity: the only way new can impact anything during a freeze is if it's an existing CD-affecting source that adds new binary packages, and in those cases we want the packages up-to-date for the milestone anyway
[23:57] <slangasek> ScottK: well, the triggering example was 4 related packages 3 of which were accepted
[23:58] <slangasek> and I was trying to figure out if that was intentional or accidental