[00:03] Purely ooi, and because I'm attempting to copy it for use in my own project, is it correct that db patches don't necessarily land in numerical order? [00:06] Correct. [00:31] wgrant: Does Launchpad work with python2.6/lucid at all for you now? I am now getting the distribute pain on multiple lucid machines, and it looks like it ought to reproduce 100% [00:32] maxb: I forget if I still have everything downgraded. [00:32] * wgrant tries. [00:32] I appear to have the latest version of python-distribute and python-pkg-sources. [00:32] er, *resources [00:33] There is still the zope.interface issue, but that's all I have held. [00:33] Hmm. I wonder if I apt-get install python-distribute, it will work for me [00:33] And I did a tree build (not from scratch, but from a fresh branch) this morning. [00:33] zope.interface issue? [00:33] I don't have python-distribute installed. [00:33] huh [00:34] Builds were failing a couple of weeks ago for me because LP wants zope.interface 3.5.2, while Lucid has 3.5.3. [00:34] how odd. I can't even run bootstrap.py without hacking ez_setup.py [00:34] What's the error you're getting now? [00:34] Right, I was in that situation for a while. [00:34] But it works now. [00:35] PYTHONPATH=ws.find(pkg_resources.Requirement.parse('setuptools')).location) [00:35] AttributeError: 'NoneType' object has no attribute 'location' [00:35] ugh, how mysterious [00:36] Yeah, that one... [00:36] It was never particularly reproducible. [00:37] perplexing. ok. [00:38] maxb, i think gary was working on that issue. he helped me get past that on lazr-js [00:39] I would imagine so. Poor gary gets stuck with all the buildout insanity :-) [00:39] maxb, if you fetch the bootstrap.py from lp:lazr-js it *might* work, though the command line options changed a little bit. [00:39] that could be interesting [00:57] * thumper drags attention back to email jobs [01:24] utilities/ec2 land --dry-run lp:~james-w/launchpad/export-code-import [01:52] mwhudson: do you remember the simple way we should be getting a store now? (in a test) [01:52] thumper: IStore(ModelClass) ? [01:53] ta [01:54] oh FFS, why is it in canonical.launchpad.interfaces... [02:07] Is there a place for all that Foundations stuff to go? [02:13] wgrant: like what? [02:14] thumper: Most of the Foundations stuff still lives in canonical.$NONLOGICALCONGLOMERATIONOFPACKAGES [02:14] wgrant: well, specifics? [02:14] c.l.webapp [02:15] wgrant: most foundational stuff should go into lp.services [02:15] The Storm utilities. [02:15] we should probably have lp.services.storm [02:15] lp.app.webapp maybe? [02:15] Probably. [02:15] Maybe. [02:15] or lp.services.webapp [02:15] and call it something else [02:17] lp.services.AAAAAAAAA [02:18] oops. did I type that in? sorry.... >:) [03:36] gara! [03:37] * mwhudson fights the database restore [03:38] * wgrant is bemused by the existence of lib/canonical/not-used [03:38] It contains only an empty directory -- hctapi, of all things. [03:39] at least the naming is self-referentially correct :-) [03:39] wgrant: i [03:39] 'll review a branch removing it [03:40] spm: heh [03:41] It's also tempting to kill canonical.doap and lp.archivepublisher.library. Both have been untouched and unused for at least four years. [03:45] ✁☹ [03:45] silly team inconsistencies with the rest of the codebase [03:45] .teamowner vs .owner for *everything* elase [03:55] * thumper pushes up pipe 2 of 4 for email job work [03:57] thumper: Well, teamowner is special, given that it defines the type of the object. [03:57] wgrant: yeah, I know [03:58] wgrant: it could just be called owner and have the same impact [03:58] Possibly. [03:59] mwhudson: ref the DB restore; also triggered a nagios alert on "staging in restore mode for > 1 hour"; the actual "outage" part of a staging restore was 62 minutes. ouchies. ie sync new code; build it; (~45 mins) alter _new DB's and re-start, ~ 17mins. [03:59] spm: ugh [04:00] it would be really nice to ratchet make build time down some [04:11] * thumper EODs the 1/2 day [07:59] Is launchpad totally unresponsive (beyond the front pages) for anyone else? [08:00] jtv: WFM [08:01] good morning [08:10] wgrant: for example, do you get https://code.edge.launchpad.net/launchpad/+activereviews ? [08:10] hi adeuring [08:10] ji jtv! [08:14] jtv: I do/can [08:15] hmm... [08:15] I've got no problem with https to our wikis, or to the front page, but I can't access anything useful on LP [08:15] diff browser? and or sniff network traffic? [08:15] * wgrant can too. [08:15] time to check /etc/hosts [08:16] /etc/hosts is fine. :/ [08:16] jtv: is "I can't access anything useful on LP" some sort of reference to the info hosted by LP? or a network access type of comment? :-P [08:16] spm: I can't access code, bugs, or translations pages for any projects I've tried. [08:16] awesome [08:16] try a different browser? [08:16] * wgrant deletes 10KLOC [08:17] wgrant: only 220K more to go! [08:17] spm: heyy, that did the trick! [08:17] so... why doesn't it work in chromium!? [08:18] jtv: seriously? oh my. in that case, flush your cache for starters/restart that browser; and if still no joy; zot cookies as well. if STILL no joy; rename that . dir and start afresh [08:18] jtv: you're the developer. debug it! :-P [08:19] man, I am *so* going to hell.... [08:19] I just did. It was the browser I had the kanban board open in. [08:19] spm: as opposed to the people who have to work with you? I wonder what we're being punished _for_ though [08:19] I'm trying to get launchpad codereviews to work on my own launchpad setup. It currently works on the web and it is sending mails. But how is the replying to the mail part working? [08:19] jtv 2, spm 0. [08:20] snaggen: there's a processmail script that runs that processes incoming email [08:20] spm: so the trick turns out to be, don't keep leankitkanban.com open any longer than you have to. With chromium at least you don't need to restart the browser to undo its damage, so that's progress. [08:21] snaggen: cronscripts/process-mail.py fwiw [08:22] spm: but the reply goes to some mp+1@code.launchpad.dev. So I guess I have to have some mailserver running on that host. But is there some procmail to get the mails in to the database or how does that work? or does teh process-mail.py script access to the mailboxes? [08:22] jtv: I tried chromium, but with the number of tabs I typically have open; it (impressively!) eats even more memory than firefox [08:22] snaggen: process-mail.py looks in a mailbox. [08:23] snaggen: latter; pop3 I think... [08:23] See mailbox.txt. [08:23] wgrant: spm: Thanks for the pointers... [08:24] np [08:24] and on that note. dinner beckons. night all. [09:01] Morning [09:26] morning [09:26] Morning bigjools. [09:27] bigjools/noodles775: What do you think of https://code.edge.launchpad.net/~wgrant/launchpad/show-package-sets-in-queue/+merge/21521? [09:28] wgrant: looks great, my only question is did you look at the difference in the number of queries made? [09:28] that page is very, very sensitive to query count [09:29] i.e. it's close to the timeout limit [09:29] Hm, I thought that was only when accepting stuff. [09:32] it's displaying the page [09:32] It renders in 3 seconds SQL time on edge. [09:32] we fixed the acceptance issue by making it redirect when the txn finishes [09:32] Oh, it didn't before? [09:32] what I am interested in is the increase in queries needed for each row [09:33] it never used to [09:33] Crazy. [09:33] it was fixed just before karmic [09:33] yar [09:39] stub: when all references to a libraryfilealias have gone, the gc deletes the files automatically right? [09:41] bigjools: It adds just one query per source row. [09:41] And it's pretty trivial as well. [09:42] wgrant: ok that's fine then cheers [09:51] bigjools: Do you have a solution to build start time estimation with builder pools? [09:51] wgrant: nope [09:52] wgrant: btw can you get another reviewer to check out your +queue change please, I am sprinting [09:52] soryr [09:52] I've been wondering how to do it for multi-arch builders, and it seems to be a similar sort of problem :/ [09:52] sorry, too [09:52] bigjools: Oh, I intended to. [09:52] yes it's kinda hard [09:52] Just wanted you to OK it. [09:53] cool thanks for asking :) [09:53] I can't see an obvious way to do it apart from a full simulation. [09:53] it's a *estimation* :) [09:55] jtv: The 'building' icon spacing on https://edge.launchpad.net/builders seems a bit broken. Is that related to your changes? [09:56] wgrant: yes, it is. How appropriate it is depends a bit on your perspective: it's the build status, so I'm displaying it as part of the link to the build. It did simplify the code. [09:57] wgrant: in fact this is the subject matter of a UI review that's currently somewhere in limbo. [09:57] jtv: The current spacing is definitely broken. I think the ordering is too, but that's up for debate. [09:58] wgrant: I don't think I changed the ordering... did I? [09:58] It was '( ) Building _blah blah blah i386_' [09:58] It is now 'Building ( )_blah blah blah i386_' [09:59] wgrant: oh, sorry, misunderstood you earlier. That's the part I was talking about all along. [09:59] jtv: Why does it make the code simpler? [09:59] Because it was looking at the build status to generate the icon? [10:00] wgrant: and because it was easier to have a link formatter for builds. [10:01] jtv: Argh, where's the template for that? [10:01] * wgrant cannot find it. [10:01] builder-index.pt [10:03] jtv: Looks like buildfarmbuildjob-current.pt [10:03] ah yes, that's where the link happens now. [10:03] That was another thing: we can't show that icon for a buildless job. [10:04] So that's another way in which it belongs to the build, not the builder. [10:04] So, I think we should do what is done for the rest of the states. [10:04] And just use the currentlybuilding icon if there's a job assigned. [10:04] Regardless of state. [10:04] That's fine by me. [10:04] jtv: did you update the MP with the instructions for demoing it that we discussed? I won't get to it while sprinting, but there are quite a few people around who can do it? [10:04] bigjools: yes, after while. [10:04] Although, I now it'll be a separate MP. [10:05] noodles775: alas, no. Catastrophic system failure & bad telephone line. [10:05] aha. [10:05] Not fun, being negotiated down to 1mbps when you're paying for 12 [10:06] while your main system won't boot [10:06] Ow. [10:06] stub: ok ta [10:06] jtv: Ah, so you already hardcode that icon form non-build BFJs? [10:07] wgrant: I _think_ I did that in an earlier iteration but it didn't seem appropriate. [10:07] It appears to be in devel's buildfarmjob-current.pt [10:08] stub: Question for you re: checkwatches holding transactions open, if you've got a sec. [10:08] sure [10:08] wgrant: there was a lot of exploring to get it all in a sort of minimal working shape... I don't mind moving things around a bit now that we have a working situation. [10:09] Yep. [10:14] henninge: weird... following the pbuilder instructions, when I exit my chroot and login to it again, I've lost my /etc/hosts patch that ntp needed. Wasn't --save-after-login supposed to preserve that? [10:15] jtv: yes, I thought so [10:15] maybe --save-after-exec instead? [10:15] but may --login takes the system files and overwrites them on each login? [10:15] jtv: I have not tried that too many times, I admit. [10:16] jtv: try putting it in your own /etc/hosts ... [10:16] will the chroot talk to my local dns!? [10:17] * wgrant again points out that you can change the NTP host. [10:18] wgrant: you mean in /etc/ntp.conf? Or by running an explicit ntpdate? [10:19] Hmm... ntpdate isn't likely to work if it'll compete for a port with the host ntpd [10:19] Damn Internet is a yoyo. I must be wearing the wrong colour shirt. [10:19] jtv: By altering /etc/launchpad-buildd/default [10:19] http://paste.ubuntu.com/397153/ [10:19] http://paste.ubuntu.com/397153/ [10:19] http://paste.ubuntu.com/397153/ [10:20] http://paste.ubuntu.com/397153/ [10:20] wgrant: ntphost? That's set to pool.ntp.org btw [10:20] wgrant: which is what I'd hope for, I guess [10:20] jtv: Then you shouldn't need stuff in /etc/hosts. [10:20] jtv: that's true [10:22] jtv: I suspect that pbuilder updates the /etc/hosts, /etc/hostname, /etc/resolv.conf on each --login. That's why I was suggesting putting it there. [10:23] wgrant: I have to get some food soon... could you file a bug for the build[er] status icon? [10:23] jtv: Will do. [10:23] thanks. [10:23] noodles775: how about we call wgrant's feedback a UI review? [10:23] Hmm. There is no appropriate project any more :( [10:24] wgrant: yeah... I've been dealing with that by calling it Soyuz. [10:24] I guess the views live in soyuz until somebody bothers to move them, so it can go there. [10:28] mwhudson, are you still around? [10:28] * jml wants to know in how many places we've implemented two-stage kill [10:35] jtv: yeah, it's definitely valuable, so add it to the MP (when you create it, it'll make it much easier for a ui-reviewer to approve it :) [10:38] stub: Sorry; didn't see your reply. So, my question: [10:39] jtv: are you going to fix that icon problem on /builders? [10:39] stub: We know that checkwatches has a habit of holding transactions open whilst it does network stuff, which is Bad. However, we're not sure under what circumstances the transaction killer will come in and stomp on us. As far as we can tell, the first time we access a Storm object a new transaction is started, is that correct? [10:40] (assuming there isn't a transaction already) [10:42] gmb: yes [10:43] stub: So if we have a storm object locally, even if we're not updating it, just accessing its attributes, we're essentially going to hold a transaction open whilst we do network stuff that might require data from that object, correct? [10:43] From the Zope transaction side of things, yes, from the DB side of things, maybe. [10:44] 'maybe' because it will depend if Storm decides it needs to refresh something from the DB for some reason. [10:44] Oh... not accessing the store... just the object... [10:45] 'maybe' on both counts in that case :) [10:45] stub: Hmm. allenap did some testing last night and it appeared that Storm *always* refreshes from the DB if you access anything other than the ID. Is that not necessarily the case? [10:46] stub: I'll forward you the example I wrote. [10:46] I don't know. [10:46] allenap: Ta. [10:46] I used to be the one campaigning to not keep objects alive over transaction boundaries :) [10:49] heh [10:50] why isn't hitchhiker packaged in karmic, dammit [10:52] allenap, gmb: Look like it is refreshing, yes. Same behavior with aborting and committing the transaction. Not sure if this is Storm or Storm+SQLObject compatibility standard. [10:55] def commit(self): [10:55] """Commit all changes to the database. [10:55] This invalidates the cache, so all live objects will have data [10:55] reloaded next time they are touched. [10:55] Looks like Storm default behavior [10:55] Hmph. [10:55] stub, allenap: So, looks like local caching is the way to go. Feels like a bodge, though. [10:55] Running checkwatches in autocommit mode might be the simplest solution. It doesn't seem like the sort of problem you need transactional integrity for. [10:56] gmb: Right, the floor is covered in egg shells. [10:56] stub: That sounds good. [10:56] Also, consider pulling your objects from the slave and casting them to IMasterStore(obj) before making changes. [10:56] stub: That also sounds good. Will the transaction killer not kill transactions from slave stores? [10:57] stub: And, what's the right way to get checkwatches to run in autocommit mode? [10:58] It will, but there is no reason not to use the slave given you are already using possibly out of date information. [10:58] We are less aggressive on the slaves, and can be more lenient if necessary. [10:58] Sorry... IMasterObject(obj)... [10:58] Hmm... it is twisted isn't it. [10:59] Oh... it is also using LaunchpadScript as a base. There is an argument in there you can set. [11:01] isolation=ISOLATION_LEVEL_AUTOCOMMIT argument to run() [11:01] the constant imported from canonical.database.sqlbase [11:02] bigjools: I'd like to fix that, yes [11:04] * gmb -> rebooting for updates [11:07] allenap, gmb: Using the slave would be quite simple. Just install the SlaveDatabasePolicy(), and cast objects you need to write to using writable_obj = IMasterObject(object). [11:08] with SlaveDatabasePolicy(): [...] [11:08] stub: You're awesome, thank you. [11:36] any keen reviewers for https://code.launchpad.net/~jml/launchpad/sftp-poppy/+merge/21627 [11:39] jml: I'll do it. [11:40] allenap, thanks, but I've already swapped with noodles. your comments are still welcome though. [11:46] henninge, wgrant: http://pastebin.ubuntu.com/397192/ :-( [11:47] slave goes through: [11:47] Iterating with success flag 0 against stage INIT [11:47] Iterating with success flag None against stage UNPACK [11:47] Iterating with success flag 0 against stage CLEANUP [11:47] jtv: Your verifySlaveBuildID is probably buggy. [11:47] It's being told to abort. [11:47] * jtv looks at the master log [11:50] wgrant: yup, that looks plausible! [11:50] 2010-03-18 18:13:05+0700 [-] Builder 'bob' rescued from 'bf-test-5': 'BuildQueue 5 is not available: Object not found' === matsubara-afk is now known as matsubara [11:54] wgrant: I rather suspect that ended up being the job id instead of the buildqueue id... [11:54] Did we mention that this stuff was unnecessary complex? :-) [11:54] Yup, it's the job id. [11:57] Heh. [12:04] * jtv has to run off for a bit [12:05] make that quite a bit === jtv is now known as jtv-afk [12:05] danilos: confirmed 539499, fix is on the way. [12:06] jtv-afk, it'd be better if you said "confirmed it's a fluke, fixed it in the wiki page" :) [12:06] danilos: better in what way, given that it's not the truth? [12:06] jtv-afk, better if it was the truth ;) [12:06] wel duh! [12:09] jtv-afk: There is of course the other matter of lp-buildd being unhappy about being aborted during unpack. [12:11] wgrant: who wouldn't be? [12:11] Heh. [12:15] It's *just* *not* *fair*. I tested against this exact problem, and the only way it could have failed to fail is if the job and the buildqueue happened to get the same id. [12:15] I wondered about how the tests managed to pass. [12:21] Yup. Same id. Pure, dumb coincidence. [12:21] I wonder how I'm going to explain this to my reviewer. [12:21] but first, afk. [12:24] noodles775, btw, the doc I was showing you is http://www.muthukadan.net/docs/zca.html [12:24] noodles775, it's an excellent guide to zope component architecture, imho [12:30] the buildbot is broken, is anyone working on it? [12:38] bigjools, http://www.kieranholland.com/code/documentation/nevow-stan/#the-tags-module [12:38] jml: I'm disabling the test that is (apparently) causing the issue. [13:55] noodles775: Did you disable that failing test? db_lp is still in [testfix] [13:56] I mean, I know I can force a build so that I can land a branch, but that seems to be the wrong thing to do. [14:58] stub: Hi. transaction.get()._resources seems to still contain stuff even when isolation is set to auto-commit. Checking with the psycopg connection seems to give me valid information. Do you object if I go back to checking with the raw connection? [14:58] In autocommit mode, there is no point doing the checks at all. [14:59] I have no objections to reverting to checking the raw connection. You probably need to query the IZStorm utility for all stores and check each of them. === matsubara is now known as matsubara-lunch [15:01] stub: Okay, cool. It's useful at the moment, during development, to make sure that tests are valid (i.e. using auto-commit). I also want to prevent regression in the future. [15:02] matsubara-lunch, Ursinha, are we having a production meeting this week? [15:02] rockstar: yes sir [15:02] rockstar: why? [15:02] Ursinha, because I'm wondering where everyone is. [15:03] Oh crap, nevermind. I forgot that the rest of didn't jump on the DST bandwagon yet. [15:04] rockstar: :) === salgado is now known as salgado-lunch === matsubara-lunch is now known as matsubara [16:02] matsubara, stub, check, gary_poster, rockstar, bigjools, sinzui, allenap: hey! what about a production meeting now? #launchpad-meeting @ Freenode [16:02] Hi [16:02] Ursinha: :-) matsubara standing in for me today [16:02] thanks gary_poster :) [16:02] Ursinha: soyuz is sprinting, can you ping me if you need anything [16:03] sure bigjools, thanks [16:03] thanks Ursinha === leonardr is now known as leonardr-lunch === salgado-lunch is now known as salgado === gary_poster is now known as gary-lunch [16:47] gmb: As you've probably figured by now, I disabled the test with the testfix on devel only. [16:47] (missed your message earlier). [16:49] sinzui, in lib/canonical/launchpad/emailtemplates/email-processing-error.txt there is a URL ("https://help.launchpad.net/EmailInterface") that is to a non-existent page. I can just fix it to include "Bugs", as in "https://help.launchpad.net/Bugs/EmailInterface", but the text around it implies that it's about more than bugs. Are there any other email interfaces to Launchpad? [16:49] deryck: (if you know the answer to above, feel free to chime in) [16:50] kfogel: There is a page about review email command [16:50] sinzui: thanks [16:50] https://help.launchpad.net/Code/Review/#Email%20interface [16:52] frustrating that search (https://help.launchpad.net/HelpOnActions?action=fullsearch&context=180&value=email+interface) doesn't find that page! [16:55] I only search google to find our content. moin suck [16:55] kfogel: https://help.launchpad.net/Code/Review [17:01] sinzui: thanks. see above; I found it [17:45] is https://code.edge.launchpad.net/~james-w/launchpad/code-imports-use-ibranchtarget/+merge/21651 too big for a single branch? [17:48] * james_w thinks of a better way to do it anyway === leonardr-lunch is now known as leonardr [17:51] james_w, it's probably not too big for a branch like that. [17:51] james_w, you might want to arrange something with the reviewer though. [17:51] I dropped the makeAnyCodeImport as makeCodeImport means the same thing essentially [17:51] james_w, ok. [17:51] if we want the distinction then I can do it as a followup branch [17:52] james_w, yeah. === gary-lunch is now known as gary_poster [18:00] ok, less than half the size, much better [18:24] jml: hi [18:24] mwhudson, hi [18:25] aaaargh. Is there no way in the help wiki to do a relative link to an anchor on a different page? E.g., "[[Code/Review/#Email interface|foo]]" ? It will come out as "https://help.launchpad.net/Code/Review/#Email+interface", which will not work. But if you put in %20 for the space, it will escape the % and you'll get %2520. [18:26] kfogel, don't know, I'm afraid. #moin will probably be able to help though. [18:27] jml: I'm just adding a manual anchor "<>" and linking to that. Harrumph. [18:28] jml: you pang [18:28] mwhudson, I did? [18:28] mwhudson, hmm. let me consult my oracle. [18:28] jml: about 8 hours ago, it has to be said [18:28] mwhudson, oh yes. in how many places have we implemented two-stage kill? [18:30] mwhudson, because I did a thing. [18:31] mwhudson, https://code.edge.launchpad.net/~jml/launchpad/sftp-poppy/+merge/21627 [18:31] mwhudson, guess why the librarian was always taking 5s to shut down? [18:34] jml: I don't think tachandler can import from lp [18:35] james_w, why not? [18:35] I'm just finding the bug [18:35] it's used on machines that don't have the full lp source tree available [18:36] james_w, !!! [18:36] jml: um, did it send a signal then wait 5 seconds to see if it had died yet? [18:36] there should be a comment in tachandler saying this [18:36] mwhudson, it sent a signal, didn't allow the zombie to be reaped, then kept polling every .1s for 5s to see if the zombie had gone yet (which it won't have) [18:36] * mwhudson cries [18:37] there should be a comment in lp.services.osutils and maybe a unit test [18:37] or we could just fix whatever bug it is that forces us to duplicate code this way. [18:38] the issue is that tachandler is used on the buildds [18:38] I mean, exactly how many more things do we need other than the vast size of our code base to block us from having a well organized code base [18:40] mwhudson, so tachandler should be in a separate tree then, I guess. [18:40] there is a difference between what we want and what we get :/ [18:41] mwhudson, indeed. [18:42] jml: bzr diff -r 10137..10137.2.2 [18:42] jml: as a hack to get this landed, you could define the functions in tachandler, but still put them in lp.services.osutils.__all__ [18:42] mwhudson, yeah, that's what I was thinking [18:42] mwhudson, although, it's running through ec2 test right now [18:43] is there a test that will block this landing? [18:43] unlikely [18:44] i [18:44] :( :( :( [18:45] i'm not really sure how you could write one, i guess you could execute a script that goes "import _pythonpath; from daeamons import tachandler; import sys; assert 'lp' not in sys.modules" [18:45] well, it's not even clear to me what the constraints are for the buildd [18:45] or what bits of launchpad it actually uses. === Ursinha is now known as Ursinha-food [18:47] jml: i believe you are physically close to people you can beat into telling you [18:47] mwhudson, yes. I might have to do that. [18:47] mwhudson, anyway, aside from that [18:47] i think the only think it uses outside canonical/launchpad/build is tachandler though [18:47] mwhudson, how many two-stage kill implementations do we have in Launchpad? [18:47] s/think/thing/ [18:47] I guess at one point it may have been desirable to stop people catting the LP tree while their package was building [18:48] james_w: also, launchpad doesn't install so well on HPPA [18:48] jml: um, at least two i guess> [18:48] ? [18:49] mwhudson, where's the other one? [18:49] jml: twistedsupport [18:49] oh of course [18:49] * jml looks [18:51] mwhudson, btw, did you see the dependency graph? [18:51] jml: only enough to notice that eog is an awful svg viewer [18:54] mwhudson, use dotviewer from pypy [18:57] jml: if you insist [18:59] mwhudson, pypy is a python interpreter written in python, it's pretty cool [18:59] mwhudson, :P [18:59] heh heh [18:59] mwhudson, Although see their current topic, "PyPy is a actually a visualization project, we just build interpreters to have interesting data to visualize" [18:59] :) [19:00] #pypy has a history of nicely surreal topics [19:00] jml: it is entertaining how lp.testing is in the centre [19:04] mwhudson, yeah. also canonical.launchpad needs to die. [19:05] well yes [19:09] man this buildd thing has made me angry === bjf is now known as bjf-afk === bjf-afk is now known as bjf === noodles785 is now known as noodles775 [19:24] intellectronica: ayt? === Ursinha-food is now known as Ursinha [20:15] thumper: hello? === salgado is now known as salgado-brb [20:38] jml: perchance still around? [20:48] morning [20:51] morning thumper [20:52] hi james_w [20:52] thumper: could you perhaps provide a little SQL help? [20:53] sure [20:54] CodeImportSet.composeQueryString() assumes a Product, but that will no longer always be true in my branch [20:54] I need to rewrite the query to allow for using SourcePackage as well [20:55] ok === salgado-brb is now known as salgado [20:55] james_w: I'm just looking at your code import target branch [20:55] hmm.. seems to have gone [20:55] great [20:56] I keep screwing up the initial settings and forgetting things like prerequisite branches [20:56] :) [20:56] james_w: can you paste me a link? [20:56]