=== StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 262 - 0:[#######** stack stamashing detected: ./lp terminated [01:05] * lifeless heads off to a hospital apptment. Be a few hours. [01:05] mobile is on if anyone needs me. [01:06] Bye lifeless. [01:06] StevenK: You're doing it all wrong. [01:06] Why would it overflow before writing the 8th character? [01:06] * wgrant fixes. === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 262 - 0:[########*** stack smashing detected ***: ./lp terminated [01:06] That's how it was last week :) [01:09] Bleh [01:50] cjwatson: It looks like the lucid backported apt-ftparchive hangs when writing out Translations.en [02:12] wgrant: We are now QA'd up to r13911 [02:13] Indeed. [02:13] * wgrant deploys. [02:13] Although ITYM 13910 [02:14] I meant r13911 is the next revision to QA, but probably. [03:16] StevenK, wgrant: time to Q/A my frightening gina/dominator changes. Given the risks, would very much appreciate your help. === Nigel is now known as G [03:45] jtv: Indeed. [03:45] wgrant: glad you're here. :) [03:45] jtv: I guess we should do lots of overrides, some multiple overrides, some reverted overrides, some overrides with uploads, and then attack gina... [03:46] Overrides are something I have very little experience of, so good thing you brought it up. Maybe we should try publish-ftpmaster first to see that regular domination still works properly. [03:46] I ran it this morning and it didn't melt, but I don't think there was much to do. [03:47] Okay, not melting is good—I'm more concerned though with whether it still does the right thing. :) [03:47] Of course, but it's a first step.. sort of. [03:49] “Good news! We put 20,000 Volts through this sensitive circuit and the fuse *still* works.” [03:49] Heh [03:50] To be honest I lack the knowledge or imagination right now to come up with any way in which the new Ubuntu domination could behave differently from traditional domination. [03:50] Which, admittedly, means I need more coffee. [03:51] Right, which is why we are going to try lots of things, particularly stuff which has been traditionally.. problematic. [03:51] I suppose “it doesn't melt” is about the best test for this part. [03:51] We could set up a derived distro for these tests, and run publish-ftpmaster on that. [03:52] I was just going to molest oneiric. [03:52] Or whatever the dev DF series is at the moment. [03:52] Well, if you run publish-ftpmaster then it's going to dominate the whole series, right? [03:52] Since it has a representative selection of sources and binaries. [03:52] Ahem, *distro* [03:52] Yes. [03:52] Well. [03:52] Could use -s [03:52] To restrict it to a series. [03:52] Oh, yes, we could. [03:52] s/series/suite/, even [03:53] I used that to test index generation this morning -- publish-ftpmaster passes it through fine. [03:53] This is on dogfood? [03:53] Yes. [03:53] Hm. [03:53] I updated it yesterday, so you should have gotten the new code. [03:53] Ahh. [03:53] (Took some nursing over the weekend to get this landed) [03:53] I wondered why it had nothing to pull. [03:53] The other reason was semi-permanent buildbot failure. [03:54] Ja. [03:54] But that seems sorted now. [03:54] stub was kind enough to fix up an apparent race condition in the pgbouncer fixture. [03:54] Even the stuff that has plagued us for the last three weeks should be fixed now. [03:54] After some annoying SMS and email from me. :) [03:54] So it might be stable. [03:54] Hah. [03:54] To be fair to me, I reviewed it. [03:55] Great thing about weekends: you can really get stuff done when you're not busy being managed. :-) [03:55] (I'm joking. Julian's actually helpful as a manager.) [03:55] Anyway. [03:56] DF's Debian is all published. We might want to unpublish bits of it. [03:56] So the smoke test passed, the smoke alarms remained quiet. [03:56] To test the transitional code. [03:56] Good idea. [03:56] Shall I just do that then? [03:56] Sounds like a plan. [03:57] You attack gina, I attack archivepublisher? [03:57] For now, at least. [03:57] By the way, just to avoid any misunderstandings, we're talking about making Published SPPHs Pending again, right? [03:57] Yes. [03:57] I'm talking about published, not published. Duh. [03:57] Oh yes of course, [03:57] how could I miss that [03:59] (I know I do this a lot, maybe more than seems necessary — but the cost of backtracking from a mistake of this kind can be so costly that I'd rather spend an appreciable percentage of my regular communication time on it) [03:59] I'm not sure I can do much with gina: how to set it up for a run, how to run it, how to look at overrides etc. But I'll patch up the DB first. [04:00] The easiest way to fake gina override changes is probably to mangle the DB. [04:01] Rather than mangle the source archive. [04:04] Can we run gina such that it really imports from Debian? [04:04] And 7 hours later, launchpad tests are still running. [04:04] jtv: You can fake a new import, yes. [04:05] jtv: It's an ... interesting process [04:05] Hm, I guess it's going to be a little difficult now. [04:05] Since we can't do a partial import any more. [04:05] We can't? :-/ [04:05] It will nuke anything that isn't present. [04:06] Sigh. NFS mount from iron [04:06] * StevenK waits for the ICBM [04:06] Hah. [04:06] Well… it'll only nuke it a little bit. [04:06] Call it a tactical warhead, just fission without the fusion part. [04:06] Perhaps we should grab a small PPA and import it into a new distro. [04:06] wgrant: Thanks for QA-ing that bug. I wasn't sure how I'd do it. [04:07] nigelb: I just made a few changes, linked a couple of questions, checked that it didn't crash. [04:07] Meanwhile, the latest 23K or so Debian SPPHs just went back to Pending on dogfood. [04:07] Great. [04:08] (Is it a bad sign that I think nothing of generating histograms in SQL?) [04:09] * jtv → ☕ [04:09] Coffee? Java? [04:10] Running the full tests can take /forever/ [04:10] Hmm. [04:11] https://launchpad.net/debian/+source/dpkg/+publishinghistory [04:11] gina stopped setting datepublished a while ago. [04:11] That is unfortunate. [04:11] We should probably fix it. [04:11] And likely set it to datecreated everywhere it is unset. [04:13] mmm, rain. [04:14] hi lifeless [04:14] wgrant: don't tell me there's another loosely-related ancient glitch that I also ought to fix! [04:14] Welcome back lifeless. [04:14] hi lifeless, hi poolie [04:14] and congrats! [04:14] jtv: Well, I think you probably stopped it from setting datepublished somehow. [04:15] *me*? [04:15] oh, he's officially back? [04:15] Probably not, but he wouldn't be lifeless if he had a life. [04:15] I think he might be. [04:15] hi poolie [04:15] jtv: Well, it broke some time since February [04:15] jtv: thanks. [04:15] wgrant: and obviously I didn't actually *set* it in my SQL. [04:15] I am back 4 days a week [04:16] lifeless: Which day off, or will it vary? [04:16] wed [04:16] Aha [04:16] Well, that was inconvient. [04:16] wgrant: nah, he's going to keep working for one day longer than he should, every week, and so the day off will shift until it's sunday and then it will stay there. [04:16] Heh [04:17] wgrant: two cases of missing datepublished that I should probably take responsibility for: [04:17] GUILTY [04:17] 1. The patch-up SQL doesn't set it. [04:17] The patch-up SQL shouldn't. [04:18] 2. When gina creates a BPPH, it just passes a status directly. I changed that, but did not add a datepublished. [04:18] gina always used to set datepublished, even when it was setting them to Pending. [04:18] Ah. [04:18] Gina does not create BPPHs [04:18] Not in its current form of use, no. [04:18] Well, not how we run it. [04:18] ?PPH, then. [04:19] (For SPPH I call what I hope is the appropriate method so it should get set) [04:20] wgrant: could you explain why the patch-up SQL shouldn't? Isn't it inappropriate to have Published SPPHs without datepublished? [04:20] jtv: It is. But the patch-up SQL shouldn't have had to, since gina was always meant to set datepublished even for Pending records. [04:20] But it turns out that's no longer the case, so the patch-up stuff possibly should. [04:21] setting it if its null should be safe [04:21] So you're saying the patch-up SQL merely shouldn't _need_ to. [04:22] wgrant: Out of interest, do you have a branch up for your db patch of much deletion? [04:22] wgrant: do you expect any practical interaction with the gina and domination changes? Or can we treat this as a separate problem? [04:23] lifeless: Right, I was imagining something like UPDATE sourcepackagepublishinghistory SET datepublished=datecreated WHERE datepublished IS NULL AND archive = 3; [04:23] jtv: Shouldn't be, just noticed when I was checking +publishhistory to see what state some packages were in. [04:24] Phew. [04:29] lifeless: Could you review my db patch? https://code.launchpad.net/~nigelbabu/launchpad/kill-statusexplanation/+merge/74934 [04:30] nigelb: wrong reviewers :P [04:30] gah [04:30] nigelb: you need to request a review from both stub and I, of type 'db', per the wiki page. [04:30] nigelb: You need to add two other reviews: lifeless and stub with a type of 'db' [04:30] that was default! [04:30] yes [04:30] db patches are speical [04:30] actually we could change that now. [04:30] Hey, its my first time! [04:30] as only db patches go to db-devel. [04:31] Hrm, I can't set the type for the first person? [04:32] wgrant: so… how are we going to set up these overrides and how are we going to run gina? [04:32] jtv: We can't really get a full Debian archive onto mawson, so we will have to import a smaller archive into another distro. [04:32] Wha. What happened to the type that I set. [04:32] I'm waiting for publish-ftpmaster to finish with the 10 zillion new Ubuntu series. [04:33] nigelb: The picker is just daft [04:33] :/ [04:33] I have lifeless and stub on review with empty type fields. [04:33] I wish I could edit type later. [04:33] * nigelb gives up [04:34] nigelb: I think you can, but by “requesting another review” of the same person. [04:34] nigelb: file a bug :) [04:34] StevenK: You misspelt "awesome and flawless" [04:34] jtv: that will create a separate review request - its a feature. [04:34] wgrant: Did I? Try it :-P [04:34] jtv: hmm, perhaps not for non-teams. Who knows :) [04:34] What a ...useful.. feature. [04:34] wgrant: Damn it, answer my question :-P [04:35] Why did I get the review type wrong? [04:35] StevenK: Oh, the DB patch thing? Not yet. Distractions, Soyuz, and distractions. [04:35] Currently hacking p-d=r :( [04:35] wgrant: There's at least one bug we can link to it. [04:35] Oh? [04:35] wgrant: If there was a branch, I was going to do the linkage [04:35] I selected the person, the field was filled out and it runed out empty. [04:35] bug 345810 [04:35] <_mup_> Bug #345810: Remove old infestations database stuff < https://launchpad.net/bugs/345810 > [04:35] Ah. [04:35] Indeed. [04:35] I will get to it today. [04:36] Just want to get p-d-r done so Julian can approve it and we can get the bastard run. [04:36] And it really is going to be a bastard run. [04:36] Heh] [04:40] lifeless: you and stub are on the review list, but not 'db' review. I'm guessing that's minor. [04:40] thats fine [04:41] Heh [04:41] # These 5 lines are untested. Deal with it. [04:49] StevenK: if you want to glance at the wonderful p-d-r "fix" [04:51] I'm not sure that I do ... [04:52] wgrant: So the plan is this lands gets run once, or cowboyed in for one run? [04:53] Cowboyed.' [04:53] Does it work acceptably on DF? [04:55] No idea. I'm running publish-ftpmaster for other reasons at the moment, and I need to check if dryrun mode actually is a dry run. [04:55] But the tests pass (as long as I use hoary instead of dapper) [04:56] I'm not sure I trust the domination tests. [04:56] Not domination. [04:56] Not even judgement. [04:56] This is reaping. [04:56] heh [04:56] nigelb: Those are all technical Soyuz terms! [04:56] wgrant: Do eet, then. [04:57] Publications are created, published, dominated, judged, then reaped. [04:57] wgrant: Imagine someone who doesn't know what gina is reads this stuff. [04:57] nigelb: I think it shows the mindset of those who wrote it [04:57] heh [05:00] JS still sucks. [05:00] heh [05:00] JS is <3 [05:01] nigelb: Then you can explain our JS to me. [05:01] dealing with the DOM is not <3 [05:01] StevenK: YUI, however, is special [05:02] I don't mind JS most of the time. [05:02] And why we have 3 different JS functions that all deal with unsubscribing people from bugs. [05:02] Point me to the code? [05:02] I'm just stuck trying to get at the bug itself when LP.cache.context is a bugtask [05:03] I couldn't parse that :) [05:04] We have a cache inside JS called LP.cache [05:04] It has a context memeber which is JSON of an IBugTask [05:05] You wwant to access parts of the JSON? [05:06] I can not work out how to inject the private attribute into the cache, since the view code is incomprehsible and I also can not work out how to get a JSON representation of an IBug given the link from the bugtask. [05:07] Where does this code live so I can poke? [05:08] The JS I'm currently dealing with is lib/lp/bugs/javascript/subscription.js [05:09] 1351 lines of JS. [05:09] How pleasant. [05:09] And I have this sinking feeling that lp.app.javascript.confirmationoverlay only deals with forms, which this isn't. [05:10] nigelb: 100789 lib/canonical/launchpad/icing/build/launchpad.js [05:10] Which is "okay" [05:10] should minify that for more scary effect ;) [05:11] wgrant: Have you jumped the gun? [05:12] wallyworld: *prod* [05:18] Do we have a procedure for dropping something from the API? [05:18] If it's only in devel, drop it. [05:19] DSP.getBugTasks() [05:19] If it's in 1.0, pretend to consider whether it's worth breaking backwards compatibility, then probably drop it anyway. [05:19] If it's in beta, that's EOLed so anybody using it is stupid :) [05:19] Why would you drop that? [05:19] Because it's horrible [05:19] And because better codepaths exist [05:19] And there's a bug [05:20] Are there better ones> [05:20] It's not just DSP. [05:21] IHasBugs.searchTasks() [05:21] Huh, how it only exported on DSP... [05:21] Sure, but getBugTasks doesn't do the same thing. [05:21] It takes a list of bug numbers and returns the bug tasks from those bugs in this context. [05:22] getBugTasks does not, no [05:22] def getBugTasks(self, bug_ids): [05:22] Wrong method [05:23] line 185 of lib/lp/registry/interfaces/distributionsourcepackage.py [05:23] That's the interface. === jtv is now known as jtv-eat [05:23] It was called 105 times last month. [05:23] getBugTasks does not appear in DSP's model, since it's called bugtasks [05:24] And the interface renames it and the parameter [05:24] Yes. There is only one getBugTasks model method, and it's the one I quoted. [05:24] Is that the one that is being called? [05:24] Oh, so you're not actually talking about DSP.getBugTasks() [05:25] It appears like that to the API [05:25] In the model code it's DSP.bugtasks [05:25] So, it's still called, but the PPR doesn't say in which version. [05:25] You could check the appserver logs. [05:26] And you should probably also delete the Python getBugTasks... it seems to be unused. === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [05:27] I hates distutils [05:27] or setuptools [05:27] one of em [05:27] /usr/lib/python2.6/dist-packages/pytz/__init__.py:32: UserWarning: Module tests was already imported from tests/__init__.pyc, but /usr/lib/python2.6/dist-packages is being added to sys.path [05:28] from pkg_resources import resource_stream [05:28] ---fail--- [05:28] /endrant [05:28] wgrant: Where are the logs hiding? [05:28] StevenK: /srv/launchpad.net-logs/lpnet [05:31] % bzr di | diffstat -s [05:31] 6 files changed, 124 deletions(-) [05:32] That was therapeutic. [05:45] anyone know how our storm stores get _database.name set ? [05:45] storm doesn't -seem- to do this itself [05:46] argh [05:46] class LaunchpadDatabase(Postgres): [05:46] ok [05:46] Yes. [05:46] I was dealing with that a bit last week. [05:46] What are you doing? [05:46] moving code to storm [05:47] I have three branches in the wild which delete lots of our DB handling, so don't be too invasive. [05:47] Ah. [05:47] so that u1 can use TimelineTracer [05:47] Sounds good. [05:47] so that they can use python-oops-* [05:47] our Tracer is 3, maybe 4 separate tracers. [05:47] gary's work added substantially to that [05:47] lifeless: Do you feel like hacking PQM to expose the commit message as an envvar or something? [05:48] wgrant: no, I am on the critical path for SOA. [05:48] wgrant: but I can advise. [05:48] wgrant: Why? [05:48] StevenK: handling of accidental db->devel commits. [05:49] StevenK: at a quess [05:49] How do you typo guess as quess? q and g are nowhere near each other :-P [05:50] very carefully. [05:52] hmm, this is a nuisance. [05:54] we should have pushed this upstream years ago. [05:54] * lifeless kludges [05:56] lifeless: :( [05:58] erm [05:58] File "storm/tracer.py", line 166, in __init__ [05:58] super(TimelineTracer, self).__init__() [05:58] TypeError: super() argument 1 must be type, not classobj [05:58] wtf [05:58] No __metaclass__ = type ? [05:59] thanks [05:59] been a long time since I hit that particular wtf [06:00] jtv-eat: I have performed several great evils on the primary archive, and it seems to have the same set of bugs as before, so we are good there. [06:00] jtv-eat: As for gina... who knows. [06:02] And make lint runs buildout? WTF? [06:02] StevenK: bin/lint is built by buildout. [06:03] narrative uses a moin header. == take the equals out and replace with what? [06:03] StevenK: An underline. [06:38] wgrant: 97 calls in the last month [06:38] In fact, a bit less, due to my branch name [06:39] Which version, and who? [06:39] Most of them identify themselves as ubuntu-dev-tools [06:39] But getBugTasks doesn't appear in ubuntu-dev-tools [06:39] It'll be someone using ubuntu-dev-tools' wrappers. [06:40] 82 without my IP [06:40] All in one incident? [06:41] No, spread around the month and the DSP they call from [06:41] :( [06:41] Similar IPs? [06:42] 19 unique IPs [06:43] Same ISP, or not? [06:44] Highly doubtful [06:44] No, they are not [06:45] :( [06:46] All of the calls are against 1.0 [06:46] :( [06:47] We have to leave it then? [06:47] jamesh: https://code.launchpad.net/~lifeless/storm/timelinetracer/+merge/74947 [06:47] StevenK: Unexport it from devel, at least. [06:48] wgrant: That makes me unhappy [06:48] wouldn't it be cool if launchpadlib *could* warn on using a deprecated API [06:48] http://ubuntu-dev-tools.sourcearchive.com/documentation/0.86/lp_8py-source.html [06:48] * lifeless goes to cook dinner [06:49] StevenK: That's the only callsite that Google seems to know about. [06:49] Ignoring lp-shell and test gives 43 [06:50] 'emesene bug maintenance' turns up 12 times [06:50] So 31 calls from something in u-d-t [06:51] StevenK: Did you see my link? [06:51] I did === jtv-eat is now known as jtv [06:54] wgrant: thanks, it's good to hear that our beloved bugs are safe. I suppose it's on to gina then. [06:55] What would happen if we just ran it on dogfood? [06:55] It probably wouldn't work, because DF doesn't have a Debian archive. [06:55] And doesn't have space for one. [06:56] Unless StevenK's partial one is still there, in which case it would set most of the LP archive to Deleted. [06:56] Which would possibly be bad. [07:01] I don't suppose staging would do it? [07:03] Well, we could hack it into staging's config, but I'm not sure that staging has a few hundred gigabytes of free space either. [07:09] Morning! [07:17] hi mrevell [07:17] wgrant: no smaller part of Debian that we could import? If not, maybe we can run a sabotaged version of gina that doesn't mess with the filesystem at all? [07:18] jtv: Well, given that gina's whole purpose is to take an archive from the filesystem and put it in the DB, that sounds possibly difficult or not a representative test. [07:19] ie. removing FS stuff from gina basically becomes a no-op. [07:19] Well the part that changed really only involves the Sources lists and the database. [07:19] I guess we could disable the non-domination stuff and then give it a fake set of (package, version) pairs. [07:20] Why not feed it a real listing to parse? [07:20] Mmm, I guess we could do that and deal with the fallout. [07:21] It's just going to be a little odd, as the mirror is 4 months out of date, so won't have lots of the current versions. [07:21] And since we'd have to disable the import stage, they would not be imported. [07:21] So lots of stuff would be deleted instead of superseded. [07:22] We could feed it a copy of an old Sources file, with manual changes. [07:22] StevenK: Erm. [07:23] StevenK: bzr grep [^p]review_diff [07:23] StevenK: There is some code that still talks about review_diff, and a test that checks it on BMP. [07:23] How... [07:24] wgrant, is lp devel in a safe enough state that i could land my dkim branch this week? [07:24] poolie: It is. [07:24] The spurious buildbot failures appear to have disappeared. [07:24] ok [07:25] Which may have had something to do with disabling the codeimport integration tests. [07:25] i'm going to do a little more testing first [07:25] i had an idea for my process-one-mail script, which is that before it exits it should look at the outgoing mail queue and print it to stdout [07:26] either before or after or during finishing the transaction, whatever is easier [07:40] wgrant: before I went on leave you were muttering about picking up my gpg work [07:40] wgrant: did you? [07:42] lifeless: Sorry, didn't get time. Too much Soyuz and buildbot breakage. [07:42] thats fine [07:42] needed to know if I had sync-up to do or not [07:42] Nope. [07:42] So, get that sorted out this week, then we can be fully nodowntime :) [07:42] (by removing poppy from LP) [07:42] Cheating, I know. [07:55] good morning [08:04] hi adeuring [08:04] Hmm [08:04] hi jtv! [08:04] I wonder if this comment is ready to be retired: [08:04] # XXX kiko 2005-10-23: Until I or someone else completes [08:04] # LibrarianGarbageCollection (the first half of which is [08:04] # awaiting review) [08:06] Oh God this is so depressing. That's in a function called check_not_in_librarian. The part of it that interacts with the librarian has been commented out. [08:06] Yep. [08:06] There's another comment saying it's untested. [08:06] Depressing? This. Is. Gina. [08:06] “Hi, Gina.” [08:06] (Said in the tired tone of 12-step program groups in films) [08:08] But Gina is bug-free. [08:08] There's an even older XXX from debonzi saying “check it later” where the computation of an unused variable is commented out. The variable looks important. [08:08] Also, I found a trilobite. [08:11] wgrant: I see that. [08:11] jtv: I also found a trilobite: "XXX 2008-06-16 mpt bug=241298: [...] dangerous and should be renamed (or removed)" [08:12] StevenK: I have a branch in ec2 to remove those references. [08:12] wgrant: Pity, I was just about to. [08:12] rvba: 2008? That's old but definitely post-Cambian. [08:14] rvba: it sounds like that may be a fossilized Critical bug. [08:16] Hehe. Not critical I think... but this code is strange now that we have DD. Using spr.upload_distroseries is likely to trigger bugs. [08:17] rvba: Yeah, bigjools fixed one of those last week. [08:17] rvba: Changelog bug closing was using that :( [08:18] Oh that must have been fun. [08:19] not so much [08:19] wgrant: So I can't just break DSP.getBugTasks() for 18 users? :-( [08:20] StevenK: Ideally track them down and kill them or the script. [08:20] wgrant, so i might retry the landing for bug 721166 if you're pretty sure lp will stay on bzr 2.4 [08:20] <_mup_> Bug #721166: Tests sometimes fail on EC2 due to _LockWarner garbage < https://launchpad.net/bugs/721166 > [08:20] poolie: We are 2.4+abit [08:21] The abit increased late last week. [08:21] >=2.4 is all i need [08:22] Yeah, we're staying. [08:27] wgrant: apt-ftparchive> Oh hell. Is there a bug for this yet? [08:29] cjwatson: No, sorry. [08:29] cjwatson: But it's happened on mawson and locally. [08:29] (locally on lucid) [08:31] mvo seems to be back from holiday, so attempting to grab him [08:31] (which is better than me fumbling with apt) [08:31] Thanks. [08:31] Yeah. [08:33] wgrant: Was this with include_long_descriptions at the default of True (i.e. old behaviour) or set to False (new behaviour)? [08:33] bug 241298 [08:33] cjwatson: I manually set it to false to a series to test. [08:33] cjwatson: With true it's fine. [08:33] Right. [08:37] wgrant: just ping me when you are ready, I will continue my mail catchup in the meantime [08:39] mvo: All looks good. [08:44] wgrant: DB patch? :-P [08:45] StevenK: I have the combined patch in ec2. [08:45] StevenK: To check that it all works with the tables remvoed. [08:45] StevenK: and am about to send off the three pieces separately. [08:46] (remove FKs, remove person merge code, remove tables) [08:47] nigelb, hi? [08:49] wgrant: 3 seperate patches? [08:50] StevenK: Yes. [08:55] nigelb: you should request a DB review from stub for your latest MP [09:02] wgrant: Julian has no suggestions for how to run gina. But actually, if it could just run with the existing sources files I think it'd do just about what we need. [09:02] jtv: If we have exactly the version that was last imported from, sure. [09:03] If not… is it likely to do anything bad that the next db restore won't fix? [09:03] No. [09:03] But we'll have to be careful what we look at. [09:04] Because, as I said, a lot of packages will have no live versions. [09:05] Does that matter though, as long as some do? [09:05] If we can track them down :) [09:05] And track down intended deletion/superseded cases. [09:07] Well we could approach it from the other side: see which ones become Superseded, Published, and Deleted; and take samples from each. [09:07] That way the database does the searching. [09:10] Shh [09:13] bigjools: So, what do you think about cowboying careless-executioner? [09:13] bigjools: It is sort-of-tested. [09:13] bigjools: In that I made deathrow.txt test the missing LFC case, and it passes when restricted to hoary but fails when restricted to dapper... [09:14] "careless executioner"..? Wouldn't "The Sloppy Chopper" be catchier? [09:14] our sample data is not exactly a bastion of perfectly related data [09:14] Heh [09:14] bigjools: Lies. [09:14] Reminds me of the song about George Michael - Careless Wrister [09:15] And that's how he got nicked? [09:15] allegedly [09:16] Meanwhile, in the real world: if I run gina, will it try to download anything from the debian archive? Or has that already been done by some other component? [09:16] jtv: It needs a local archive on disk. [09:16] Yeah but we've got that, sort of, partially. [09:16] Well, at least somewhere in the local FS. [09:16] It won't try to grab it from the network. [09:17] So… just run the thing? [09:18] If you have enough of an archive to be a useful test case. [09:18] wgrant: the carless-executioner branch looks ok [09:19] * wgrant dines. [09:19] wgrant: let's do it [09:21] jamesh: hi ? :) [09:37] StevenK: thank you for fixing bug 421705 [09:37] <_mup_> Bug #421705: archiveuploader tests leave files behind < https://launchpad.net/bugs/421705 > [09:45] bigjools: Indeed. What could go wrong, and all that. [09:46] wgrant: run it on DF first [09:46] Yeah. [09:47] jtv: You're not still molesting mawson? [09:47] wgrant: I am, just in a low-intensity way ATM. OTP. [09:50] wgrant: running gina on sid now. [09:50] Ooh. [09:50] I backed up all SPPH statuses. [09:50] Ah! [09:50] Even better. [09:50] Thanks. [09:50] Into a table, with supersededby. [09:51] So it'll be easy to tabulate things like “all SPPH status changes that weren't for Debian” [09:51] Yup. [09:51] (Which would hopefully be somewhere in the vicinity of "None") [09:53] We can hope. [10:06] jtv: Do you value your gina -l diff? [10:06] wgrant: no [10:06] * wgrant demolishes. [10:06] wtf, puppet using 50% CPU [10:06] 80%... [10:07] Hm, gina using a bit too. I might wait. [10:07] poolie: hi! [10:08] adeuring: Yeah, I've marked him on the review itself. Need to find time to poke him :) [10:08] * nigelb is having a busy day at $DAYJOB [10:11] Hrm, I guess I missed poolie :( [10:12] stub: Hi! Could you have a glance at https://code.launchpad.net/~nigelbabu/launchpad/kill-statusexplanation/+merge/74934 [10:13] k [10:21] jtv: qIt seems done. [10:21] Let's see the damage... [10:21] Yes. I'm checking results. [10:22] The only change seems to be: [10:22] 113 new Published SPPHs for sid. [10:22] Hmm [10:22] (I ran it on sid alone) [10:22] https://dogfood.launchpad.net/debian/+source/dpkg/+publishinghistory [10:22] It didn't set everything to Published in the fixup? [10:22] But did set all the right stuff to superseded, it seems. [10:24] I don't think so. The only change I see in the database is those 113 new Published ones. [10:24] Oh. Those are all superseded from 1.5 weeks ago. [10:24] Bah. [10:25] Crap DB is crap. [10:26] Don't tell me it's a missing commit. [10:26] nigelb: That branch can land [10:26] Ahaha [10:26] stub: Did you see my two pretty trivial DB reviews? [10:27] Just in the last few minutes. [10:27] wgrant: not yet [10:28] stub: Could you land it for me please? [10:28] stub: (Also, Thanks!) [10:28] wgrant: I see you're OCR tomorrow ... may I take the liberty to assign the review of a branch I just finished to you? It's not big but I'd be happy it you were the one to review it. [10:28] rvba: Sure. [10:29] jtv: Hm, should that really all be one transaction? [10:29] wgrant: Thanks! [10:29] jtv: That could possibly take a while, even on !DF [10:29] We are dropping webservice ban? Is this a WHUI, or are we using some other mechanism for throttling evil people? [10:30] WHUI [10:30] openidrpconfig, openidrpsummary, staticdiff are the only tables that code still used (apart from for person merges). [10:30] I don't think webserviceban was ever used. [10:31] And if someone happens to need it, they can spend the extra 10 lines to recreate it as they wish. [10:31] But it's now like 4 years old, so I think it can die. [10:31] fairy nuff [10:31] mailinglistban is the same. [10:32] Two months ago I would have said to leave them, as adding tables took a month. [10:32] Now? Not so much. [10:34] wgrant: In the -3 branch I don't see a db patch. Think it needs a bzr add [10:34] Shh. [10:35] Hmm. [10:35] It is there AFAICT. [10:35] 2588- in the diff [10:35] yer - ic [10:35] email truncated [10:35] Ah, heh. [10:35] The sampledata diff is large, yeah. [10:36] hmm... wonder if upgrade.py should drop tables in a consistent order? Not sure if it helps much [10:37] I considered that. [10:37] But it's normally pretty simple to drop the interdependencies. [10:37] Just this case is a bit of a mess. [10:37] Because there are 35 tables. [10:37] Which leaves only 270 tables! [10:38] Should probably make a 'drop_table' stored procedure that strips all foreign key references and moves the table to the todrop schema [10:38] Yeah. [10:39] I was going to use a procedure to automatically drop everything here, but decided I was too lazy. [10:40] Hmm. [10:40] Damn. [10:40] I made the "Unmanaged roles on managed objects" security.py warning DEBUG, so I can't see what cruft there is on prod. [10:40] (full-update seems to only run it at INFO) [10:41] I think it accepts -v too [10:41] Ah. [10:42] But security.py is pretty spammy at -v, so we probably don't want that regularly anyway. [10:42] gmb, adeuring: Which squad is on interrupts this week? [10:42] stub: Thanks. [10:43] wgrant: Whichever one isn't the Yellow Squad. [10:43] (I forget colours) [10:43] Ah, and we are henningeless today. [10:43] Orange [10:43] wgrant: It would also accept --log-file=DEBUG:/... I think. Not sure if I got it all wired up correctly. [10:43] So that's why there's no CHR person. [10:43] adeuring: Are you handling #launchpad from 1100? [10:43] stub: Probably. I might get a LOSA to run --no-revoke -v tomorrow. [10:43] wgrant: We do lose the slony spam though in the log files [10:44] We may want to use CommandSpawner or so to invoke slonik. [10:44] Haven't seen that [10:44] Since it pushes output through the logging infrastructure. [10:45] jtv wrote it a few months ago. [10:45] Sounds like an awesome fit [10:45] It was originally written to do parallelisation. [10:45] slonik spam bugs me a lot, but sometimes I need it. [10:45] But it's also convenient for making logging not suck. [10:49] bigjools: So the extra files bugged you to? :-) [10:49] s/\(to\)/\1o/ [10:50] sometimes, I think Steve's typos are just a way to consequently willy-wave his prowess with regexes [10:50] StevenK: yes, they did bug me [10:51] wgrant: this is more like it… http://paste.ubuntu.com/687535/ [10:52] Note though that nothing was superseded. [10:52] bigjools: 1) Like backreferences are hard. 2) I don't use regexes all the time to correct typos ... [10:53] bigjools: I suspect there's some http://xkcd.com/208 involved. [10:53] bigjools: If they bugged you, why didn't you fix it? :-P [10:53] StevenK: like I don't have enough to do already [10:53] :-P [10:54] nigelb: perfect! it even has the Perl reference [10:55] wgrant: at this point it would be helpful to see those Sources files. [10:55] jtv: Erm, you don't have them? [10:55] Then what have you been running with? :/ [10:55] It plucks them out of the librarian, right? [10:55] No. [10:55] It gets them from whereever the archive is configured to live in the FS. [10:56] bigjools: :D [10:56] root: /srv/launchpad.net/gina-mirror [10:56] For dogfood [10:56] Thanks. [10:58] wgrant: I was just struck in the head by an irony [10:58] *ow* [10:59] Oh? [10:59] AFAICS this bug makes the branch qa-ok. [11:00] Before we go to the trouble of tracing all the data. [11:00] Not necessarily. [11:00] We should check the deletions, I suspect. [11:00] I see some 113 of them. [11:00] Interesting. [11:01] As there are also 113 new Published publications. [11:01] Suspicious! [11:01] The deletions only happen with the commit inserted that I forgot before. [11:02] Hence my comment: as long as the commit is missing, they're not a concern from a deployment standpoint. [11:02] Ah, yes, because we are source-only. [11:02] So it skips the only other commit. [11:02] Agreed, looks like this is "ok" [11:03] The 113 new Published records are there even without the commit, i.e. before domination. I wonder what happened there. [11:03] As you say, the equal numbers are suspicious. [11:04] It'll be easy to figure out if they're for the same packages, as one would expect. [11:04] Yep. [11:04] Might be component changes or something. [11:04] It's not unexpected that there would be new ones. [11:05] As the source archive could well have new ones. [11:05] Oh. [11:05] I know what it'll be. [11:05] They're new, but older versions. [11:05] Because the Debian mirror is older than the last one that was imported before the DB was dumped. [11:05] So the live version is older than the latest version in the DB. [11:05] That makes sense. [11:05] So the latest version gets Deleted. [11:05] Let's verify it. [11:06] That's not the sense of adventure I expect from a Soyuz engineer. [11:06] I AM NOT A SOYUZ ENGINEER! [11:06] Wanted to get that straight. [11:06] One thing bothers me about the theory: [11:06] one word. [11:06] 'good' [11:07] Thank you lifeless. [11:07] One thing bothers me about the theory: wouldn't we be seeing the same SPPHs being created as Pending, immediately upgraded to Published, and then marked Deleted? [11:07] IANSE. [11:07] That could catch on. [11:07] jtv: Won't they be directly Published now? [11:08] jtv: And why would they be marked Deleted? They are the live version, so dominatePackage won't touch them. [11:08] We're seeing 113 going Deleted, and 113 being created and going Published. [11:08] Yes. [11:08] They are not the same SPPHs. [11:08] So, the DB has foo 1.1 live [11:08] The mirror is older than the DB. [11:08] It has foo 1.0 [11:08] jpds: IANASE maybe? [11:08] gina import foo 1.0 as Published. [11:09] It then calls dominatePackage on [foo 1.1, foo 1.0], with 1.0 as a live version. [11:09] foo 1.1 is not live, and there is no dominant, so it gets Deleted. [11:09] foo 1.0 is live, so it is untouched, and remains Published. [11:10] Gar. Watching publication in reverse. [11:10] “You get this ebony bathtub, right? But the thing is, it's conical. And you fill it up with fine, white sand…” [11:10] Heh. [11:11] I'm about to dig up an example. [11:11] But first, checking for idempotency. [11:11] This theory is supported by the fact that gina didn't catch on fire. [11:12] The mirror must therefore be older than the DB: all the SPRs had already been imported, so no attempt was made to grab files from the disk, where they don't actually exist. [11:12] Well you can prove _anything_ from a contradiction. [11:12] Heh [11:13] rvba: Are you also going to make normal uploads set SPPH.creator? [11:13] Furthermore, I suppose it makes sense that the difference was small enough that none of these packages had more than one release "supraseded" by an older one. [11:13] subseded? infraseded? [11:14] fucked? [11:14] whats the recipe to make custom storm eggs again [11:15] wgrant: AFAIK that's not part of the plan just now. [11:16] lifeless: one custom storm, add eggs to taste. Beat until fluffy. [11:17] wgrant: supporting fact — the deleted spphs were all for different sprs [11:17] jtv: SPRs or SPNs? [11:17] sprs [11:18] haven't tried spns yet; working on it [11:18] k [11:18] rvba: Oh, setting ancestor too. Thanks, this will make copies *much* more auditable. [11:20] wgrant: do you remember ? [11:20] you guys need to find a way to backronym SRS and BSNS into soyuz [11:20] BinarySourceNameSpace [11:20] We actually need something just like that for disclosure :P [11:20] Mapping binary names back to source names. [11:21] Soyuz Really Sucks [11:21] lifeless: Ummm. [11:21] wgrant: the deleted SPPHs — http://paste.ubuntu.com/687555/ [11:21] lifeless: I may have manually edited setup.py and tarred. I can't remember... [11:21] lifeless: mtimes may tell you how badly I did it. [11:21] bigjools: You know this now? I've not touched it and I've heard that multiple times. [11:22] Ah, right. You're documenting soyuz. [11:22] jtv: Can you get (spn, deleted version, published version) for the relevant publications? [11:22] nigelb: it's a meme. It's not really true. Soyuz is Really Sweet. [11:22] Nah, Soyuz Are Really Sweet. [11:22] wgrant: working on it [11:23] jtv: FASTER! [11:23] * wgrant fetches the whip. [11:23] * jtv was once kicked out of a university course for fear of SARS [11:23] haha., I was about say "someone hand wgrant a whip" [11:23] jtv: https://dogfood.launchpad.net/debian/+source/simple-scan/+publishinghistory seems to reinforce my grand unified theory of gina borkedness. [11:23] orange or strawberry? [11:24] bigjools: Cool hwhip. [11:24] http://cryptome.org/info/soyuz-tma18/pict2.jpg <-- soyuz [11:24] (that never gets old) [11:24] elmo: I was displeased that bigjools replaced that as the #soyuz topic :( [11:24] wait, there's a #soyuz? [11:24] Internally. [11:24] And deprecated. [11:24] Fire the retro rockets! [11:25] It tends to nowadays be where people complain when Soyuz is more broken than normal. [11:25] Or when their builds have melted a few buildds. [11:25] Nothing good happens there. [11:25] only one soyuz capsule ever landed doing 150mph more than it should have been [11:25] Er, weren't there three? [11:25] Oh, no, one of those just depressurised. [11:26] But there were at least two with parachute issues. [11:26] bigjools: when the criteria is '150mph more than it should have', once is usually enough [11:26] especially for those in the vehicle in question at the time [11:26] At least our Soyuz never has the problem that it goes too fast. [11:26] And Dapper only partially depressurised... [11:27] wgrant: visual animation also supports your GToGB. The newly-created versions are all slightly older than the deleted ones. [11:27] Sounds like it is not fatal, then. [11:27] elmo: apparently the guy in that capsule was swearing at mission control all the way down to his death. It seems somewhat appropriate... [11:27] And since the bird is cruel, zc.buildout just had to be among them. [11:27] Yes, there is a recording somewhere. [11:27] rvba: O Hai. I had some questions about confirmationoverlay, if you have a second. [11:28] jtv: I wonder, though, why there are none superseded... [11:28] jtv: Ah. [11:28] wgrant: only one had a parachute failure [11:28] jtv: I guess you cleaned them all up on the 1st. [11:28] StevenK: sure, shoot. [11:28] jtv: We may want to set everything back to Published and rerun? [11:28] rvba: Does it show a Yes and No button? [11:29] (StevenK: btw, love your spph denormlization work) [11:29] bigjools: Ah, right: a depressurisation, a parachute failure, and two ballistic reentries. [11:29] wgrant: I don't see what you mean with the "cleaned them all up on the 1st." Isn't it simply because of the version reversion we're seeing here? The only superseding that happened was in reverse, leading to deletion. [11:29] rvba: If so, I don't want it to submit a form on Yes, I would like it to call a JS function, is that possible? [11:29] wgrant: yup [11:29] Soyuz 5 and TMA-11 were the amusing ballistic reentries. [11:29] StevenK: it shows a formoverlay (that you are freel to fill with content) with two buttons. [11:30] That's what I was thinking of as the other two. [11:30] free* [11:30] jtv: I was expecting to see 150000 superseded publications. [11:30] ahhh [11:30] StevenK: Ah, that's not possible yet. [11:30] jtv: But looking at https://dogfood.launchpad.net/debian/+source/simple-scan/+publishinghistory, that was all done on 2011-09-01 [11:30] the 1st of the month, now I see. [11:30] jtv: Should we set everything back to Published and rerun? [11:31] Given that's how it'll be on prod.' [11:31] Yeah sure, it's getting to be fun. [11:31] (once we fix the commit) [11:31] rvba: I am also getting defeated by my utter lack of JS knowledge. [11:31] StevenK: For now it only protects a form, and it submits the form in question if you click 'yes' on the confirmation overlay. [11:31] rvba: Okay, thanks. I shall chat to Curtis about it in the morning. [11:31] StevenK: This is so easy to do that I'm ok to do it if you want. [11:32] jtv: If we wanted to be really accurate... [11:32] jtv: we could delete all Debian publications since the mirror date. [11:32] We can pick some obscure release that nobody will miss. [11:32] jtv: That might yield a more analysable result. [11:32] Hm? [11:32] (Which is usually anything except "sid," in my experience) [11:33] Or is everything supposed to be restored anyway? [11:33] Update done. All is Published again in sid. Here we go. [11:33] If we just work out the timestamp of the Sources file we have, and delete every DF publication since like a day after that, we will have a pretty simulation of what we're about to experience on production. [11:33] Rather than what we're doing now, which is regressing the mirror. [11:34] Still, this should be mostly sensible. [11:34] We just have to ignore the bits where it goes backwards. [11:34] StevenK: I confess I wanted to do it because then the confirmation overlay would be usable to protect pure js calls. [11:34] jtv, bigjools: Any reason not to kill DF's buildd-manager? [11:35] It's eating most of a core. [11:35] nope [11:35] and can't be helping postgres. [11:35] * wgrant murders. [11:35] I can't wait to get Rabbit working with it [11:35] Oooh. [11:35] Although it's not so useful there. [11:35] Since the slaves still have to be polled. [11:35] then those crazy periodic queries can die [11:36] Sort of. [11:36] you're kidding, right? [11:36] We'll have to invert the dispatch algorithm. [11:36] The slaves can't talk to rabbit. [11:36] no no no [11:36] StevenK: and in return you might give me a hand with the branch that William kindly accepted to review tomorrow... deal? ;) [11:37] we just have the existing query replaced with a blocking fetch of an item from Rabbit [11:37] bigjools: At present dispatching is handled by the normal builder polling loop. For each idle builder, we find suitable builds. [11:37] Mm. [11:37] in that thread, anyway [11:37] I guess we could work that out, somehow. [11:37] polling - BAD [11:37] But it's not going to be as awesom as the job system. [11:37] Which can be fully rabbit and instaneous. [11:37] some good jokes on here today [11:37] Like it should have been 7 years ago, but I digress... [11:37] bigjools: polling is bad for some things. It can actually scale well in some circumstances. [11:38] jtv: I know, but I am talking about the insidious nature of it in LP generally [11:38] rvba: I may regret this ... but what branch? :-) [11:38] StevenK: I see you're cautious ... https://code.launchpad.net/~rvb/launchpad/sync-bug-827608-credit-copy-2/+merge/74958. [11:39] mvo: Any luck with apt-ftparchive? I'm probably only around for another hourish if you need help to reproduce it. [11:39] StevenK: What's blocking Jenkins from moving into the DC now? [11:40] StevenK: I think we should kill off buildbot soon. [11:40] StevenK: No reason not to now. [11:40] Jenkins now has the good combination of attributes of a) not sucking and b) being reliable [11:40] Neither of which buildbot is good at. [11:40] wgrant: could you mail me your config? just for completness? I did not get far, too many interruptions, but I attack it now [11:40] mvo: Let me attempt to obtain one. [11:41] thx [11:41] There we go, hung... [11:41] * wgrant grabs the config. [11:41] The hang makes it nice and easy to grab it from the tmp dir... [11:42] wgrant: further checking in Sources.gz confirms the GToGB. Another victory for theoretical soyuz physics! [11:42] jtv: Excellent. How is the next run going? [11:43] It is, that's all I know. [11:43] Heh [11:43] mvo: , invoked as 'apt-ftparchive --no-contents generate /var/tmp/archive/ubuntu-misc/apt.conf' [11:43] Let me just try it in a clean dir. [11:44] great, thanks [11:45] Hmm. [11:45] I may have to give you a tarball with other state. [11:45] Ah, there we go. [11:47] mvo: mkdir -p /var/tmp/archive/ubuntu/dists/warty/{main,universe}/i18n is sufficient to make it hang. [11:47] bigjools: When does the Rabbit stuff come up? [11:47] nigelb: in what context? [11:47] mvo: With just one of those it's fine. With both it hangs. [11:47] bigjools: In the context of MPs [11:47] nigelb: when it's done [11:48] HA. This sounds like the answer to "When does Ubuntu 10.10 come out?" [11:48] nigelb: Interesting that you should pick 10.10 [11:48] ;) [11:48] nigelb: As it's the one release where the time was precisely known months before :) [11:49] I meant to type 11.10, but typo'd to the one release I'd be wrong :) [11:50] mvo: It spawns to child apt-ftparchives, each with a gzip, and they block on a pipe... [11:50] s/to/two/ [11:51] On dogfood is spawned four, so I presume it's one per component, as would make sense. [11:53] wgrant: great, thanks, that is really useful information, the vm is still building but that sounds like reproducing should be really straightforward [11:54] wgrant@lucid-test-lp:~/launchpad/lp-branches/devel$ apt-cache policy apt-utils [11:54] apt-utils: Installed: 0.7.25.3ubuntu9.6+mvo1 [11:54] launchpad@mawson:/srv/launchpad.net/codelines/current$ apt-cache policy apt-utils [11:54] apt-utils: Installed: 0.7.25.3ubuntu9.6+mvo1+0.IS.10.04 === benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: benji | Critical bugs: 262 - 0:[########*** stack smashing detected ***: ./lp terminated === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: benji | Critical bugs: 263 - 0:[########*** stack smashing detected ***: ./lp terminated [12:08] wgrant: new gina results are in. [12:08] Very similar to the old ones, I'm afraid. [12:08] New: 69 went from Superseded to Deleted, and 3 from Deleted to Published. [12:09] O_o deleted to published? [12:09] Oh/ [12:09] This is diffing from the old statuses, though. [12:09] So that makes sense. [12:09] old = before we set everything back to published [12:09] https://dogfood.launchpad.net/debian/+source/dpkg/+publishinghistory [12:09] Some stuff still from 2011-09-01... [12:09] Oh, but that's not sid. [12:10] All the sid stuff is freshly and correctly superseded. [12:10] I declare this a provisional success. [12:10] Ah yes, ISWYM [12:11] Since I imagine you're EODing soon, want to set the whole archive back to published and let it rerun? [12:11] We can check it in the morning. [12:11] It could take a little while. [12:12] Do you have names for the Deleted->Published three? [12:12] That is a little bit odd. [12:14] wgrant: do you have any idea how we can manage chroots remotely? [12:14] I thought of doing some rain-type dance, myself [12:16] wgrant: from the all-Published starting point, changes were: 18,668 stayed Published, 60,106 became Superseded, 182 became Deleted. [12:18] wgrant: the three that now stayed Published even though they were previously Deleted: [12:18] bzr | 1.5-1.1 [12:18] a2ps | 1:4.14-1 [12:18] python-virtualenv | 1.3.3-1 [12:20] Mind you, those were Deleted before we started, and then we set them back to Published & re-ran domination, so maybe the previous deletions weren't even domination-based. [12:22] Hah [12:22] Since there was no way to delete them... [12:22] bigjools: Easy to do through the API. [12:22] bigjools: Permissions are the hardest bit... [12:22] wgrant: !!!! [12:23] ? [12:23] uploading hundred meg files? [12:23] Well, there is that, but it's not without precedent. [12:23] eg +storeblob does it sometimes. [12:23] no way jose, not in the API [12:23] jtv: Erm. [12:23] jtv: Want to check the archive on those? [12:24] jtv: I suspect they're not archive=3 :) [12:24] No idea what to look for. [12:24] Oh, archive in the DB [12:24] I suspect we need something like poppy and process-upload [12:24] bigjools: aaaaaaaaaaa [12:24] wgrant-induced archive pollution [12:24] why? [12:24] HTTP uploads should work fine. [12:24] wgrant: you're right, not in archive 3. 71, 2919, 7823 respectively. [12:24] We need to be able to do large HTTP uploads. [12:25] jtv: That would do it. [12:25] exactly. May I introduce you to the librarian. [12:25] as long as it's not through an appserver, yes. I didn't specify which protocol. [12:25] jtv: Now, what have I told you about queries that mention a series or distribution without an archive ;) [12:25] appservers can do several hundred MB uploads fine actually; though it is undesirable I would advise not blocking on that aspect. [12:26] as we already have that through storeblob [12:26] Given how rare chroot uploads are. [12:26] lifeless: you want to tie up an appserver thread for an hour? [12:26] wgrant: …that all I had to fear was the mess you left in the database? [12:26] I don't think it's going to be much of a problem. [12:26] jtv: Silence! [12:26] Well you asked. [12:26] rare *now* yes [12:26] bigjools: well, its more complex that than... it doesn't get dispatched to a thread until the upload completes. [12:27] we probably want to do some checks on the upload too, which would mean unpacking it [12:27] bigjools: I don't think so. [12:27] I really, really don't want to do this in the appserver [12:27] wgrant: well, I do [12:27] bigjools: If a distro owner wants to fuck their own distro, they can feel free. [12:27] bigjools: that should be done post upload, same as the apport blobs that storeblob does [12:27] What checks can we perform? [12:27] wgrant: they'd also be fucking the builder [12:27] bigjools: Oh? [12:27] GNU tar shouldn't allow builder fucking. [12:27] wgrant: for my next experiment, I'd love to delete a package from Sources.gz and re-run. Or would that be very bad of me? [12:27] Not even LP does now. [12:28] jtv: That would be very correct and thorough of you. [12:28] * jtv looks for the catch [12:28] bigjools: I guess for me - I'd like to see it be uploaded via +storeblob, then we can move *all* +storeblob to the librarian - less special cases, more win. [12:28] jtv: I think gina is crap and doesn't verify Release, so you should just be able to change the file. [12:28] lifeless: that sounds ok, as long as we have a way of processing it later [12:28] lifeless: That's roughly what I was thinking. [12:28] bigjools: The uploader gets a UUID back. [12:28] bigjools: yes, +storeblob goes into a queue for post-processing [12:28] cool [12:28] bigjools: They can then give that to a chroot management function. [12:29] bigjools: you do an upload and then an API call saying 'hey, use this for $that' [12:29] bigjools: and stuff gc's after a day or something [12:29] Pretty much. [12:29] splendid [12:29] we don't need to worry about this yet anyway [12:29] But I'm pretty sure we can't do much sensible post-processing here, so it may just end up creating a PocketChroot with the LFA. [12:30] *shrug* [12:31] jtv: Could you set up the full archive run just before you EOD? It would be handy to have that test. [12:31] Although it is looking very promising so far. [12:31] wgrant: as in, all of Debian? [12:31] Yes. [12:31] UPDATE sourcepackagepublishinghistory SET status=2, supersededby=NULL, datesuperseded=NULL WHERE archive=3 [12:31] And by the way, with the work I've been doing, the correct acronym for my transition from work to not working is OD, not EOD. [12:32] Heh [12:32] lifeless: We can still land DB patches with only one approval, right? [12:36] wgrant: yes, long as they complete in < 10 seconds etc. [12:36] I'm just dropping 35 tables... should be pretty quick. [12:36] wow [12:36] cool [12:37] that might shave 10% off our slony overhead [12:37] That was precisely my reasoning for doing it now. [12:37] 305 -> 270 [12:37] Is POComment among them? [12:37] No. [12:37] Should it be? [12:38] I noticed it, but didn't know it to be obsolete. [12:38] I _think_ so. [12:38] I thought it was still used or something. [12:38] POSubscription is dying, however. [12:38] I'm not sure we ever used it. [12:38] Good. [12:38] I collected this 35 on one pass through \dt [12:38] I probably missed a couple of HWDB/translations. [12:38] Since I don't know those areas wonderfully. [12:39] http://paste.ubuntu.com/674281/ is the list I have patches for. [12:39] We also have plenty unused columns. [12:39] Yeah. [12:39] Those are less of a win, though. [12:40] (deleting tables is a win because disabling/enabling triggers is slow, and slony has to do that to every table around every slonik script) [12:40] Well we do have some tables that are painfully slow to scan or retrieve from. [12:40] Indeed. [12:40] * jtv checks a few columns [12:41] * wgrant goes through the table list again. [12:41] grr [12:41] Uhoh. [12:41] setuptools you really annoyme [12:41] I remember a --egg-info parameter [12:41] but not what command [12:41] setup.py egg_info -b-somesuffix sdist? [12:42] looks like [12:42] ./setup.py egg_info -b -lpwithnodatetime-r397 sdist [12:43] but now I need to wait for jamesh :) [12:43] :( [12:43] he had some feedback on the patch, I don't want to roll two eggs for LP to migrate across [12:43] wgrant: Some potentially unnecessary ones in TranslationMessage: is_fuzzy, was_obsolete_in_last_import, was_fuzzy_in_last_import. In POFile: description, fuzzyheader, from_sourcepackagename. In POTemplate: copyright, sourcepackageversion, binarypackagename. In POTMsgSet: potemplate, sequence. [12:44] I'll switch back to the gpg migration stuff [12:45] wgrant: Not seeing any change after removing a package from Sources.gz and re-dominating. :( [12:45] benji: Got time for a shortish but possibly wartish review? https://code.launchpad.net/~allenap/launchpad/series-init-failure-explanations-bug-835024-ui/+merge/74974 [12:46] allenap: sure [12:46] jtv: Sure it was the right series? [12:46] sid. [12:46] :( [12:46] jtv: What did you delete? [12:46] benji: Thanks. [12:46] wgrant: adonthell [12:47] Hmm, indeed. [12:47] * wgrant checks the code. [12:48] Still seeing a neat Superseded, Superseded, Superseded, Published run for that one. [12:49] jtv: Oh. [12:49] You know, we're still in transitional mode... [12:49] It's not meant to be Deleted in transitional mode, is it? [12:49] *bash* [12:49] * jtv thinks [12:50] The latest version [12:50] # will then, finally, be marked appropriately Deleted once [12:50] # we remove this transitional hack. [12:52] Yup. [12:52] I already have the follow-up branch waiting in the wings, and that messed up my view of transitional domination. Thanks for spotting that. [12:52] I'd forgotten about it too, don't worry. [12:52] Until I checked the code. [12:52] And saw the 10 line XXX [12:52] ooooh. [12:55] jtv: I think pocomment is the only remaining unused table. [12:55] Well, unused except by the POTranslationPruner. [12:55] wgrant: Can haz link to your branches? [12:55] :( it references person [12:55] So I might add it to this lot. [12:56] Since it means it's a three-branch effort to remove it. [12:56] jtv: Can I kill it? [12:56] wgrant: Did you want me to clean up POTranslationPruner? [12:56] Since that should be quickish [12:56] No, I'll delete that in my second branch. [12:56] I already delete a bit of other stuff there. [12:56] https://code.launchpad.net/~wgrant/launchpad/demolish-unused-tables-1-db/+merge/74960, https://code.launchpad.net/~wgrant/launchpad/demolish-unused-tables-2/+merge/74961, https://code.launchpad.net/~wgrant/launchpad/demolish-unused-tables-3-db/+merge/74963 [12:57] Love the branch names [12:57] wgrant, behind the wheel of a wrecking ball. [12:58] (╯°□°)╯︵ ┻━┻ [12:58] wgrant: yes, please kill POComment. If we ever used it, I think it has to be more than 4 years ago. [12:59] +ALTER TABLE pushmirroraccess DROP CONSTRAINT "$1"; [12:59] Das twitch [12:59] wgrant: Next experiment… change component on a package. Should supersede the existing SPPH and publish a new one. [12:59] (pushmirroraccess is not related to distribution mirrors, but arch mirrors, FWIW... I thought it was a WHUI for managing Ubuntu push mirrors, but no, far worse) [13:00] jtv: Indeed. That works in archivepublisher, but I haven't tried gina. [13:01] Err… I say Component, but what does that look like in a Debian sources list? [13:01] Ah, demolish. [13:01] Need to add to that list of names I should use in a branch. [13:01] jtv: Sources is divided by component. [13:01] nigelb: it's been done now. But “annihilate” may still be available. [13:01] jtv: You'll note that you're looking at main/source/Sources... use contrib/source/Sources instead. [13:02] Oh, OK [13:02] wgrant: Going to link bug 345810 to -3 [13:02] <_mup_> Bug #345810: Remove old infestations database stuff < https://launchpad.net/bugs/345810 > [13:02] wgrant: I guess in this case I should move a package from one to the other. [13:02] StevenK: I'm going to search that out on Wednesday when I land -3, yep. [13:02] jtv: Indeed. [13:02] Or copy. [13:02] That might get confusing. [13:03] It's not really a situation that the new gina logic supports. [13:03] But it should behave the same way. [13:03] wgrant: So, is that "Yes, please link" or "No, I will look for that and other bugs on Wednesday?" [13:03] StevenK: You might as well link. [13:04] wgrant: I can't help but notice that the contrib Sources is empty. [13:04] Not any more, of course, with a package moved in there. [13:04] Heh. [13:04] wgrant: So now it's the Comdemned 36? [13:04] StevenK might be a bad person, I suspect. [13:04] wgrant@lucid-test-lp:~/launchpad/lp-branches/demolish-unused-tables-1-db$ bzr ci -m "pocomment becomes the last member of the Condemned 36." [13:04] Way ahead of you, StevenK. [13:05] Heh [13:05] wgrant: Yes, I'm a bad person [13:05] StevenK: How did you create the gina-mirror on mawson? [13:05] StevenK: It seems to only have main. [13:05] By Perl and by hand ... :-) [13:05] As I said. [13:05] Bad person. [13:05] Hmm. [13:06] I wonder what breaks if I land -3-db with a commit message of "(╯°□°)╯︵ ┻━┻" [13:06] Please can I land mine first before you ruin us? [13:06] Ruin?! [13:06] We're deleting 36 tables! [13:06] s/Ruin/Make/ [13:07] By breaking PQM and/or buildbot? Yes, ruin. [13:07] You should be PRAISING us! [13:07] For breaking PQM and/or buildbot? Alright: praise you. Praise you all to hell. [13:07] But gina' [13:07] s still in transitional mode. [13:08] We won't actually be removed. [13:08] buildbot needs to die anyway [13:08] So you can send us to hell, but we'll still be here :( [13:08] And PQM sucks [13:08] StevenK: yes but _after_ I've landed my next few branches please, is what I'm saying. [13:08] wgrant: you'll be superseded here and published in hell. [13:08] fuuuu [13:09] allenap: your branch looks fine, I had one idea for a small simplification to the template [13:11] benji: Ah, cool. If tal:content evaluates to nothing, does the paragraph get dropped? [13:11] allenap: no :) I was figuring that an empty paragraph wouldn't hurt too much. [13:14] benji: Okay. I'll check. [13:14] wgrant: still no change. Not sure what I've done to deserve this. Have I been editing in the wrong place maybe? [13:15] wgrant: I really have to go. I'll kick off that Debian run first. [13:15] jtv: It didn't even crash? [13:15] jtv: I would expect a crash, given that the files aren't in the contrib pool. [13:15] jtv: But maybe it doesn't look there if there's something already in the archive. [13:15] We shall investigate tomorrow. [13:15] jtv: Need to borrow Mark's dictionary for some new words ;) [13:15] wgrant: oh, then maybe it just ignores it. [13:16] nigelb: Heh [13:18] benji: I chucked two very brief branches onto the review queue, but am now OD. [13:18] does anybody have experience working on Launchpad in lxc? [13:19] jtv: I hope that was a dropped E on EOD and not really OD ("overdosed") ;) [13:19] benji: I know what I said. [13:19] heh [13:20] jelmer: lifeless and I do it. [13:20] wgrant: gina didn't create a second SPPH for adonthell. I could just make its next-to-last SPPH point to the same SPR as the previous one, and see how it fares in the Great Overnight Debian Domination of 2011. [13:20] wgrant: I just found /Running/LXC on the wiki [13:20] jelmer: I've been doing it for about two weeks now. [13:20] jtv: Let's not push it. [13:20] wgrant: I guess that means it works ? [13:21] jelmer: Yeah. I run mostly lucid-on-oneiric, but also sometimes oneiric-on-oneiric. [13:21] * jelmer is a bit tired of Oneiric breaking his Launchpad setup every couple of days, so I'd like to run Lucid in LXC [13:21] jelmer: lucid-on-natty also mostly works, with a bit more effort as described on the page. [13:21] wgrant: OK, I'll just kick off the GODD2011 then. [13:21] jtv: GODD2011A, just to be safe. [13:21] I doubt this will be the last :( [13:22] OK. [13:22] BTW you just had me update 172737 records. [13:22] wgrant: I guess I should run gina with --all then? [13:24] jtv: A good question. [13:24] Let me check what targets we have... [13:24] (BTW I have a branch on the review queue that adds a --list-targets option) [13:25] Hm. DF may only have sid configured... [13:25] Brillant. [13:25] Bah, and we only have sid indices. [13:25] Upsetting. [13:25] I guess we'll have to deal. [13:26] So… still a sid-only run then? [13:26] Seems so :( [13:26] Actually, that's a no-op now. [13:28] No, it's not. We just reset everything to Published. I'll re-run. [13:28] benji: Looks good. Also, the |nothing wasn't needed either; None is rendered as the empty string it seems. [13:29] wgrant: it's on the way. I suggest we both stop working now. [13:29] Probably. [13:30] Just finishing off the pocomment abolition. [13:30] I'm going to try and get the two DB patches deployed tomorrow and Wednesday. [13:30] As a test of fastdowntime efficiency. [13:30] Then we'll have to finish Q/A for this first. [13:31] How does the DB patches deployment work? [13:31] jtv: Yeah, QA for this has to be done by Wed morning. [13:32] But we have all of tomorrow. [13:32] And we've got a lot out of the way already. Good thing they were separate tickets. [13:32] jtv: yeah. [13:32] jtv: I will check it all out in the morning. [13:32] And hopefully declare qa-meh [13:32] Thanks. And now, offness. [13:32] Night! [13:32] nn [13:32] later jtv! [13:33] nigelb: The actual deployment? We turn off pgbouncer, which has the effect of disconnecting everyone from the DB and making appservers crash terribly when they try to talk to it. [13:33] Then we apply the patches through slony. [13:33] Recreate all stored procedures. [13:33] Reapply all security settings. [13:33] Then turn pgbouncer back on. [13:33] StevenK: I've improved the ConfirmationOverlay so that it can take a callback method to call instead of submitting the form. [13:33] Roughly. [13:33] wgrant: And how often does it happen? [13:33] nigelb: Up to once a day. [13:33] StevenK: The branch is up for review. [13:33] At 0830Z [13:33] If required. [13:33] wgrant: and sequential? [13:34] (in terms of db-devel revisions) [13:34] nigelb: Yes. And lifeless says we should apply one patch at a time, but I'm going to hope he's not around if we ever get more than one in the queue. [13:34] benji: Hi, could you have a look at this tiny js branch please? https://code.launchpad.net/~rvb/launchpad/confirmationoverlay-fn/+merge/74997 [13:34] wgrant: Well, I may have landed one today, and I thought you were landing a few as well? [13:35] nigelb: Ah, true, forgot there was yours in front of mine. [13:35] Sad. [13:35] I have two, but one can only be landed once the other is deployed. [13:35] rvba: sure [13:35] wgrant: Ah, ouch. [13:35] I may have to convince Lynne to drag lifeless away for a few hours tomorrow night. [13:36] wgrant: You do know lifeless is working 4 days a week right? [13:36] :) [13:36] Oh, that might work as well. [13:36] benji: Thanks. [13:36] allenap: I should have realized you'd get a "None" out. Is that attribute always a string? If so, you should be fine doing it that way. [13:37] benji: error_description can be None, but my point was that the template DTRT and renders it as "" instead of "None". [13:38] cool [14:03] rvba: done, I had one thought about a test addition, but the branch looks good [14:05] benji: Okay, thanks. [14:15] rvba: You have a typo in your branch "Ann (optional)" it should be "An (optional)" [14:16] StevenK: Thanks for spotting this, I'll add the test as benji suggests and land this. [14:17] Sounds great to me. [14:26] benji: If you're up for that I've got another branch up for review ;) https://code.launchpad.net/~rvb/launchpad/sync-greyedout-resolved-841934/+merge/74975 [14:26] rvba: sure thing [14:26] Thanks. [14:34] hi folks, is there a reason why bin/lint.sh in launchpad uses pocketlint instead of pyflakes? what's the difference between the two? [14:35] rvba: done [14:35] cr3: pocketlint uses pyflakes and pep8 [14:35] nigelb: thanks! [14:35] benji: Thanks. [14:36] my pleasure [14:36] cr3: and I'm fairly sure it can lint more than just python. [14:36] There was more to it, but I didn't dig deep enough the last I checked. [14:37] nigelb: correct me if I'm wrong but I don't think pocketlint considers disable-msg comments in source files, which is kinda annoying [14:37] I don't know about that, sorry. [14:43] sinzui: care to mumble? [14:43] yes [14:45] jcsackett, sorry, I pressed screencap and too 2000 pictures [14:45] wow. bet that ate some resources. [14:45] I heard you, but I need another minute to fix my oops [14:46] ok. [14:48] sinzui: i can hear you, seems you cannot hear me? [14:49] * jcsackett restarts his mumble. [14:54] deryck: chat? [14:55] abentley, sure, give me 5 minutes to wrap what I'm doing. [14:55] deryck: sure. [15:00] jcsackett, ssh-askpass-gnome [15:02] abentley, I'm good now. Firing up mumble. [15:05] sinzui: just in case it helps, this is the error http://paste.ubuntu.com/687676/ [15:11] jcsackett, bug 796873 [15:11] <_mup_> Bug #796873: ec2 land generates gnomekeyring.IOError if run over an ssh session < https://launchpad.net/bugs/796873 > === matsubara is now known as matsubara-lunch [15:28] sinzui: around? [15:29] nigelb, I am [15:30] sinzui: Looking at #launchpad, I just noticed a weird picker issue. [15:30] The picker doesn't find me when trying to assign a bug to myself. Works on subscribing though. [15:30] (Well, the seach asactually. [15:30] Gah [15:30] The search can't find 'nigelbabu' [15:31] we need a picker for nosetests, then it would be a nose picker [15:31] Or anyone else. [15:31] bigjools: bwahaha. [15:31] I'm here all week [15:31] nigelb, yuck [15:31] I will look into this [15:32] sinzui: pfefferz just noticed this, you might want to help him out :) [15:33] bigjools: Also, you guys didn't get to win yesterday. [15:34] Well, we didn't win either. But meh. [15:34] nigelb: outrageous umpiring keeping them on in the rain [15:34] the 2 late wickets swung you a tie [15:34] bigjools: Hey the English tried to delay things in the last over :) [15:37] nigelb: it was pretty hilarious - when India was ahead in D/L they rushed off and left England hanging around. When England were ahead in D/L, the exact opposite happened. [15:37] :D [15:46] sinzui: I'd recommend a blog post about this. I'm sure more people will trip over this fairly soonish :) [15:47] nigelb, I was planning to. I am landing a branch that will require more attention from testers. [15:47] \o/ [15:48] I like the new picker, except for when I have to click twice even though I know the person's LP ID. [15:48] (I think I saw that bug already) [15:55] Ok, so js-oopsd. [15:55] * nigelb gets to coding it. [15:57] bigjools: semicolon slash slash? [15:58] you mean :~/ [15:58] ? [15:58] nigelb, I am landing the branch to address that very issue. The expander will move the the next line so that you can use the first line to select the user [15:58] nigelb: yes, there was some C++ or Java in your tweet [15:58] sinzui: \o/ [15:59] bigjools: lol [15:59] That's the zsh theme :P [15:59] I used to use zsh actually, back when the alternative was csh or sh [15:59] 22 years ago, yegads [16:00] * nigelb was probably born around that time-ish :P [16:02] bigjools: I only use zsh, because oh-my-zsh pretty much configues it out of the box. [16:02] I also typo a lot and most of the time zsh catches it. [16:03] Most of the scripts I write are bash, not zsh though :) === salgado is now known as salgado-lunch [16:53] Are there rules around how to create a new file? [16:54] (this is for a service, js-oopsd - https://launchpad.net/js-oopsd) [17:10] I'd like to get the list of ubuntu packages available in main, how would one do that through the API? [17:20] hmm. [17:21] Ursinha: source packages or binary packages? [17:21] Ursinha: IIRC something like lp.distributions['ubuntu'].getSeries(name_or_version="oneiric").getPublishedSources() [17:22] jelmer: distroseries don't have published sources [17:22] jml, packages that can be bugs files against [17:22] Ursinha: actually, lp.distributions['ubuntu'].getSeries(name_or_version="oneiric").main_archive.getPublishedSources() [17:22] main_archive is not just main [17:23] it includes universe as well, I was told [17:23] ah [17:23] I guess you could filter out some packages based on section, though that would be quite slow [17:23] jelmer: not quite! lp.distributions['ubuntu'].main_archive.getPublishedSources(component="main", distro_series=lp.distributions['ubuntu'].getSeries(name_or_version="oneiric"), status="Published") [17:23] In [41]: ubuntu.main_archive [17:23] Out[41]: [17:23] oh crap [17:23] ah [17:23] no "component" there [17:23] sorry [17:23] yeah [17:24] * Ursinha looks for a bug [17:24] you you have to iterate over the return of getPublishedSources [17:24] and do if publishing_record.component_name != "main": continue [17:24] Ursinha: I'm not sure in what context you're trying to do this, but another option could be to use the local apt cache [17:24] I don't know of a way to have LP do that step for you [17:24] hmm [17:25] that's bad isn't it [17:25] james_w, do you know if there's a bug for that? [17:25] I don't, sorry [17:26] Ursinha: I'm in mega-distraction mode anyway, let me try knocking up a patch. [17:26] jelmer, I'm trying to get this information from launchpad, to check which teams are subscribed to them [17:26] (warning: very low timeout on this, I might give up) [17:26] jml, awesome. I owe you a pack of the finest brazilian coffee. [17:32] bug 848097 [17:32] <_mup_> Bug #848097: Not possible to get a list of packages in a component through the API < https://launchpad.net/bugs/848097 > [17:36] Ursinha: ta [17:39] grunk. [17:40] grunk? [17:40] querying the published sources timesout consistently :/ [17:41] Ursinha: james_w has some code in lp:udd that could help with that [17:41] Ursinha: (I'm using the API for my pkgme work) [17:41] * Ursinha looks [17:41] nigelb: the bug in the testing-cabal version of testtools that I just fixed is preventing me from running lp tests [17:42] jml: Ouch [17:42] (I'm waiting for LP to build & publish the new package) [17:42] use virtualenv more often? :) [17:42] nigelb: I had to use a lot of willpower then. [17:42] nigelb: I'd rather not. [17:42] :) [17:43] Hrm. Need more help on this js-oopd. Gah, should find lifeless tomorrow morning. [17:44] * jml works around [17:45] jml: I'm curious, what's the work around? [17:45] nigelb: comment out the import of subunit in lp.testing [17:45] ah. [17:46] jml: that udd backoff code really ought to move into launchpadlib ... [17:46] +1 [17:47] cjwatson: agreed. [17:47] cjwatson: I guess now that there's less internal resistance to adding stuff to lplib, I could probably start proposing patches. [17:49] particularly since we're now doing fastdowntime which is likely to kick off API scripts once per business day [17:49] even if it doesn't happen at other times ... [17:50] cjwatson: good point. [17:50] bug 848120 [17:50] <_mup_> Bug #848120: add the udd backoff code to lplib < https://launchpad.net/bugs/848120 > [17:52] Ursinha: :) [17:53] :) [17:53] bugger. [17:57] * jml installs rabbitmq-server, breaks "Restart" [17:59] rabbitmq being necessary to run archive pagetests, of course === matsubara-lunch is now known as matsubara [18:09] Ursinha: https://code.launchpad.net/~jml/launchpad/get-published-sources-component-name/+merge/75054 [18:09] ~43 mins? [18:09] LP needs to be easier to hack on. [18:09] or I need to get faster. or both, probably. [18:10] jml, \o/ [18:11] Ursinha: while you are in the flush of gratitude, might I ask you to update https://wiki.ubuntu.com/JonathanLange with a recommendation for membership? [18:11] sure :) [18:11] Ursinha: thanks. [18:13] benji, hello :) what's the criteria to have a branch reviewed? jml just wrote a patch that will make me cry rainbows and unicorns [18:13] Ursinha: crying rainbows and unicorns is, in fact, the criteria [18:14] awesome [18:14] :) [18:14] Ursinha: this one? https://code.launchpad.net/~jml/launchpad/get-published-sources-component-name/+merge/75054 [18:14] benji: yep! [18:14] benji, yes :) [18:14] I'll take a look now. [18:14] benji, thanks! [18:18] jml, Ursinha: the branch looks good, approved [18:18] benji: thanks. Can you please land it? I don't have commit access any more. [18:19] (a matter of implementation, rather than policy) [18:19] jml: sure [18:20] benji: thanks. [18:20] crying rainbows and unicorns? heh. [18:21] jml: huh, why did you lose commit access? [18:21] jelmer: because I left the canonical-launchpad team. [18:22] I thought thre was an emeritus team. [18:22] *there [18:22] jml: I think I was kicked out of that too, but I still have commit access. [18:22] nigelb: there's a *plan* for one [18:22] Ah. [18:23] ah, ~canonical-bazaar is a member of ~launchpad for some reason [18:23] access probably. [18:23] jml: JFDI it ;) [18:24] nigelb: I don't have the necessary permissions. (or inclination, tbh) [18:24] heh === beuno is now known as beuno-lunch [18:44] publishing takes for*ever* [18:46] thanks jml and benji :) === salgado-lunch is now known as salgado [18:47] lifeless: ping, for whenever you get on :) [19:06] * deryck goes offline for lunch, back soon [19:07] nigelb: hi [19:08] lifeless: Hey, I had a few questions from python-gpgfixtures [19:08] flacoste: morning [19:08] nigelb: cool [19:09] hi lifeless [19:09] One is, what does "__metatype__ = object" do, and the other is, is threading necessary? [19:10] nigelb: __metatype__ = object makes [19:10] class Foo: [19:10] equivalent to [19:10] class Foo(object): [19:10] Ahh. [19:10] nigelb: as for threading, perhaps a little context will help me answer :) [19:10] Why can't we re-use ppa names once the ppa has been deleted? [19:11] because apt. [19:11] https://answers.launchpad.net/launchpad/+faq/661 [19:11] In the keyserver.py, there's "from threading import Lock" and "self.gpg_lock = Lock()" [19:12] I'm guessing that's threading, but I may be wrong :) [19:12] so, wsgi servers are threaded generally [19:12] ah [19:12] an app 'foo' will be called within each thread [19:12] I'm new to writing bare wsgi. So, my inexperience comes into play slightly :) [19:12] unless you take special steps to ensure non-threaded [19:13] simpleserver for instance has one thread listening [19:13] then on a new request hands that off to a worker [19:13] which does [19:13] app(environ, start_response) [19:13] AHH. [19:13] the gpg fixtures keyserver wants to avoid race conditions [19:13] so it has a little lock in it [19:14] that doesn't mean other wsgi apps need, or do not need, such a lock. [19:14] ok :) [19:16] lifeless: Oh and finally, could you review https://code.launchpad.net/~nigelbabu/launchpad/kill-statusexplanation/+merge/74934 :) [19:16] I have stub's greenlight [19:16] no need [19:16] the review for me is so I am in the loop [19:16] Oh. [19:16] read the page again :) [19:17] In that case, I'm guessing stub just forgot to land it. [19:17] I thought it might be because you needed to ack :) [19:17] no, that would be a pita for folk [19:21] No, its because I'm too used to people landing their own branches that I didn't think :-) [19:21] Wha. [19:21] Why are you awake. [19:21] nigelb: you're like the third non-canonical person to land db patches [19:21] Oh. [19:22] Cause I woke up at 3pm of course. What a silly question! [19:22] Oh, nice. [19:22] lifeless: Who else besides William? [19:22] * nigelb looks === lifeless changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: benji | Critical bugs: 263 - 0:[########*** stack smashing detected ***: ./lp terminated [19:23] Ah, I see. [19:29] stub: thanks again! [19:29] np [19:30] lifeless: The process was relatively easy. Except for the bit about fti.py which I needed stub's help. [19:30] <3 the detailed documentation. === beuno-lunch is now known as beuno [19:32] stub: Your sleep cycle seems lovely ;) [19:34] its more of an orbit [19:34] cause it has precession [19:35] lol. [19:35] Yeah, I've seen him wake up at 3 as well [19:35] *3 pm [19:41] lifeless: I think nigelb is attempting to get his own sleep orbit as well ;-) [19:41] I have a precise cycle. I sleep betwen 2 am and 3 am and wake up betwen 9 am and 10 am. === matsubara is now known as matsubara-afk [19:47] nigelb: hah [19:48] Secretly, I've given up on seeing 3 am when I wake up. [20:03] nigelb: I don't know that I believe you go to bed that early. Certainly not with that consistancy :P [20:07] test_sigint_exits_nicely (bzrlib.plugins.lpserve.test_lpserve.TestLPServiceInSubprocess) [20:07] buildbot in testfix. Anyone in maintenance want to look before I rebuild? Got several branches with ec2 I'd rather not bounce. [20:08] what happened to the RT about buildbot access to community? [20:08] at least to see what failed. [20:09] * stub shrugs [20:09] This one has been a regular failure in any case. [20:10] or maybe not. dunno. === benji is now known as Guest95110 === benji___ is now known as benji [20:38] benji: are you still reviewing? [20:39] bac: yep [20:39] benji: great. https://code.launchpad.net/~bac/launchpad/bug-831991/+merge/75068 [20:39] I'll take a look momentarily. [20:46] bac: done, it looks good [20:46] benji: thx [20:46] np [20:50] I'm getting this error when running the tests: http://paste.ubuntu.com/687893/; the punchline is "psycopg2.OperationalError: fe_sendauth: no password supplied" [20:51] benji: Ian and me hit that as well [20:51] benji: The fix seems to be to make sure you have lines for IPv6 in your pg_hba.conf [20:52] ok, let me look at that [20:52] benji: http://pastebin.ubuntu.com/687895/ is what mine looks like now [20:52] thanks [20:55] jelmer: that fixed that error, thanks! (now to figure out the next one, maybe a good old-fashioned make schema will help) [20:56] benji: what's the next one? [20:57] I also hit another one shortly after that, and then decided to go back to lucid. [20:57] "ProgrammingError: column distribution.package_derivatives_email does not exist" [20:57] ah, heh, that does indeed sound like a schema issue :) [20:59] jcsackett, ping [20:59] sinzui: pong. [21:00] did you get the email about the 404 [21:00] sinzui: yeah, looks like i missed a doctest that needed updating. [21:01] jcsackett, I can update the one broken test and submit to pqm if want [21:01] jcsackett, That is an evil doctest. [21:01] sinzui: that's fine by me, if you have the time. [21:01] I do [21:01] sinzui: all doctests are evil. :-P [21:01] That one take more than 10 minutes to run [21:02] ok, that's exceptionally evil. [21:04] sinzui: you need me to change the owner of the 404 branch, or are you good? [21:04] No, I just branched and will wait for the test to complete [21:05] jcsackett++ [21:05] sinzui: dig. [21:05] nigelb: :-) === benji changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 263 - 0:[########*** stack smashing detected ***: ./lp terminated [21:16] jcsackett, sinzui: nice solution to to the "too clicky" problem! [21:17] Has that landed yet? [21:17] it's in the buildbot queue. [21:18] \o/ [21:18] flacoste, That was all jcsackett's work. I am his landing surrogate while he beats his computer into submission [21:19] flacoste: horrible name, but http://pypi.python.org/pypi/RunningCalcs/0.1 - online algorithms; might be able to simplify the PPR using this [21:22] Does LP by itself have an OOPS report page? [21:23] no [21:23] the reporting is done by a not-yet-opened tool 'oops-tools' [21:23] AH. [21:23] thats blocked on time more than anything else [21:24] Open it for help? :) [21:24] need to audit for passwords etc that need changing before releasing the code [21:24] AH. [21:24] yes, it had deployment details mingled with the source tree. [21:25] Ouch [21:25] so did LP :P [21:25] My memory of LP doesn't extend that far :P [21:26] I've been around for only 2 years. I'm guessing LP has been open for most of it. [21:27] "like the Forth Bridge in [21:27] nigelb: yep [21:27] Scotland - its a never-ending job to paint it from end to end [21:27] that sounds like critical bugs for LP :P [21:27] (its a quote from an email to ubuntu-devel@) [21:27] * jelmer remembers being very curious about the LP source code around UDS Barcelona (Karmic?) [21:28] I'm sure there are some bits everyone's curious about :P [21:31] jelmer: Yep, Karmic (https://wiki.ubuntu.com/DeveloperSummit) [21:43] lifeless: indeed! [21:44] lifeless: we'd probably have to port my median implementation to it though [21:48] flacoste: that would give it a home :) [23:07] sinzui, wallyworld_: I can't hear anything any more. [23:29] Project devel build #1,061: FAILURE in 1 hr 3 min: https://lpci.wedontsleep.org/job/devel/1061/ [23:30] Hm [23:30] * nigelb waves [23:30] * jelmer hums back at StevenK [23:30] 200 != 503 [23:31] that looks like HTTP status [23:33] There were 1 imports of names not appearing in the __all__. [23:33] You should not import GeneralizedPublication from lp.archivepublisher.domination: [23:33] lp.soyuz.scripts.gina.dominate [23:33] RARGH [23:33] heh [23:34] This the "Gina, the dominatrix" branch [23:34] Part of it, yes. [23:39] can has review - alternative fix for the pgbouncer buildbot fail. https://code.launchpad.net/~lifeless/python-pgbouncer/bug-846236/+merge/75091 [23:41] lifeless: You're not going to remove the other fix? [23:41] wgrant: the one I rolledback ? [23:41] Ah, that would do it. [23:41] We're going to assume that pgbouncer isn't insane, so it writes the whole pid atomically? [23:41] StevenK: i only have one _ today [23:42] wallyworld_: The day is still young. [23:42] if its writing one byte at a time and doing a flush, then we should fix it. [23:42] lifeless: r=me [23:42] put it this way, *all* the service management code in Ubuntu assumes that 'pid file is intact' [23:43] True [23:43] and I don't think, in general, that you can assume anything else and use pid files at all. [23:44] Oh, bleh. The next thing to do is land indicies [23:46] wallyworld_: Why is transitively_private becoming explicit rather than explicitly_private? [23:46] wgrant: Your merged branch uses -83-1, but according to allocated.txt, that is jml's number ... [23:46] wallyworld_: Having the default attribute be the right one to check sounds beneficial. [23:46] Erm, I pushed. [23:47] cheating! :P [23:47] .... but it failed and I didn't notice, because I was behind. [23:47] Fail. [23:47] wgrant: not sure i fully understand your ?. column "private" = explicitly private. column "transitively_private" = private because stacked on private branch [23:48] wallyworld_: Yes, but checking the explicitly private field is never the right thing to do. [23:48] But it is looks like a sensible default, because it's named 'private'. [23:48] checking in what context? [23:48] API or internal. [23:49] It's never OK to check the explicitly private column. [23:49] You have to check the transitively private column. [23:49] yes [23:50] And having the wrong one named 'private' sounds like an accident waiting to happen. [23:50] wgrant: the attribute is call explicitly_private. it's just that the db column has not been renamed [23:50] wallyworld_: Ah, k, as long as that's not exposed outside the DB. [23:50] the Branch.private attribute has already been renamed to Banch.explicitly_private [23:50] wallyworld_: And as long as not much queries directly... [23:51] only on place has hand coded sql [23:51] and this should be done using storm in any case [23:51] wgrant: thanks for those hints on lxc btw, seems to work well [23:52] i'm not sure how expensive it is to rename a column, but that would be nice to do once the dust has settled [23:52] jml: I'm sorry, I've stomped on your DB patch number. I failed to notice that my push failed, so I've landed 83-1 already. Could you please take another number? :/ [23:52] jelmer: Yeah, there's only one tests that seems to fail in LXC. [23:53] wallyworld_: It's trivial. [23:53] wallyworld_: Except that it's hard to do with fastdowntime. [23:53] s/hard/impossible [23:53] wgrant: except that it would need to be done as a column copy, and then a delete [23:53] lifeless: Lies. [23:53] you can do a copy+delete [23:53] but not a rename [23:53] so that the code could be changed in between [23:53] lifeless: I think we can mangle the Storm classes with feature flags. [23:53] lifeless: wait, isn't that the same? [23:54] wgrant: as long as its not fragile [23:54] jelmer: one takes 0.0001 seconds. One takes a week. [23:54] jelmer: so no, not the same. [23:54] lifeless: You're to quick. I had a good joke lined up about renames in VCS. :P [23:54] *too [23:54] :P sorry [23:55] wgrant: bug 848400 is the rollback [23:55] <_mup_> Bug #848400: fixture shares fd's with testrunner process, will cause test hangs and worse. < https://launchpad.net/bugs/848400 > [23:55] Is that was just caused the failure on Jenkins? [23:56] doubtful [23:56] possibly related [23:56] the rollback was in python-pgbouncer [23:56] next step is a version bump in lp's versions.cfg [23:56] It looked like a hang, no test output for 600 seconds? [23:56] Where? [23:56] https://lpci.wedontsleep.org/job/devel/1061/testReport/junit/canonical.librarian.tests.test_db_outage/TestLibrarianDBOutage/test_outage/ [23:56] ? [23:57] Oh, a new failure that I hadn't seen yet. [23:57] That's just the failure, the console log has a little more. [23:57] That's a brand new tests. [23:57] So it may actually be bad. [23:57] * StevenK prods wgrant until he pushes a new allocated.txt [23:58] jml: I've tentatively given you 86-1. [23:59] ha [23:59] wgrant: if his patch is ready to roll, you might like to fix-and-land it as a courtesy. its $am there. [23:59] lifeless: I discussed it with him last week, and it was on ice. [23:59] Otherwise I would :)