[16:27] <roaksoax> rvba: howdy!! I was wondering if you guys already have a ETA for the multiple environments storage fix? I just wanna have on idea on when we can do the SRU
[16:29] <rvba> roaksoax: Hi.  We just finished sketching out a plan for this.  Now we're working on the code. End of next week seems like a reasonable ETA. <- allenap, what do you say?
[16:30] <allenap> rvba: Yeah, that sounds about right.
[16:32] <roaksoax> rvba: awesome, thanks!
[17:04] <roaksoax> rvba: so what are the reasons why trunk maas can't run in precise?
[17:04] <roaksoax> other than dependencies
[17:06] <rvba> roaksoax: there is only the dependencies issue AFAIK
[17:06] <rvba> The only reason we have 2 branches (trunk and 1.2) is because we added 2 new features in trunk that were considered "too much" to be SRUed.
[17:07] <roaksoax> rvba: which ones are those?
[17:07] <rvba> roaksoax: offline operation and user commissioning scripts
[17:08] <roaksoax> rvba: ack! thanks
[17:08] <rvba> np
[17:09] <roaksoax> rvba: and kernel params too
[17:10] <roaksoax> rvba: what are the dependencies that differ?
[17:11] <rvba> roaksoax: I think kernel params have been backported to 1.2
[17:11] <roaksoax> rvba: nah
[17:13] <roaksoax> rvba: what are the dependencies that trunk has that make it impossible to work on precise?
[17:14] <rvba> roaksoax: I don't know offhand
[17:14] <rvba> roaksoax: 1.2 and trunk are so similar that I even wonder how the dependencies differ…
[17:17] <roaksoax> rvba:  iirc bigjools did ssy that trunk wont eork in prrcise
[18:02] <roaksoax> rvba: ok this it what i'll do
[18:02] <roaksoax> rvba: i'll upload 1.2 to raring, then to precise-proposed and quantal-proposed before FF
[18:02] <roaksoax> rvba: once I do that, I'll upload trunk to raring
[18:02] <roaksoax> before FF
[18:02] <roaksoax> rvba: but then when your fix is really, will upload it to -precise-proposed and quantal-proposed
[18:03] <rvba> roaksoax: do we really have to upload now?
[18:04] <roaksoax> rvba: i', not really concerned with raring TBH
[18:04] <roaksoax> rvba: and the upload to -proposed will sit there for a while
[18:04] <roaksoax> rvba: and once it gets approved it will be there for SRU verification
[18:05] <roaksoax> so it is not really gonna be released right after upload
[18:05] <roaksoax> rvba: as far as raring, nobody will be upgrading current environments right? since raring is still in development
[18:05] <rvba> roaksoax: if yes, then I suggest you don't upload the last version.  But instead r 1438 in trunk and r 1361 in 1.2
[18:06] <roaksoax> rvba: the plan is to get multiple environments fix rather than a new feature for the SRU
[18:06] <rvba> Because we've changed the way the file storage works and that change will only be properly complete when the fix we're working on will be released.
[18:06] <roaksoax> smoser: ^^
[18:07] <roaksoax> rvba: right but upgrading from 1363 to 136X should be fixed right?
[18:08] <rvba> roaksoax: what do you mean?
[18:08] <smoser> ugh.
[18:08] <smoser> roaksoax, unless daviey or sru team told you otherwise, just upload something to raring. its a pre-relesae snapshot. thats fine. it has bugs.
[18:08] <roaksoax> rvba: so if I release 1363 (1.2) to raring, then I release 136X (which contains your fix), then upgrading will fix the problem right?
[18:09] <smoser> whether or not we wait for the multiple-environment bug fix or not to upload to -proposed (quantal and precise) is un-related.
[18:09] <roaksoax> smoser: yeah that's what I'm planning to do
[18:09] <smoser> and i'd just upload a trunk snapshot to raring.
[18:09] <smoser> somethign that passed basic test.
[18:10] <roaksoax> smoser: i'll upload lp:maas/1.2 to raring, then to {precise,quantal}-proposed, and since it is gonna sit there for a while we'll wait for the bug to be released in trunk and update -proposed . But in the meantime, upload a trunk snapshot
[18:10] <roaksoax> do I make sense?
[18:10] <rvba> roaksoax: it will, but it you use 1363 you might encounter serious bugs.
[18:11] <smoser> why do you bother uploading maas/1.2 to raring ?
[18:11] <roaksoax> rvba: yes which is why it will be sitting in -proposed :)
[18:11] <smoser> ugh.
[18:11] <smoser> don't upload something to -proposed that we're not happy to release.
[18:12] <rvba> +1
[18:12] <rvba> The bug we're fixing is really ugly.
[18:12] <smoser> but i'm do not think that this maas multi-user thing is significant.
[18:12] <smoser> no one is using that
[18:12] <smoser> and its not a regression
[18:12] <rvba> It is.
[18:12] <smoser> it is a regression from something in ubuntu ?
[18:13] <roaksoax> ok then I'll upload trunk to -raring
[18:13] <smoser> rvba, ?
[18:13] <roaksoax> trunk will be released as 1.3
[18:13] <roaksoax> and SRU will have 1.2~bzr136X, which is nowhere in the archives
[18:14] <smoser> wait to see if rvba says this is a regression, but otherwise, i'm fine with that.
[18:14] <rvba> smoser: this is really tricky tbh.
[18:14]  * rvba thinks
[18:14] <smoser> "tricky" isn't answering the question :)
[18:14] <roaksoax> if it gets rejected by the SRU team because we are backpoirting a new upstream which is nowhere in ubuntu, then we are screwed :)
[18:14] <rvba> smoser: That's why I need to think :)
[18:14] <smoser> roaksoax, honestly, if it does, then that is silly.
[18:15] <smoser> because, as you've suggested, there is a very stupid workaround for that process requirement.
[18:15] <roaksoax> smoser: well I came across a situation like that long time ago and was told "you can only backport something that is in the archive"
[18:15] <smoser> roaksoax, then if you want to, upload a 1.2 to raring. i'm fine with that too.
[18:16] <smoser> but i tihnk that it wont be a sticking issue on sru
[18:16] <rvba> smoser: I think it's a regression.  If you have 2 users, you'll definitely see a regression.
[18:16] <smoser> remember, you're also not allowed to entirely new packages
[18:16] <smoser> or features.
[18:16] <smoser> rvba, you see that if you have 2 users on current quantal mas and you upgrade to 1.2 ?
[18:17] <smoser> is that what your'e saying ?
[18:17] <rvba> Yes.
[18:17] <smoser> if only we had unit tests
[18:17] <smoser> then we'd neer see bugs like this.
[18:17] <smoser> roaksoax, i say hold off on it then. i dont want to upload a regression to sru.
[18:18] <roaksoax> smoser: right but this time we got a TB exeption
[18:18] <smoser> but imo upload whatever you want to raring. we're already in major exception mode.
[18:18] <smoser> this little thing is a very minor exception.
[18:18] <rvba> smoser: this problem is not because of the lack of unit tests.  It;s because we had to rush something to meet a crazy deadline at some point, and now we're paying the price for it.
[18:18] <roaksoax> i will just upload trunk to raring
[18:19] <smoser> and doing the dance to avoid that exception will cause you to make another exception (FFE)
[18:19] <roaksoax> i'll continue as suggested, upload trunk (1.3) to raring, and SRU 1.2
[18:20] <smoser> roaksoax, right. but dont bother sruing without the fix for bug 11239986
[18:20] <smoser> 1123986
[18:20] <roaksoax> smoser: i won't SRU until it gets fixed
[18:20] <rvba> roaksoax: why don't you upload 1.2 revision 1361 and trunk revision 1438 ?
[18:21] <roaksoax> rvba: 1263 has IPMI fixes
[18:21] <roaksoax> err 1363
[18:21] <rvba> The problem is only that right now, we're half way through fixing the multiple env bug.
[18:22] <roaksoax> and I need to make available those IPMI fixes to raring too
[18:22] <roaksoax> but we need tests for them
[18:22] <roaksoax> so that will take me couple days maybe
[18:22] <roaksoax> and then i'll upload trunk to raring
[18:22] <roaksoax> wait for your fix
[18:23] <roaksoax> and upload 1.2 tyo -proposed
[18:23] <rvba> Ok, I take it no one is using raring in prod now so it does not really matter.
[18:24] <roaksoax> exactly
[18:24] <rvba> Just don't upload the current tip of trunk or 1.2 before next week's fix to an important place :)
[18:25] <roaksoax> raring is fine to have bugs so raring is not really a concern
[18:25] <rvba> Right.
[18:26] <rvba> So you'll wait until next week for the other uploads right?
[18:30] <roaksoax> rvba: yeah
[18:30] <rvba> roaksoax: ok, thanks.
[18:30] <roaksoax> rvba: no worries :) just fix that bug i'll take care of the rest :)
[18:30] <rvba> roaksoax: we're on it, you can trust me.
[18:32] <roaksoax> i do :)
[18:32] <roaksoax> you've never disappointed so I'm really not concerned :)
[18:34] <rvba> Good :)


[00:00] <mbarnett> who knows where you could find one of those!?
[06:49] <LPCIBot> Project db-devel build (278): FAILURE in 5 min 10 sec: https://hudson.wedontsleep.org/job/db-devel/278/
[07:01] <LPCIBot> Project db-devel build (279): STILL FAILING in 0.47 sec: https://hudson.wedontsleep.org/job/db-devel/279/
[07:16] <LPCIBot> Project db-devel build (280): STILL FAILING in 0.47 sec: https://hudson.wedontsleep.org/job/db-devel/280/
[07:31] <LPCIBot> Project db-devel build (281): STILL FAILING in 0.46 sec: https://hudson.wedontsleep.org/job/db-devel/281/
[07:46] <LPCIBot> Project db-devel build (282): STILL FAILING in 0.47 sec: https://hudson.wedontsleep.org/job/db-devel/282/
[08:01] <LPCIBot> Project db-devel build (283): STILL FAILING in 0.46 sec: https://hudson.wedontsleep.org/job/db-devel/283/
[08:16] <LPCIBot> Project db-devel build (284): STILL FAILING in 1.3 sec: https://hudson.wedontsleep.org/job/db-devel/284/
[08:31] <LPCIBot> Project db-devel build (285): STILL FAILING in 0.46 sec: https://hudson.wedontsleep.org/job/db-devel/285/
[08:46] <LPCIBot> Project db-devel build (286): STILL FAILING in 0.49 sec: https://hudson.wedontsleep.org/job/db-devel/286/
[09:01] <LPCIBot> Project db-devel build (287): STILL FAILING in 0.48 sec: https://hudson.wedontsleep.org/job/db-devel/287/
[09:16] <LPCIBot> Project db-devel build (288): STILL FAILING in 0.49 sec: https://hudson.wedontsleep.org/job/db-devel/288/
[09:31] <LPCIBot> Project db-devel build (289): STILL FAILING in 0.48 sec: https://hudson.wedontsleep.org/job/db-devel/289/
[09:46] <LPCIBot> Project db-devel build (290): STILL FAILING in 0.46 sec: https://hudson.wedontsleep.org/job/db-devel/290/
[10:01] <LPCIBot> Project db-devel build (291): STILL FAILING in 0.48 sec: https://hudson.wedontsleep.org/job/db-devel/291/
[10:16] <LPCIBot> Project db-devel build (292): STILL FAILING in 1.9 sec: https://hudson.wedontsleep.org/job/db-devel/292/
[10:31] <LPCIBot> Project db-devel build (293): STILL FAILING in 0.48 sec: https://hudson.wedontsleep.org/job/db-devel/293/
[10:46] <LPCIBot> Project db-devel build (294): STILL FAILING in 0.46 sec: https://hudson.wedontsleep.org/job/db-devel/294/
[11:01] <LPCIBot> Project db-devel build (295): STILL FAILING in 0.48 sec: https://hudson.wedontsleep.org/job/db-devel/295/
[11:16] <LPCIBot> Project db-devel build (296): STILL FAILING in 0.48 sec: https://hudson.wedontsleep.org/job/db-devel/296/
[11:31] <LPCIBot> Project db-devel build (297): STILL FAILING in 0.49 sec: https://hudson.wedontsleep.org/job/db-devel/297/
[11:46] <LPCIBot> Project db-devel build (298): STILL FAILING in 0.47 sec: https://hudson.wedontsleep.org/job/db-devel/298/
[12:01] <LPCIBot> Project db-devel build (299): STILL FAILING in 0.46 sec: https://hudson.wedontsleep.org/job/db-devel/299/
[12:16] <LPCIBot> Project db-devel build (300): STILL FAILING in 0.47 sec: https://hudson.wedontsleep.org/job/db-devel/300/
[12:31] <LPCIBot> Project db-devel build (301): STILL FAILING in 0.46 sec: https://hudson.wedontsleep.org/job/db-devel/301/
[12:46] <LPCIBot> Project db-devel build (302): STILL FAILING in 0.46 sec: https://hudson.wedontsleep.org/job/db-devel/302/
[13:01] <LPCIBot> Project db-devel build (303): STILL FAILING in 0.45 sec: https://hudson.wedontsleep.org/job/db-devel/303/
[13:16] <LPCIBot> Project db-devel build (304): STILL FAILING in 2.5 sec: https://hudson.wedontsleep.org/job/db-devel/304/
[13:31] <LPCIBot> Project db-devel build (305): STILL FAILING in 0.48 sec: https://hudson.wedontsleep.org/job/db-devel/305/
[13:34] <wgrant> Hmm.
[13:34] <wgrant> I wonder if telling it to wipe out its workspace will work.
[13:46] <LPCIBot> Project db-devel build (306): STILL FAILING in 0.45 sec: https://hudson.wedontsleep.org/job/db-devel/306/
[14:01] <LPCIBot> Project db-devel build (307): STILL FAILING in 0.46 sec: https://hudson.wedontsleep.org/job/db-devel/307/
[14:16] <LPCIBot> Project db-devel build (308): STILL FAILING in 0.49 sec: https://hudson.wedontsleep.org/job/db-devel/308/
[14:33] <LPCIBot> Project db-devel build (309): STILL FAILING in 0.47 sec: https://hudson.wedontsleep.org/job/db-devel/309/
[14:46] <LPCIBot> Project db-devel build (310): STILL FAILING in 0.46 sec: https://hudson.wedontsleep.org/job/db-devel/310/
[15:01] <LPCIBot> Project db-devel build (311): STILL FAILING in 0.47 sec: https://hudson.wedontsleep.org/job/db-devel/311/
[18:02] <Ursinha> lifeless, tell me four bugs that annoy you in qa-tagger
[18:06] <jelmer> thumper: niiiice
[18:07] <thumper> jelmer: there are some wording changes on the qastaging copy
[18:07] <thumper> but the view is the same
[18:08] <jelmer> like many of the other recipe builds it would be nice if the last successful build or at least whether the last build was successful could be shown
[18:17] <lifeless> Ursinha:<PHONE_NUMBER>09<PHONE_NUMBER>73(but really just about usability in the report)
[18:19] <Ursinha> lifeless, cool
[18:19] <Ursinha> bug 674829 bug 671809 bug 681099 bug 688073
[18:19] <_mup_> Bug #674829: Deployment report for db-stable is broken. <qa-tagger:Fix Committed by ursinha> < https://launchpad.net/bugs/674829 >
[18:19] <_mup_> Bug #671809: bug mail should use the header from the bug thread rather than 'Bug fixed by a commit' <qa-tagger:Triaged> < https://launchpad.net/bugs/671809 >
[18:19] <_mup_> Bug #681099: bug=1234 merges without lp metadata don't show up in the deployment report <qa-tagger:Triaged> < https://launchpad.net/bugs/681099 >
[18:19] <_mup_> Bug #688073: qa-needstesting revisions should not be greyed out <deployment-qa> <qa-tagger:Triaged> < https://launchpad.net/bugs/688073 >
[18:20] <Ursinha> lifeless, now the big ones
[18:20] <Ursinha> lifeless, I don't plan to abandon qa-tagger, it's my child :P
[18:52] <lifeless> Ursinha: \o/
[18:52] <lifeless> Ursinha: Hopefully you will welcome assistance from the team though :>
[19:04] <Ursinha> hehe, lifeless, of course :)
[19:49] <lifeless> wgrant: https://bugs.launchpad.net/launchpad/+bug/704585
[19:49] <_mup_> Bug #704585: canonical_url performs poorly <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/704585 >
[19:53] <jelmer> StevenK: https://code.launchpad.net/~jelmer/ubuntu/natty/paramiko/randompool+addressfamilies/+merge/46669
[20:08] <StevenK> jelmer: https://code.launchpad.net/~stevenk/launchpad/more-thunder/+merge/46406
[20:11] <gmb> gary_poster: http://pastebin.ubuntu.com/555534/
[20:11] <lifeless> gmb: sooooooooo
[20:11] <lifeless> gmb: there is a bug you should see
[20:11] <gmb> lifeless: Just one? Win.
[20:11] <gmb> Link me.
[20:11] <LPCIBot> Project db-devel build (312): STILL FAILING in 4 hr 55 min: https://hudson.wedontsleep.org/job/db-devel/312/
[20:14] <lifeless> gmb: bug 507603
[20:14] <_mup_> Bug #507603: checkwatches on non-debian debbugs instances do not work <bugwatch> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/507603 >
[20:14]  * gmb looks
[20:15] <gmb> lifeless: Noted. And thanks for pointing out that it's a different debbugs DB. I was apparently suffering from an acute uptake-grasping deficiency disorder on the day when I first responded to that bug.
[20:16] <lifeless> is that a hard thing to do
[20:16] <lifeless> like
[20:16] <lifeless> did we need special arrangements to sync the db
[20:17] <jml> thumper: reviewed your patch.
[20:20] <allenap> rvb: http://wiki.bazaar.canonical.com/BzrPipeline
[20:23] <lifeless> matsubara: hi
[20:23] <matsubara> hey lifeless
[20:23] <lifeless> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1844B1523 is on disk on devpad, web ui is refusing to show it
[20:23] <lifeless> how do I debug whats going on ?
[20:23] <matsubara> working on it
[20:23] <matsubara> lifeless, I rolled out some code yesterday which broke the OopsLoader
[20:24] <lifeless> kk
[20:24] <wgrant> Ah, I was about to ask about that myself.
[20:28] <gmb> lifeless: Yes, we need to make arrangements to sync the DB to some place on loganberry. We don't support > 1 debbugs DB, either; the code is written for just the one of them.
[20:28] <lifeless> yeah
[20:28] <lifeless> so code change + a faq
[20:29] <gmb> lifeless: Yes.
[20:35] <gary_poster> mars, yoo hoo....  anyone seen a mars?
[20:35] <jml> gary_poster: he's here, getting trained in some hiring software
[20:41] <bigjools> jelmer: are you busy?
[20:48] <allenap> sinzui: Do you generate a web page of the XXXs in the code?
[20:48] <sinzui> I used to
[20:49] <sinzui> I may still
[20:49]  * sinzui looks
[20:49] <bigjools> it was on devpad IIRC
[20:49] <wgrant> There's a script in utilities/
[20:49] <wgrant> stub: Bug #526890 is probably fixed now that the auth store is gone, right?
[20:49] <_mup_> Bug #526890: Oops on export page: LocationError: (None, 'email') <lp-translations> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/526890 >
[20:50] <sinzui> allenap, I do not the script to create the xxx report is in./utilities
[20:51] <stub> closed
[20:52] <wgrant> Thanks.
[20:54] <jelmer> bigjools: hi
[20:55] <bigjools> jelmer: heyhey.  Can we talk about your outstanding bugs/branches?
[20:55] <jelmer> bigjools: yes, sure. where are you?
[20:55] <bigjools> jelmer: presidente
[21:05] <gmb> I want it noted that JS is hateful and should be shot.
[21:05] <gmb> Can we implement in-browser LISP at some point? It'd be more fun.
[21:07] <jtv> Did we just land any changes to how we tally Rosetta usage?  The translatable-projects listing on qastaging is over a thousand projects short.
[21:07] <dobey> gmb: http://kybernetikos.github.com/Javathcript/
[21:12] <mwhudson> dobey: i bet he started that because he came up with the project name and then couldn't resist implementing it
[21:13] <lifeless> gmb: oh also
[21:13] <lifeless> flags in the api; we need to talk- I think you're on crack
[21:13] <gmb> lifeless: I'm open to the idea of being on crack.
[21:14] <gmb> When I filed the bug I was feeling quite punchy about using feature flags with JS features. I haven't thought in depth about the arguments for not doing it, though.
[21:15] <lifeless> oh in js is great
[21:15] <lifeless> I'd just set the variables you need in the .pt
[21:16] <lifeless> or does that not work?
[21:20] <dobey> mwhudson: heh
[21:21] <gmb> lifeless: It works; it felt like a hack.
[21:22] <gmb> lifeless: But if you're happy for it to be done that way, let's do it that way. I'm all for uncomplicated solutions.
[21:22] <gmb> My frustration wasn't helped by bugtask_index.js shenanigans that I told you about on Sunday.
[21:22] <gmb> So feel free to mark that as BugTaskStatus.REPORTER_ON_CRACK.
[21:28] <matsubara> wgrant, lifeless: OopsLoader is fixed and it's now catching up. that oops should be available soon
[21:28] <wgrant> matsubara: Thanks.
[21:29] <matsubara> np
[21:30] <lifeless> matsubara: awesome thanks
[21:32] <lifeless> leonardr: hey
[21:32] <lifeless> leonardr: I'd like to learn a little more about how launchpadlib api authentication happens
[21:32] <lifeless> do you think you can spare a few minutes to teach me?
[21:35] <leonardr> lifeless: yes, i need a minute though
[21:35] <leonardr> we can do it on irc or irl
[21:39] <lifeless> I'm in the plenary room
[21:40] <leonardr> ok, be there soon
[21:53] <jtv> allenap: is there any innate ordering to bug subscriptions?  Seems I/we broke bugsubscription.txt line 866, in the ordering of getDirectBugSubscriptions() output.
[21:53] <jtv> rvb: interested in doing that translations bugfix I mentioned?
[21:54] <allenap> jtv: Interesting. Bug.getDirectSubscriptions() returns a newfangled BugSubscriptionSet object.
[21:55] <allenap> jtv: Which is a subclass of frozenset.
[21:55] <allenap> jtv: It has a .sorted property that might help you.
[21:55] <jtv> allenap: but the breakage is entirely arbitrary and the test is wrong to depend on the ordering of a frozenset, right?
[21:56] <allenap> jtv: Yes. I assume I missed the ordering problem when changing getDirectSubscriptions recently.
[21:56] <jtv> help(frozenset) doesn't tell me anything about "sort"
[21:56] <allenap> jtv: BugSubscriptionSet is special :)
[21:56]  * jtv winces at that word
[21:57] <allenap> jtv: It's special in a nice way.
[21:57] <rvb> jtv: sure
[21:59] <jtv> rvb: I'm in the plenary room… want to come over or do you have a better spot?
[21:59] <rvb> I'll come over in just a sec
[22:02] <jtv> jcsackett: find anything interesting in the translated-projects code?
[22:03] <jcsackett> jtv: haven't actually had a chance to look at it, to be honest, but as i need a break from what i'm doing i'll take a look right now.
[22:03] <jtv> jcsackett: cool, thanks!
[22:09] <rvb> jtv: I'm sorry it's taking longer than I tought ... I'm working on a bug with Julian
[22:10] <jtv> rvb: no worries—I can also just go ahead and get it done, if you don't feel you'll get around to it.
[22:10] <poolie> is it a known bug about 'POST /+request-token' failing with 403?
[22:10] <poolie> or maybe this is my bug
[22:10] <StevenK> poolie: Is it POSTing to edge?
[22:12] <wgrant> matsubara: Is the oops thingy still broken, or just not caught up yet?
[22:12] <matsubara> wgrant, not caught up. almost there.
[22:13] <rvb> jtv: If you have other things to do right now, I'll be happy to be on you side while you fixe this bug really
[22:13] <jtv> rvb: plenty of things to do… maybe I'll just concentrate on the workaround first.
[22:13] <jtv> (I'll ask an admin to grant the required extra database permission first)
[22:14] <poolie> StevenK, yes it was
[22:14] <poolie> i've updated it but it still seems like a bug
[22:14] <wgrant> poolie: Ugh what?
[22:14] <wgrant> launchpadlib?
[22:14] <poolie> yes
[22:15] <wgrant> Ugh.
[22:15] <poolie> bug 704664
[22:15] <_mup_> Bug #704664: 403 on post to edge /+request-token <Launchpad itself:New> < https://launchpad.net/bugs/704664 >
[22:15] <matsubara> wgrant, it's available now
[22:16]  * bigjools has Launchpadlurgy
[22:16] <wgrant> matsubara: Indeed, thanks.
[22:16] <wgrant> bigjools: Already? :(
[22:16] <bigjools> already
[22:16] <bigjools> the Berocca is not quite doing the trick
[22:18] <jml> are you pumped?
[22:31] <jml> are we running the latest bzr-builder on our slaves?
[22:32] <jml> (also, how would I find out without asking here)
[22:38] <bigjools> jml: ask a buildd admin (ie lamont)
[22:38] <Ursinha> is it possible to set a merge proposal to a status other than "approved" or "rejected" using the email interface?
[22:39] <jml> hmm.
[22:39] <Ursinha> jml, I totally forgot you used to be a code guy
[22:39] <jml> Ursinha: heh
[22:39] <jml> Ursinha: actually, I have no idea. I just looked at https://help.launchpad.net/Code/Review#Email%20interface :)
[22:40] <Ursinha> jml, :) that page only has approve and reject
[22:41] <bigjools> jml: he's responsible for what's installed on the builders
[22:48] <jml> bigjools: ok, thanks.
[22:50] <lifeless> how do we tell if karma isn't updating?
[22:52] <wgrant> scriptactivity spam is spammy.
[22:53] <spm> it should be silent.....
[23:07] <sinzui> wgrant, https://bugs.launchpad.net/launchpad/+bug/697441
[23:07] <_mup_> Bug #697441: buildmailman fails under natty <build-infrastructure> <mailing-lists> <python-upgrade> <Launchpad itself:Triaged> < https://launchpad.net/bugs/697441 >
[23:40] <allenap> lifeless: https://wiki.canonical.com/Launchpad/Strategy/DesignDiscussionDallas2011
[23:51] <wgrant> gmb: bin/kill-test-services
[23:52] <gmb> wgrant: Ooh, that's a start. Ta.
[23:52] <wgrant> Also, the librarian fixture branch that someone should be landing soon.
[23:56] <gmb> wgrant: Bum. No, that didn't help any. I'll leave it for now; I'm going square-eyed. Thanks anyway.


[04:57] <elopio_> veebers: do you have any reply for this? https://code.launchpad.net/~townsend/autopilot/fix-gcalctool-desktop-file/+merge/256702
[04:58] <elopio_> I wanted to tell him to change his test to do a normal launch hardcoding the app info in his branch instead, but I'm not sure if you have other plans.
[05:01] <veebers> elopio_: lol that fix is the opposite of the fix that we needed recently for autopilot. I have no comment, a quick fix for the legacy branch seems fine
[05:01] <veebers> I want to fix that within autopilot though, it's pretty crummy
[05:02] <veebers> elopio_: I'm off, I might be back later though
[05:03] <veebers> elopio_: to answer your questions: legacy reasons :-) this is really old part of autopilot / unity7 tests (i.e. launching known apps to test the desktop with).
[07:26] <pitti> jibel: FTR, I created wily i386/amd64 VMs everywhere, and updated most vivid->wily things in lp:a-p-t
[07:27] <pitti> jibel: so I guess we'll need to copy the jobs now, to give adt-britney something to chew? :-)
[07:27] <pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[07:28] <jibel> pitti, yep, I'll create the views on jenkins
[07:29] <pitti> jibel: the views are nice of course, but what will cause the actual jobs to get created? does that need further changes somewhere?
[07:29] <pitti> jibel: or just the RELEASE= bit in a-p-t?
[07:29] <jibel> pitti, no, that won't create the job, I'll create the job afterwards, otherwise I won't be able to see what is created automatically
[07:30] <jibel> actually I might not be able to do that anymore, they removed my privileges
[07:30] <jibel> I'll try
[07:30] <pitti> jibel: want me to copy/set up setup-testbed and setup-lxc for now?
[07:30] <pitti> jibel: or will that get in the way of your mass-copy?
[07:30] <jibel> pitti, i'll do it
[07:31] <pitti> *nod*
[07:31] <pitti> jibel: we'll need to leave setup-testbed disabled for now (I'll update the VMs manually every now and then until we get cloud images)
[07:43] <jibel> pitti, you setup proposed-migration on snakefruit?
[07:43] <pitti> jibel: I didn't; if you tell me how, I'm happy to
[07:43] <jibel> pitti, someone did it apparently
[07:44] <pitti> jibel: then infinity, I guess
[07:44] <pitti> jibel: he asked me this morning about adt-britney support for wily
[07:44] <jibel> ok
[07:44] <pitti> jibel: I pulled a-p-t there now
[08:36] <pitti> jibel: can we disable the old-style VMs part in http://d-jenkins.ubuntu-ci:8080/job/wily-adt-setup-testbed/configure and enable your new DKMS bit now?
[08:37] <jibel> pitti, no, not yet, we still need it for custom kernels
[08:37] <pitti> jibel: I'll verify and enable setup-lxc
[08:37] <pitti> jibel: ah, I'll build the old-style VMs for wily on wazn then
[08:37] <jibel> pitti, the new dkms bit only works for the default kernle
[08:37] <pitti> jibel: ok; can we still turn this on to see how it goes?
[08:38] <jibel> pitti, sure, I'll push the code
[08:38] <jibel> pitti, don't you prefer to wait for a first successful run of britney?
[08:39] <pitti> jibel: ah, ok
[09:40] <dkessel> DanChapman: thanks for wanting to look into the automatic image testing issues!
[09:43] <brendand_> ubuntu-qa - a review of https://code.launchpad.net/~canonical-platform-qa/unity-scope-click/wait_for_search_button/+merge/258002 much appreciated
[09:45] <davmor2> brendand_: why the _ ?
[09:52] <brendand_> davmor2, dunno
[09:52] <brendand_> davmor2, won't let me change it
[09:52] <brendand_> davmor2, probably someone else logged in with it
[09:58] <jibel> pitti, there are 2 jobs in the queue but no executors
[09:59] <pitti> jibel: because of the long build queue?
[10:00] <pitti> http://d-jenkins.ubuntu-ci:8080/job/wily-adt-mpich/1/console
[10:00] <pitti> jibel: that just says that it's waiting for an executor?
[10:00] <jibel> pitti, yes
[10:01] <jibel> pitti, new glibc in vivid?
[10:01] <pitti> jibel: new KDE
[10:02] <jibel> ah
[10:02] <jibel> + new kernel
[10:28] <pitti> jibel: old-style VMs created for wily on wazn
[10:40] <jibel> pitti, thanks, I'll find some time to finish porting the old-style dkms tests to autopkgtest
[10:53] <pitti> jibel: http://d-jenkins.ubuntu-ci:8080/view/Wily/view/AutoPkgTest/ \o/
[11:43] <jibel> pitti, do you want me to trigger $world for wily or wait a bit?
[12:33] <pitti> jibel: oh, do we need to? i. e. not just copy the last successful result?
[12:33] <jibel> pitti, no we don't have to
[12:33] <pitti> jibel: if so, sure -- aside from armhf the queues have caught up
[12:34] <pitti> but we need to copy the last successful vivid result either way, no?
[12:34] <jibel> pitti, history has been copied over from vivid, it's all good
[12:34] <pitti> to detect regressions
[12:34] <pitti> ah, great
[12:34] <pitti> jibel: many thanks
[12:34] <jibel> lets save some CPU cycle and some trees :)
[12:35] <jibel> pitti, I'll wait next publisher run to make sure results are copied back to britney and push the code to enable dkms
[12:36] <pitti> \o/
[13:02] <jibel> pitti, results have been synced. pushing the patch for dkms
[13:08] <jibel> well, I've to fix the grep-dctrl command first :)
[13:25] <jibel> pitti, the expression in detect in autodep8 returns 23 dkms packages while there are 40 in vivid
[13:25] <jibel> with main, universe, restricted and multiverse enabled
[13:33] <jibel> nm, if I consider all the apt index files it's better :)
[13:39] <jibel> pitti, so, there'll be some dkms packages missing because proposed migration only uses sources files
[13:41] <jibel> for example there is nothing in restricted_source that tells if nvidia is a dkms package or not
[14:50] <pitti> jibel: ah, I thought we were looking at binary packages
[14:50] <pitti> jibel: wrote that down as TODO, it's quick email/UOS time now
[14:52] <jibel> pitti, proposed-migration reads source packages for an XS-Testsuite header matching autopkgtest. The place where we added dkms detection will read the same sources
[14:53] <jibel> pitti, anyway we can start with that
[14:53] <pitti> jibel: agreed, let's see how these 24 perform now
[14:53] <jibel> pitti, okay to push http://paste.ubuntu.com/10990321/ ?
[14:54] <jibel> pitti, it's basically the same thing we did at the sprint fixed to be python compliant
[14:55] <jibel> (removed some quotes and escape characters and use source files instead of debian/control)
[14:55] <pitti> jibel: LGTM, let's roll with that and see how it goes?
[14:55] <pitti> jibel: and we'll refine later (maybe just add a static list for now)
[15:21] <jibel> pitti, pushed
[15:22] <pitti> jibel: go, go, go! :-)
[15:23] <pitti> jibel: now we just need to upload something which triggers them :)
[15:23] <jibel> pitti, I'll tail britney's logs before cjwatson pings me telling I broke it ;)
[15:29] <elopio> vila: fgimenez: published the trusty versions.
[15:29] <elopio> I think. I'm still a newbie with ppas.
[15:30] <fgimenez> elopio, ok thanks lot, i'll relaunch the job
[15:32] <vila> elopio: right, you copied the vivid versions ;) recipes are a bit easier to build for multiple releases at once (and provide clearer versions too IMO)
[15:32] <fgimenez> elopio, perfect, it liked your ppa ;)
[15:33] <elopio> vila: how do I make a recipe?
[15:33] <elopio> ah, nevermind. I'll just search the launchpad docs when I have some free time.
[15:35] <vila> elopio: from a branch you click the 'Create packaging recipe' button
[15:35] <vila> elopio: the most painful part is to select the target PPA in the huge list
[15:46] <tych0> hello
[15:46] <alesage> balloons receiving some bad news about the LXD session, tych0 realizing he has a conflict
[15:51] <balloons> tych0, ohh.. when can we reschedule?
[15:52] <tych0> balloons: i could do tomorrow at the same time?
[15:54] <balloons> alesage, you should have the power to move things around.
[15:54] <balloons> tych0, we are full schedule but we can try and fit. if you can't do it today, you can't do it :-)
[15:54] <tych0> balloons: yeah, sorry
[15:54] <balloons> meaning, we'll make it work for later
[15:54] <alesage> balloons, will this make a conflict with an existing session? --right ok
[15:54] <tych0> well, or anyt ime really
[15:54] <balloons> sorry, not to confuse. I mean, if today doesn't work, pull it off the schedule and we'll make it work later
[15:55] <tych0> balloons: sure, understood
[15:55] <balloons> but it will be hard. just have a look at the schedule and see
[15:56] <alesage> balloons, tych0 there's an empty slot Thursday 16:00 ?
[15:57] <alesage> tych0, which I think is 3:00 PM for you?
[15:57] <tych0> alesage: 1600 UTC?
[15:57] <alesage> tych0, yessir
[15:58] <tych0> hm, i think that's 10AM MDT unless i'm misunderstanding
[15:58] <alesage> tych0, or sorry, 10:00 AM my mistake in CO
[15:58] <tych0> but yeah, that works
[15:58] <alesage> tych0, you're right, I'm bad at math
[15:58] <alesage> tycho ok I'll move the session if you're willing :)
[15:58] <tych0> alesage: sure, works for me
[15:58] <alesage> tych0, great
[18:49] <balloons> elopio, ready for the helpers session.
[18:49] <elopio> balloons: almost, just recording the last demo.
[18:49] <balloons> I'll set everything up
[18:54] <elopio> balloons: can you send the official documentation links to the channel when we start?
[18:55] <elopio> I have my history full of old links
[18:55] <balloons> elopio, yes
[18:58] <elopio> veebers: #ubuntu-uos-appdev
[19:56] <elopio> balloons: the three unity8 branches are in a silo. After that lands, we can propose the namespace refactor + sphinx.
[20:03] <balloons> elopio, awesomeness
[20:20] <bip> Hello :)
[20:25] <bip> All to work? ;-)
[20:32] <elopio> bip: hello
[20:33] <bip> Hello elopio :)
[21:37] <Noskcaj> hi bip
[21:38] <bip> Hey man! sorry for disturb! :)
[21:38] <Noskcaj> You can test ISOs on virtual machines if you want, it sppeds up the process of testing so most people use VMs
[21:38] <Noskcaj> *speeds
[21:39] <bip> Noskcaj: ok. There's a standard option for a good testing? Type 1 Gb ram - 20 gb hdd etc?
[21:39] <Noskcaj> That should be enough, as long as there is enough hdd space to install, anything should work
[21:40] <bip> Noskcaj: you're a ISO Tester?
[21:41] <Noskcaj> I started my ubuntu contributions with iso testing, i mostly do packaging work now
[21:41] <bip> Noskcaj: perfect i think is a good start for me in this team :)
[21:41] <Noskcaj> :)
[21:41] <bip> Noskcaj: can you help me in this startup ?
[21:42] <Noskcaj> sure.
[21:42] <Noskcaj> If you're using a GUI, you might want to have a look at the program "testdrive"
[21:42] <Noskcaj> It's not super well maintained, but it allows you to sync the current iso and automatically makes a VM with it
[21:43] <bip> Noskcaj: yes on server i got KDE. This becouse i make some Organizzation Test :)
[21:45] <bip> Donwload.
[21:46] <bip> Noskcaj: very good idea. Thx you. Now I'm download Vivid-Desktop-amd64.iso (10 min)


[07:21] <one> What is the most direct way to obtain the source corresponding to the currently running Ubuntu generic kernel?
[07:21] <one> apt-get is pulling linux-meta and the results are a newerr version that doesn't support the same crypto
[07:28] <one> Hi
[08:19] <apw> one (N,BFTL), the easiest is probabally to look at the tags in the git repositories at kernel.ubuntu.com/ubuntu/ubuntu-<series>.git
[09:18] <one> Hi
[09:19] <one> WHat is the most direct way to obtain the kernel source?
[09:20] <one> For a spcific version. Matching what is currently run on the system used.
[09:28] <apw> one, the easiest is probabally to look at the tags in the git repositories at kernel.ubuntu.com/ubuntu/ubuntu-<series>.git
[09:28] <apw> one, or pull-lp-source -d linux <version>
[09:34] <one> apw: looking at the versions
[09:34] <one> what are 'tags' I do not want to do any more 'cooldude; lingo
[09:35] <one> The version closest to the kern I am looking for just contains a 'metasource' package in place of where the sourcecode is usually located
[09:35] <lag> apw: Hola
[09:36] <lag> apw: A friend of mine is complaining that the Ubuntu repos are pretty slow - are there alternatives?
[09:37] <amitk> lag: mirrors?
[09:37] <lag> amitk: Looking here now: https://wiki.ubuntu.com/Mirrors
[09:38] <lag> amitk: Now here: https://launchpad.net/ubuntu/+archivemirrors
[09:40] <one> Why is the sourcecode hidden?
[09:40] <amitk> lag: http://askubuntu.com/questions/39922/how-do-you-select-the-fastest-mirror-from-the-command-line
[09:41] <amitk> lag: though the installer should select the best mirror
[09:42] <lag> amitk: "It's coming down faster now" :)
[09:42] <amitk> heh
[09:43] <one> Why is the sourcecode hidden?
[09:45] <amitk> one: https://wiki.ubuntu.com/Kernel/SourceCode
[09:49] <apw> one the source code is not hidden, it is either in our git repo or in the source package for the linux-image-* package that contains your kernels
[09:51] <apw> one, i assume you are looking at the meta-package package such as "linux-image-generic" which comes from a different source, and is part of the mechanism which lets you have a "current" and "previous" kernels
[09:52] <apw> a very special feature of the kernel packages
[09:54] <apw> as amitk says that wiki page has all the details on how to obtain it easily
[09:56] <one> apw no looking at the git repo
[09:57] <one> apw no, looking at the git repo and the source tree includes linux-meta that just has a few text files
[09:57] <one> apw: Where is the actual sourcecode?
[09:57] <apw> in the right git repo
[09:57] <apw> which release are you on
[09:57] <amitk> one: read the fine manual: https://wiki.ubuntu.com/Kernel/SourceCode
[09:58] <apw> ie which kernel version range are you looking for, and i'll find you the right link
[09:58] <apw> git clone git://kernel.ubuntu.com/ubuntu/ubuntu-<release>.git
[09:58] <apw> so that one yes?
[09:58] <apw> which <release> did you substitute in
[09:58] <one> quantal
[09:58] <one> http://kernel.ubuntu.com/git?p=apw/ubuntu-quantal-meta.git;a=summary
[09:58] <one> you
[09:59] <apw> no that is substituting in quantal-meta, that is not substituting in quantal
[09:59] <apw> and that is something from my directory not from the ubuntu one
[09:59] <apw> git://kernel.ubuntu.com/ubuntu/ubuntu-quantal.git
[10:00] <apw> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-quantal.git;a=summary
[10:00] <apw> that one is the gitweb you wanted
[10:00] <one> I do not want to install git
[10:00] <one> I just want the sourcecode
[10:01] <one> not download and install more trash
[10:01] <apw> apt-get source linux-image-$(uname -r)
[10:01] <apw> is how to get the source
[10:01] <apw> if you arn't using git, as it says on that wiki
[10:01] <apw> as it even said first on that wiki
[10:02] <one> the https connection doesnt establish
[10:03] <one> if the server was accepting http I could have looked
[10:03] <apw> that i am unable to help you with
[10:03] <one> I do not want to install more trash nor do I want to be forced to use a bunch of tracking codes
[10:03] <apw> apt-get source linux-image-$(uname -r)
[10:04] <apw> will do what you want then, it will get you the raw source
[10:04] <apw> which is how you get the source of all and any package in debian based systems
[10:04] <one> that looks to be downloading the full source previously I had run apt-get source linux-source or something without the uname
[10:05] <apw> yep, that gets you the meta package which tracks our releases
[10:05] <apw> the kernel is special in that regard, so you can have old kernels for emergencies
[10:05] <one> then I downloaded the package for the source from some link that was in the meta package
[10:05] <one> and it compiled into a version other than what it was labled as
[10:07] <apw> which link was that
[10:08] <one> I do not recall at the moment it was a while back but the package is labled 3.5.0 and the result is 3.5.5
[10:09] <apw> that would depend how you build it, if you use the debian rules to build it it will likely come out as 3.5.0-NN style, if you use direct make it might well be 3.5.N
[10:09] <one> And it isnt compatible with the crypto running on the current 3.5.0
[10:10] <one> How are the debian rules used to build it?
[10:13] <apw> to build the full package you would use dpkg-buildpackage -b which will build it for the build machiens architecture
[10:13] <apw> of course you need th
[10:13] <apw> the appropriate build infratstructure installed, compilers, kernel-wedge etc etc
[10:13] <apw> or one could build it in a PPA
[10:31] <one> this looks like some more source not sure if its different from what is in the linux-source-3.5.0
[10:31] <one> they are both 3.5.0
[10:31] <one> also theres a linux-meta-3.5.0
[10:32] <one> this scheeming doesn't make sense
[10:32] <one> in that way it is hidden
[10:32] <one> without sense it becomes dice
[10:32] <one> just guess at a random naming schema
[10:33] <one> like cracking a bicycle lock just to figure out what it is possibly named
[10:36] <apw> one, apt-get source gets that actual source package which was uploaded to make the binaries you have, so its not random source
[10:37] <one> apw are there any other advantages to using dpkg-b... to build other than detecting the architechure not even to the specifics of cpuinfo
[10:37] <apw> one, you get a package that is built the same way the archive builds it, it all depends what you are building your kernel for to know whether it matters
[10:38] <one> apw: so does it force automation of everything or is there a way to modify the config?
[10:38] <apw> the configs are builtin and can be modified
[10:42] <one> apw: is it also possible to build something for another machine using the dpkg-build...
[10:44] <one> apw: the kernel is being rebuilt to cut out the extras and then add some custom modules
[10:45] <one> I am planning on some modules which use interactive crypto
[10:45] <apw> dpkg-buildpackage can build for the architectures the build machine supports only
[10:45] <apw> unless you use cross-compilers
[11:16] <one> well that is where to start, kernel, and start cleaning up this junk
[11:16] <one> bunch of junk everywhere on the machine
[11:17] <one> any links to a linux compatible braille term
[11:17] <one> interactive crypto to check the eyes for trickery
[11:18] <one> clean machine
[11:19] <one> Iam going to clean up the machine and then use it.
[11:19] <one> Can't even be used the popular idea is that folks pay to have machines use them.
[11:19] <one> obsurd!
[11:21] <one> vanguard robots spying on me
[11:21] <one> they play game
[11:21] <one> communists
[11:22] <one> it seems somewhat surreal
[11:22] <one> Did you just open emacs?
[11:23] <one> Something just opened emacs
[11:23] <one> I know you want me to code.
[23:05] <hallyn> you wanna talk about surreal
[23:16] <smb> hallyn, is that the state after too many beers?
[23:18] <hallyn> smb: haha, no, i just looking at the backscroll, with 'one' and 'apw' talking to each other
[23:19] <hallyn> smb: all i've had is half of rharper's bottle.  where are you?
[23:19] <hallyn> i've turned qemu-nbd into an orphan and accidentally downloaded an armhf cloud image, i think i can call tonight a success
[23:19] <smb> hallyn, In my room but ready to roll any time
[23:20] <hallyn> zul hasn't yet shown up on irc
[23:20] <hallyn> smb: lobby in 10 misn?
[23:20] <smb> sounds like at least some err progress (nbd and arm)
[23:20] <smb> hallyn, ack
[23:25] <hallyn> smb: woohoo, container with qcow2 backing store working '\o/
[23:27] <smb> yay
[23:55] <one> here does dpkg place the kernel after using buildpackage?
[23:55] <one> Where does dpkg place the kernel after using buildpackage?