[00:19] * maxb grimaces at tests which only fail in a full test-run [00:27] lp.services.scripts.tests.test_all_scripts.ScriptsTestCase is the testcase of doooooom [00:27] I worry that it's going to melt my laptop [00:38] maxb: it won't melt; but it might get a bit soft and wobbly/deform.... [00:39] It's when the laptop starts to smell a little like a soldering iron that I worry :-) [01:04] maxb: so long as the smoke doesn't escape? everything is gravy! === matsubara is now known as matsubara-afk [01:39] spm: can i get you to apply a patch to strawberry pls? [01:39] sure [01:39] spm: http://pastebin.ubuntu.com/413405/ [01:40] spm: *should* apply to the tree on there, not completely sure though [01:40] if it doesn't i'll just get you to replace the entire file i guess [01:41] kk [01:42] spm: in news that may please a sysadmin, this patch is essentially telling bzr to stop being clever and be very stupid instead [01:43] :-) applied [01:43] spm: can you kill the running import on strawberry ? [01:44] mwhudson: with great and a deep sense of satisfaction and pleasure; done. [01:46] mwhudson: fyi. afk for a sec. delivery arrival... [01:52] ok [01:52] back [01:53] stupid > smart [01:53] in this case [01:53] :-) [01:53] noop import before patch: 1hr 10 minutes [01:53] noop import after patch: three minutes [01:54] mwhudson: the create_tree_if_local argument to sprout() doesn't work as expected? [01:54] \o/ [01:54] jelmer: it doesn't? [01:54] jelmer: the problem seems to be mainly that 2a fetch is terribly slow [01:54] mwhudson: I'm not sure, just trying to work my head around what your patch does differently [01:55] jelmer: my patch uses copy_tree_to_transport rather than sprout [01:56] jelmer: i think that counts as fairly different [01:56] Oh, nice! [01:57] mwhudson: heh [01:57] Do I spy a bzr bug coming soon? [01:57] (credit to abentley for the idea) [01:57] mwhudson: I missed that, surprised bzr doesn't do that itself.. [01:57] mwhudson: (in those cases where it's possible_ [01:57] ) [01:57] mwhudson: should the branch scanner work ? [01:58] The puller times out :( [01:58] next on the hit list: having the puller use a similar hack for import branches [02:00] Hm. So it takes 37 seconds to copy directly, and slightly under 70 minutes for bzr to do it? [02:02] something like that yes :( [02:06] aragh [02:06] Transport operation not possible: Transport has not implemented list_dir (but must claim to be listable to trigger this error). [02:06] It pulls over HTTP!? [02:06] yes [02:07] actually not on staging, so this patch will probably work there.... [02:07] Hm, but that's probably actually faster than using the smartserver here. [02:07] yes, smartserver is /mostly/ a squeeze on latency [02:07] and bandwidth in some cases i guess, but we have lots of one and very little of the other so... [02:09] the error message seems to be lying fwiw [02:26] * mwhudson hacks, mightily [02:40] spm: hi, could you apply this patch to the tree on tellurium please? http://pastebin.ubuntu.com/413423/ [02:40] warning: do no attempt to read said patch [02:40] *not [02:41] :-) [02:44] aaaaaaa. I am blinded and cannonit see [02:44] mwhudson: applied [02:44] need codehost restarted? looks like not.... [02:45] spm: no [02:50] It's taking a while.. [02:51] spm: is there a mirror-branch.py process running on tellurium? [02:52] 000 3944 97.1 18.5 653364 382120 ? R 02:48 3:25 \_ /usr/bin/python2.5 /srv/bazaar.staging.launchpad.net/staging/launchpad/scripts/mirror-branch.py /home/supermirror/importd-push-branches/0004ea4b lp-mirrored:///~mwhudson/linux/trunk 322123 ~mwhudson/linux/trunk IMPORTED 1 [02:53] spm: okay [02:53] seems maybe my hacks aren't helping all that much [02:53] spm: can you du -sh /home/supermirror/importd-push-branches/0004ea4b /srv/bazaar.staging.launchpad.net/mirrors/00/04/ea/4b ? [02:54] 620M /home/supermirror/importd-push-branches/0004ea4b [02:54] 61M /srv/bazaar.staging.launchpad.net/mirrors/00/04/ea/4b [02:54] thats an impressive mismatch? [02:54] bah [02:58] spm: can you apply this patch to tellurium too? /home/supermirror/importd-push-branches/0004ea4b [02:58] no [02:59] spm: http://pastebin.ubuntu.com/413428/ <- this patch [03:00] sure [03:01] patched [03:02] spm: can you zap the mirror-branch process? [03:02] * spm reaches under the desk for the larger hammer..... [03:03] yo stub [03:03] put the hammer down... [03:04] but *stub* I was gunna make you plural! [03:05] spm: ok, can you sync the puller logs from tellurium to devpad please? [03:05] mwhudson: 1000 4772 99.5 8.0 436900 165584 ? R 03:04 0:53 \_ /usr/bin/python2.5 /srv/bazaar.staging.launchpad.net/staging/launchpad/scripts/mirror-branch.py /home/supermirror/importd-push-branches/0004ea4b lp-mirrored:///~mwhudson/linux/trunk 322123 ~mwhudson/linux/trunk IMPORTED 1 [03:07] mwhudson: synced === poolie1 is now known as poolie [03:12] oh goody oops reporting is broken [03:14] i guess i'll give up for now and have lunch [07:58] good morning [08:06] thumper: mwhudson: if you're still around, I need a pointer to the twisted vfs stuff in the lp code base - the policy on permitted file names specifically. [08:15] thumper: mwhudson: nevermind, found it, drive by patch submitted [09:19] bigjools: How many years is it since buildd-sequencer has been used? [09:20] since Jan 2009 [09:20] Oh. [09:21] cprov wrote it in the back of the van at UDS Mountain View :) [09:21] I thought buildd-slave-scanner was used before buildd-manager, and buildd-sequencer came before slave-scanner. [09:22] wait [09:22] it's *not* been used since 2009 [09:22] I mean cprov wrote b-m in the van [09:23] slave-scanner is the same thing as buildd-sequencer [09:23] we like to use as many different confusing names as possible [09:23] Er, is it? [09:23] lib/canonical/buildd/sequencer.py seems reasonably unrelated to cronscripts/buildd-slave-scanner.py [09:25] Or is buildd/sequencer not actually buildd-sequencer? === wgrant changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 1 of 10.04 | PQM is open | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in irc://irc.freenode.net/#launchpad-reviews | Use http://paste.ubuntu.com/ for pastes [09:35] wgrant: I've no idea what the former is, since it's in the buildd dir then it's part of the slave [09:36] Ah: [09:36] The task sequencer is a simple twisted daemon which looks after making [09:36] sure that the buildd tasks (E.g. slave scanner, queue builder etc) are [09:36] only run one at a time, and potentially more often than once per [09:36] minute. [09:37] Sounds useless, is in the wrong place, and breaks slightly with Python 2.6. [09:37] no kidding [09:37] And hasn't been touched significantly since 2005. [10:12] bigjools: So, will anybody miss it if I remove it and its doctest as a step towards Python 2.6 support? [10:18] wgrant: where's the test? [10:18] bigjools: lib/lp/soyuz/doc/buildd-sequencer.txt [10:19] good grief [10:19] Hm? [10:19] delete it with prejudice [10:19] * wgrant destroys. [10:40] It's impossible to remove config schema elements at the moment, right? [10:46] huh? [10:47] Didn't rollouts explode last week because a config key had been removed, so the production configs (which still had a value for it) were invalid? [10:49] Ah, yes, bug 557271. [10:49] Bug #557271: Unable to remove config entries from the schema [11:00] hmmm [11:01] Morning, all. [11:05] howdy deryck [11:06] jml, where's that patch you wanted me to land again? [11:07] https://bugs.edge.launchpad.net/zope.testing/+bug/560259 [11:07] Bug #560259: Subunit output formatter doesn't handle layer setup errors [11:07] sidnei: it's the branch linked to that, and the attached patch [11:08] jml, both? or either? [11:08] either [11:08] same patch [11:08] oh, looks trivial. [11:23] jml, you need a new release too? [11:24] sidnei: yes please [11:24] sidnei: and yes, it's really trivial :) [11:31] jml, done [11:32] sidnei: woot! thanks! [11:32] np! === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell [13:30] sidnei_: can you come over to #lp-review, please? ;) === sidnei_ is now known as sidnei [13:56] leonardr, ping [13:57] hi ursinha_ [13:57] leonardr, hi, I hit an error with one of my lpapi scripts, I wonder if you know what could it be [13:57] leonardr, "SyntaxError: no element found: line 16363, column 186" [13:58] this is the error, when I try to login_with [13:58] that sounds like there's a problem with the wadl [13:58] leonardr, yeah, but I have no idea why, since it works with another user [13:58] leonardr, invalid credentials? [13:58] you would get a 400 error. is that the entire error? [13:59] there's no headers? [13:59] leonardr, let me show you the traceback [13:59] no, i guess there wouldn't be since it's not an http error [14:00] leonardr, this is the traceback: https://pastebin.canonical.com/30486/ [14:01] ursinha_: i suggest catching the exception in _browser.py#get_wadl_application and printing out 'content' [14:04] leonardr, sure, a moment [14:50] leonardr, this is weird, it seems that the end of that 'content' is missing [14:54] leonardr, line 16363, column 186 is the last line of that content, and it's not complete [15:02] kfogel, ping [15:04] deryck: on phone, bbiab [15:04] ack [15:04] Ursinha_ that content comes from a file on disk. lib/canonical/launchpad/apidoc/wadl-*-*.xml [15:04] check that file and see if it's truncated [15:04] aha [15:04] if so, remove that directory and make again [15:06] leonardr, hmm, thing is I'm running my script on devpad [15:06] works with one user and doesn't work with another [15:08] leonardr, and I can't reproduce the error locally [15:09] Ursinha_: i don't use devpad so i don't know what that means. you don't have access to the apidoc/*.xml? [15:10] leonardr, exactly [15:10] Ursinha_: i suggest you escalate to someone who does have access [15:11] Aren't the API scripts running against prod/edge? [15:11] So it's probably a client-side cache. [15:11] leonardr, but I'm running the script with edge lp api [15:11] what wgrant said [15:11] wgrant, cache huh [15:11] ursinha_: on phone, sorry [15:12] leonardr, no problem, thanks so far [15:12] Ursinha_: Try obliterating/moving ~/.launchpadlib/api.edge.launchpad.net/cache [15:21] wgrant, yeah, that worked [15:21] wgrant, thanks [15:26] gmb, bug 294223 is done, right? [15:26] Bug #294223: Bugs missing after import from SourceForge [15:27] deryck, Yep. [15:27] Forgot about that [15:27] gmb, can you update and assign to the current milestone please? [15:31] deryck, Sure [15:31] Done [15:32] gmb, thanks [15:43] adeuring, can you update bug 261254 with linked branch, status, and assign to the current milestone? I believe this is done, yes? [15:43] Bug #261254: Launchpad couldn't connect to ALSA Bug Tracker.

[15:43] deryck: sure [15:43] adeuring, thanks! [15:49] sinzui, ping, do you have some time today to chat about changing some more /@@/ icons into sprites? I have a question or two about it. [15:49] sinzui, if you have time, whenever you have time [15:50] mars, I will after 3:00+. I do not know much about how icons become sprites. EdwinGrubbs wrote the tools that generate the sprite and css [15:51] maxb: how is going ? =) [15:51] hello :-) [15:51] sinzui, ok. EdwinGrubbs, do you have time to chat about sprites some time today? [15:51] maxb: do u know how to enable karma .. just to see may digging =) [15:51] mars: sure [15:52] EdwinGrubbs, what time for you? [15:52] I know nothing more than it involves a cronscript somewhere [15:52] mars: I can do it now, but it might be a little noisy since I'm at a coffee shop. [15:52] heh [15:52] EdwinGrubbs, that should be fine [15:52] EdwinGrubbs, skype or mumble? [15:52] maxb: i see 'karma has expired.' all time [15:54] mars: skype === Ursinha_ is now known as Ursinha-lunch === deryck is now known as deryck[lunch] [16:16] intellectronica, online? [16:16] mars: yes [16:16] how can i help you? [16:17] Tom, I'm looking at turning some of the /@@/edit icons in the bug status table into sprites [16:17] intellectronica, can you see an issue with me doing so? [16:18] this is in the name of improved page performance, btw :) [16:18] mars: nothing i can think of off the top of my head. looks like a net win to me. [16:19] intellectronica, cool. I'll ask someone on the bugs team for a review when I'm done, just to make sure your team thinks my changes are sane. [16:20] cool [16:20] thanks! === barry is now known as flufl === flufl is now known as barry === deryck[lunch] is now known as deryck [17:06] I'm forcing a rebuild of the recently failed 'lp' buildslave [17:07] "no space left on device" seems to be the originating error === beuno is now known as beuno-lunch [17:32] * jml discovers CachingIterator [17:32] it's just like lists in Haskell! [17:36] ooh, there is something like that? [17:36] * jelmer has reimplemented it at least twice :-) [17:37] jml: where does it live? [17:37] jelmer, lp.services.utils [17:37] jelmer, which is the best known home for such a thing [17:37] oh, in Launchpad itself. It'd be a great thing to have in itertools... [17:38] jml: Thanks anyway, I'm sure this will come in useful sometime :-) [17:38] yeah === Ursinha-lunch is now known as Ursinha [17:38] * bigjools reboots from karmic into lucid [17:38] jelmer, I should also add synchronize and dichotomy to itertools, I guess [17:38] jelmer, I didn't write it, fwiw. I just found it. [17:38] given the docstring, I'll wager abentley wrote it [17:39] jml: you can tell that just from the docstring? [17:40] jelmer, "Some generators and iterators are expensive to calculate, like calculating the merge sorted revision graph for a bazaar branch" [17:40] ah, the reference to Bazaar [17:41] jelmer, nope, thumper. === leonardr is now known as leonardr-afk === beuno-lunch is now known as beuno [18:18] deryck: pong [18:18] deryck: can't remember if your ping was internal or external channel :-) [18:19] did I ping? :-) [18:20] oh, this morning... right [18:20] kfogel, are you working on stats for patch project? Do I recall that correctly? [18:21] deryck: yup [18:22] deryck: https://code.edge.launchpad.net/~kfogel/tuolumne-lp-configs/patches-time-to-closing [18:22] deryck: queries there; not much code yet [18:22] deryck: abel is helping w/ queries btw [18:23] kfogel, ok, that's all I needed to know. I've been meaning to get back to stats for that project and wondered if your work included lpstats stuff. [18:23] kfogel, btw, you'll have to subscribe me to that branch to see it. [18:25] deryck: oh, it's private? one sec [18:25] deryck: you want rev notifications too, or just branch attribute notifications? [18:25] kfogel, just attrs. [18:26] deryck: done === gary_poster is now known as gary-lunch [18:28] kfogel, thanks. and thanks for getting the stats together. [18:30] deryck: you're welcome; but thank me when it's done -- it's hard to measure this thing! [18:30] not use, but benefit, I mean [18:30] yeah, that's why I hadn't got round to working on it yet. [18:48] jpds, ping === dpm is now known as dpm-afk === leonardr-afk is now known as leonardr [19:11] sinzui: Hello. [19:12] jpds, have you tested that you can control the official country mirror status using api? [19:12] sinzui: Yes. [19:14] jpds, as you represent the primary user of the feature, you want to update this bug's tag to qa-oa: https://bugs.edge.launchpad.net/launchpad-registry/+bug/361650 [19:14] Bug #361650: launchpad could know about official country mirror status

[19:14] sinzui: Sure, done. [19:15] thanks [19:41] hi gary-lunch, I filed a bug now, bug 562486, are you aware of this issue? and, is that really foundations? [19:41] Bug #562486: accessing pending_gpg_keys using the api fails to some users === gary-lunch is now known as gary_poster [20:02] Ursinha: I was not aware of the issue. It's definitely a foundations issue, and if it is a matter of how the code is exported rather than infrastructure, it is also a registry issue. I'll ask leonardr for his opinion...once the oops tools are fixed :-) [20:03] gary_poster, :) [20:03] gary_poster, thanks [20:03] thank you [20:05] gary_poster, Ursinha there are two issues that relate to this bug... [20:06] gary_poster, 1, the seem to be available in one database and not another, leading to many oopses.... [20:06] but there is a second debacle from last release where gpgkeys were renamed to gpg_keys, not not all the code was updated [20:07] Ursinha, EdwinGrubbs is landing a fix for the latter. [20:08] sinzui: "seem to be available in one database and not another": which different databases? Do you mean replication slaves and masters? [20:08] gary_poster, yes, gpgkeys are manages via logintokens [20:09] gary_poster, we also saw this happen in the CoC web UI [20:10] sinzui: does that maybe mean that you need to always connect to the master for these queries, using one of stub's context manager things? [20:10] gary_poster, I do not know [20:10] * gary_poster doesn't really know context so is probably not helpful [20:10] it sounds like it [20:10] sounds like a race condition [20:11] and if it is a race condition with the slaves, force using the master. [20:11] if you think that sounds reasonable, and you are not sure about stub's context manager, I can hunt up an example for you, sinzui [20:29] sinzui: regarding the bug with +claim, does this mean that the Account.activate() method is also problematic since it sets a password that might be different from what was entered on the LoginService? [20:29] james_w, can you give me the specific failure you get when you trigger bug 561521? [20:29] Bug #561521: Success of PATCH request dependent on dict iteration order [20:29] leonardr: it was in the mailing list post [20:30] james_w: ok, i'll find it and put it into the bug [20:30] EdwinGrubbs, I do not know. /me looks [20:31] EdwinGrubbs, isn't the account the SSO account, I do not think there is a Launchpad Account [20:32] leonardr: note that it's a followon error that is in the thread. If you want the exception thrown by the mutator then modify the test mentioned in the bug to print the response from the patch request. [20:33] EdwinGrubbs, the use case we are trying to avoid is a non-login user working with profiles and account. So if the user can access Account.activate() without being logged into the SSO server, there is a problem [20:35] james_w: i can't find the relevant post in my mailbox. what was the subject? [20:35] "Test failures on some platforms due to lazr.restful bug" [20:36] sinzui: the reason I ask is that +claim gives you a login token that takes you to the ClaimProfileView in c/l/browser/logintoken.py and that calls emailaddress.account.activate(), so it would seem like the non-login user could access it. [20:36] ok, i got it [20:36] EdwinGrubbs, yes, that is taking the wrong path bad= person > email > account [20:37] EdwinGrubbs, good = account > email > person [20:38] EdwinGrubbs, so I think Account.activate is not a problem, but the callsite must know when/how to call it. claim does not [20:39] sinzui: huh, does that just mean that we don't want to link a launchpad person that has the same email as the account but isn't already linked to that account directly? [20:39] EdwinGrubbs, we do want to link person to emails, we have to since emails are unique [20:40] sinzui: I'm just trying to clarify why account>email>person is good. [20:40] EdwinGrubbs, I think this discussion is moot. there are two callsites, and you are removing one of them [20:41] EdwinGrubbs, So we can limit our discussion to Person.setPreferredEmail [20:43] EdwinGrubbs, Maybe we should change the guard in setPreferredEmail() and raise an exception instead of trying to fix the issue? [20:45] sinzui: do you think it could be broken, or do you just want to get rid of the kludge? [20:45] EdwinGrubbs, We need to be careful in this method, I believe reset password switched the account from deactivated (by the user) back to activated. we may need to ensure the callsites (SSO!) has updated the account first. [20:46] EdwinGrubbs, ^ reset password switcheS THE ACCOUNT USING THIS METHOD [20:48] EdwinGrubbs, maybe I am over thinking this issue. setPreferredEmail() has no issues with active activated and deactivate accounts. suspend accounts cannot get here. so the problem is only when the account is not active. [20:49] EdwinGrubbs, I see scripts are calling setPreferredEmail. This could be very ugly. [20:51] hmmm [20:51] EdwinGrubbs, I think we should remove the account hack in setPreferredEmail(), but I need to verify how we are resting password [20:52] sinzui: well, I'll continue working on removing +claim for the time being. [20:53] yes, I suspect setPreferredEmail() is a separate bug [20:59] EdwinGrubbs, SSO reactivates the account itself. I think we can treat bug #248518 as a trivial deletion in a separate branch [20:59] Bug #248518: setPreferredEmail activated accounts

=== EdwinGrubbs is now known as Edwin-afk [21:19] good morning [21:20] hi mwhudson [21:42] * mwhudson tries to browse the code of the kernel import [22:16] abentley, rockstar: https://code.staging.launchpad.net/~mwhudson/linux/trunk [22:37] trunk != linux-2.6.31.y.git [22:38] it's just the default in the form :) [22:55] weee adding all the revisions in the scanner for that kernel import took 90 minutes === matsubara is now known as matsubara-afk