[00:34] thumper: hello! [00:34] thumper: can you read https://code.launchpad.net/~mbp/launchpad/690021-rlimit/+merge/43733 when you get back? [01:51] thumper: hi? [01:51] poolie: hi [01:57] hi thumper [01:57] can you read https://code.launchpad.net/~mbp/launchpad/690021-rlimit/+merge/43733 for me please? [01:58] oh, you did [01:59] yep [01:59] what kind of a test would you like? [01:59] that it gets set? or how killed jobs are handled? [02:00] I think that right now, if a job isn't marked as done or failed explicitly, it will be retried [02:02] that's good [02:02] you said "care to add a test" [02:02] what test? [02:09] poolie: What error is raised when rlimit killed? [02:09] poolie: can we catch it and fail the job? [02:10] grr [02:10] it's complicated [02:10] * thumper wants to move BufferLogger into lp.testing.logger [02:10] bug archivepublisher uses it [02:10] you may get a MemoryError or you may get a signal [02:10] s/bug/but [02:10] poolie: hmm... [02:10] thumper: How is it different from the other five fake loggers? [02:10] istm it would be more robust to just have the whole process terminate and have a higher level supervisor notice it [02:11] thumper: And why does archivepublisher stop you from moving it? [02:11] wgrant: BufferLogger inherits from FakeLogger and writes into a StringIO [02:11] if you're out of memory there are no real guarantees that python can keep doing nontrivial things [02:11] this may be overly pessimistic though [02:11] wgrant: it seems wrong to import it into a not-testing piece of code [02:11] thumper: oh, right. [02:11] poolie: I'm just concerned that if we kill the job due to memory problems, it'll do it every time [02:12] as it gets retired [02:12] retried [02:12] so... [02:12] we need a way to make sure that doesn't happen [02:12] not sure exactly how though [02:12] unless... [02:12] right at the start of the scan we increment the try count on the job [02:12] and we only try to load jobs with counts less than x [02:13] that seems like a good idea to me [02:14] of course you should reset it when it actually completes [02:14] i thought there would already be something like that in place [02:14] also, what's up with [02:14] rm: cannot remove directory `/var/tmp/bazaar.launchpad.dev': Operation not permitted [02:15] * poolie stops recursing [02:18] * poolie makes schema, and lunch [02:27] poolie: I think I fixed the permission problems with that dir [02:30] Thinking of recursion: bug 692085 is the latest stacking-related joy [02:30] <_mup_> Bug #692085: "maximum recursion depth exceeded while calling a Python object" on self-stacked branch < https://launchpad.net/bugs/692085 > [02:47] mm i saw your comment on that [02:47] Hmm. [02:47] It would be nice if the MP page showed if the prereq was merged. [02:47] By giving it a strikethrough, maybe. [02:47] mm that would be good [02:48] lp could use strikethrough a lot more [02:48] haha, or smallcaps for sarcasm [02:49] i'm adding a new test class [02:49] and it fails with [02:49] ComponentLookupError: (, '') [02:49] i guess because i didn't specify a layer [02:49] what's the cheapest one that would work? [02:49] (the test itself shouldn't need to touch the db or anything) [02:50] * thumper unifies QuietFakeLogger and BufferLogger [02:50] thumper: I have something new in EC2 that uses QuietFakeLogger, so watch out if you're renaming it. [02:50] poolie: if it is complaining about logging in, you should have the DatabaseFunctionalLayer [02:50] wgrant: ack [02:51] wgrant: I'm not renaming it, just deleting it :) [02:51] Hah. [02:51] thanks [02:51] wgrant: and moving it [02:51] thumper: Moving *and* deleting? You are truly skilled. [02:52] wgrant: well, moving BufferLogger and FakeLogger and deleting QuietFakeLogger [02:52] So we are going to be down two fake loggers today. [02:52] Good progress. [02:54] aka "taking it behind the shed, then shooting it" [02:54] It's the best we can do. [03:06] OMG [03:06] just deleted three other loggers [03:06] The one from lp.archivepublisher.tests.util? [03:08] and two others [03:09] The archivepublisher one's death is currently in PQM. [03:09] ah [03:09] ok [03:10] is it /dev/nul or /dev/null ? [03:12] * thumper makes DevNullLogger to express explicit intent [03:17] and another FakeLogger killed [03:22] OMFG three MockLoggers? [03:22] sorry, four [03:23] I didn't think there was quite that many. [03:23] Oh, some doctests define their own. [03:23] Nice. [03:23] me either [03:23] * thumper fetches the machete [03:38] WTF, a Launchpad page load is causing my disk to thrash. [03:39] ... oh. [03:39] Forgot to turn off devmode. [03:39] So it was creating hundreds of OOPSes. [03:49] hooray [03:50] It's tempting to fix that, except, well, JS. [05:34] I welcome all changes to make dev and prod closer [05:34] in principle :P [05:36] Does anyone happen to know which config cesium uses? [05:36] It looks like it might be ftpmaster. [05:36] But that sounds wrong. [05:36] poolie: hi [05:37] poolie: thanks for looking at bug 314507; I'm struggling to understand how the existing code had the behaviour it has, given the test looks for 'OAuth realm' [05:37] <_mup_> Bug #314507: OAUTH server ignores ignores first element in header (rather than realm key)

< https://launchpad.net/bugs/314507 > [05:37] s/test/condiiton/ [05:42] Hm. [05:42] Just had lots of devscripts tests fail in ec2: [05:42] _StringException: Text attachment: garbage [05:42] ------------ [05:42] [] [05:42] ------------ [05:42] Anybody ever seen anything like it? [05:47] That's a strange object to have as gc garbage. [05:50] I mean, it does have a __del__ method, but it carefully only has a reference to a str (a repr() of a LockableFiles instance) and int, so I can't see any reason why it would be in a reference cycle. [05:52] * wgrant pqm-submits. [05:54] === Top 10 Time Out Counts by Page ID === [05:54] Hard / Soft Page ID [05:54] 85 / 343 BugTask:+index [05:54] 70 / 5123 Archive:+index [05:54] 22 / 193 Distribution:+bugs [05:54] 18 / 196 POFile:+translate [05:54] 12 / 122 ProjectGroupSet:CollectionResource:#project_groups [05:54] 10 / 204 Distribution:+bugtarget-portlet-bugfilters-stats [05:54] 7 / 12 NullBugTask:+index [05:54] 6 / 36 MailingListApplication:MailingListAPIView [05:54] 6 / 0 Distribution:+builds [05:54] 5 / 4 Person:+bugs [05:55] Archive:+index is just a big softie, really. [05:55] BFB is currently enabled on edge/qastaging regardless of team memberships. Do we still desire that? [05:56] sure [05:56] edge will become irrelevant when the rt to redirect to prod goes live [05:57] (as far as BFB is concerned) [06:00] lifeless: Well, what I really want to know is if I can delete them from the configs, which lets us eventually remove that code. [06:01] There's a lot of obsolete cruft in the configs because you can't remove things from the schema without first removing them from the prod config. [06:01] Some of this stuff is 4 years old. [06:06] wgrant: doit [06:06] lifeless: Thanks. [06:06] wgrant: the feature flag is sufficient control [06:06] That's what I thought. [06:07] wgrant: OTOH [06:07] wgrant: I'd really like not to have unnecessary config changes with my branch [06:07] which rejiggers everything [06:08] lifeless: Doesn't it only affect the appserver instances? [06:08] * wgrant rereads. [06:08] wgrant: but perhaps you could update my branch for me ? [06:08] wgrant: edge are appservers [06:08] wgrant: I'm not sure if I would be affected or not [06:08] lifeless: Right, but I'm only dealing with the stuff in the root directory. [06:08] wgrant: I'm expressing a 'I don't want more effort' plea, is all. :) [06:08] Your generated configs inherit from it. [06:08] Sure. [06:09] stub: perhaps you could look at why the query in bug 691478 is slow [06:09] <_mup_> Bug #691478: Archive:+index timeouts < https://launchpad.net/bugs/691478 > [06:13] Initial guess, it is horrible old SQLObject code generating horrible queries. All that _prejoin... === almaisan-away is now known as al-maisan [06:17] db_statement_timeout doesn't do anything outside the webapp, does it? [06:17] I've never seen scripts time out. [06:19] Scripts never time out [06:19] We rely on some reaper cronjobs to kill stuff behaving terribly (runtime > x hours, transactions > x minutes) [06:19] So why, then, does germanium's config have a special DB timeout... [06:19] sigh. [06:20] There is one rosetta script they hacked timeouts into I seem to recall (stop gap fix) [06:21] Right. [06:28] wgrant: db_statement_timeout is now usable in other contexts [06:28] wgrant: its likely not actively used, but it can be. [06:38] 5~/win 6 [06:38] Grah. [08:45] good morning [08:45] stub: Can I grab a patch number now for dropping Distribution.lucilleconfig and DistroSeries.lucilleconfig, or must I get it during review? [08:45] Morning adeuring. [08:45] hi wgrant! [08:46] wgrant: patch-2208-35-0.sql [08:46] stub: Thanks. [10:45] danilos: Hi. [10:45] wgrant, hi [10:46] danilos: Are you able to QA that TTBJ change? [10:47] wgrant, I will definitely need some help, but I am not sure even dogfood is sufficient (it doesn't have codehosting set-up if I remember correctly) [10:47] wgrant, I was QAing the easier stuff we got landed first :) [10:47] danilos: Right, it's probably better on staging. [10:48] wgrant, yeah, the important code change is on staging fwiw, though I'll need help to learn how exactly was the error triggered on the build master [10:48] danilos: I have a regression fix a few revs behind it, so I'm somewhat interested in getting it out of the way ASAP. [10:48] danilos: I don't recall myself. Let me check the logs. [10:49] wgrant, ah, makes sense [10:49] wgrant, if I QA the part where the job is generated with appropriate build link, would you be able to QA the build master part? :) [10:50] danilos: Sure. I can easily hack that into the DF DB. [10:50] wgrant, cool, let me go and generate a job on staging then (though, I need to check staging has the revision first) [10:50] Thanks. [10:51] it does, cool [10:55] Ahh, it breaks during failure counting. I see. [10:55] That is approximately impossible to test on staging. [10:55] I will work out how to do it on DF> [10:57] gnight [10:57] Night lifeless. [11:03] danilos: What's a good branch to test on? [11:03] I haven't manually created TTBJs without local codehosting before. [11:11] wgrant, I am using lp:upstart [11:12] wgrant, the thing is that we want this to go through codehosting as well since that's what sets the .build property basically [11:12] wgrant, i.e. it's a kludgy hack which makes use of the branchjob.json_data to store build_id [11:12] danilos: Right. [11:12] I saw the diff. [11:13] You'll verify that it was created properly on staging, and I will manually create roughly the same one on DF. [11:13] I will then reset the builder half-way through the build, hopefully triggering the failure counting code path. [11:13] wgrant, right, sure [11:28] danilos: OK, I can reproduce the issue. [11:28] So we may be in a position to QA it. [11:28] wgrant, cool [11:28] wgrant, I am waiting for a LOSA to run scan_branches on staging, but none seem to be around [11:35] wgrant, fwiw, if the script that jtv wrote to construct TTBJs on dogfood is still there somewhere and it uses the actual TTBJ.create() then you might try using that for QAing your part of it [11:35] danilos: That's what I've used. [11:35] Well, .create() [11:35] Didn't see a script. [11:35] Just used the harness. [11:35] wgrant, right, that should be enough [11:36] wgrant, if you can see a branchjob with job_type=6 you can also look at json_data and if that contains "build_id" then you should be good to QA it all [11:36] danilos: Right. [11:36] I think we have a bug, though. [11:36] Checking. [11:36] Once mawson wakes up. [11:36] wgrant, ok [11:42] danilos: qa-ok from my end, but it doesn't fix the bug. [11:42] danilos: TTBJ.build isn't exposed on the interfaces. [11:42] So I still get ForbiddenAttribute. [11:42] After creating IBJFO['build'] it works fine. [11:42] wgrant, ah, but it was not exposed on any other buildfarmjobold's I checked [11:42] But this is no more broken than it was before. [11:43] wgrant, either I mean [11:44] wgrant, yes, I understand, but I was under the impression that it was not needed since none of the other jobs had it on the interface: would they not hit the same problem? [11:44] danilos: I see IBuildPackageJob['build']... [11:45] wgrant, I guess I missed it then [11:46] danilos: So, as long as it doesn't break the scanner, I think it's qa-ok. Do you want to land a branch adding it to the interface, or shall I? [11:47] wgrant, I wouldn't mind if you do it, since I've got other things to QA as well (12101 which might also block your revision from being rolled out) [11:48] danilos: Sure. Thanks. [11:48] wgrant, btw, can I ask you for some help in QAing another soyuz-affected translations bug? is it possible for you to trigger a rebuild of kde-l10n-sr package on dogfood? [11:49] danilos: Sure. Is this the /-stripping one? [11:49] Or variants? [11:49] wgrant, nope, it's variants :) [11:49] Right. [11:49] wgrant, I can QA the "/" stripping one without soyuz [11:50] danilos: Any particular series? [11:50] wgrant, not really as long as it is recent, just let me know which one it is [11:50] danilos: Do you need some rosetta script run to process the tarball? [11:52] wgrant, doing a cronscripts/rosetta-approve-imports.py should be enough after the custom upload has been processed (and entries added to the queue) [11:52] danilos: OK. It will probably take a while to build, as the DF builders are a little bad. [11:52] I'll let you know when it's done. [11:53] wgrant, cool, thanks [11:54] wgrant, it shouldn't be too bad in that it should only run msgfmt (if that) over all the PO files which is very quick [11:56] danilos: It took 10min on the fast i386 production builder. [11:57] Although that might have been before buildd-manager was fixed. [12:01] Morning, all. [12:06] danilos: DF is being troublesome, but it will eventually bend to my will. [12:07] wgrant, I can see that builders have just picked up the build :) [12:07] danilos: Yeah... it will hopefully even work this time. [12:16] There we go. === Ursinha-afk is now known as Ursinha [12:33] danilos: After a few minutes with a load of 6 and iowait of 99%, process-accepted.py is processing the tarball. [12:33] But it has been doing so for some minutes. [12:35] wgrant, right, that step will take because it has to insert a few hundreds of rows [12:36] Oh good, now apt-get is eating the CPU and disk. [12:36] And I cannot kill it like I can everything else :( [12:43] danilos: The upload is processed. [12:43] I guess I need to run the approval script now. [12:43] wgrant, woohoo, if there are many existing entries in the queue it might take ages [12:43] danilos: I'm about to find out and DELETE them all. [12:44] wgrant, well, no, that would remove the new ones as well :) [12:44] wgrant, you can delete all that are not for source package kde-l10n-sr though [12:44] wgrant, translationimportqueueentry.sourcepackagename is the column you want to filter on [12:44] danilos: Thanks. [12:50] wgrant, btw, can you pass me the generated kde-l10n-sr_4.5.85-0ubuntu1+df1_i386_translations.tar.gz please? (you can just get a libraryfilealias row from the DB for that filename and I can construct a URL) [12:51] danilos: 57545773 [12:51] wgrant, thanks [12:51] OK, I've killed all the other import queue entries. [12:52] rosetta-approve-imports running... hopefully mawson won't singlehandedly thaw the UK. [12:54] danilos: It's going through a lot of transactions, but not logging anything apart from that. [12:55] wgrant, that's ok, it's approving files alright: https://translations.dogfood.launchpad.net/ubuntu/natty/+source/kde-l10n-sr/+imports?start=0&batch=50 [12:55] wgrant, however, the generated tarball is not what I expected [12:56] danilos: Is it worth letting it continue? [12:57] wgrant, not really, it's basically qa-ok in that nothing seems to be broken, but I am just checking what the natty tarball looks like on production [12:58] wgrant, oh, it's actually the same, KDE seems to have changed the layout yet again :( [12:58] danilos: It is midnight here, so I should probably sleep. But if you want anything else done to QA it properly, let me know and I'll do it tomorrow. [12:59] Hah, lovely. [13:00] wgrant, we'll probably have to do it for maverick to see if the new functionality works, but then also to see what the new layout in kde 4.5.85 is and implement that :( [13:00] danilos: Can I reupload maverick's to maverick-updates, then? [13:01] wgrant, sure, that wouldn't hurt, though you should get some sleep as well :) [13:01] * wgrant uploads. [13:02] danilos: -proposed uploads translations too, yeah? [13:02] wgrant, uhm, I have no idea to be honest [13:03] * wgrant checks prod. [13:03] wgrant, I don't think it does though [13:04] danilos: Do I need to rebuild the tarball, or can I just use an old maverick one from prod and hack it into a new upload? [13:04] That will let us bypass the builder. [13:04] wgrant, hum, it might not help since it looks like pkgstriptranslations has changed (and not KDE layout) to strip these translations (though I'll have to check that assumption) [13:04] http://launchpadlibrarian.net/54801590/kde-l10n-sr_4.5.1-0ubuntu1_i386_translations.tar.gz is the one I'm looking at. [13:05] wgrant, yeah, that should work [13:06] wgrant, I didn't know that was an option :) [13:07] danilos: We have direct DB access. *Everything* is an option. [13:07] wgrant, heh, I meant a *viable* option [13:11] danilos: OK, DB hacked. Hopefully process-accepted will see it. [13:11] wgrant, cool, thanks [13:32] danilos: I thought it had failed. Then I looked at the right series. [13:32] https://translations.dogfood.launchpad.net/ubuntu/maverick/+source/kde-l10n-sr/+imports?field.filter_status=NEEDS_REVIEW&field.filter_extension=all [13:32] If it looks OK, I'll run the approval script. [13:33] wgrant, yeah, looks good, we've got 4 times more files [13:33] wgrant, and anyway, the natty is nothing to worry about since upstream didn't include the files either [13:36] danilos: Some stuff is approved now. [13:37] With variants. [13:37] leonardr: could you help me to figure out a test for accessing restricted librarian files via the webservice? http://paste.ubuntu.com/545953/ indicates that a webserive client can't call open() for restricted files [13:38] adeuring: The token restricted librarian does not work in a dev or test environment. [13:38] It needs wildcard DNS. [13:38] wgrant: I know [13:39] wgrant: the point is that I'd like to check at least the URL of a restricted file [13:41] adeuring: you want to see which url it would request, without requesting the url? [13:41] wgrant, /me looks [13:41] leonardr: ;) not exactly, but... [13:41] launchpadlib is making the request and then following a redirect, so you would need to change its redirect handling [13:42] wgrant, can you please kill the script? it's not working [13:42] wgrant, I also forgot to ask if that revision is included in the dogfood codebase? :) [13:42] leonardr: yes, that was my idea too, but I don't see right now a nice way to tell the client to not follow the redircte [13:43] danilos: devel r12107, right? [13:43] adeuring: you can set .follow_redirects = False on the http object, which i think is Launchpad._browser [13:43] wgrant, that's right [13:43] leonardr: ah, cool,I'll try that. thanks! [13:44] danilos: It's there. [13:45] wgrant, ok, thanks [13:48] wgrant, can you please copy lib/lp/translations/model/translationimportqueue.py somewhere for me? [13:48] wgrant, and then I let you go to sleep :) promise ;) [13:50] danilos: http://ppa.dogfood.launchpad.net/translationimportqueue.py [13:51] wgrant, thanks, looks good, I'll have to spend more time with it to see where is it going wrong [13:52] wgrant, thanks for the help today [13:53] danilos: np [13:53] Thanks for QAing your stuff quickly. [13:53] yw [13:54] * wgrant sleeps. === bac` is now known as bac === Ursinha is now known as Ursinha-lunch [14:31] Once a merge request to LP is accepted, what is it waiting on at that point? [14:32] pcjc2: merging [14:32] https://code.launchpad.net/~pcjc2/launchpad/allow-empty-comments/+merge/43449 [14:32] Is that automatic? [14:32] pcjc2: Usually a developer makes sure all tests are run and then submits it to our merge bot [14:32] pcjc2: at the moment, that's done manually by a Launchpad developer [14:33] ok, I think gmb was going to look at it for me [14:33] I'll ping him to see if there were any problems with the test-suite [14:33] I've just commented on the MP [14:33] He was also waiting for my signed copyright assignment, which I sent - might just have got missed [14:34] thanks. [14:35] Once that is in, I have some bug import XMLs I'd like to test on staging - is here a good place to ask about that, or #launchpad. I understand a LOSA needs to look at it [14:36] you need an lp dev before a losa for that [14:50] thanks === Ursinha-lunch is now known as Ursinha [15:48] gmb, deryck: I am having a WTF moment in lp/bugs/mail/newbug.py near line 68. [15:49] gmb, deryck: "if event_creator is not None:" really? What can assign a user a bug and not be a creator in the event? Is there a poltergeist in the system? [15:50] sinzui: hey, two secs to wrap a test I'm on and I'll look. [15:50] thanks [15:55] sinzui: so you can assign yourself, no? [15:55] yes, but I would then be the creator in the event [15:57] deryck, The clause is used to add who assigned you to the bug rational. I was rewriting the message for a bug 670064 [15:57] <_mup_> Bug #670064: Mail notification refers to "bug task" database schema

< https://launchpad.net/bugs/670064 > [15:57] sinzui: yeah, it does seem odd. I would guess there is *some* reason, some corner case, that isn't obvious. Were I trying to find out, I would delete code and run tests and see what breaks. :-) [15:58] There is not test for it [16:02] sinzui: no rational email test? [16:02] rught [16:04] deryck, I think this method I am in does a lot more than I supposed. I was thinking this is about the act of assignment, but the bug could be updated by a bug watch, and you will get an email about this because you are the assignee [16:04] sinzui: I would add a test if it were me then. I'm surprised we don't test that though. I thought I fixed a bug in that and had a test [16:04] deryck, so the creator is only for the assignment case [16:04] * sinzui might be able to test this in a few lines [16:05] no, the assignee is a new recipient. I am still confused [16:07] sinzui: yeah, it's confusing to me too. I would write a test to see what's happening. [16:07] yep [16:08] allenap: see sinzui ^^. is there really no test for rational message? I can look more myself here shortly, just being lazy.... if you know :-) [16:08] deryck, There is one for the creator, not one for the other case [16:09] * allenap reads [16:09] The problem text "a bug task for" is used twice in code and tests [16:09] sinzui: ah, gotcha. yeah, so you could add that pretty easily. nevermind allenap, unping. sorry for the noise [16:10] deryck: np. === beuno is now known as beuno-lunch === deryck is now known as deryck[lunch] === al-maisan is now known as almaisan-away === Ursinha-afk is now known as Ursinha === beuno-lunch is now known as beuno === deryck[lunch] is now known as deryck === benji is now known as benji-lunch === benji-lunch is now known as benji [21:22] don't we have a DocTest matcher somewhere? [21:23] testtools.matchers.DocTestMatcher [21:23] sorry [21:23] DocTestMatches [21:23] ta [22:37] I'm getting an oops trying to update ubuntu's bug reporting guidelines [22:37] "Hard limit of 1000 exceeded." [22:48] oops [22:48] bdmurray: file a bug :-) [23:01] danilos: Hi. [23:03] jcsackett: Still around? [23:04] wgrant: around-ish. :-) [23:04] jcsackett: Bug #118284 is qa-bad... what's the issue with it? [23:04] <_mup_> Bug #118284: URLs ending with a ) aren't linkified properly

< https://launchpad.net/bugs/118284 > [23:05] wgrant there's a condition that introduces an OOPS in the branch. i have a fix branch ready and it passed a full ec2 run, but pqm is bouncing testfixes. or was. [23:05] * jcsackett looks at buildbot [23:06] do we go out of blocked for testfix once a a testfix is submitted, or once that build passes? [23:06] jcsackett: AFAIK as soon as a testfix is submitted. [23:06] jcsackett: It only affects the webapp right? [23:06] correct; when you view bugs with certain comments it will OOPS. [23:07] wgrant ^ [23:07] jcsackett: OK, thanks. [23:07] wgrant: you're welcome. encountering a related issue? [23:08] jcsackett: No, just really really wanting to roll out r12112 to cesium. [23:08] wgrant: i'm resubmitting my fix to pqm. if it passes buildbot before i go to bed, i'll qa it so you can get that out posthaste. [23:09]