[00:05] Does the branchscanner run on qastaging? [00:06] Not regularly, AFAIK. [00:08] That's going to make QA'ing bug 813349 inconvenient :/ [00:08] <_mup_> Bug #813349: hard to get from mp to per-revision diffs < https://launchpad.net/bugs/813349 > [00:09] spiv: You can request it to be run manually [00:17] Anyone feel like reviewing https://code.launchpad.net/~wgrant/launchpad/retarget-bugtask-model/+merge/68761? === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 240 - 0:[######=_]:256 [00:31] wgrant: r=me [00:32] Thanks. [00:32] * StevenK prods wallyworld about OCR [00:33] StevenK: sorry, i was caught up finishing a branch [00:34] lifeless: How is HA-librarian going? === wallyworld changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld* (jtv) | Critical bugs: 240 - 0:[######=_]:256 [00:39] wgrant: rt something or other === lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld* (jtv) | Critical bugs: 240 - 0:[#######=]:256 [01:03] Yippie, build fixed! [01:03] Project devel build #909: FIXED in 5 hr 43 min: https://lpci.wedontsleep.org/job/devel/909/ [01:22] lifeless: Hah, subtle. [01:23] destroy beta testers? [01:23] life imitates glados [01:23] Heh [01:26] wgrant: ? [01:26] lifeless: The progress bar. [01:26] wgrant: heh yes [01:49] jtv: you around? want to mentor https://code.launchpad.net/~gary/launchpad/bug812335/+merge/68762 ? [01:50] wallyworld: no, I'm not here. It's almost 4 AM here. [01:50] jtv: oh, sorry! you still in europe then i assume [01:50] Yup [01:51] when are you back? [03:05] wallyworld: It seems the intersection of my freetime + your available hours don't collide, so I wonder if I can take it to email? :) [03:09] nigelb: otp, talk soon [03:12] nigelb: you can email me. or ping me on irc. i'm normally lurking in my evening and will respond to any queires [03:25] wallyworld: I finally landed something I had pending yesterday, so I can work on linkfying + titling bugs with XHR. [03:25] nigelb: excellent, well done. [03:26] where is it that I should start looking? :) [03:26] lib/lp/bugs/javascript? [03:26] ok, there's 2 places - the javascript which makes the xhr call and the python code which runs serverdide [03:27] serverside [03:27] justa moment, i'll grab the file names [03:28] the javascript file is lp/lp/app/javascript/lp-links.js - this harvests potential links when the page loads and makes a single xhr call to have those processed [03:29] lp/app/browser/linkchecker.py is the python code which receives the xhr call, does the work, and returns the results as a json data structure. the js code above then processes the result and pokes the dom to update the page [03:30] so, I need to update the python code to return title and process that extra information in the js. [03:30] the bit which wires it up is the +checklinks browser:page section in lp/app/browser/configure.zcml [03:31] yes, that is correct [03:31] you can add extra fields to the json dict returned by the xhr call [03:31] and then update things like the title attribute of the anchor or whatever in the js [03:32] make sense? [03:32] Yes [03:32] Does this already check if the bug exists? [03:33] looking at the code, it only handles branch links so far, but it does check that the branch exists [03:33] so you would need to extend it to support harvesting and processing bug links [03:33] ah [03:34] you could make the xhr call send a dict with a branches and a bugs list [03:34] The current linkyfing seems to be server-side. Is that the right wway? [03:35] yes, the serverside is the place to check the validity or permission to access info about the bug/branch [03:36] what is it you want to do exactly? [03:38] I'd like to look for "bug 1234" type links, check if they exist, get the title, add the title attribute if it exists and remove the linkification if the bug doesn't exist. [03:38] <_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts < https://launchpad.net/bugs/1234 > [03:39] are these would appear in text fields like comments, merge proposal descriptions and the like? [03:40] Yeah, the same [03:42] there's a file lp/app/browser/stringformatter.py with a method linkify_bug_numbers() which parses the text and does the initial linkification [03:42] this is done when the view is rendered [03:42] so, does this make sense. [03:42] add a css class for all the bugs, fetch all of the links with that class, send xhr request, modify dom. [03:44] yes. the comment on the code which does the initial linkification says: [03:44] # Don't look up the bug or display anything about the bug, just [03:44] # linkify to the general bug url. [03:44] so the work you are proposing would be post-processing in effect to add the extras [03:44] yeah, it wwas removed for performance. [03:44] like for the branches, make invalid (or invisible due to privacy) links grey etc [03:45] yep! [03:45] so using a css class to mark the bug links is good because that's how the current code for branch link processing works [03:46] all the plumbing is there, you just need to extend the js and python ti support another different type of link processing [03:47] oh cool! I'll try tonight to start step by step. I'll update you by email since your times don't match very well. [03:48] ok. but feel free to try and ping me on irc if you want. i may have a glass of red in hand but should be coherent enough to type :-) [03:48] haha [03:48] ok :) [03:48] i have soccer first too, so it will be late evening before i am in front of the laptop again [03:49] the problem is your late is still early enough for me that I'd be at work. [03:50] what time is it now where you are? [03:50] 9:20 AM [03:50] so you ate 4.5 hours behind me [03:50] are [03:51] so except for fridays when i have soccer, i am normally pingable at a time which would be close to EOD for you [03:53] ah, I'll note that :) [03:54] or even at start of your day, it's only afternoon for me :-) [03:54] so we do have a fair bit of overlap [03:54] heh, start of the day is often problematic. I tend to sleep late and wake up fairly late :) [03:55] np. i used to do that before kids :-( [03:57] heh, off to work. Laters! [05:07] wgrant, lifeless: Do either of you want to mentor wallyworld's review of https://code.launchpad.net/~stevenk/launchpad/dsp-vocab-issues/+merge/68763 ? [05:24] StevenK: Done. [05:25] wgrant: Thanks! [05:35] wallyworld: Around? [05:37] We have yet another form picker regression. [05:37] They don't populate the textbox. [05:37] Works OK on lpnet. [05:37] But there are no picker changes since then. [05:37] So WTF? [05:43] wgrant: yo [05:44] wallyworld: See #launchpad-ops. [05:44] qastaging ninja-updated. [05:44] So there was in fact a relevant rev: r13485 [05:44] Reverting now. [05:44] That makes you fairly distracted if it takes 50 minutes to update and you didn't notice :-P [05:45] It was mostly updated when I started looking at it, and crucially when I loaded the deployment report :) [05:46] I think jcsackett may have failed at conflict resolution with wallyworld's work. [05:46] The extra arg to create() is missing. [05:46] So it never gets hooked up to anything. [05:46] Anyway, reverting. [07:06] Hi wallyworld :) [07:07] jtv: hello [07:09] wgrant: I don't think I touched the archivecruftchecker as such. [07:10] $ bzr diff -c13478 lib/lp/soyuz/scripts/tests/test_archivecruftchecker.py | diffstat test_archivecruftchecker.py | 19 ++++++++----------- [07:10] Oh. [07:10] That's tests. [07:11] Ahem [07:11] * jtv stands back and admires wgrant's genius :) [07:11] But [07:11] Hm. [07:11] But that could be it. [07:11] I did change something in the test. [07:11] It is those tests that are spewing crap to stderr. [07:11] Yes. It's because publish-distro is now a LaunchpadCronScript. [07:11] It previously redirected stdout/stderr to null pipes. [07:11] Where that test instantiates the object, it should inject a DevNullLogger. [07:12] But now runs PublishDistro directly. [07:12] Yeah. [07:12] I can do that. [07:12] Thanks. [07:13] I wanna QA my db update script, which will make qastaging die for a few seconds. [07:13] Feel free. [07:13] We are bad and a while away from buildbot completion. [07:14] * wallyworld goes out to buy food === wallyworld changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 240 - 0:[#######=]:256 [07:26] stub: \o/ [07:27] stub: we need a catchup call too [07:27] I couldn't last night - family thing, and am eating now; can we make a time later today? [07:32] lifeless: sure [07:33] I might grab some fud too [07:42] shall we say in one hours time then ? [07:44] k [07:49] good morning [08:04] Howdy [08:06] morning everyone [08:06] hi bigjools, mrevell [08:06] lifeless: still here? [08:06] o/ [08:06] kindof :> [08:06] the U3011 is amazing [08:06] you should totally get one [08:06] imax-mode [08:08] \o/ [08:11] woo! [08:13] poolie: photo ? [08:15] lifeless: https://plus.google.com/112646476239496153808/posts/ApTZ7GyWAdo [08:15] looks like a big glowing thing [08:15] heh, that laptop looks like a netbook [08:35] stub: now ok ? [08:40] jtv: Contents is not updated yet it seems [08:40] oh [08:40] http://archive.ubuntu.com/ubuntu/dists/oneiric/ for example [08:41] jtv: http://launchpadlibrarian.net/75734346/2TgWVd4UTg0dWE5ieBiCMVPmNBE.txt [08:41] grrr [08:41] jtv: need to set up script monitoring for this :) [08:41] We don't have that? [08:42] jtv: you need to tell losas to do so [08:42] and this is a new LPS [08:42] LPS? [not LaunchpadProductionStatus I assume] [08:42] Local Processor Status? [08:42] Hi lifeless :) [08:42] hola jtv [08:43] LaunchpadScript [08:43] I guess [08:43] Ah yes :) [08:47] lifeless: I'm going to try skype on my desktop again [08:48] ok [08:48] ARGH [08:48] call me :) [08:48] FeatureFixture cancels all other feature flags. I've been burned. === adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring | Critical bugs: 240 - 0:[#######=]:256 [09:22] bigjools: generate-contents-files cron fix has deployed, so we'll see. [09:22] jtv: oh, cowboy? [09:22] cron change — no code change. [09:22] ah cron, sorry [09:29] bigjools: another thing: we should be able to scratch steps 12 & 14 off https://wiki.ubuntu.com/NewReleaseCycleProcess now, shouldn't we? [09:30] yup [09:31] cjwatson: I realize we discussed this already, but I'd like to check up: if we do ^^^ then step 13 could go as well because you watch these files like a hawk anyway, right? [09:35] Anyone running Aurora ? [11:24] adeuring: hey! [11:24] adeuring: Moin ;) [11:24] adeuring: Wenn du so nett wärst ... [11:24] bitte [11:24] ;) [11:24] file:///home/henning/canonical/lp-branches/devel-work/lib/lp/code/javascript/tests/test_branchdiff.html [11:24] crap [11:24] mist [11:24] adeuring: https://code.launchpad.net/~henninge/launchpad/bug-813627-preview-diff-overlay/+merge/68820 [11:42] henninge: sure, I'll look [11:47] adeuring: thank you! [11:52] I'm writing a launchpadlib script, running it against staging for now. [11:52] am using login_with, [11:52] get this error: http://paste.ubuntu.com/649908/ [11:52] what am I supposed to do with that? [11:54] why am I unauthorized? how do I become authorized? do my users need to know about access tokens? [11:55] * jml ducking out to get some food. please don't let that stop you answering in the mean time. [11:56] jml: I wonder if it's anything to do with the cache bug I filed the other day [12:02] henninge: r=me [12:03] adeuring: thanks again ;-) [12:09] bigjools: which one is that? [12:10] jml: mine was to do with cached wadl not updating but I wonder if the auth tokens sometimes get the same problem [12:10] I seem to recall something like that. [12:10] It usually happens when we blow up the session database. [12:11] bigjools: https://bugs.launchpad.net/launchpadlib/+bug/812799 ? [12:11] <_mup_> Bug #812799: Local cache not updated when it should be < https://launchpad.net/bugs/812799 > [12:11] well I've always usually been directed to re-auth [12:11] jml: yes [12:17] bigjools: I moved .launchpadlib out of the way and still get the same problem [12:18] which is consistent with my discoveries from strace. [12:18] jml: it should offer to re-auth :/ [12:20] bigjools: I guess it's using some kind of system keyring [12:21] yeah it throws the token in the password storage that your desktop uses [12:22] I can't find it in Passwords & Encryption Keys [12:27] it's called something odd IIRC === bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring, bac | Critical bugs: 240 - 0:[#######=]:256 [12:33] james_w: the code says it's called 'launchpadlib' [12:33] at least, that's what is passed to keyring.get_password [12:34] hmm, ok [12:34] but that doesn't exist in Passwords & Encryption Keys [12:34] so I'm trying to figure out where the hell it's looking [12:34] * jml busts out set_trace, since google is failing. [12:34] woo ajaxy mid-review diffs working [12:35] the link should be green though [12:35] it's called "network password" here [12:35] jml, ^ [12:36] Project devel build #911: FAILURE in 5 hr 44 min: https://lpci.wedontsleep.org/job/devel/911/ [12:36] harumph [12:36] ahh... [12:36] 'launchpadlib' is the domain. or something. [12:37] which doesn't show up in P&EK [12:45] https://bugs.launchpad.net/launchpadlib/+bug/814595 [12:45] <_mup_> Bug #814595: Unrecoverable error when authorization fails < https://launchpad.net/bugs/814595 > [12:47] sorry if it's a little grumpy. it's a pretty serious bug & I lost a fair bit of time to it. [12:47] james_w: how did you figure out that it was called "network password"? [12:48] jml, just by looking at everything that didn't have a clear non-launchpad purpose [12:48] james_w: heh, ok. thanks. [12:49] unfortunately the string "network password" isn't under our control; the Gnome keyring calls that class of entries "network password" === matsubara-afk is now known as matsubara [12:52] wow, adeuring, no backlog [12:52] benji: that is a shame. [12:53] bac: well, I did only two reviews this morning. [12:53] two more than me today! [12:53] seems that people are in holidays [12:54] benji: luckily, the bug can be fixed without that, since the ideal is never to be compelled to look for keys in the keyring [12:54] jml: indeed; in fact, I /thought/ that invalid auth tokens were silently thrown away [12:56] :\ [12:59] http://shnatsel.blogspot.com/2011/07/weve-just-revolutionized-alpha-testing.html <- a Launchpad success story [13:08] nice [13:11] today is obviously a 'file lots of bugs' day [13:12] almost makes me want to file bugs on Launchpad about improving my person-oriented bugs views. [13:14] jml: in happy news my inline diffs on merge proposals patch landed on production (for ~launchpad) [13:14] * spiv -> bed [13:16] dpm: ping [13:28] henninge, pong [13:32] henninge, ping for standup [13:33] deryck: argh, already [13:34] can I delete a PPA over the API? [13:35] no [13:36] bigjools: why not? [13:36] deryck: mumble dead, try again [13:36] jml: because nobody write the code to do it [13:36] henninge, ah ok [13:36] wrote* [13:36] bigjools: fair enough. [13:36] jml: are you grumpy today? :) [13:37] bigjools: not really. just while debugging the login error. [13:47] Should be fairly easy to add, just the decorator. [13:47] We should perhaps not do it until PPA deletion does something useful. [13:47] Which is also very easy. [13:48] wgrant: you criticise with no suggestion of what would be useful. Many people already find it useful. [13:48] Right [13:48] bigjools: It doesn't free up the name or disappear. [13:48] It is useful for the purpose for which it was implemented. [13:49] there's a bug about those IIRC [13:49] But an API for that purpose is not particularly useful. [13:49] I don't think. [13:49] make it disappear was rather hard [13:49] Yeah. [13:49] Rename it is one line of code plus tests :) [13:49] And it fixes most issues that I know of. [13:49] Clean up job that removes the row from Archive after a day? [13:49] one line? [13:50] But that then means you need to delete the publications too [13:50] StevenK: that would be the naive approach :) [13:50] StevenK: With all the BPRs and SPRs that have been copied into other archives? [13:50] Tis messy [13:55] why not delete in real-time? [13:56] We cannot remove the DB stuff. [13:56] And there is stuff on disk to be removed. [13:57] ok, so that just means we use long poll, right? [13:57] Hah [14:00] we'll work on deploying long poll when Red goes to maintenance [14:02] oh, interesting. [14:03] wgrant, StevenK: BTW, I am very concerned about never being able to derive from distros with a) active builds b) items in the queue [14:03] well, it's not like deleting PPAs is going to be attempted before then. [14:03] I think relaxing b) is easy [14:03] I am not sure of ramifications for a) [14:03] It is pretty messy. [14:03] This goes back into the copying partial subsets of binaries thing. [14:03] indeed [14:04] Another dupe of which was filed yesterday. [14:05] That we should allow copying binaries only? [14:05] That if something built in karmic, you can only copy it from karmic, not anything later. [14:07] Do we have a way for tests to query the log level that LaunchpadScript sets? Apparently it gets set on a handler, not the logger, but I'm not seeing the handler. [14:14] hi sinzui [14:17] jtv: You would have to poke the internals. Why would it matter what level the script sets? [14:18] stub: for some reason LaunchpadScript setup changes log levels. [14:18] You probably have to invoke a script and look for DEBUG, INFO etc. [14:19] That'd be very costly. :( [14:19] It adds log levels, and configures the various handlers to what level they emit by default. [14:20] logging.DEBUG isn't changes to a new number or anything like that. [14:20] We have several cases where scripts instantiate and run other script objects, which seems to change the log level no matter what you do (and never change it back) [14:20] c/changes/changed [14:20] Well no, that'd be very weird. [14:20] Yer, have no idea what happens if you try to do that. [14:21] Point is, logger.getEffectiveLevel returns NOTSET. [14:21] LaunchpadScript seems pretty difficult to invoke except as a standalone script. [14:22] awesome, ec2 sent me an email saying "Test Runner FAILED" [14:23] logging.getLogger('').getEffectiveLevel() you mean? [14:23] (the root logger?) [14:23] Would that work? [14:23] I just tried getEffectiveLevel on the logger that LaunchpadScript created. [14:24] NOTSET just means inherit from somewhere I think [14:24] Although it does seem to do something global, because when script A instantiates script B, that's enough to change A's logging as well. [14:24] so the logger the script just uses its parents or something like that. [14:25] So suddenly from the moment B is instantiated, A continues without the log level you specified on the command line. [14:25] There are a number of loggers, and we only want to bother maintaining one, so we just configure that stuff on the root logger IIRC. [14:25] That would explain. [14:26] Yer. Cause we can't force scripts to use the logger instantiated just for them, or we could, but legacy code would need to be waded through. [14:27] (and we would have to pass it around everywhere and use it whenever some code elsewhere wanted to log a message) [14:27] So yeah, it is global state and LaunchpadScript or somewhere in that mess sets it up so we see the messages per -v, -q etc. with the nice formatting and timestamps. [14:28] Maybe some flag is needed to create a LaunchpadScript without doing that setup? [14:28] I was thinking maybe we should skip it if test_flags is given. [14:28] That sounds sane [14:28] Except it makes for damned ugly tests. [14:28] Because how do you test this without passing test_args? [14:29] I think you have to pass test_flags in, or it will use argv anyway, and make the test runner explode. [14:29] Exactly. [14:29] yer. [14:29] so new flag. [14:29] Or maybe one test could just sabotage options parsing. [14:30] No, no, I don't think it'd help much. :( [14:30] if you like monkey patches over explicit arguments and the probability of you forgetting to unsabotage it leak your breakage to later tests... [14:30] Ah yes, the joy of global variables. [14:31] wgrant: were you talking about bug 813749 ? [14:31] <_mup_> Bug #813749: copying package that have been copied from another series doesn't work if you do not use the "original" package < https://launchpad.net/bugs/813749 > [14:31] Feel free to refactor the entire LaunchpadScript API. It it horrible and difficult to extend. [14:31] Anyway, I think it's probably reasonable to skip the logger setup if test_args is given. The script simply own't have -v and -q. [14:31] whoa, I just learned about https://launchpad.net/launchpad/+documentation ;) [14:31] *won't [14:32] wgrant: and what is the dupe? [14:32] can't find it [14:32] bigjools: Oh, apparently I saw it and forgot to triage it. [14:32] Probably because I couldn't find the dupe. [14:32] heh [14:32] jtv: It might break some tests, but I think it unlikely enough to give it a go. [14:32] It was like 6am, so meh. [14:32] stub: right ho, I'll try that. [14:32] But you know the general idea of the bug, right? [14:33] wgrant: vaguely [14:33] 2nd copy copies already copied binaries or something [14:33] karmic has lpia, while >= lucid don't. [14:33] So if you copy something from karmic to lucid, lucid only gets two of the three binaries. [14:33] So you can't copy from, say, lucid to maverick. [14:33] Because the copy doesn't have a superset of the archive's binaries. [14:34] wgrant: I think we can alter the +initseries job so that it checks the packages you're copying to see if any of them are building [14:35] rather than a blanket "something is building, argh" [14:35] Even that is probably too strict. [14:35] even if copying with binaries? [14:35] But making it more lenient than that is more than probably extremely painful and difficult. [14:36] wgrant: actually I'm still struggling to understand this issue [14:36] it's been a long week and my brain was shredded the last 2 days by derived distros problems [14:38] wgrant: I guess the problem is, why do we check the superset [14:38] or is that the bug? [14:38] bac, https://code.launchpad.net/~gary/launchpad/bug812335/+merge/68762 when you have a mo [14:38] bigjools: See line 399 onwards in packagecopier.py [14:39] * bigjools looks [14:39] bigjools: I'm not sure the rationale remains valid, but we need something like that. [14:39] gary_poster: will do it now [14:39] ty [14:39] wgrant: I don;t undserstand the rationale [14:39] my typing has gone to hell [14:40] bigjools: The rationale doesn't explain the superset check. [14:40] and what is the problem it's trying to check [14:40] right :) [14:40] It's simply providing reasoning that all BPRs have unique files. [14:41] unique across what set? [14:41] All their files have different contents, that is. [14:41] Ah. [14:42] The superset check is, I suspect, to prevent different sets of builds being copied in together. [14:42] * bigjools tries to find the original bug [14:42] eg. if I have an i386 binary for that source already in this archive, and I try to copy a different i386 one in. [14:42] Then the source will have two different i386 binaries. [14:42] In one archive. [14:43] Or something. [14:43] bug #387613 [14:43] <_mup_> Bug #387613: CheckALL - CopyALL approach does not work well for multiple copies

< https://launchpad.net/bugs/387613 > [14:44] Where'd you get that? Annotate? [14:44] "conflicting versions to be copied in the same batch" [14:44] annotate, then bzr log [14:47]