[06:55] lifeless: Ah, I'm glad you have a better solution than granting launchpad.View on private teams just because of a PPA subscription. === almaisan-away is now known as al-maisan [07:11] wgrant: I try === al-maisan is now known as almaisan-away === Ursinha-afk is now known as Ursinha [08:45] morning [08:46] Evening. [08:48] day. [08:50] G'Tag [08:51] That's not very Czech. [08:52] Oh, sorry. Dzień dobry === almaisan-away is now known as al-maisan [10:02] leonardr, wbn to extract whatever groundcontrol uses for this and make it sit on top of a generic authenticate mechanism, and be the default gtk impl [10:03] poolie, i don't think it's worth it, given that the common case will be to use the credentials manager packaged with ubuntu [10:17] jml wow ec2 test is pretty classy [10:36] poolie: you've seen bzr selftest --parallel=ec2 ? [10:36] heard of it [10:36] :P [10:36] i think i tried it and hit some snags [10:37] i think for me it looked like a bad latency/throughput tradeoff :) [10:37] maybe i should try it [10:37] But with LP it's different, since the test suite is damn slow? [10:37] lifeless, i'd actually like a variation that runs remotely on my desktop [10:37] yeah basically [10:47] poolie, want to review the launchpadlib branch we talked about yesterday? [10:47] https://code.edge.launchpad.net/~leonardr/launchpadlib/improve-workflow/+merge/29849 [10:48] i'd be delighted [10:49] poolie: the reason there are no automated tests is we don't have the framework for them [10:50] leonardr, you know when i said 'rhinos' i meant the internal mailing list about this? not the animals? [10:50] poolie: i thought you meant the o'reilly book (after whom the list is presumably named) [10:51] the problem with launchpad for ec2 is that instance setup is quite slow of course [10:51] we could have an instance with the results of 'make schema' baked into it, that would help a bit [10:51] nice cover letter [11:05] leonardr, reviewed, very nice but i have some tweaks [11:05] ok === Ursinha is now known as Ursinha-afk [11:48] poolie, maybe you can help me understand how os.open works [11:48] leonardr, maybe i can :) [11:48] * poolie waves [12:02] Is ShipIt still a Launchpad parasite? [12:03] Ah, lunch, I guess. [12:03] wgrant: yes [12:04] wgrant: to both bits [12:04] mwhudson: :( [12:04] wgrant: although there was talk of not rolling out launchpad to shipit app servers any more === Ursinha-afk is now known as Ursinha [13:36] gary_poster: it seems our VirtualHostRequestPublicationFactory doesn't really implement IRequestPublicationFactory, because __call__ returns a request *factory*, not a request [13:36] gary_poster: does this ring any bells? [13:39] or hm [13:39] maybe the docs are just broken [13:41] yeah, i think so [13:50] mwhudson: (Sorry no reply before) That sounds likely to me, fwiw. If it works with the rest of the Zope machinery, then that sounds like a good argument. [13:50] gary_poster: np === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [14:37] I appears there is one or more Git imports in the Reviewed state which somehow I am Forbidden to see [14:37] This manifests as a Forbidden error when I try to page through the list of them, on one particular page [14:39] It appears to be number 459 in the list [14:40] and mumber 498 too [14:41] maxb: hmm [14:41] maxb: sounds worth of bug filing [14:42] https://code.edge.launchpad.net/+code-imports/+index?field.rcs_type=GIT&field.rcs_type-empty-marker=1&field.review_status=REVIEWED&field.review_status-empty-marker=1&submit=Submit+Query&start=497&batch=1 [14:42] Can you view that? [14:43] https://code.edge.launchpad.net/+code-imports/+index?field.rcs_type=GIT&field.rcs_type-empty-marker=1&field.review_status=REVIEWED&field.review_status-empty-marker=1&submit=Submit+Query&start=458&batch=1 [14:43] or that? [14:43] hoping to find someone to figure out which ones are the problem, so I can say something more definite than an index in search results which will change [14:45] maxb: i can't see that [14:45] hmm. I guess we'll need a losa [14:45] but i can see the branch name in the traceback [14:46] i assume it's a private branch-only project [14:46] makes sense [14:51] leonardr: hi, is there a solution for using launchpadlib.load in (launchpad) tests that doesn't involve hardcoding the root uri or accessing a private attribute? I thought I had seen a branch from you to make load work with relative URIs. [14:58] james_w: yes, in the latest version of launchpadlib you can pass a relative url to load() [14:58] or, actually, in the latest lazr.restful [14:58] leonardr: is that landed in launchpad yet? [14:58] lazr.restfulclient [14:58] yeah, it's lazr.restfulclient 0.9.20, revno 102 [14:59] grep restfulclient versions.cfg [14:59] lazr.restfulclient = 0.9.14 [15:00] oh, i see what you mean [15:00] is it part of the launchpad application, not is it on the launchpad site [15:00] I'll try an upgrade branch [15:01] i'll do a branch upgrading the packages later this month [15:01] remind me to do it, if you would [15:04] leonardr: you don't want me to do it now? [15:05] leonardr: is there some way that I can mark the place in the code where I will put the ugliness for replacement at that point? [15:05] james_w: sure, if you want to take care of it i'd be very happy [15:06] i didn't know that was what you meant by 'upgrade branch' [15:06] leonardr: latest versions of lazr.restfulclient, launchpadlib and lazr.restful? [15:06] let me double check, but yes [15:06] i.e. should I upgrade all of them? [15:07] james_w: yes. send me the mp, but if the ec2 test passes, it's fine [15:08] leonardr: any gotchas you can think of that would save me time? [15:08] any dependencies that should be upgraded or anything? [15:08] james_w: the only thing i'm worried about is whether 'make' will generate a reasonable-looking apidoc [15:09] wait, actually it doesn't matter, because i didn't release that launchpadlib revision as a new version of launchpadlib [15:09] so it should be fine [15:09] ok [15:10] hi james_w [15:10] hi poolie [15:10] new post: http://blog.launchpad.net/api/three-tips-for-faster-launchpadlib-api-clients [15:11] lifeless, one nice thing about having everything in debs would be less crap about 'please run link-external-sourcecode' etc [15:12] I'm actually starting to like the approach taken by buildout etc. for development [15:12] poolie: utilities/link-external-sourcecode -p ~/launchpad/lp-sourcedeps/ [15:13] poolie: co-located branches would make that less of an issue too :-) [15:14] true [15:15] hm, though you'd still need to rebuild them etc [15:23] writing unit tests for publication details makes me want to stab things [15:26] ILaunchBag needs to die [15:27] ILaunchBagBiter [15:29] ILaunchPoo [16:02] flacoste, mwhudson: who currently runs our mootbot? [16:03] kiko: no idea [16:20] poolie, https://bugs.edge.launchpad.net/launchpadlib/+bug/605462 [16:22] gary_poster: this diff adds a vostok layer: http://pastebin.ubuntu.com/463574/ [16:22] looking [16:22] gary_poster: this one adds a very simple new view for the root http://pastebin.ubuntu.com/463575/ [16:26] mwhudson: for first patch, I don't understand change to lib/lp/code/xmlrpc/tests/test_codehosting.py : why did it say "vostok" in the first place? [16:27] gary_poster: the scripts used to be run on a machine called that, i guess i went for 'realistic' test data [16:27] heh, what a coincidence [16:28] yeah [16:28] i changed it because i want grep -ir vostok to only find this stuff :) [16:28] heh, cool, makes sense [16:33] mwhudson: oooh, I like your root template [16:33] gary_poster: :) [16:38] mwhudson: a 50% review: looks good to me. It is sad that it requires so much machinery, though we do this so infrequently I suppose it is not worth thinking about [16:41] gary_poster: thanks [16:42] you know, it might be useful for us to have vostok.launchpad.net as an "unsupported" interface to launchpad.net. [16:45] james_w: i guess you looked at the diffs [16:46] I did [16:46] cool [16:48] thumper: around? [16:49] mtaylor: sorta [16:49] mtaylor: if you say stuff he'll see it i imagine [16:49] mwhudson: heh. something seems to be quite off with merge proposal diff [16:49] diffs [16:50] mtaylor: in what way? [16:50] I've got three up: https://code.edge.launchpad.net/swift/+activereviews (from pipeline, depend on each other) and the unmerged revision list for each is off [16:50] as is the diff that was emailed and the one that is displayed in the UI [16:51] mwhudson: if you don't have super-launchpad perms, I'll have to add you to a team so you can see it [16:51] mtaylor: i don't have the perms any more [16:51] mwhudson: ok. lemme add you real quick [16:52] mwhudson: if you look at https://code.edge.launchpad.net/~mordred/swift/add-doc-package/+merge/29896 [16:52] mwhudson: that merge should contain revs 16 and 17 - but even if it just contained rev 17 the diff still should not be empty [16:52] mtaylor: bah, i can't see that [16:52] Unauthorized: (, 'landing_targets', 'launchpad.View')
[16:53] hrm. lemme add you somewhere else... [16:53] mwhudson: try again [16:53] success [16:54] woot [16:55] mtaylor: i think the unmerged revisions list being too big has been like that always [16:55] mwhudson: no - that's not the problem ... [16:55] mwhudson: sorry, I didn't mean unmerged revs... [16:56] mwhudson: if you look at the grey list of revs under "Add a review or comment" ... it should be listing 16 as well... and then the diff should be quite different/larger [16:56] mtaylor: thumper agrees that it's ****ed [16:56] yay [16:56] (he's now sitting next to me) [16:56] * mtaylor cries a bit [16:57] * mtaylor was going to teach new people how to work with merge requests and why they're wonderful today... [16:57] is it possible that is's ****ed because of all the private nonsense? [16:59] mtaylor: trying to reproduce something [16:59] mtaylor: very unlikely [16:59] ok [17:00] mtaylor: can you delete the problem proposal and try again? [17:00] mwhudson: sure [17:00] mwhudson: there are two problematic ones... shall I delete bothj? [17:01] mtaylor: which is the other problem one? [17:01] but no, just delete one for now [17:03] https://code.edge.launchpad.net/~mordred/swift/rework-dh-install [17:03] ok [17:04] mtaylor: yeah, the diff on https://code.edge.launchpad.net/~mordred/swift/rework-dh-install/+merge/29891 is just the diff from r13 isn't it? [17:05] mtaylor: hi [17:05] mtaylor: I've opened my laptop again [17:05] mtaylor: same empty diff again [17:05] thumper: hi! [17:05] mwhudson: bleh [17:05] mtaylor: yes [17:07] mtaylor: I'm sitting next to abentley discussing your diff [17:07] or lack thereof [17:07] thumper: did I break somethignm [17:07] ? [17:07] mtaylor: maybe [17:07] mtaylor: I seem to recall something like this happening before [17:07] but I don't remember why [17:07] or what we did about it [17:09] yay! [17:09] thumper: I did push the first branch (~mordred/swift/bzr-builddeb) ... then I reconfigured to pipeline [17:09] then I re-pushed it [17:10] not sure if it's relevant [17:10] mtaylor: you should probably remove me from those teams [17:12] mwhudson: I will [17:13] mwhudson: do you not need it to see things anymore? [17:13] mtaylor: i'm letting thumper and abentley worry about it :-) [17:13] mwhudson: cool [17:13] mtaylor: bad news [17:13] mtaylor: when we manually do what the script should be doing [17:13] we get a diff [17:13] so... [17:13] sounds like a bug in our diff generation [17:14] yay! [17:14] please demonstrate with a different project [17:14] thumper: should I try deleting an recreating all three merge props? [17:14] mwhudson: done [17:14] mtaylor: cool === beuno is now known as beuno-lunch [17:15] mtaylor: you could try adding a rev to the source branch of the one with the bad diff [17:15] this would force a new diff to be generated [17:15] alternatively, try merging the prerequisite into the source [17:15] if the tip isn't already [17:15] it may be an edge case === beuno-lunch is now known as beuno === al-maisan is now known as almaisan-away [19:58] no ec2test mail makes james_w a sad panda [19:58] phew, there it is, just really slow === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === flacoste is now known as flacoste_afk