[00:00] james_w: are you wanting me to land ~james-w/launchpad/code-imports-use-ibranchtarget ? [00:38] How does the webservice versioning work? Are we really committed to maintaining the full 1.0 API for 5 years? [01:01] wgrant: ask leonard [01:01] I'm not sure how it works [01:06] i've been wondering about that [01:06] maxb, hmm. what did I do wrong to make that happen? [01:06] maxb, I was doing what jelmer told me to. [01:06] jml: dch adds -ubuntu to the version number by default [01:07] ahh, I see. [01:07] It seems like only a tiny fraction of the API is actually going to be used by anything. [01:07] so what should I do to correct my mistake? [01:07] And it's going to be rather prohibitively model-change restrictive. [01:07] jml: Have you uploaded it to the PPA yet? [01:07] wgrant, yes, I have. [01:07] Ah. [01:07] You can't. [01:08] Unless you increment the version again pointlessly. [01:08] ok. [01:08] wgrant, but say I had a very good reason for incrementing the version, I could do that and remove the suffix? [01:08] jml: Right. [01:08] hopefully the next person to do an upload will remember to clean up the number [01:09] Speaking of launchpad-dependencies... [01:09] I noticed yesterday that we seem to have an awful lot of external dependencies built into the tree itself. [01:09] well, I've been thinking about adding a suggests or recommends for snakefood so I can land that dependency graph [01:09] Things like BeautifulSoup and oauth, which have packages. [01:09] And we don't carry any local changes to them. [01:09] Does anybody know why they're in the tree, rather than using one of the other three external dep mechanisms? [01:10] We also have like 10000 lines of unused JavaScript libraries in contrib/. [01:10] wgrant, I don't. [01:10] wgrant, ... and a bunch of useless .dia & html files in high-level directories [01:11] wgrant, I would look favorably on patches that delete these things. [01:11] And a whole lot of obsolete docs, yeah. [01:11] jml, wgrant: https://dev.launchpad.net/LaunchpadPpa?action=diff&rev2=23&rev1=22 [01:12] wgrant, I guess the thing is, no one is 100% sure and that's enough to make procrastinating on deleting them very tempting [01:12] And a few broken makefiles. [01:12] mwhudson, goodness me there's a wiki page [01:12] wgrant: i think oauth is a bit hacked, maybe? [01:12] or was [01:12] or something [01:12] 31 files changed, 9270 deletions(-) [01:12] mwhudson: Hm, let me diff again. [01:13] But the tests pass with the system one. [01:13] jml: i'm shocked, yes shocked! that you didn't find a wiki page! [01:14] mwhudson, it's a disgrace. I blame those bureaucrats in Brussels. [01:14] * mwhudson adds a link to https://edge.launchpad.net/~launchpad/+archive/ppa [01:14] jml: and cancer causing immigrants [01:16] * mwhudson hits http://www.qwghlm.co.uk/toys/dailymail/ a few times [01:19] Are rising house prices hurting Britain's swans!? [01:19] Or will cancer defraid them? [01:19] Er, defraud. [01:20] anyway, I'm going to bed. Maybe sometime soon I can land my zope.testing upgrade. [01:22] I need to finish this damn work so I can read my book! [01:22] * thumper must not get distracted === NCommand1r is now known as NCommander === matsubara is now known as matsubara-afk [01:56] Can someone please land https://code.edge.launchpad.net/~wgrant/launchpad/show-package-sets-in-queue/+merge/21521 and https://code.edge.launchpad.net/~wgrant/launchpad/export-basic-binary-download-stats/+merge/21544? [01:57] Is Launchpad going to burn down if it tries to render a 10000 line diff in an MP? [02:04] wgrant: no, not any more [02:04] Ah, good. [02:04] it caps the lines (and bytes) displayed [02:05] 31 files changed, 9270 deletions(-) [02:19] * thumper has finished (subject to review) the branch that makes merge proposal emails sent by a job [02:20] What's the status of not sending emails for WIP MPs? [02:21] wgrant: dependent on thumper's just finished branch [02:21] Excellent. [02:21] although it is such a wonderful afternoon, I'm losing the will to write the last pipe [02:22] the last pipe is the bit that actually gets all the emails to send... [02:29] mwhudson: if your afternoon is like mine, you could take a look at the two reviews on the review channel :) [02:30] yeah ok [02:31] * wgrant has two reviews that are already reviewed but need landing. [02:34] wgrant: does noodles need to ui-stamp https://code.edge.launchpad.net/~wgrant/launchpad/show-package-sets-in-queue/+merge/21521 ? [02:35] Hmm, possibly. [02:36] wgrant: also, is direct_inclusion what you really want? [02:37] i admit to not being sure about this area [02:37] mwhudson: It's what the archive admins want. [02:37] I've talked to the three people who are going to be using that page most. [02:37] ok [02:38] good enough for me [02:46] mwhudson: Thanks/ [02:58] thumper: i don't think i'm going to get through even the first of your branches, sorry [02:58] mwhudson: that's ok [02:58] I'm struggling with warsaw's law myself [02:59] heh heh [02:59] mwhudson: what are your thoughts about modifying lib/contrib/glock.py? [02:59] mwhudson: the losas have complained that it doesn't give the lock path when creating the lock [03:00] mwhudson: I've traced the log output to that file [03:00] oh right [03:01] oh FFS [03:01] lib/lp/soyuz/tests/../doc/buildd-slave.txt failed on ec2 [03:01] thumper: that file hurts my eyes :( [03:02] i also like the way it's in contrib and has no license information i can see [03:02] wgrant: does that file have intermittant failures? [03:03] thumper: No. [03:03] thumper: What was the failure? [03:04] wgrant: http://pastebin.ubuntu.com/397585/ [03:04] test_min_time_to_next_builder (lp.buildmaster.tests.test_buildqueue.TestMinTimeToNextBuilderMulti) failed in other ec2 test run [03:04] That's not one I've seen before. [03:05] glock seems to be lgpl [03:05] AssertionError: Wrong min time to next available builder (30 > 29) [03:05] And it passed for me on devel just an hour or two ago. [03:05] test min time to builder was the one we timezone fixed in a stand up [03:05] * StevenK blinks [03:05] it seems to be cursed [03:06] Yeah, that one I recognize. [03:06] File "lib/lp/soyuz/tests/../doc/buildd-slave.txt", line 101, in buildd-slave.txt [03:06] ... [03:06] + ProtocolError: [03:07] What What should I do about the pointless embedded code copies I mentioned earlier? [03:07] oauth and BeautifulSoup are unmodified copies of old upstream versions. [03:08] well i'm going to go and watch the cricket [03:08] good weekend, all! [03:09] Ooh, who's playing? [03:09] * StevenK picks on wgrant [03:09] StevenK: Hm? [03:10] Wow, a bug in Launchpad against Soyuz you *aren't* subscribed to. [03:11] Ah, just got the email. [03:11] * wgrant isn't a reviewer. [03:12] StevenK: Does everybody want that? [03:12] It seems like a good idea, except that it removes the remaining tiny bit of security against compromises. [03:12] wgrant: I know you're not, but you're in my timezone and you know the code [03:14] mwhudson: TTFN [03:15] I hate code that lies [03:15] however if I want to make it right, I've got a metric shit load to change [03:15] arse [03:19] What's lying? [03:23] the code if I don't fix it [03:24] wgrant: we currently have a cronjob called mpcreationjobs.py [03:24] wgrant: a horrible name, but one I want to change to merge-proposal-email-jobs.py [03:24] I'd always assumed that that created MPs, until I noticed that there were no emails coming out until I ran it. [03:24] wgrant: no that is createmergeproposals.py [03:25] wgrant: it is a point of much confusion [03:25] even for me [03:25] Heh. [03:25] A little WTFing and detective work led me to that conclusion after a while. [03:25] yeah, well lets aim for less WTFs per minute [03:34] thumper: merge-proposal-email-jobs.py + 1 from losaville, so long as you also modify the name it uses in scriptactivity to be the same. script names that don't match their logged names is a source of pain and frustration. [03:35] spm: yeah, I also need to change a lot of config stuff [03:35] spm: also, I've done a drive by fix for adding the lock file to 'creating lockfile' info logging line [03:36] woohoo! [04:06] * thumper EODs [04:06] can't think straight any more === Ursinha_ is now known as Ursinha-afk [05:19] OOPS-1539ED198 [05:19] What's the culprit on that? [05:24] Timeout in SQL [05:25] Well, yes. [05:25] No obviously big queries? [05:25] No, it's a nice and short one [05:25] Hmmm, query count is ~700. That page sucks. === jtv is now known as jtv-sick [07:43] wgrant: which page? [07:48] thumper: DistroSeries +queue [07:48] It does some pretty ugly and elaborate prejoinish stuff, but doesn't make use of it very well. [07:49] It would be nice to see the query log, but I have a bit of an idea of what's going on locally. [07:52] I wish our sampledata wasn't illegal :( [08:15] good morning [09:03] Hrm. We have all kinds of version skew in launchpad-dependencies across hardy/jaunty/karmic/lucid. people haven't been copying it after upload [09:03] * maxb fixes [09:04] jml: You didn't put your upload in bzr either :-/ [09:06] * maxb imports it [09:09] maxb, are instructions to do that on the wiki page? [09:10] maxb, because I really didn't know what I was doing (as you've probably guessed) [09:10] wgrant, let's delete the sample data! [09:10] Is it possible to create legal sample data? [09:18] persia, I can't begin to explain how little I enjoy legal discussions about code. [09:19] jml: The dch gotcha was not en-wikied (mwhudson has since docced), but the wiki page does say about the package is in bzr, and mention using bzr mark-uploaded to tag it [09:19] maxb, ok, thanks. [09:19] maxb, I only found out about the wiki page after I tried the upload [09:21] maxb, mwhudson has linked to the wiki page from the ppa description now, so it should be all good. [09:22] tee hee [09:22] every time I say "ppa" [09:22] I hear a noise from bigjools' laptop [09:22] Haha. [09:22] heh heh [09:22] jml [09:22] jml [09:22] jml [09:22] This reminds me of thumper vs. bigjools in Wellington. [09:22] screw you hippy! [09:22] hahaha [09:22] I bet it beeps when I say "hippy" [09:23] ppa [09:23] heh [09:23] joke's on you, it doesn't beep unless I am not looking at the channel :) [09:25] bigjools: +queue query counts make me very sad. [09:25] jml: wasn't i talking to you about three hours ago? [09:25] It is so incredibly inefficient. [09:25] mwhudson, yes. [09:26] mwhudson, I'm not well rested [09:26] jml: last day of the sprint at least, i guess? [09:26] wgrant: it used to be 4000+ [09:26] am I ok to land a change that relies on subunit 0.0.4? [09:26] I optimised it down to <1000 [09:26] mwhudson, yeah :) [09:26] it's also f***ing hard to optimise [09:26] Which page is this? [09:27] QueueItemsView [09:27] * wgrant finds a particularly horrible example. [09:27] https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=3&queue_text= [09:27] Look at that time. [09:28] Got an example that won't timout on me ;) [09:28] 1 → 30 of 128120 results [09:29] that doesn't seem like it's going to work well [09:29] That one has ~700 queries in 15-16 seconds. [09:29] nm - it doesn't look suitable as a memcached test [09:29] mwhudson: Why not? If it batches properly (which it does), it doesn't need to suck. [09:30] i guess [09:31] Retrieving the last 50 items from 100k ordered results usually requires materializing those results, sorting them and returning the final records. [09:31] Well, where is the time spent in OOPS-1539ED198? [09:31] In the initial query? [09:32] It's a simple one like "SELECT PackageUpload.archive, PackageUpload.changesfile, PackageUpload.date_created, PackageUpload.distroseries, PackageUpload.id, PackageUpload.pocket, PackageUpload.signing_key, PackageUpload.status FROM PackageUpload WHERE packageupload.distroseries = 10 AND packageupload.archive IN (1, 12) AND packageupload.status IN (0) ORDER BY PackageUpload.id DESC LIMIT 8 OFFSET 0" [09:32] stub: Is that going to be horrifically bad? [09:32] the page is returning a lot of results from a lot of different places. I'd like to throw away the ORM queries and use storm.execute quite frankly [09:33] It can be very bad. Depends. [09:33] it's the most complicated page I know of [09:33] bigjools, why would storm.execute be better than storm.find in this case? [09:33] fewer queries [09:33] bigjools, really? [09:34] storm.find()s can become arbitrarily complex... [09:34] No need to resort to raw SQL. [09:35] as I explained to jono in person, it's the property traversals that kill us [09:35] Not if we emulate a prejoin. [09:35] .execute or .find, whatever [09:35] I disliked storm query syntax [09:35] err dislike, present tense [09:35] Although it appears that Storm can't really prejoin ReferenceSets :( [09:35] wgrant: A zillion LibraryFileAlias retrievals - loading them one at a time doesn't help. Another zillion SourcePackagePublishingHistory requests, one at a time. Death by 1000 cuts. [09:35] prejoins in Storm make my eyes bleed [09:35] I wrote a helper for that. [09:35] stub: exactly [09:36] stub: Where is this helper? [09:38] wgrant: lp/services/database/prejoin.py [09:38] stub: Ahh, handy. [09:50] Do we have a wiki page describing the current qa process and wot i should do with these qa- tags? [09:50] nm - found it [09:50] https://dev.launchpad.net/PolicyAndProcess/PreReleaseQAProcess/Experiment [09:51] But I don't understand 'when a bug is fixed in rcmode' [09:51] hmm. [09:52] so, now that I've got subunit in launchpad-developer-dependencies, do I need to create a new ec2 image? === jpds_ is now known as jpds [09:54] yes, apparently [10:01] Morning, all. [10:05] deryck, hi [10:05] henninge, hello! [10:05] Hi jml! ;) [10:06] henninge, I want to be one of VALID_AMI_OWNERS [10:06] henninge, I see that you are one of those [10:06] henninge, how do I join the club [10:06] jml: just add your number there [10:06] henninge, which number? [10:07] jml: AWS account number [10:07] henninge, you mean the one in the form nnnn-nnnn-nnnn? [10:08] henninge, mine starts with a zero [10:08] jml: yes but without the - [10:08] let me see [10:09] jml: leading 0 seems to be fine, Diogo's like that, too [10:09] henninge, well, I'll see if it works for VALID_AMI_OWNERS, which seems to treat these things as numbers [10:10] oh [10:10] henninge, ~/.ec2/aws_user -- should that have hyphens in it? [10:10] jml: mine doesn't [10:11] henninge, ok, thanks.- [10:12] * jml tries [10:13] good luck, jml ;-) [10:13] bigjools: So, I've so far cut the query count by 2/3. [10:18] meh. I need to add subunit to the ppa. [10:21] wgrant: \o/ [10:21] is that using that helper? [10:22] the big problem was always with having lots of custom uploads on the queue, that wasn't optimised [10:22] bigjools: No, that doesn't help for ReferenceSets, it seems. [10:22] * jml thinks [10:22] Even if the objects themselves are cached, retrieving a ReferenceSet makes a query to get all the object IDs. [10:24] meh :( [10:25] stub: Do you know any way around that? [10:27] No. To discover the results of a database query you need to ask the database. [10:29] stub: Well, yes, but there's no reason I can see why one couldn't do that in single big query in a prejoinish sort of thing. [10:29] Sure [10:29] But I can't see a way to do that with Storm. [10:30] store.find( (Foo, Bar, Baz, Bing), ....) should do the big query [10:30] And the prejoin helper can be used so you don't need to change callsites to handle the bigger list of results. [10:31] That will pre-cache all of the objects. But accessing a ReferenceSet will still make a query. [10:31] I don't follow. Accessing the ReferenceSet makes a query because you need to ask the database for the results at some point. [10:31] store.find(...) doesn't issue a database query. Accessing it does. [10:33] I can do a prejoin which will avoid further queries for Reference attribute accesses. I can also formulate a query which will calculate all of the ReferenceSets for all of my objects in one query. [10:33] But I cannot use the results of the second in a normal ReferenceSet access. [10:34] SQLAlchemy can do eager loading of collections like this, even automatically. [10:34] But it appears that Storm cannot, even manually. [10:34] This makes me sad, and pages slow. [10:36] I don't see why you 'cannot use the results of the second in a normal ReferenceSet access'. [10:36] Are you trying to use it in a subquery or something? [10:38] I have PackageUpload.(sources|builds|customfiles) and a horrible huge hierarchy underneath each. [10:38] I have written a query manually to grab them all without making thousands of queries. [10:39] But even if I've preloaded all of the objects with that query, PackageUpload.sources[0] will still hit the DB. I want it to not. The way I am doing it now is by using a separate data structure and avoiding the ReferenceSet entirely. [10:40] So you materialized the list or something before calling PackageUpload.sources[0] ? [10:41] I have a list equivalent to PackageUpload.sources, from my massive query. [10:43] And is this a result set, or a materialized list? [10:43] A materialized list. [10:43] So you might have thrashed the cache. [10:44] If you materialized 100k items, they won't all fit in Storms cache. [10:44] Erm... hang on... [10:44] But I haven't told it enough to cache the ReferenceSet. [10:44] I think I'm confusing myself. [10:44] I've just made an equivalent query myself. [10:44] You don't cache reference sets. You cache objects. [10:44] Right. [10:45] But there's no reason I shouldn't be able to cache reference sets. [10:45] You did by materializing it [10:46] I didn't materialize the ReferenceSet itself. I couldn't materialize them all in less than a lot of queries, so I created a parallel data structure which I *could* complete in one query. [10:48] So Storm is being obstructive here, forcing me to avoid the objects in order to get reasonable performance. [10:51] wgrant, that sounds like an argument for fixing storm. [10:51] jml: Yes, that is my point :) [10:51] wgrant, good good. carry on. [10:51] I was just wondering if it was already possible. [10:51] It appears to not be. [10:51] Which seems odd. [10:52] I got confused - didn't click ReferenceSet rather than ResultSet [10:52] Ahh. [10:52] So you are building the equivalent of PackageUpload.sources, but have no way of telling Storm that your list should be used instead of PackageUpload.sources [10:52] stub: Right. [10:53] I assume 'packageupload.sources = my_list' doesn't work? [10:53] * stub hasn't really used ReferenceSets [11:01] stub: Ah, that does seem work (but requires relaxing of security proxies, and is really ugly, and there's no reason Storm can't do that itself). [11:03] First step would be coming up with the syntax. [11:03] Dunno if the SQLAlchemy syntax can be stolen [11:04] http://www.sqlalchemy.org/docs/05/ormtutorial.html, search for 'eager' [11:04] I'm not sure how Storm-appropriate that would be. [11:05] And I'm particularly unsure on how to refer to deeper collections. [11:08] Ah, and that workaround won't work with Storm trunk. [11:09] Assigning to a ReferenceSet will deliberately crash. [11:16] That looks like what I'd want 'prejoin' in Storm to be able to do, and eager is a better name (still sucky, but wtf does prejoin mean?) [11:17] Heh. [11:17] It's interesting that Storm has a prejoin implementation -- but only in the SQLObject compat layer. [11:19] I miss prejoins in SQLObj :/ [11:47] danilos: I found out what my problem was. [11:47] henninge, what was it? [11:47] danilos: the tarfile data was opened with mode "r|*" which is different from "r:*" in that it does not allow random access. [11:48] danilos: is there a special reason for using "r|*", like performance? [11:48] * henninge was not aware of that difference. [11:50] henninge, I don't know [11:51] henninge, note that tarfiles are stream-based, so seeking around them is slow; is there any reason why you wouldn't re-open the file and start over? [11:52] henninge, when I say "stream-based" I mean: "you have to go through the entire file to read all the file names" and "optimized for saving to and reading off tapes" :) [11:52] danilos: actually, the files are accessed in the right order but unless I use the iterator, I cannot access them. [11:52] I mean, I get the error. [11:53] even with re-opening, I mean. [11:53] henninge, oh, very, very interesting [11:53] henninge, sounds like a bug in tarfile module then :) [11:55] yup [11:59] danilos: btw, the tarball I am working on is in memory (StringIO) [12:00] henninge, right, that shouldn't make a big deal, seeks usually work pretty well in memory :) [12:00] shouldn't random access be just as cheap there as sequential access? [12:00] henninge, it probably is, but code might not be optimized [12:00] henninge, it should be easy to check if it makes any difference :) [12:01] henninge, btw, have you tried doing a seek on StringIO yourself before re-opening? [12:01] danilos: no, I have not. [12:01] but it had crossed my mind [12:02] henninge, anyway, at least confirm it's not seriously affecting performance by timing opening and listing files for a tarball with a big number of files [12:02] henninge, if it's not outrageously different, go with the simplest solution; if it is, let's find better solutions :) [12:03] danilos: ok, let me see what I can do. [12:03] henninge, fwiw, random-access might even be faster for tarfile access if implemented with some heuristics :) [12:05] adeuring, hi. I took over Bug #531003 on the board, just to play with queries and follow up with bdmurray. [12:05] Bug #531003: searchTasks with hardware_is_linked_to_bug parameter times out regularly

[12:05] deryck: ok [12:05] adeuring, like you said, though, I'm not sure I see a way to improve this. [12:06] deryck: I should probably try to debug my memory. I might have thoufh about these timeouts some time ago, but can't remember any details... [12:07] s/thoufh/thought/ [12:08] adeuring, bdmurray has debugged it's just the hardware_is_linked_to_bug option, which just adds the join. So there's thay M2M table, but it's needed. And how can you query that any more quickly? I don't see a way. [12:08] deryck: right... [12:09] and like you say, after caching, it works reasonably fast. === matsubara-afk is now known as matsubara [12:13] deryck, sometimes postgres chooses suboptimal joins as well [12:13] deryck, s/joins/query plans/ [12:13] deryck, you can influence that with subselects usually [12:16] he teases and leaves.... [12:40] I don't suppose stub is around at this hour? [12:41] * stub hides behind the couch [12:41] stub! I see you. :-) === Ursinha-afk is now known as Ursinha [13:18] deryck, I believe that bug 541637 is not a malone issue, but entirely a launchpadlib/webservice issue. If you agree, I'll change things around one way or another so that launchpadlib and foundations are on the hook, not launchpadlib and malone. Agree? [13:18] Bug #541637: searchTasks doesn't return all matching tasks?! === Chex_ is now known as chex [13:19] gary_poster, yes, thanks! I was going to ping you today about that one actually. [13:19] cool, deryck, on it === flacoste_afk is now known as flacoste [13:35] EdwinGrubbs: bac: stand-up in 2 minutes [13:49] is it a known bug that when you add a comment to a bug report in today's launchpad, you do not get a page updated with the comment, but only a weird text that says: [object Object] [13:49] ? [13:49] reloading the page shows my comment [13:59] barry: I do not experience that issue. I think you got a timeout on the callback [14:03] sinzui: ok. i'll keep an eye on it and if it comes up again i'll file a bug [14:13] stub: still around? === NCommand1r is now known as NCommander === mbarnett` is now known as mbarnett [14:39] Am I insane. Do I really see two identical WindmillTestCase classes defined in lp.testing? [15:04] is someone available to finish reviewing my branch that has been first reviewed 10 days ago? https://code.edge.launchpad.net/~didrocks/launchpad/expose-sshkeys-bug-357235/+merge/20995 === henninge_ is now known as henninge [15:29] didrocks: you're best asking in #launchpad-reviews [15:29] bigjools: doing that now, thanks [15:41] !!! [15:41] http://launchpadlibrarian.net/41290965/buildlog_ubuntu-hardy-i386.subunit_0.0.5-1~ppa1_FAILEDTOBUILD.txt.gz [15:42] my life is strewn with cowpats from the devil's own satanic herd. [15:48] Have you considered going into the home fueling business? === beuno is now known as beuno-lunch [16:12] james_w: ping === deryck is now known as deryck[lunch] === gary_poster is now known as gary-lunch === beuno-lunch is now known as beuno === EdwinGrubbs is now known as Edwin-lunch === Ursinha is now known as Ursinha-lunch === deryck[lunch] is now known as deryck === matsubara is now known as matsubara-lunch === matsubara-lunch is now known as matsubara === salgado is now known as salgado-upgradin === maxb_ is now known as maxb [20:06] gary-lunch: ping [20:07] sinzui: oops, not been at lunch for quite awhile now === gary-lunch is now known as gary_poster [20:08] gary_poster: I am trying to register a view in a test so that I test some yui testunit files, but my registration does not let me access http://launchpad:8085/+yui-unittest [20:09] This is what I have tried: https://pastebin.canonical.com/29442/ [20:09] looking [20:13] sinzui: everything looks fine to me. If I were trying to make it work, the first thing I would do is try to be more promiscuous in my registration--that is, instead of (ILaunchpadRoot, IDefaultBrowserLayer) I might go for (Interface, IRequest). If that failed, the next thing I might do is [20:14] see if my reading of the error is correct--IOW, if I am getting a component lookup error, is it for the object I registered, or is the registered object being found, and some of its code blowing up? [20:14] In this case, maybe LaunchpadView actually does something interesting. [20:15] I'll also doublecheck the interface for registerAdapter to make sure order of arguments is correct, but it looks right, and I suspect you already did that double-checking. [20:16] gary_poster: Well I am very relieved at your opinion and suggestion. I can try a general interface and a simpler view. The interfaces used are the same I saw in the debugger then +dotspecgraph registered. [20:17] sinzui: ack, like I said, it didn't look wrong, but that's the kind of thing I'm suspicious of first === salgado is now known as salgado-afk === matsubara is now known as matsubara-afk [22:04] path_expression="string:+binaryhits/${binary_package_release/name}/${binary_package_release/version}/${binary_package_release/build/distroarchseries/architecturetag}/${day}/${country/iso3166code2|string:unknown}" [22:04] Hmmm. [22:12] * maxb raises an eyebrow at no one complaining that lp-dev-deps is currently uninstallable on karmic [22:39] Anybody around who can look at the traceback for OOPS-1539L2382? [22:48] wgrant, sure [22:48] LocationError: (None, 'filesize') [22:49] wgrant, http://paste.ubuntu.com/398034/ [22:50] Huh. [22:51] Looks like the librarian GC is being overzealous? [23:22]