[00:11] StevenK: Sorry, I'm just trying to look at a couple of things. What appears on the recipient_subscriptions_url and ppa_url pages? I can see from the test what those urls translate to, I would just like to see an example of those pages. [00:13] StevenK: I'm mostly trying to see the difference between those pages [00:13] wgrant: so... [00:14] lifeless: It's now Invalid. There are other bugs for the build notification issues. [00:14] lifeless: (which should have been a critical part of DDs, but nobody in the squad thought about it) [00:16] StevenK: Ah actually I figured it out. [00:19] wgrant: can you confirm my comment on bug 47353 [00:19] <_mup_> Bug #47353: give-back-loop detection would be desireable

< https://launchpad.net/bugs/47353 > [00:20] StevenK: I know you haven't touched this, but shouldn't the 'recipient_subscriptions_url' link to be to: https://launchpad.net/~huwshimi/+archivesubscriptions/(id)/+index instead of the generic list of *all* the archives (I assume we can be smart enough to do that)? [00:25] sinzui: I believe bug 50894 should be fix released [00:25] <_mup_> Bug #50894: Can't change the distribution for a distro package bug report < https://launchpad.net/bugs/50894 > [00:27] sinzui: and have you seen bug 52656 in the context of disclosure? [00:27] <_mup_> Bug #52656: Reports that bug contacts have been subscribed when they haven't < https://launchpad.net/bugs/52656 > [00:27] sinzui: also! bug 52915 - wallyworld_'s work should fix-release that, no ? [00:27] <_mup_> Bug #52915: Reassigning a private bug to a different product doesn't notify either the new product maintainer or security contact < https://launchpad.net/bugs/52915 > [00:28] sinzui: perhaps not, but close to it. Or something. [00:28] lifeless: i don't think it will but i can add it to my todo list [00:28] wallyworld_: I'd check with sinzui but it seems awfully close to 'easy' now. [00:28] +1 yes [00:35] wgrant: is bug 54773 still relevant? [00:35] <_mup_> Bug #54773: Dry run on process-accepted isn't always dry < https://launchpad.net/bugs/54773 > [00:35] s/process-accepted/Soyuz/ s/always/often/ [00:36] and hah - isn't bug 55030 a dupe ? [00:36] <_mup_> Bug #55030: Binary domination removes arch-all binaries too soon

< https://launchpad.net/bugs/55030 > [00:36] (sorry to be dragging you into this, but these bugs are sparse on symptoms) [00:36] lifeless: 55030 would be the original, I assume... [00:37] But I think there is a modern dupe which has been escalated. [00:37] Right. [00:38] and bug 55520 [00:38] <_mup_> Bug #55520: Extend the package-driven approach to Domination & JudgeSupersed

< https://launchpad.net/bugs/55520 > [00:38] a work item with no context. \o/ [00:39] I *think* that refers to the pushing of lots of publishing code into SPPH.publish. [00:39] But that bug has long been a mystery. [00:40] bug 55521 is even more useful [00:40] <_mup_> Bug #55521: Benchmark DeathRow procedure

< https://launchpad.net/bugs/55521 > [00:40] Yeah, because we know how fast it is. "not" [00:41] lifeless: Hmm, I'm pretty sure there's an RT for that bug you said there was an RT for. [00:41] https://rt.admin.canonical.com/Ticket/Display.html?id=43780 [00:41] wgrant: echan :P [00:42] oh good [00:42] I just failed at search [01:03] wgrant: is 60190 fixed ? [01:03] Bug #60190 [01:03] <_mup_> Bug #60190: Misleading email when uploads are UNAPPROVED < https://launchpad.net/bugs/60190 > [01:04] I think it is fixed. [01:04] I'm pretty sure modern emails say "Waiting for approval" in the subject. [01:16] sinzui: would like your thoughts on bug 56650, i fyou are still around. [01:16] <_mup_> Bug #56650: Restrictions on milestone editing should be dropped < https://launchpad.net/bugs/56650 > [01:16] * StevenK waits for buildout [01:16] * StevenK looks for a private bug on qas [01:17] wgrant: Do you happen to have one handy? [01:18] wgrant: so, bug 54773 - is --dry-run wanted for soyuz? [01:18] <_mup_> Bug #54773: Dry run on process-accepted isn't always dry < https://launchpad.net/bugs/54773 > [01:18] wgrant: or was it all yagni ? [01:20] wgrant: and did I ask you about bug 47353 ? [01:20] <_mup_> Bug #47353: give-back-loop detection would be desireable

< https://launchpad.net/bugs/47353 > [01:21] StevenK: Bug #1234 should be private still. [01:21] <_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts < https://launchpad.net/bugs/1234 > [01:22] lifeless: Most of our scripts have a dry-run option, but a lot of them don't work. [01:22] lifeless: I don't know what we want to do with them. [01:22] I commented on 47353 an hour ago. [01:22] ah thanks [01:27] Oh, ouch [01:27] It *isn't* a timeout [01:27] ProgrammingError: column branch.transitively_private does not exist
LINE 1: ...agename, Branch.stacked_on, Branch.target_suffix, Branch.tra...
^

[01:27] WALLYWORLD!! [01:29] wallyworld_: ^ [01:30] StevenK: context? [01:31] qastaging hasn't had the column added [01:31] not wallyworlds fault [01:31] lifeless: i was told that db patch had been rolled out? [01:31] process failure with fastdowntime; it should have been applied to qastaging too [01:31] Hah. [01:31] or at least i thought it was [01:31] I just independently asked for that in #-ops. [01:31] Seeing just such an OOPS myself. [01:33] lifeless: so i can rollback or i can fix the new problem [01:33] mwhudson: rollback [01:33] lifeless: is there a command line for that? [01:33] It's not landed yet, is it? [01:33] bzr merge -r x..before:x; bzr commit; bzr push; bzr lp-land --rollback x [01:34] it might still be in ec2 actually [01:34] I see the rollback in 14011 [01:34] And nothing since. [01:34] mwhudson: kill the instance [01:34] Kill the instance. [01:34] ok done [01:34] hooray for a slow test suite [01:34] Oh, bah, I was looking at the wrong rollback. We can't deploy for a while. [01:34] blame the software why don't you [01:34] see [01:34] Because the rollback was landed 5 hours after I asked :/ [01:35] 'hooray that ec2 is so slow' [01:35] is what I would say [01:35] wallyworld_: We need to roll back your garbo job, too. [01:35] wallyworld_: We can't deploy that until the triggers are in place. [01:35] wgrant: why? [01:36] wgrant: the garbo job doesn't need the triggers [01:36] wallyworld_: Because the job only touches branches where transitively_private is NULL, right? [01:36] yes [01:36] And the trigger isn't there to keep transitively_private consistent once it is set. [01:36] yes [01:36] So the job is going to be setting stuff which then gets out of date. [01:36] And is never corrected. [01:37] yes, i think that's the case sadly [01:37] Can you revert it, please? [01:37] there is an alternative [01:37] or we could get the triggers deployed [01:37] hi all [01:38] which is what i was counting on [01:38] set the transitive field to null when updating private [01:38] wallyworld_: We can't do that until friday night. [01:38] wallyworld_: its /never/ safe to land code with a db dependency in devel before that dependency is in production. [01:38] wallyworld_: it needs to be a hard rule, because the timelines for deploys are so radically different [01:39] lifeless: it wasn't intentional. i had a few branches on the go and got mixed up about the order [01:39] wallyworld_: no worries [01:39] nigelb has been hitting that, he wants to drop a column, but we haven't deployed the code that stops using it everywhere. [01:40] wallyworld_: I'm trying to be really clear about how this stuff hangs together, at the risk of telling folk to suck eggs. [01:40] StevenK: reverse case, but yes. [01:40] Damn, buildbot is still only half-way through. [01:40] StevenK: this is why finishing RFWTAD is so important [01:40] lifeless: i know the rules, it was a scheduling mistake [01:40] wallyworld_: cool :) [01:40] wallyworld_: like I said, just erroring on clarity atm cause its so new for everyone [01:40] wallyworld_: So, you're reverting that in the next hour or so? [01:40] yes [01:41] wgrant: should i mark as qa bad first? [01:41] qa-bad bad-commit-XXX [01:41] Land with --rollback=XXX [01:41] And lp-land, don't ec2 land. [01:41] where xxx is the rev nr? [01:41] Yep. [01:42] what happened with qas and the column? [01:42] But that is seperate from what is blocking my QA, right? [01:42] i thought the patch to add the column had been deployed everywhere? [01:42] Waiting on a LOSA/completion. [01:42] StevenK: It's the same rev, but qastaging needed the patch anyway. [01:42] wallyworld_: qastaging doesn't automatically do DB upgrades. [01:42] TBH, I think that needs fixing [01:42] wallyworld_: Mostly to catch stuff landing on devel with DB patches that aren't on prod. [01:43] sure, but it thought a downtime would do it [01:43] wallyworld_: But it also made me notice your rev. [01:43] wallyworld_: downtime does the minimal possible. [01:43] I'm sick of qas having a DB that is months behind [01:43] wallyworld_: Which is applying a patch to production. [01:43] it's no good on prod if it's not on qas :-( [01:43] wallyworld_: We should probably apply to qastaging immediately afterwards, but the timing is terrible and the last couple of downtimes have been.. chaotic. [01:44] sure. we need to fix the process cause folks will land devel code that will break qas [01:44] if qas != prod [01:44] Well. [01:44] OTOH if we leave it manual, it means that lifeless and I are more likely to notice revs like this one. [01:47] StevenK: DB restores and upgrades are largely unrelated, FWIW. [01:47] Anyway, I am wandering off for a while. [01:47] wallyworld_: Please land that revert ASAP. [01:47] sure, have to save some work first [01:47] Confused... [01:48] Oh, IDE people. [01:48] lol [01:48] :) [01:48] wgrant, lifeless: can you be paranoid over https://code.launchpad.net/~mwhudson/launchpad/feature-flag-xmlrpc-2/+merge/76493 once more? [01:48] no, not ide. [01:48] i use a single sandbox that i bzr switch between [01:48] no ide required to do a rollback [01:49] at least i can debug without editing source code :-P [01:49] mwhudson: That's not landing again until it's been aggressively tried locally, but it looks more sensible now. And is even tested. Thanks. [01:50] wgrant: it was tested before [01:50] Ah, that was one of the tests you inverted the order of? [01:50] I only noticed the TeamScope ones. [01:50] just with the controller constructed and the request set up in the wrong order [01:50] But that's the only scope I knew was broken, so maybe I wasn't looking for the others. [01:50] Ah [02:04] wgrant: do you know of any tricks for testing feature rules locally? [02:04] mwhudson, locally in what sense? [02:04] other than grep for a feature flag check in a template and try to make it happen [02:04] on lp.dev interactively? [02:04] poolie: yes, lp.dev [02:05] mwhudson: visit /+feature-rules [02:05] and look at the comment at the bottom of all html pages [02:05] poolie: ah cool [02:07] mwhudson: better [02:08] mwhudson: thanks! [02:11] wgrant: well, i've done positive and negative tests for pageid: and team: scopes [02:11] obviously default still works [02:11] and i'm not sure server scope really makes sense in lp.dev? [02:11] i guess i can change the config to make it look like edge [02:11] server.beta IIRC [02:11] or something [02:11] .dev i think [02:11] lifeless: ah you seem to be right [02:12] yeah .beta [02:12] we could add a /+feature-test form that lets you evaluate random stuff [02:13] wgrant: bug 1234 on qas is public [02:13] <_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts < https://launchpad.net/bugs/1234 > [02:13] lifeless, do you want to talk about our qbr some time [02:25] sure [02:29] lifeless: Hey! Sorry, about the late reply. I was trying to understand errorlog.py the other day and I was stuck a bit. [02:35] no worries [02:36] I have to pop out for a few, if yo uwant to chat in ~20 I'd be delighted to do so [02:36] Cool! [02:36] wgrant: any comment on bug 117557 ? [02:36] <_mup_> Bug #117557: Nascent Upload code doesn't check properly for bad distroseries

< https://launchpad.net/bugs/117557 > [02:36] I'll grab coffee by then and boot into the right computer. [02:37] lifeless: "aaaaaaaa" [02:37] lifeless: NascentUpload is pretty bloody awful. [02:37] lifeless: Probably still valid. [02:38] wgrant: qa-ok [02:38] StevenK: Thanks, but it's sorta irrelevant now :/ [02:39] Indeed :-( [03:01] nigelb: okies [03:01] lifeless: gimme 2 mins. My laptop with launchpad is booting :) [03:02] still? wow... [03:02] Well, I made coffee in between, etc [03:02] :P [03:02] YHBT HAND HTH [03:06] wgrant: permanent gina domination looks good on dogfood… deleted a frightening number of sid packages, but the remaining number matches the number I see in Sources.gz. [03:07] jtv: Yep, saw that on the bug. Excellent news. [03:07] Unfortunately there's a qa-bad in the way. [03:07] jtv: Less excellent news, however, is that it still seems to be running very slowly on production... and script-monitor isn't alerting about it. [03:07] 3 qa-bads, actually. [03:07] Just two of them are already deployed. [03:08] wgrant: 3!? I only see 1 qa-needstesting & 1 qa-bad. [03:08] jtv: Like I say two of them are already deployed. There are three rollbacks that need to come through buildbot and qastaging before we can deploy :/ [03:08] We'll have to see whether the slow runs are really a concern after (1) the transitional code is gone and (2) the initial deletions have been done. [03:09] Yeah. [03:09] I'm more worried that we're not getting alerts about it. [03:09] its doing shorter transactionw now right ? [03:09] Muchly. [03:09] cool [03:10] wgrant: I had to leave before we could discuss my p-d-r suggestion yesterday. Is it correct that the main worry is hidden long-standing dependencies on ancient librarian files? [03:13] jtv: No, that was the first p-d-r issue. This one is probably pool files. [03:14] The reaper deletes those as well? [03:15] huwshimi: do you think bug 126684 is still relevant ? [03:15] <_mup_> Bug #126684: Style sheet is overly complex

< https://launchpad.net/bugs/126684 > [03:18] lifeless: okay, coffee by my side, and work computer turned off. [03:19] In other news, a colleague deleted a library from production server because "it was not being used" [03:19] I had to put out a fire today morning for that one :) [03:20] win [03:21] totally! [03:21] Okay, couple of things - 1) What all information do I log? [03:21] everything you can get except the session cookie [03:22] errorlog.py is mostly irrelevant to you btw [03:22] s/mostly/entirely/ [03:22] Oh. [03:23] Gah. [03:23] I'll get error message, URL, line number as get parameters into js-oopsd [03:23] I suppose I can also get a timestamp based on when I get the request [03:31] lifeless: 1) More embarassingly, I don't see where in errorlog.py the oops is actually written to file. [03:31] I'm guessing that's the bit I can take away from launchpad's oops handling [03:40] nigelb: sorry [03:40] EBABY [03:40] nigelb: all the oops stuff is in python-oops, python-oops-wsgi, python-oops-datedir-repo etc [03:41] ah [03:41] I could just be using those libs.. [03:42] s/could/will be/ [03:42] Right. :) [03:43] for instance, http://bazaar.launchpad.net/~lifeless/+junk/gpgverify/view/head:/gpgverify/main.py#L87 [03:43] parses and configures a datedir repo [03:44] then runs the app (a web.py thing, I suggest using wsgiref - it will be cleaner) [03:44] see the various project README's and pydocs for more info [03:44] what you need will be: [03:44] one repo [03:44] two configs - one for received js oopses, one for oopses from your wsgi app itself [03:45] oops_wsgi wrapped around your app for the latter [03:45] and explicit use of the former for the ks oopses [03:46] *js [03:46] that thing [03:47] okay, so I need to read up on python-oops-wsgi and python-oops-datedir-repo [03:47] and python-oops :P [03:48] remind me tomorrow and I'll put a full project skeleton, and a sketch, together fo ryou [03:48] aren't these projects by Canonical/Launchpad? [03:48] so you can focus on the interesting stuff [03:48] okay! [03:48] nigelb: they are, recently extracted from the LP code base [03:48] Yeah, I thought so ) [03:48] :) [03:49] wallyworld_: Hey, around? [03:49] nigelb: yep [03:49] wallyworld_: The other day we were talking about overriding default styles for certain forms for the +editemails form that was fixing [03:50] we were [03:50] Do you have an example to point me at? [03:50] just a sec [03:50] I want to get those small bugs of my list :) [03:51] nigelb: lp/code/templates/branch-macros.pt [03:51] but only if it is truly a one-off [03:52] it really should be in styles-3-0.css [03:52] Hrm, I could put it in styles--3.0.css [03:53] nigelb: and i'd check with huwshimi since he is looking at this sort of stuff and trying to fix what we've done badly in the past [03:53] Add an ID, grab it in css. override. [03:53] Cool, okay. [03:54] nigelb: so, in other words, we've done certain things in the past with respect to css but it may not be the right way now [03:54] heh, I'll talk to him. [03:54] cool. thanks [03:54] best to try and avoid creating more tec hdebt :-) [03:55] especially when I'm trying to fix tech debt :P [03:55] lol [03:55] nigelb: it may be that what was done in branch-macros.pt is ok, but better to ask [03:55] just to be sure [03:56] Personally, I dislike CSS going anywhere other than style.css most of the time. [03:56] <-- fan of semantic web [03:59] yep [04:05] wgrant: the reaper deletes pool files as well then? [04:05] jtv: That is the entire purpose of the reaper. [04:06] wgrant: and so the great fear is that we might reap files there that we shouldn't? [04:07] Yes. [04:08] I gag at the thought, but perhaps we could have a look at atimes to see if we might get lucky with the number of files that we need to worry about? [04:08] If we have atimes, of course. [04:08] No. [04:08] No we don't have atimes, or no we can't look at them? [04:09] You are aware that there are some hundreds of Ubuntu mirrors, right? :) [04:09] Ah those. [04:10] And we can't sample atimes from those? [04:10] Or do the files get read in the mirroring process? [04:13] Won't help with internal access, but could eliminate one source of problems? [04:24] I don't suppose we could stop files that we think can be reaped from being mirrored? [04:24] wgrant: re bug 137448, I seem to have the option to change everything [04:24] <_mup_> Bug #137448: New UI is confusing and counter inuitive for changing affected package < https://launchpad.net/bugs/137448 > [04:25] micahg: You can't change the package or distribution inline -- you have to know to open the expander. [04:25] micahg: It used to be that clicking on the package name opened the expander. [04:26] Same with status/importance. [04:26] Before AJAX. [04:26] ah, right [04:26] But now you can click on status/importance to change them inline, so nobody knows about the expander. [04:44] wallyworld_: Hey [04:44] huwshimi: yello. was going to ping you later :-) [04:44] wallyworld_: Would you like to wait? [04:44] wallyworld_: Or is now ok? [04:45] huwshimi: is it ok if i ping you in an hour or so? i'm just finishing a branch [04:45] wallyworld_: Of course! I'm in no hurry [04:45] huwshimi: thanks. how's the bub? [04:46] wgrant: how soon do we need the question about the safety of pool-reaping resolved? [04:46] undef [04:46] wallyworld_: Doing great. Started smiling on the weekend! [04:46] Hey, what are the branch portlets which show statistics? I can't find any. [04:46] huwshimi: we all laugh at you :-P [04:47] wallyworld_: It's true [04:47] wallyworld_: Wah! There are multiple pretty-overlays on a bug page! [04:47] what the.... [04:47] I can now hide comments? [04:48] StevenK: yes! hence the advice in the mp to do stuff relative to a specific content box or by id :-P [04:48] nigelb: No, that's a display bug to do with memcached. [04:48] * StevenK hides nigelb's last comment [04:48] WIll be fixed in a few hours. [04:48] wgrant: AH [04:48] StevenK: lol [04:48] Can someone help me with bug 656941 [04:48] <_mup_> Bug #656941: Portlets on branch list pages disclose information on private branches < https://launchpad.net/bugs/656941 > [04:49] I can't reproduce the bug. [04:49] wallyworld_: It's fine for +subscriptions, but there are like four for a bug page [04:49] Wait. Fix Released. [04:49] it's fine until someone adds another one :-) [04:50] id="yui_3_3_0_1_13166655391282262" [04:50] Handy. [04:57] wallyworld_: ^ ? [04:58] StevenK: that's a defualt generated one. you need to tie the overlay to a specific content box or look for it relative to another dom element [04:58] Can I pass an id to the constructer? [04:58] StevenK: for our widgets, we tend to create content box divs with an id named after the property [04:58] StevenK: see picker_patcher [04:59] the contentBox is passed in from memory [04:59] we construct the content box with the id we pass in [04:59] i could be a bit off on the details [04:59] http://pastebin.ubuntu.com/694948/ [05:00] Those are the first elements of [05:01] what are those overlays used for? [05:01] whicu ui elements? [05:02] A bunch of them are for bug task editing [05:02] The first one is the one I want, but how the frack do you *tell* that :-) [05:02] they may be tied to an Activator [05:02] are the overlays shown when the user clocks on a link, or a little sprite? [05:03] Yes [05:03] what's the js module? [05:04] bug_subscription_portlet [05:06] StevenK: it looks like a single overlay is created when the user clicks on a link, and then destoyed after the ajax call. so those other ones must be from elsewhere [05:07] what's the html inside one of them? [05:07] Obviously [05:07] The first three all start with a div with class content_box_container [05:10]