[00:08] how warm / cold is it in Dallas? [00:08] should I pack warm clothing? [00:11] thumper: I'd recommend a winter coat [00:11] It's 2 or 3 degrees (Celcius) at the moment I think [00:15] crap [00:15] jelmer: I take it the hotel is warm enough? [00:15] thumper: It's going to vary. [00:15] thumper: It looks like 16-17 early next week. [00:15] But 1 tomorrow. [00:15] And 4 later next week. [00:15] hmm... [00:15] You'll need to take roughly everything. [00:16] thumper: the hotel is nicely warm. At least they don't have the airco on "freeze" mode like in some places. [00:16] wgrant: when are you heading out? [00:17] thumper: Sunday. [00:18] You? [00:20] same [00:27] hello! i'm trying to fix https://bugs.launchpad.net/bzr-hg/+bug/518510 (since it's blocking something else i'm working on) and i'm trying to get my launchpad instance to import a mercurial repository so i can reproduce the bug locally. i don't think that functionality works on dev instances of launchpad. does anyone have any tips on either: how to better debug this issue or how to get my dev instance of launchpad to also support runn [00:27] <_mup_> Bug #518510: assertionerror in _find_most_recent_ancestor < https://launchpad.net/bugs/518510 > [00:28] lavid: You shouldn't need to run a local Launchpad instance to test that. [00:29] huwshimi: hello & welcome! [00:30] wgrant: fair enough. i guess i was hoping to get a better idea as to what's happening further up the stack trace. how'd you recommend tackling this? [00:39] lavid: install bzr-hg as a plugin in bzr [00:39] lavid: then try to clone a mercurial branch and doign incremental pulls into it [00:40] I am trying to provide a precise recipe, but my machine is being objectionable. [00:40] One of the key things to the bug appears to be that it only happens on incremental pulls that import new revisions. [00:41] jelmer: cool. thanks. any tips for running the bzr-hg plugin via eclipse or some other visual debugger? [00:41] lavid: Setting BZR_PDB=1 will open a pdb interactive debugger for you when an exception occurs in bzr [00:42] I don't have any experience with Python in Eclipse, sorry [00:42] hi jelmer, wgrant [00:42] jelmer: ooh, tasty! thank you! [00:42] 'evening poolie [00:43] Morning poolie. [00:43] Or evening, I guess. [01:00] see you all in a bit. [01:01] * jml is off for stuff. [02:23] oh FSF [02:23] FFS [02:23] make build dying on OSError: [Errno 4] Interrupted system call [02:23] still === Ursinha is now known as Ursinha-afk [02:25] thumper: Didn't it work on Friday? :/ [03:10] wgrant: it did [03:11] wgrant: so it seems to be temperamental [03:12] thumper: Yay. [03:12] thumper: It wasn't a parallel make? [03:13] I don't think so [03:16] thumper: Does it die on the .join()? [03:16] wgrant: no, times out [03:17] wgrant: actually, yes [03:17] File "./utilities/create-lp-wadl-and-apidoc.py", line 86, in main [03:18] sorry, didn't look enough up the stack [04:37] wgrant: any idea how to get around the make problem? [04:37] I can't make run [04:37] :( [04:37] which makes it hard for me to test this thing === lavid is now known as lavid_ [04:41] thumper: You could hack it to not use multiprocessing. Or use multiprocessing, but serially. [04:41] It is tempting to debug, except for the whole POSIX signal fuckedness. [04:43] * thumper loses the will to fix it on a Monday afternoon and calls it a day [06:06] === Top 10 Time Out Counts by Page ID === [06:06] Hard / Soft Page ID [06:06] 63 / 293 BugTask:+index [06:06] 36 / 4408 Archive:+index [06:06] 21 / 294 Distribution:+bugs [06:06] 13 / 112 ProjectGroupSet:CollectionResource:#project_groups [06:06] 12 / 177 POFile:+translate [06:06] 12 / 0 ProjectGroup:+milestones [06:06] 8 / 12 NullBugTask:+index [06:06] 7 / 201 Question:+index [06:06] 6 / 13 Branch:+index [06:06] 5 / 4 Cve:+index [06:08] Does anyone happen to know why Storm would be doing lots of 'SELECT 1 FROM foo WHERE foo.id=bar' in a test after invalidating the store? [06:08] It doesn't seem to do that in production. === almaisan-away is now known as al-maisan [08:48] good morning [09:06] Good morning ! === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === matsubara is now known as matsubara-lunch === henninge_ is now known as henninge [14:09] benji: good morning [14:10] morning, julius maximus === yofel_ is now known as yofel [14:10] heh, never been called that before [14:10] I'm still struggling to get my dev environment fixed :( [14:11] I downgraded launchpadlib to 1.6.5 (which is the last version I had an egg for) [14:11] and the librarian won't start up in tests still, I get loads of "No handlers could be found for logger "librarian"" [14:12] hmm, that doesn't sound related to launchpadlib; I can't imagine why it'd be screwing with the librarian's logger [14:13] me neither [14:16] benji: can you do qa for bug 686690? [14:16] <_mup_> Bug #686690: 1.8.0 breaks login_with() API compat with existing credentials files, and forces keyrings

< https://launchpad.net/bugs/686690 > [14:18] jcsackett: martin has confirmed the behavior, so i think we are ok [14:18] leonardr: ok, so i can mark that as qa-ok then? [14:19] jcsackett: i'm about to upgrade launchpadlib in launchpad again. let's mark it qa-ok after i test that [14:19] leonardr: sounds good. thanks. [14:22] gmb: can you do qa for bug 686690? [14:22] <_mup_> Bug #686690: 1.8.0 breaks login_with() API compat with existing credentials files, and forces keyrings

< https://launchpad.net/bugs/686690 > [14:22] sorry, gmb, bad copy paste. i meant bug 683672 [14:22] <_mup_> Bug #683672: Bug description in verbose footer should be indented by 2 spaces

< https://launchpad.net/bugs/683672 > [14:26] jcsackett: I will be doing so shortly; just waiting for deryck to get up-and-running with the staging mailbox. [14:26] gmb: cool, thanks. [14:50] benji: at what point is the keyring doing stuff it should not at import time? When it loads the backend, or something else? [14:50] I made a keyringrc.cfg to force an alternative backend and it still goes bang [14:52] bigjools: it's certainly doing backend selection at import time, but it may well be doing other things; did your bang look related to the SIGCHLD stealing or something else? [14:52] benji: yeah, same EINTR stuff [14:52] let me look at the keyring code and see where it's doing that registration [14:53] I forced anUncryptedFileKeyring backend [14:53] benji: I'm just trying to hack anything in to get me unblocked :( [14:55] bigjools: hmm, I don't see anywhere that it explicitly registers a SIGCHLD handler; wait, didn't you say you downgraded to a pre-keyring launchpadlib? if so, keyring shouldn't ever be imported [14:57] benji: I've gone back to the latest lplib since the other once had that logger problem [14:57] well, the librarian problem [14:57] ah, ok [14:57] the sigchld is registered somewhere in PyQt4 [14:57] I figured. :( [14:57] according to my strace anyway [14:58] it's all so frustrating :/ [14:59] bigjools: I think you can hack your launchpadlib to never import the keyring module (just comment out the import) and your LP will work (some tests will fail) [14:59] ok, never thought of the obvious :) === matsubara-lunch is now known as matsubara [15:01] benji: ok, that reduces me back to the No handlers could be found for logger "librarian" [15:01] maybe if I bang my head up the wall a bit more....! [15:09] gary_poster: around? [15:09] who is release manager this time? [15:09] i ought to know this [15:09] lifeless: I am [15:09] mwhudson: jcsackett [15:09] jc I thought [15:09] gary_poster: thanks [15:09] gary_poster: hi; thanks for fast tracking the oops prefix updates [15:10] lifeless: hi, np. [15:10] jcsackett: which revno is being released today? [15:10] gary_poster: I'm wondering when that goes live (and if it will mean that the oops reports mailed to the list change accordingly) [15:10] ah, db-stable 10119 [15:11] lifeless, the intent is today, and yes. [15:11] mwhudson: huh no [15:11] we deploy from stable [15:11] https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html [15:11] mwhudson: rev 12177 [15:11] mwhudson: and we're blocked on rev 12167 [15:11] jcsackett: ^ [15:11] ah cool [15:12] well, not the being blocked part [15:12] but that means the fix i care about (and just qa-ed) is going to be released [15:13] mwhudson: we're deploying on the 12th, not the 10th. did i say the 10th in an email? [15:13] errr [15:13] no, [15:13] * jcsackett has written a lot of emails lately, very well could have goofed. [15:13] can i blame jetlag? [15:13] :-) [15:13] mwhudson: yes you can. :-) [15:13] jcsackett: we ar edeploying from stable, right ? [15:13] gary_poster: sweet, thanks. [15:13] np [15:14] lifeless: correct. [15:14] jcsackett: great, my heart can start beating again [15:14] we need to deploy at least through r12177 on stable. [15:15] 10119 was the db revision we qa-ed and merged on friday, lifeless. [15:15] jcsackett: thanks [15:15] np. [15:16] gary_poster: can you spare me a moment please? I've worked around the keyring problem for now, but still have a problem with the librarian in tests :( http://pastebin.ubuntu.com/552492/ [15:16] benji, leonardr, can either of you help bigjools ? [15:18] gary_poster: I can take a look; not done much with the librarian yet though [15:18] bigjools: thats weird [15:18] benji: ack. Lemme check in with the other pending pings and I'll see what needs to be handled [15:18] benji: I would have asked you but you were busy fixing the keyring :) [15:18] bigjools: when did this start? [15:19] lifeless: once I worked around the keyring problems just now [15:19] also I hate python logging, I truely do [15:19] I've not had a working dev environment since Thursday last week [15:19] 2011-01-10 20:30:34+0530 [-] No handlers could be found for logger "librarian" [15:19] bigjools: it's nice to be loved [15:19] lifeless: I share your hate [15:19] -not- a sane failur emode [15:20] bigjools: do you have a /var/tmp/fatsam.test/librarian.pid ? [15:21] lifeless: ignore that, it's a relic of the earlier failure [15:21] ok [15:21] I delete fatsam each run [15:21] ok [15:21] so its leaving the pid file when it fails to start? Could you file a bug on that - we should fix that too [15:21] * bigjools tries again [15:22] didn't we discuss that some time ago and it was hard to fix for some reason? [15:22] ARGHHHHH [15:22] it's working now [15:22] dunno; the code is a lot cleaner than it was it should be fixable. [15:23] there was a librarian left running [15:23] deleting old ones on start is problematic; dealing with a failed start is simpler [15:23] thought I'd killed it [15:23] however it sounds like it was behaving correctly ;) [15:23] define correctly :) [15:23] not connecting you to an existing librarian on the statically defined port [15:24] however the diagnostics are terrible - please do file a bug that it didn't manage to tell you [15:24] roger [15:24] bigjools, benji, sorry, I misunderstood thought the librarian thing was a webservice/keyring thing [15:25] but so anyway, that's "resolved" enough for benji to get back to what he was doing before, bigjools [15:25] ? [15:25] it might have been :) [15:25] gary_poster: in all fairness, it might have been! I had no idea what was up. [15:25] heh [15:25] gary_poster: yes, thanks, I've commented out the keyring import for now [15:27] lifeless: to confirm, what did you expect it to do that it was not doing? Telling you about an existing librarian, or something else? [15:27] bigjools: ack, and that solved it, or...something solved and you are moving on? [15:28] gary_poster: "worked around" would be the right phrase :) benji is fixing the keyring code to not do stuff when it's imported [15:28] hi flacoste [15:28] bigjools: lol, ack, right. thanks [15:29] gary_poster: I'm gonna have to do some work now it's fixed. Darn. [15:30] bigjools: lol, sorry :-) [15:30] :) [15:45] hi lifeless === flacoste changed the topic of #launchpad-dev to: Launchpad Development Channel | New starters: huwshimi | 11.01 Release Week 3 | PQM in RC for devel | RM: jcsackett | firefighting: - | Get the code: https://dev.launchpad.net/Getting [15:47] sinzui: around? [15:56] bigjools: yes [15:57] sinzui: when you have a moment, it's not urgent, but I'd appreciate your feedback on the mockups for the new +addseries page and its new +initseries, see https://dev.launchpad.net/LEP/DerivativeDistributions#Mockups [15:58] bigjools: thanks [15:58] sinzui: thank *you* [16:05] benji: are bugs 651852 and 669701 qa-able? [16:06] jcsackett: looking [16:06] thanks. [16:07] /win 70 [16:08] jcsackett: both are; 651852 is now marked qa-ok, but 669701 will have to be QAed by someone that has write permission for feature flag rules, a LOSA perhaps [16:09] benji: dig. === Ursinha is now known as Ursinha-lunch [16:09] thanks. [16:18] /win 70 [16:18] bah === beuno is now known as beuno-lunch [16:29] wgrant: *all* oops/timeout are 'high' [16:29] wgrant: per ZeroOopsPolicy [16:54] jcsackett: Bug 683672 is now qa-ok. [16:54] <_mup_> Bug #683672: Bug description in verbose footer should be indented by 2 spaces

< https://launchpad.net/bugs/683672 > [16:54] gmb: thanks! [16:55] lifeless: we have a problem, project can only be part of one project group [16:56] which means that lazr projects cannot be part of both lazr and launchpad [16:56] we could make them all part of launchpad [16:56] maybe except lazr-js [16:56] and even then [17:00] flacoste: ah, yes we should fix that ;) [17:00] lifeless: i'm moving all of them to launchpad, leaving a URL to the other lazr project [17:00] anything lazr is vapourware [17:00] so not really worth separating out === deryck is now known as deryck[lunch] === benji is now known as benji-lunch [17:03] flacoste: ah [17:04] flacoste: I fear that if we don't have a brain-dead-simple way of querying all the bugs that lp interrupt squads should care about, that ones outside the default-set will get starved [17:04] lifeless: i agree [17:04] that's why i'm moving all the projects which we maintain to launchpad-project [17:04] \o/ [17:05] except storm [17:05] which we don't maintain :) [17:05] right [17:05] and when it affects us [17:05] we usually have a bugtask on launchpad for it [17:09] lifeless: all done [17:12] gaaarh [17:12] the list of projects is cached I guess [17:12] flacoste: what about launchpad-buildd? [17:12] lifeless: it is [17:12] :( [17:12] bigjools: already there i think [17:12] * lifeless embugginates [17:12] 'launchpad auto build system' [17:13] flacoste: well generally I mean, it wasn't folded into launchpad like the others, do we intend to keep it separate? [17:13] (given the bug about splitting out the code from the tree) [17:13] bigjools: being part of Launchpad project is orthogonal to having a separate tree [17:14] bigjools: wait a moment [17:14] a) yes, it should be a separate project [17:14] b) it should be part of the launchpad-project so that its bugs are part of the overall bugs we need to fix [17:14] list [17:14] ok [17:14] c) we should move it out in a separate code tree [17:14] sounds reasonable to me [17:14] like lazr.restful or wadllib [17:15] * flacoste goes to lunch [17:35] flacoste: so, I can bug triage now [17:35] ? === Ursinha-lunch is now known as Ursinha === beuno-lunch is now known as beuno === deryck[lunch] is now known as deryck === gary_poster is now known as gary-lunch [18:27] lifeless: yep === al-maisan is now known as almaisan-away [19:27] matsubara: Ursinha: I am looking a bug 687465. The code thinks it is reporting oopses, but I never see them in oops reports. Can you confirm that production mailman is generating oopses and we rsync them [19:27] <_mup_> Bug #687465: add oops reporting to the xmlrpc queue runner

< https://launchpad.net/bugs/687465 > [19:27] sinzui, /me looks === gary-lunch is now known as gary_poster [19:32] sinzui, which machine does production mailman runs one? [19:33] matsubara: I do not know. Chex do you know ^ [19:37] matsubara: forster [19:42] sinzui, there's a /srv/launchpad.net-logs/scripts/forster/mailman-xmlrpc dir in devpad and the last oops dir there is 2009-10-06. I'm trying to find a newer mailman-xmlrpc dir in devpad [19:42] Chex, thanks [19:50] sinzui, ./staging/asuka/mailman-xmlrpc [19:50] ./scripts/forster/mailman-xmlrpc [19:50] ./qastaging/asuka/mailman-xmlrpc [19:50] those are the dirs where I'd expect mailman oopses to show up [19:51] and by mailman oopses I mean those with MMX prefix [19:51] or QSMMX for qastaging nad SMMX for staging [19:51] matsubara: I think the product config says the oopses start with a c [19:52] matsubara: as I noted in the bug, I found bugs in the database there were never in the daily reports [19:55] sinzui? [20:02] sinzui, the reason OOPS-1795C1521 doesn't appear in the report (https://devpad.canonical.com/~lpqateam/oops-summaries/lpnet-2010-11-30.html#informational-only-errors) is because it's hidden amongst the 2858 error of the same kind. the report just show a sample of 10 [20:02] it's very likely OOPS-1795D3104 doesn't show up for the same reason [20:02] :( [20:03] hi Sinzui, I've provided updated information on the my LP bugs you triaged earlier [20:03] matsubara: what can we do to ensure mailman oopses are not information-only-errors [20:04] pcjc2: I dedupped the bug [20:04] well I undid regardless of that word I just mad up [20:04] made [20:04] * sinzui gives up [20:05] cool - was a little frustrating to see them closed down so quickly given a LP dev had asked me to file them [20:05] sinzui, why do you think OOPS-1795C1521 is a mailman oops? [20:06] Is the canonical-identity-provider code available to take a poke at? [20:06] or is that a closed-source part of LP? [20:07] matsubara: the TB: Module lp.registry.xmlrpc.mailinglist, line 200, in getMembershipInformation [20:08] sinzui, OOPS-1795C1521 has no traceback information and is the informational only oops [20:08] matsubara: since mailman is an antonymous system, most of its issues will appear related to MailingListAPIView [20:08] sinzui, OOPS-1795D3104 is not an informational only oops [20:08] https://lp-oops.canonical.com/oops.py/?oopsid=1795D3104 [20:08] has a tb [20:09] yep, and that one is not informational only [20:09] * pcjc2 found the identity-provider branch [20:09] matsubara: as for https://lp-oops.canonical.com/oops.py/?oopsid=1795D3104, Chex saw it in mailman's log we know the runner reported it [20:13] matsubara: I have the death trail of Mailman's failure in November. There are a lot of oopses it reported hours before it's death http://pastebin.ubuntu.com/552570/ [20:15] sinzui, OOPS-1795D3104 is a timeout. it didn't show up in the report because there were a total of 218 unique timeouts on that day and only 15 showed up in the report https://devpad.canonical.com/~lpqateam/oops-summaries/lpnet-2010-11-30.html#time-outs [20:18] matsubara: okay. We may need to think about that because mailman thinks it is being DoSed [20:18] sinzui, so the runner tried to get_subscriptions but LP was timing out on that call and recording each oops correctly [20:18] I'm trying to login to the staging server, but it won't auth with the API provider [20:18] Sorry - OpenID provider... [20:19] Does the staging server sync the user database for production regularly? The user I'm trying to use is for a robot, and I created the account only a couple of days ago [20:19] matsubara: since we are getting the oopses. I will change mailman to send the 503 and 504 information as oopses so we see mailmans conclusion that life has no meaning and kills itself [20:20] pcjc2: I do not have an answer. SSO is not launchpad and we do not control it. Canonical's ISD group does and they can set Lp staging to use their staging version of SSO. We do not know the state of their DB [20:21] ok I hadn't appreciated the division there [20:21] pcjc2: try qastaging. The DB is many weeks old, but it does using production SSO (login.ubuntu.com) [20:22] is that LP database ok to screw with arbitrarily? [20:22] (I'm writing a robot, and don't want to mess things up where I shouldn't!) [20:22] pcjc2: as long as there is a login.launchpad.net, no one will know there that they have two separate systems [20:22] pcjc2: you can do what ever you need. The DB will be restored in a week or two [20:22] Is there a political divide? [20:23] Awww, mwhudson's cloak changed :-( [20:23] ok - will create some bugs against our project and play with them [20:23] only 8 months later or whatever [20:24] sinzui, sounds sensible. at least that way we'll see those reported as XMLP kind of oopses, right? [20:24] pcjc2: there are different teams [20:24] ValueError: qastaging is not a valid URL or an alias for any Launchpad server [20:24] pcjc2: we see eye to eye but we (effectively) cannot change stuff in that code [20:24] pcjc2: No. We do not want to be in the OpenID biz. Users want more from it than we do. So gave it to Ubuntu. We want to allow users to login using any OpenID service. The problem is that setting up a domain that looks like launchpad, bug does not work like Launchpad was a mistake [20:25] credentials.get_request_token(web_root="qastaging") <-- is there a URL I can use there instead? [20:25] sinzui: I'm glad you want to let logins from any OpenID service [20:25] We just migrated our bugs and stuff to LP, and some of our users wanted to use existing OpenID logins etc.. [20:29] pcjc2: I use launchpadlib.launchpad.Launchpad.login_with('testing', 'https://api.qastaging.launchpad.net/') === almaisan-away is now known as al-maisan [20:40] needed to drop the "api." for the credentials.get_request_token(web_root="https://qastaging.launchpad.net"). but it worked [20:40] Thanks === matsubara is now known as matsubara-afk [20:43] * pcjc2 does find the distinction between loging on to LP and loging on at login.launchpad.net a little amusing [20:43] but it seems less strange to me as I know vaguely how it works ;) [20:44] I wish LP had an option to let me masquerade as another user [20:44] (my robot), rather than forcing me to log off all the way [20:45] https://launchpad.net/~gpleda-launchpad-robot [20:45] Would also be nice to have somewhere that I (or the developer team) "own" that user account [20:45] There is a very old bug suggesting that we provide I way to become another user or change privileges temporarily. I do not think we plan to work on it any time soon. [20:46] sounds like many of the feature requests for our project.. nice idea.. no time ;) [20:46] (or other priorities) === Ursinha is now known as Ursinha-afk [20:55] Is there a schedule for when DB updates to staging / qastaging get made? [21:04] OOPS-1836QS24 [21:04] Can someone check that for me? [21:05] Getting a HTTP Error 404: Not Found for bug.bug_tasks on this bug: [21:05] https://bugs.staging.launchpad.net/geda/+bug/693991 [21:05] <_mup_> Bug #693991: compiz crashed with SIGSEGV in nux::IOpenGLSurface::UnlockRect()

< https://launchpad.net/bugs/693991 > [21:06] is there an easy way to run ec2 tests with a different version of dependencies? say if i'm working on changes to a lazr lib? i can't find anything in the wiki. [21:07] pcjc2: hasn't mirrored yet [21:07] jcsackett: edit your versions.cfg [21:08] and setup.py [21:08] ec2 test is meant to propogate that [21:11] lifeless: i may be (read: probably am) wrong, but it looks like that requires existing version numbers. is there a way to use something that only exists as a branch i'm working on? [21:11] i see my earlier question wasn't clear. my apologies. [21:11] jcsackett: once you've added it to the download cache, its fine [21:12] lifeless: ah! so i add the tarball or what have you to that, and ec2 pulls info from there? i didn't realize. that's cool. [21:12] its documented on ze wiki I think [21:12] you add the tarball, bzr add, bzr commit [21:12] OOPS-1836QS42 ? [21:13] pcjc2: also won't have syncted yet :) [21:13] lifeless: dig. thanks! [21:13] what is the timeframe? [21:13] pcjc2: generally 15 minutes IIRC [21:13] gah, I'm being a tool... [21:13] I filed the bug on staging, not qastaging [21:31] wgrant: are you awake yet? [21:36] pcjc2: hmm, so [21:36] oops 1836QS24 [21:36] how did you generate that oops ? [21:36] from the API, accessing a non-existant bug [21:36] hmm [21:36] shouldn't OOPS [21:36] Here is a real one which is annoying me: 1836O1543 [21:37] what was the API call you made ? [21:37] OOPS-1836O1543 (this was jut now, so need to wait a bit) It is a bug search timing out [21:37] sure [21:37] so, QS24 [21:37] what does the code look like that triggered it ? [21:38] lifeless: hello. where are you? [21:38] B [21:38] >>> from launchpadlib.launchpad import Launchpad [21:38] >>> from launchpadlib.credentials import Credentials [21:38] >>> credentials = Credentials.load_from_path ("commit_robot_qastaging.credentials") [21:38] >>> launchpad = Launchpad(credentials, service_root="https://api.qastaging.launchpad.net") [21:38] >>> bug=launchpad.bugs[123456789] [21:38] >>> print bug [21:38]