[00:34] wallyworld_, StevenK: Please don't force buildbot yet. [00:35] ok [00:35] wallyworld_: However, I do need an urgent review for https://code.launchpad.net/~wgrant/launchpad/connectionstring-hates-production/+merge/74321 [00:35] If you have a sec. [00:35] sure [00:36] Copyright year fail. [00:36] Fixing. [00:40] wgrant: shoud the test for changes include the case where the key being changed is in the original connection string, as well as just adding a new key value? [00:41] wallyworld_: Probably, yes. [00:41] * wgrant fixes. [00:41] thanks [00:46] * wallyworld_ wants longpoll NOW. hitting refresh on a mp is a pita [00:48] Diff has updated. [00:48] wgrant: r-me. thanks [00:48] Thanks. [01:00] wgrant: r13862 is marked as bad, what rev is the relevant fix/rollback? [01:01] [r=henninge][no-qa] Sort utilities/sourcedeps.cache. Finally. [01:01] Oh, Henning! [01:02] G: You have two revs to QA -- bug 697157 and bug 841658 [01:02] <_mup_> Bug #697157: Streamline "You have assigned this bug to yourself" message

< https://launchpad.net/bugs/697157 > [01:02] <_mup_> Bug #841658: DistroSeries/DistroArchSeries API link does not return any entries

< https://launchpad.net/bugs/841658 > [01:04] StevenK: jtv said he was going to QA 697157 because it's his responsibility ;) [01:04] wgrant: Any idea how to QA bug 841850? [01:04] <_mup_> Bug #841850: OpenIDRPSummary continues to exist < https://launchpad.net/bugs/841850 > [01:04] but I'll test 841658 now :) [01:04] StevenK: it's on qastaging now right? [01:05] G: Aye [01:06] StevenK: Acquire a user without PPAs (or ask me to use one of my test accounts), ensure that renaming displays the warning sensibly, and that acknowledging it works. [01:07] wgrant: I have a PPA, so I think it should be one of your test accounts [01:07] And I don't really want to launch into the mess of deleting it just to QA something :-/ [01:08] StevenK: yep, 658 looks correct, I'll mark it qa-ok [01:09] StevenK: You can't delete it, because qastaging doesn't have a publisher. [01:10] So not signing up for a new account on qas :-) [01:11] * wgrant is doing it. [01:11] qa-ok [01:12] wgrant: So marked, thanks [01:16] No staticdiffs against Launchpad. Bah [01:16] Hm, sure? [01:16] Perhaps I should get the LOSAs to actually do the migration on qastaging ... [01:16] You didn't accidentally commit the migration, did you? [01:17] On DF? I don't think so [01:17] You can't use the presence of staticdiffs for QA. [01:17] Because you can't view prod diffs on qastaging. [01:17] launchpad_dogfood=# SELECT count(*) from branchmergeproposal where review_diff is not null and merge_diff is null; => 5251 [01:17] Just check the a new preview diff works OK. [01:17] No need to QA the migration you did yesterday. [01:18] So create a new MP and check the diff gets generated? [01:19] yes. [01:19] Ideally check that revision mail still works too. [01:19] So... [01:20] Push up a new branch. [01:20] Subscribe to revision mail. [01:20] Push up some new revisions. [01:20] Scan the branch. [01:20] Push up some more new revisions. [01:20] Scan the branch again. [01:20] Uncommit and push. [01:20] Scan the branch again. [01:20] Create a merge proposal somewhere (doesn't need to be same branch), and check that the diff is generated. [01:23] * StevenK works through that list slowly [01:24] According to https://code.qastaging.launchpad.net/~stevenk/+junk/foo I'm already subscribed? [01:24] Not to revision diffs. [01:24] Probably only to merge proposals. [01:25] * StevenK changes his subscription [01:25] Do I need a LOSA to run the scanner? [01:25] Yes. [01:31] 45 files changed, 127 insertions(+), 801 deletions(-) [01:31] ow [01:38] wgrant: The scanner has been run, but the branch page still says Updating ... [04:21] Way too much cron spam [04:23] Yes. [04:23] It is mildly insane. [04:24] Just don't look at the staging mailbox. [04:25] It's disturbing cynthia. Can fix ? [04:25] BHeh [04:26] Well. Part of it needs an RT that is way down the queue fixed. [04:26] Other parts need hloeung. [04:26] The apt pyrge thingy? [04:27] Yes. === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 256 - 0:[########]:256 [04:28] Meep [04:28] We got to 260 on Monday :) [04:28] Uhm, perhaps that ticket should be higher. It's not in fhe losa queue [04:28] Afaik [04:29] LOSAs can't do it. [04:29] So perhaps it shouldn't be in the LOSA queue. [04:29] But it is in the LOSA queue. [04:29] #9 [04:29] Right :) [04:29] You have priority powers, feel free to use them :) [04:30] Talking to a gsa will be fadter [04:30] Nobody else subscribed to the list has powers. [04:30] Sm kn phone [04:30] Heh. [04:30] What the heck are you typing on? [04:30] Or *with* [04:30] Im on phone [04:30] I assume. [04:30] Yes [04:30] lifeless may be teaching cynthia how to type already [04:30] Or perhaps Cynthia is proxying for him. [04:30] Heh [04:31] It could have been a dvorak keyboard via a pencil in the mouth given the typos [04:31] cinerama: ^ [04:33] If you could move that ticket around for yts that would be awesome [04:34] https://rt.admin.canonical.com//Ticket/Display.html?id=47596 is the ticket. [04:34] But there is no vanguard today. [04:34] cocoplum has one too [04:35] Yeah, there are lots. [04:35] I saw it with the paste from the dapper destruction [04:36] I really should just have reverted Chameleon while it was easy :/ [04:43] Woah, Cynthia is already on IRC? [04:43] She should post her first branch in a few days [04:43] First landing in trunk in what, a week? [04:44] I guess so [04:45] buildbot failed again :( [04:45] Yeah. Something leaked a forkingservice again. [04:45] 1:20 to go on the next run. [04:46] Jenkins remains stable. [04:47] It's hard to leak stuff between runs when the entire instance is shot in the head [05:31] Is it okay for a package publication to be superseded but not have supersededby set? === almaisan-away is now known as al-maisan [05:39] StevenK, wgrant: this may happen if we allow multiple versions of a package to survive domination: a publication may become superseded but without a clear dominant. The schema allows it, but won't it break anything? [05:40] jtv: No, it's only used by the UI. [05:40] So it's fine to say "superseded, but not by any particular release"? [05:40] jtv: And deletions from before ArchiveRemovalRedesign are already Superseded without a supersededby [05:41] Very very few. [05:41] Try to avoid it, but it's legal and acceptable. [05:41] How is there not a clear dominant, though? [05:41] Can't you just use the oldest live one after the publication? [05:41] Idiot. [05:42] Oh? [05:42] Heh. I'm asking about the case where there isn't one, of course. [05:43] If there is no newer live publication, isn't it probably Deleted? [05:44] That's the kind of thing I'm asking about. Think "latest version of a package is removed from Debian Sources list, leaving only the previous version." [05:45] lifeless, wgrant: ok, i see the RT, i'll just go and see what we are going to do [05:45] I could mark that as superseded (but by which version?) or as deleted. [05:46] jtv: Seems likely it's Deleted if there's nothing to supersede it. [05:46] "likely" [05:46] How would we know the difference? [05:46] cinerama: Thanks. I know the issue fairly well, so can hopefully clarify anything that needs it. [05:46] What difference? [05:46] If there something newer alive -> superseded [05:46] Otherwise -> deleted [05:46] Between a deleted one and a superseded one in this situation? [05:47] So you meant "likely" as in "I'm not sure"? [05:47] No, I'm sure that it's true in most cases. [05:47] Then how do we tell the difference between cases where it is and cases where it isn't? [05:48] We probably can't. [05:48] The status doesn't make a huge difference. I think the method I described will get it right just about all the time. [05:51] OK [05:56] G: Around? [05:59] wgrant: yo [05:59] G: Do you have a moment now to QA bug #697157? [05:59] <_mup_> Bug #697157: Streamline "You have assigned this bug to yourself" message

< https://launchpad.net/bugs/697157 > [06:00] G: I can grab the mail from qastaging's mailbox. [06:00] Or I can do the whole thing. [06:00] wgrant: jtv, said he was going to QA it but if you want to [06:00] wgrant: I'll create two bugs and you can do the rest if you want [06:03] wgrant: your LP login is wgrant I take it? [06:03] G: Indeed it is. [06:03] Note that it can't be a bug on any of the Launchpad projects, because I'm already subscribed to all of them. [06:04] wgrant: you should have got a correct message about me assigning you https://bugs.qastaging.launchpad.net/pymheg2xmltv/+bug/800256 [06:04] <_mup_> Bug #800256: Blue Triangle, top left, next to BFB. < https://launchpad.net/bugs/800256 > [06:04] Nigel Jones (dev-nigelj) has assigned this bug to you for MHEG5 to XMLTV Converter: [06:04] wgrant: and if you assign https://bugs.qastaging.launchpad.net/pymheg2xmltv/+bug/800257 to yourself... [06:05] You have assigned this bug to yourself for MHEG5 to XMLTV Converter: [06:05] Looks good. Thanks. [06:06] wgrant: ok, so i've removed the egg info and reinstalled where i found python-tz, didn't see python-setuptools as i was expecting [06:06] cinerama: The package often isn't installed any more. [06:06] In that cause just remove the directory. [06:06] s/cause/case/ [06:06] wgrant: np, happy to help [06:06] is there another downtime-less update happening overnight or something? [06:07] With a bit of luck we'll do one in about an hour. [06:07] Need to QA incoming bugmail now, though :( [06:08] back to getting a sane xmltv file for my mythtv setup :) [06:08] Good luck with that. [06:09] I never had much luck. === al-maisan is now known as almaisan-away [06:09] wgrant: I'm processing the MHEG data directly :) [06:09] G: Doesn't MythTV normally do that itself? [06:10] Ah, no, that's not MHEG. [06:10] I've been using an xmltv file that someone creates using the Satellite EIT data, but the DVB-T (OTA) service doesn't really have much EIT data [06:11] wgrant, lifeless: ok, looks like we should be rid of those bad eggs [06:11] cinerama: Thanks. Which hosts did you clean? [06:11] problem is, the Satellite data doesn't always match the DVB-T data :) [06:11] wgrant: the ones mentioned in your ticket for hloeung [06:16] cinerama: Thanks. Logging changes over the last couple of days have revealed four more that need fixing :( I've just updated the ticket. [06:16] hloeung: ^^ === almaisan-away is now known as al-maisan [06:26] wgrant: ok, i think we've tidied up the others now [06:27] cinerama: Great. There's probably another host or two that isn't spamming dozens of times an hour and has been drowned out until now, but I'll update the ticket later if so. [06:27] Thanks! [06:28] wgrant: sounds good. i am going to leave the ticket with the losas since they can do most of it and can just poke a gsa for help [06:28] Oh, can they? [06:28] Didn't know that :( [06:29] The staging mailbox has gone three minutes without a dozen messages a minute. This is good progress! [06:29] we can poke GSAs for help - that's "most of it" [06:32] Heh [06:37] yay, let's open some champagne to celebrate [06:45] cinerama: Hm, tellurium seems to still have pytz. [06:47] ... and asuka just showed up with 11 pytz-whining emails too :( [06:50] ugh, need to clean up /usr/lib/python2.6 stuff as well as /usr/share/pyshared stuff [06:50] brb [07:01] germanium too. [07:02] nigelb: Your webfonts stuff looks good. [07:05] Hm, actually. [07:07] It's fine in Chromium, but Firefox 7 doesn't display the bold fonts properly. [07:08] It seems to scale up the normal weight. [07:08] cinerama: wgrant: thank you both very much [07:09] there still appear to be some broken links for eggs in that area for packages you haven't mentioned -- do i need to fix those up as well? [07:13] cinerama: They're not being noisy, but if you want to... === jtv is now known as jtv-eat === al-maisan is now known as almaisan-away [07:28] ok, i think i've properly dealt with pytz [07:42] good morning [07:44] cinerama: Thanks. [07:45] wgrant: Oh. Its in production? \o/ [07:46] It is not [07:46] ah, qastaging. [07:47] * StevenK digs for canonical_url [07:47] So tempted to move it to lp.app [07:48] But the diff would be LARGE [07:50] nigelb: I think it may need further work; see the bug for details. [07:50] wgrant: I saw. Need to get back home to test on my machine. [07:50] * nigelb just got to work [07:51] I'm using Firefox 8 though. [07:52] wgrant: Do you want to qa-bad that or just want me land a better fix later today? [07:53] nigelb: I don't think it's worth marking it bad. [07:53] Particularly given we're already fairly blocked. [07:53] heh, ok :) [07:53] Some bold fonts will look bad on some browsers for a day. Meh. [07:54] Yeah, stub marked my email fix as qa-untestable for faster deployment :) [07:54] That deployment sadly failed. [07:54] Oh. Why? [07:54] :( [07:55] Changes to DB connection string handling meant that hostnames with hyphens didn't work. Staging and dev use underscores, production uses hyphens, boom. [07:56] Do we have a ... um, something for a "Are you sure?" action? [07:56] There is a new confirmation overlay that rvba or allenap has been working on. [07:57] And the bug assignee picker already has a confirmation page at the end. [07:57] wgrant: rvba I think. [08:09] StevenK: ConfirmationOverlay [08:10] StevenK: It's meant to be used to 'protect' an existing submit button. Very much like the js 'confirm' method. [08:10] Howdy [08:22] Morning mrevell :) [08:22] Who wants to do a review? [08:23] https://code.launchpad.net/~allenap/launchpad/pcj-more-often-bug-770721-pre/+merge/74293 [08:23] Please :) [08:28] allenap: r=me [08:28] StevenK: Thanks :) [08:34] jamesh: am I right that the only missing thing to migrate to oops-wsgi is an answer for storm query capturing ? [08:36] lifeless: that's the main one I've identified. That said, we've got code to handle this, so I could wire it up with python-oops [08:37] lifeless: I need to follow up with a few others on the U1 team though to see if there is anything else. [08:37] the thing blocking me extracting the tracer we use from LP is identifying 'current request' [08:38] because 'current transaction' doesn't seem like a good match [08:38] lifeless: https://wiki.canonical.com/UbuntuOne/Futures/Notes/PythonOops has my in-progress notes for moving over. [08:38] unless we inject 'this is the oops-in-progress' into the tracer from a wsgi decorator === jtv-eat is now known as jtv [08:39] in which case we need a storm-timeline tracer (which could go in storm itself), and a storm-wsgi which would have a thin wsgi app to set and unset the timeline that the tracer should use [08:39] does this sound sane ? [08:41] lifeless: one other case I'd like to eventually handle (as in "I don't think we currently do it but it would be nice") would be tracing statements in the API server [08:41] what sort of statements ? [08:41] do you mean like a custom debug hook that logs rather than profiling/debugging ? [08:41] it is a twisted daemon that performs DB transactions via deferToThread() [08:41] cause that would be the bomb. [08:42] still storm statement tracing, but not in a "one thread per request" model [08:42] oh right [08:42] I guess a "this is the current timeline" API would handle that though. [08:42] uhm, so that seems straight forward, have a wrapper - deferToThread(setTimeline, timeline, realthingtocall, realparams) [08:42] right. [08:43] rvba: Are you off the stand-up? [08:45] lifeless: I haven't looked the python-timeline package you're using in LP yet. I guess it would be worth looking at together with the other OOPS stuff though. [08:45] jamesh: its tiny, but yeah [08:46] jamesh: we put memcached call-outs, google search API calls, librarian operations, storm queries all into the timeline [08:46] jamesh: lets us see slow backend API's [08:46] (and SSO!) [08:47] StevenK: not yet. [08:47] lifeless: I guess that is a bit more structured than just capturing all logging messages to the oops report ... [08:47] [that seems to be the equivalent functionality from the wsgi-oops package we're using] [08:48] yeah [08:48] log messages are fine [08:48] but this is introspectable [08:49] so we can get duration, which log messages don't have [08:49] and that lets oops-tools tell us that '5400ms were taken up by repeated query Y' [08:50] and be confident that its that, and not slow python code post-query, for instance. [08:50] yep. [08:50] you could do that with log messages with a well-known-form [08:50] StevenK: ? [08:51] but IMO it gets a bit ugly having a heuristic to ditch ones not matching it [08:53] I'm not suggesting you switch to the logging module. [08:53] no :) [08:53] I was just being verbose [08:54] jamesh: do you think the tracer belongs in core storm? will add the dependency on the timeline module for testing at least. [08:55] rvba: You're working on a confirmation overlay? [08:55] lifeless: we've got a number of optional modules in Storm already: storm.zope (which you're using) and storm.django (which we're using). [08:56] one more wouldn't be out of place [08:56] StevenK: It's already in the code actually: lib/lp/app/javascript/confirmationoverlay/confirmationoverlay.js [08:56] rvba: Nice! [08:57] StevenK: It's used on +localpackagediffs to add a confirmation overlay when you're about to sync stuff. [08:57] rvba: I was about to ask [08:57] I was going to use it to solve a disclosure bug [08:57] StevenK: See lib/lp/registry/templates/distroseries-localdifferences.pt [08:58] StevenK: I hope it can suit your needs without modification. [08:58] rvba: That would be nice, I'll dig tomorrow, thanks for the help. [08:59] StevenK: np. [08:59] StevenK: when it's not timing out, you can see it in action and play with it https://dogfood.launchpad.net/ubuntu/oneiric/+localpackagediffs === almaisan-away is now known as al-maisan [09:38] Is it just me or are EC2 tests not working? [10:24] jtv: I dunno, are you not working? === al-maisan is now known as almaisan-away [10:24] bigjools: I am, but ec2 isn't. [10:24] I get timeouts and hanging instances. [10:26] jtv: I lannched an instance 1 hour ago without problem. [10:26] Thanks. Blast. [10:32] stub: hey there [10:33] hiya! [10:33] stub: python-pgbouncer seems to have some skew in its version numbers - __init__ says 0.0.1, setup.py 0.0.2 and pypi 0.0.3 ;) [10:33] stub: I'm really glad you updated it :) [10:33] stub: I was worried I hadn't setup enough permissions [10:34] setup.py should have 0.0.3 too since that is what is used to build and upload the package to pypi [10:34] Didn't think of a number in __init__, but now I think of it I've had setup.py pull the version number from __init__ before. [10:35] yeah, me too in other projects [10:35] need to copy that glue across [10:35] hey, so fastdowntime seems to be awfully close [10:35] nice work [10:36] Just trying to get the know issues stuff landed. [10:36] yah [10:36] we always knew there would be rabbits in holes. [10:36] its pretty awesome getting it all flushed out [10:37] I'll hack around lag mon with PGPORT instead of --port so I don't have to worry about that crud for now. I think the wanted revs are otherwise in place now, which I'll check after I've updated these rollout scripts for ISD. [10:37] lynne is having some trouble, I -may- not be back next week. I'll let you know when I let francis know (which will be ~ 5 minutes after I know :P) [10:37] Yup. No worries. Reviews have been pretty boring. [10:38] they always are... until you get one that terrifies :) [10:38] need to ensure we don't lose google juice with async loading of comments, and privacy is making some of the branch queries go recursive (if your stacked on branch is private, you are private too even if you claim to be public). But the queries I've seen so far are fast. [10:39] I believe google have js execution in their crawlers now [10:39] to handle twitter et al [10:40] Good luck with Lynne and the spawn too! [10:40] thanks ;) [10:41] 'spawn' is smiling and gurgling cutely already. [10:42] I think we probably want a boring old batched comment listing, as well as the async loading. [10:42] async should batch as well [10:42] yer, thats what I said. I don't think we lose with what is behind the FF at the moment either. [10:42] faster for the only-reads-a-few case [10:43] and permits scroll-to-end etc [10:43] but thats efuture :) [10:49] stub: We should be OK to deploy the port fix in an hourish. [10:49] stub: Did you see the fireworks overnight? [10:50] Apart from the bug being flagged as rolled back, I don't know what happened. [10:50] Well, ConnectionString thought that connection string values were in \w+ [10:50] \w is roughly [a-zA-Z0-9_] [10:50] Production DNS aliases have hyphens... [10:51] So host=lp, and boom. [10:51] blah [10:51] And because of our marvellously unified database connection mechanisms, appservers were not affected so it wasn't noticed for a while. [10:52] Still, Zopeless is now very nearly dead. [10:52] wgrant: So you have landed the fix and it is with ec2 or buildbot atm? [10:52] stub: It's been on qastaging for a few hours now. [10:52] Just waiting on three revs of QA. [10:52] bigjools, henninge: ^? [10:52] Thankyou very much. I should sleep in more often :-) [10:52] wgrant: will be a little longer [10:53] The connection string syntax supports escaping and quoting, but I decided we needed a quick fix so just added an assertion to prevent unnoticed misparsing of those cases. [10:53] So it just uses [^ ]+ instead of \w+ [10:53] patience [10:53] ffs [10:54] Yes, I think that is the better approach too [10:55] stub: If someone tries to use a space in a username, hostname or database name, they probably deserve a crash :) [10:56] Yes :-) On my list is to switch all the usernames using hyphen to using underscore too, and block hyphen in security.py. Quoting the names is annoying. [10:59] Yeah, although that's fairly well encapsulated now. [10:59] Before I rewrote half of it it was quoting and unquoting everywhere :( [11:02] stub: https://code.launchpad.net/~wgrant/launchpad/more-zopeless-destruction/+merge/74367 may be of interest [11:03] Pretty simple continuation of the series. [11:03] But gets rid of most of the rest of ZTM's non-wrapper bits. [11:04] wgrant: I am having a problem with that revision [11:04] Uhoh. [11:05] wgrant: It is not fixing the bug, just movingn an exception being raised from the UI to a script run. [11:05] Heh. [11:05] where it is more likely to cause problems [11:06] or be ignored ... [11:06] wgrant: Unfortunately there does not seem to have been a pre-implementation chat with translations people. [11:06] bad enough to need a revert? [11:06] It sounds pretty rare. [11:07] I hope jtv is around for a second opion. [11:07] what now? [11:07] ;-) [11:07] jtv: Hi! [11:07] hi! [11:07] jtv: can you please have a look at https://code.launchpad.net/~benji/launchpad/bug-742662/+merge/74254 ? [11:07] OK [11:08] jtv: I am not sure it is an improvement. [11:08] Wait… we always did report mixed newlines, didn't we? [11:09] jtv: yes, it currently happens when submitting translations. [11:09] (see the OOPSes) [11:09] in the UI. [11:09] This branch moves the check into the importer. [11:09] Which would be fine if the exception was caught and added to "errors". [11:10] wgrant: hi [11:10] jtv: I don't like uncaught exceptions in the importer ... [11:10] jelmer_: Morning. [11:10] wgrant: I saw something in the logs about an import test leaving processes around? [11:10] jelmer_: Something is occasionally leaving a forking service around. [11:11]