[00:00] <thumper> james_w: are you wanting me to land ~james-w/launchpad/code-imports-use-ibranchtarget ?
[00:38] <wgrant> How does the webservice versioning work? Are we really committed to maintaining the full 1.0 API for 5 years?
[01:01] <thumper> wgrant: ask leonard
[01:01] <thumper> I'm not sure how it works
[01:06] <mwhudson> i've been wondering about that
[01:06] <jml> maxb, hmm. what did I do wrong to make that happen?
[01:06] <jml> maxb, I was doing what jelmer told me to.
[01:06] <mwhudson> jml: dch adds -ubuntu to the version number by default
[01:07] <jml> ahh, I see.
[01:07] <wgrant> It seems like only a tiny fraction of the API is actually going to be used by anything.
[01:07] <jml> so what should I do to correct my mistake?
[01:07] <wgrant> And it's going to be rather prohibitively model-change restrictive.
[01:07] <wgrant> jml: Have you uploaded it to the PPA yet?
[01:07] <jml> wgrant, yes, I have.
[01:07] <wgrant> Ah.
[01:07] <wgrant> You can't.
[01:08] <wgrant> Unless you increment the version again pointlessly.
[01:08] <jml> ok.
[01:08] <jml> wgrant, but say I had a very good reason for incrementing the version, I could do that and remove the suffix?
[01:08] <wgrant> jml: Right.
[01:08] <mwhudson> hopefully the next person to do an upload will remember to clean up the number
[01:09] <wgrant> Speaking of launchpad-dependencies...
[01:09] <wgrant> I noticed yesterday that we seem to have an awful lot of external dependencies built into the tree itself.
[01:09] <jml> well, I've been thinking about adding a suggests or recommends for snakefood so I can land that dependency graph
[01:09] <wgrant> Things like BeautifulSoup and oauth, which have packages.
[01:09] <wgrant> And we don't carry any local changes to them.
[01:09] <wgrant> Does anybody know why they're in the tree, rather than using one of the other three external dep mechanisms?
[01:10] <wgrant> We also have like 10000 lines of unused JavaScript libraries in contrib/.
[01:10] <jml> wgrant, I don't.
[01:10] <jml> wgrant, ... and a bunch of useless .dia & html files in high-level directories
[01:11] <jml> wgrant, I would look favorably on patches that delete these things.
[01:11] <wgrant> And a whole lot of obsolete docs, yeah.
[01:11] <mwhudson> jml, wgrant: https://dev.launchpad.net/LaunchpadPpa?action=diff&rev2=23&rev1=22
[01:12] <jml> 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] <wgrant> And a few broken makefiles.
[01:12] <jml> mwhudson, goodness me there's a wiki page
[01:12] <mwhudson> wgrant: i think oauth is a bit hacked, maybe?
[01:12] <mwhudson> or was
[01:12] <mwhudson> or something
[01:12] <wgrant>  31 files changed, 9270 deletions(-)
[01:12] <wgrant> mwhudson: Hm, let me diff again.
[01:13] <wgrant> But the tests pass with the system one.
[01:13] <mwhudson> jml: i'm shocked, yes shocked! that you didn't find a wiki page!
[01:14] <jml> 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] <mwhudson> jml: and cancer causing immigrants
[01:16]  * mwhudson hits http://www.qwghlm.co.uk/toys/dailymail/ a few times
[01:19] <jml> Are rising house prices hurting Britain's swans!?
[01:19] <wgrant> Or will cancer defraid them?
[01:19] <wgrant> Er, defraud.
[01:20] <jml> anyway, I'm going to bed. Maybe sometime soon I can land my zope.testing upgrade.
[01:22] <thumper> I need to finish this damn work so I can read my book!
[01:22]  * thumper must not get distracted
[01:56] <wgrant> 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] <wgrant> Is Launchpad going to burn down if it tries to render a 10000 line diff in an MP?
[02:04] <mwhudson> wgrant: no, not any more
[02:04] <wgrant> Ah, good.
[02:04] <mwhudson> it caps the lines (and bytes) displayed
[02:05] <wgrant>  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] <wgrant> What's the status of not sending emails for WIP MPs?
[02:21] <mwhudson> wgrant: dependent on thumper's just finished branch
[02:21] <wgrant> Excellent.
[02:21] <thumper> although it is such a wonderful afternoon, I'm losing the will to write the last pipe
[02:22] <thumper> the last pipe is the bit that actually gets all the emails to send...
[02:29] <thumper> mwhudson: if your afternoon is like mine, you could take a look at the two reviews on the review channel :)
[02:30] <mwhudson> yeah ok
[02:31]  * wgrant has two reviews that are already reviewed but need landing.
[02:34] <mwhudson> wgrant: does noodles need to ui-stamp https://code.edge.launchpad.net/~wgrant/launchpad/show-package-sets-in-queue/+merge/21521 ?
[02:35] <wgrant> Hmm, possibly.
[02:36] <mwhudson> wgrant: also, is direct_inclusion what you really want?
[02:37] <mwhudson> i admit to not being sure about this area
[02:37] <wgrant> mwhudson: It's what the archive admins want.
[02:37] <wgrant> I've talked to the three people who are going to be using that page most.
[02:37] <mwhudson> ok
[02:38] <mwhudson> good enough for me
[02:46] <wgrant> mwhudson: Thanks/
[02:58] <mwhudson> thumper: i don't think i'm going to get through even the first of your branches, sorry
[02:58] <thumper> mwhudson: that's ok
[02:58] <thumper> I'm struggling with warsaw's law myself
[02:59] <mwhudson> heh heh
[02:59] <thumper> mwhudson: what are your thoughts about modifying lib/contrib/glock.py?
[02:59] <thumper> mwhudson: the losas have complained that it doesn't give the lock path when creating the lock
[03:00] <thumper> mwhudson: I've traced the log output to that file
[03:00] <mwhudson> oh right
[03:01] <thumper> oh FFS
[03:01] <thumper> lib/lp/soyuz/tests/../doc/buildd-slave.txt failed on ec2
[03:01] <mwhudson> thumper: that file hurts my eyes :(
[03:02] <mwhudson> i also like the way it's in contrib and has no license information i can see
[03:02] <thumper> wgrant: does that file have intermittant failures?
[03:03] <wgrant> thumper: No.
[03:03] <wgrant> thumper: What was the failure?
[03:04] <thumper> wgrant: http://pastebin.ubuntu.com/397585/
[03:04] <thumper> test_min_time_to_next_builder (lp.buildmaster.tests.test_buildqueue.TestMinTimeToNextBuilderMulti) failed in other ec2 test run
[03:04] <wgrant> That's not one I've seen before.
[03:05] <mwhudson> glock seems to be lgpl
[03:05] <thumper> AssertionError: Wrong min time to next available builder (30 > 29)
[03:05] <wgrant> And it passed for me on devel just an hour or two ago.
[03:05] <mwhudson> test min time to builder was the one we timezone fixed in a stand up
[03:05]  * StevenK blinks
[03:05] <mwhudson> it seems to be cursed
[03:06] <wgrant> Yeah, that one I recognize.
[03:06] <StevenK> File "lib/lp/soyuz/tests/../doc/buildd-slave.txt", line 101, in buildd-slave.txt
[03:06] <StevenK> ...
[03:06] <StevenK> + ProtocolError: <ProtocolError for localhost:8221/rpc/: -1 >
[03:07] <wgrant> What What should I do about the pointless embedded code copies I mentioned earlier?
[03:07] <wgrant> oauth and BeautifulSoup are unmodified copies of old upstream versions.
[03:08] <mwhudson> well i'm going to go and watch the cricket
[03:08] <mwhudson> good weekend, all!
[03:09] <StevenK> Ooh, who's playing?
[03:09]  * StevenK picks on wgrant 
[03:09] <wgrant> StevenK: Hm?
[03:10] <StevenK> Wow, a bug in Launchpad against Soyuz you *aren't* subscribed to.
[03:11] <wgrant> Ah, just got the email.
[03:11]  * wgrant isn't a reviewer.
[03:12] <wgrant> StevenK: Does everybody want that?
[03:12] <wgrant> It seems like a good idea, except that it removes the remaining tiny bit of security against compromises.
[03:12] <StevenK> wgrant: I know you're not, but you're in my timezone and you know the code
[03:14] <thumper> mwhudson: TTFN
[03:15] <thumper> I hate code that lies
[03:15] <thumper> however if I want to make it right, I've got a metric shit load to change
[03:15] <thumper> arse
[03:19] <wgrant> What's lying?
[03:23] <thumper> the code if I don't fix it
[03:24] <thumper> wgrant: we currently have a cronjob called mpcreationjobs.py
[03:24] <thumper> wgrant: a horrible name, but one I want to change to merge-proposal-email-jobs.py
[03:24] <wgrant> I'd always assumed that that created MPs, until I noticed that there were no emails coming out until I ran it.
[03:24] <thumper> wgrant: no that is createmergeproposals.py
[03:25] <thumper> wgrant: it is a point of much confusion
[03:25] <thumper> even for me
[03:25] <wgrant> Heh.
[03:25] <wgrant> A little WTFing and detective work led me to that conclusion after a while.
[03:25] <thumper> yeah, well lets aim for less WTFs per minute
[03:34] <spm> 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] <thumper> spm: yeah, I also need to change a lot of config stuff
[03:35] <thumper> spm: also, I've done a drive by fix for adding the lock file to 'creating lockfile' info logging line
[03:36] <spm> woohoo!
[04:06]  * thumper EODs
[04:06] <thumper> can't think straight any more
[05:19] <wgrant> OOPS-1539ED198
[05:19] <wgrant> What's the culprit on that?
[05:24] <StevenK> Timeout in SQL
[05:25] <wgrant> Well, yes.
[05:25] <wgrant> No obviously big queries?
[05:25] <StevenK> No, it's a nice and short one
[05:25] <wgrant> Hmmm, query count is ~700. That page sucks.
[07:43] <thumper> wgrant: which page?
[07:48] <wgrant> thumper: DistroSeries +queue
[07:48] <wgrant> It does some pretty ugly and elaborate prejoinish stuff, but doesn't make use of it very well.
[07:49] <wgrant> 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] <wgrant> I wish our sampledata wasn't illegal :(
[08:15] <adeuring> good morning
[09:03] <maxb> 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] <maxb> jml: You didn't put your upload in bzr either :-/
[09:06]  * maxb imports it
[09:09] <jml> maxb, are instructions to do that on the wiki page?
[09:10] <jml> maxb, because I really didn't know what I was doing (as you've probably guessed)
[09:10] <jml> wgrant, let's delete the sample data!
[09:10] <persia> Is it possible to create legal sample data?
[09:18] <jml> persia, I can't begin to explain how little I enjoy legal discussions about code.
[09:19] <maxb> 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] <jml> maxb, ok, thanks.
[09:19] <jml> maxb, I only found out about the wiki page after I tried the upload
[09:21] <jml> maxb, mwhudson has linked to the wiki page from the ppa description now, so it should be all good.
[09:22] <jml> tee hee
[09:22] <jml> every time I say "ppa"
[09:22] <jml> I hear a noise from bigjools' laptop
[09:22] <wgrant> Haha.
[09:22] <mwhudson> heh heh
[09:22] <bigjools> jml
[09:22] <bigjools> jml
[09:22] <bigjools> jml
[09:22] <wgrant> This reminds me of thumper vs. bigjools in Wellington.
[09:22] <bigjools> screw you hippy!
[09:22] <jml> hahaha
[09:22] <bigjools> I bet it beeps when I say "hippy"
[09:23] <thumper> ppa
[09:23] <thumper> heh
[09:23] <bigjools> joke's on you, it doesn't beep unless I am not looking at the channel :)
[09:25] <wgrant> bigjools: +queue query counts make me very sad.
[09:25] <mwhudson> jml: wasn't i talking to you about three hours ago?
[09:25] <wgrant> It is so incredibly inefficient.
[09:25] <jml> mwhudson, yes.
[09:26] <jml> mwhudson, I'm not well rested
[09:26] <mwhudson> jml: last day of the sprint at least, i guess?
[09:26] <bigjools> wgrant: it used to be 4000+
[09:26] <jml> am I ok to land a change that relies on subunit 0.0.4?
[09:26] <bigjools> I optimised it down to <1000
[09:26] <jml> mwhudson, yeah :)
[09:26] <bigjools> it's also f***ing hard to optimise
[09:26] <stub> Which page is this?
[09:27] <wgrant> QueueItemsView
[09:27]  * wgrant finds a particularly horrible example.
[09:27] <wgrant> https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=3&queue_text=
[09:27] <wgrant> Look at that time.
[09:28] <stub> Got an example that won't timout on me ;)
[09:28] <mwhudson> 1 → 30 of 128120 results
[09:29] <mwhudson> that doesn't seem like it's going to work well
[09:29] <wgrant> That one has ~700 queries in 15-16 seconds.
[09:29] <stub> nm - it doesn't look suitable as a memcached test
[09:29] <wgrant> mwhudson: Why not? If it batches properly (which it does), it doesn't need to suck.
[09:30] <mwhudson> i guess
[09:31] <stub> Retrieving the last 50 items from 100k ordered results usually requires materializing those results, sorting them and returning the final records.
[09:31] <wgrant> Well, where is the time spent in OOPS-1539ED198?
[09:31] <wgrant> In the initial query?
[09:32] <wgrant> 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] <wgrant> stub: Is that going to be horrifically bad?
[09:32] <bigjools> 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] <stub> It can be very bad. Depends.
[09:33] <bigjools> it's the most complicated page I know of
[09:33] <jml> bigjools, why would storm.execute be better than storm.find in this case?
[09:33] <bigjools> fewer queries
[09:33] <jml> bigjools, really?
[09:34] <wgrant> storm.find()s can become arbitrarily complex...
[09:34] <wgrant> No need to resort to raw SQL.
[09:35] <bigjools> as I explained to jono in person, it's the property traversals that kill us
[09:35] <wgrant> Not if we emulate a prejoin.
[09:35] <bigjools> .execute or .find, whatever
[09:35] <bigjools> I disliked storm query syntax
[09:35] <bigjools> err dislike, present tense
[09:35] <wgrant> Although it appears that Storm can't really prejoin ReferenceSets :(
[09:35] <stub> 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] <bigjools> prejoins in Storm make my eyes bleed
[09:35] <stub> I wrote a helper for that.
[09:35] <bigjools> stub: exactly
[09:36] <wgrant> stub: Where is this helper?
[09:38] <stub> wgrant: lp/services/database/prejoin.py
[09:38] <wgrant> stub: Ahh, handy.
[09:50] <stub> Do we have a wiki page describing the current qa process and wot i should do with these qa- tags?
[09:50] <stub> nm - found it
[09:50] <stub> https://dev.launchpad.net/PolicyAndProcess/PreReleaseQAProcess/Experiment
[09:51] <stub> But I don't understand 'when a bug is fixed in rcmode'
[09:51] <jml> hmm.
[09:52] <jml> so, now that I've got subunit in launchpad-developer-dependencies, do I need to create a new ec2 image?
[09:54] <jml> yes, apparently
[10:01] <deryck> Morning, all.
[10:05] <jml> deryck, hi
[10:05] <jml> henninge, hello!
[10:05] <henninge> Hi jml! ;)
[10:06] <jml> henninge, I want to be one of VALID_AMI_OWNERS
[10:06] <jml> henninge, I see that you are one of those
[10:06] <jml> henninge, how do I join the club
[10:06] <henninge> jml: just add your number there
[10:06] <jml> henninge, which number?
[10:07] <henninge> jml: AWS account number
[10:07] <jml> henninge, you mean the one in the form nnnn-nnnn-nnnn?
[10:08] <jml> henninge, mine starts with a zero
[10:08] <henninge> jml: yes but without the -
[10:08] <henninge> let me see
[10:09] <henninge> jml: leading 0 seems to be fine, Diogo's like that, too
[10:09] <jml> henninge, well, I'll see if it works for VALID_AMI_OWNERS, which seems to treat these things as numbers
[10:10] <henninge> oh
[10:10] <jml> henninge, ~/.ec2/aws_user -- should that have hyphens in it?
[10:10] <henninge> jml: mine doesn't
[10:11] <jml> henninge, ok, thanks.-
[10:12]  * jml tries
[10:13] <henninge> good luck, jml ;-)
[10:13] <wgrant> bigjools: So, I've so far cut the query count by 2/3.
[10:18] <jml> meh. I need to add subunit to the ppa.
[10:21] <bigjools> wgrant: \o/
[10:21] <bigjools> is that using that helper?
[10:22] <bigjools> the big problem was always with having lots of custom uploads on the queue, that wasn't optimised
[10:22] <wgrant> bigjools: No, that doesn't help for ReferenceSets, it seems.
[10:22]  * jml thinks
[10:22] <wgrant> Even if the objects themselves are cached, retrieving a ReferenceSet makes a query to get all the object IDs.
[10:24] <jml> meh :(
[10:25] <wgrant> stub: Do you know any way around that?
[10:27] <stub> No. To discover the results of a database query you need to ask the database.
[10:29] <wgrant> 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] <stub> Sure
[10:29] <wgrant> But I can't see a way to do that with Storm.
[10:30] <stub> store.find( (Foo, Bar, Baz, Bing), ....) should do the big query
[10:30] <stub> And the prejoin helper can be used so you don't need to change callsites to handle the bigger list of results.
[10:31] <wgrant> That will pre-cache all of the objects. But accessing a ReferenceSet will still make a query.
[10:31] <stub> 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] <stub> store.find(...) doesn't issue a database query. Accessing it does.
[10:33] <wgrant> 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] <wgrant> But I cannot use the results of the second in a normal ReferenceSet access.
[10:34] <wgrant> SQLAlchemy can do eager loading of collections like this, even automatically.
[10:34] <wgrant> But it appears that Storm cannot, even manually.
[10:34] <wgrant> This makes me sad, and pages slow.
[10:36] <stub> I don't see why you 'cannot use the results of the second in a normal ReferenceSet access'.
[10:36] <stub> Are you trying to use it in a subquery or something?
[10:38] <wgrant> I have PackageUpload.(sources|builds|customfiles) and a horrible huge hierarchy underneath each.
[10:38] <wgrant> I have written a query manually to grab them all without making thousands of queries.
[10:39] <wgrant> 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] <stub> So you materialized the list or something before calling PackageUpload.sources[0] ?
[10:41] <wgrant> I have a list equivalent to PackageUpload.sources, from my massive query.
[10:43] <stub> And is this a result set, or a materialized list?
[10:43] <wgrant> A materialized list.
[10:43] <stub> So you might have thrashed the cache.
[10:44] <stub> If you materialized 100k items, they won't all fit in Storms cache.
[10:44] <stub> Erm... hang on...
[10:44] <wgrant> But I haven't told it enough to cache the ReferenceSet.
[10:44] <stub> I think I'm confusing myself.
[10:44] <wgrant> I've just made an equivalent query myself.
[10:44] <stub> You don't cache reference sets. You cache objects.
[10:44] <wgrant> Right.
[10:45] <wgrant> But there's no reason I shouldn't be able to cache reference sets.
[10:45] <stub> You did by materializing it
[10:46] <wgrant> 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] <wgrant> So Storm is being obstructive here, forcing me to avoid the objects in order to get reasonable performance.
[10:51] <jml> wgrant, that sounds like an argument for fixing storm.
[10:51] <wgrant> jml: Yes, that is my point :)
[10:51] <jml> wgrant, good good. carry on.
[10:51] <wgrant> I was just wondering if it was already possible.
[10:51] <wgrant> It appears to not be.
[10:51] <wgrant> Which seems odd.
[10:52] <stub> I got confused - didn't click ReferenceSet rather than ResultSet
[10:52] <wgrant> Ahh.
[10:52] <stub> 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] <wgrant> stub: Right.
[10:53] <stub> I assume 'packageupload.sources = my_list' doesn't work?
[10:53]  * stub hasn't really used ReferenceSets
[11:01] <wgrant> 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] <stub> First step would be coming up with the syntax.
[11:03] <stub> Dunno if the SQLAlchemy syntax can be stolen
[11:04] <wgrant> http://www.sqlalchemy.org/docs/05/ormtutorial.html, search for 'eager'
[11:04] <wgrant> I'm not sure how Storm-appropriate that would be.
[11:05] <wgrant> And I'm particularly unsure on how to refer to deeper collections.
[11:08] <wgrant> Ah, and that workaround won't work with Storm trunk.
[11:09] <wgrant> Assigning to a ReferenceSet will deliberately crash.
[11:16] <stub> 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] <wgrant> Heh.
[11:17] <wgrant> It's interesting that Storm has a prejoin implementation -- but only in the SQLObject compat layer.
[11:19] <bigjools> I miss prejoins in SQLObj :/
[11:47] <henninge> danilos: I found out what my problem was.
[11:47] <danilos> henninge, what was it?
[11:47] <henninge> danilos: the tarfile data was opened with mode "r|*" which is different from "r:*" in that it does not allow random access.
[11:48] <henninge> danilos: is there a special reason for using "r|*", like performance?
[11:48]  * henninge was not aware of that difference.
[11:50] <danilos> henninge, I don't know
[11:51] <danilos> 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] <danilos> 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] <henninge> danilos: actually, the files are accessed in the right order but unless I use the iterator, I cannot access them.
[11:52] <henninge> I mean, I get the error.
[11:53] <henninge> even with re-opening, I mean.
[11:53] <danilos> henninge, oh, very, very interesting
[11:53] <danilos> henninge, sounds like a bug in tarfile module then :)
[11:55] <henninge> yup
[11:59] <henninge> danilos: btw, the tarball I am working on is in memory (StringIO)
[12:00] <danilos> henninge, right, that shouldn't make a big deal, seeks usually work pretty well in memory :)
[12:00] <henninge> shouldn't random access be just as cheap there as sequential access?
[12:00] <danilos> henninge, it probably is, but code might not be optimized
[12:00] <danilos> henninge, it should be easy to check if it makes any difference :)
[12:01] <danilos> henninge, btw, have you tried doing a seek on StringIO yourself before re-opening?
[12:01] <henninge> danilos: no, I have not.
[12:01] <henninge> but it had crossed my mind
[12:02] <danilos> 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] <danilos> henninge, if it's not outrageously different, go with the simplest solution; if it is, let's find better solutions :)
[12:03] <henninge> danilos: ok, let me see what I can do.
[12:03] <danilos> henninge, fwiw, random-access might even be faster for tarfile access if implemented with some heuristics :)
[12:05] <deryck> adeuring, hi.  I took over Bug #531003 on the board, just to play with queries and follow up with bdmurray.
[12:05] <mup> Bug #531003: searchTasks with hardware_is_linked_to_bug parameter times out regularly <oops> <ubuntu-qa> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/531003>
[12:05] <adeuring> deryck: ok
[12:05] <deryck> adeuring, like you said, though, I'm not sure I see a way to improve this.
[12:06] <adeuring> 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] <adeuring> s/thoufh/thought/
[12:08] <deryck> 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] <adeuring> deryck: right...
[12:09] <deryck> and like you say, after caching, it works reasonably fast.
[12:13] <danilos> deryck, sometimes postgres chooses suboptimal joins as well
[12:13] <danilos> deryck, s/joins/query plans/
[12:13] <danilos> deryck, you can influence that with subselects usually
[12:16] <deryck> he teases and leaves....
[12:40] <deryck> I don't suppose stub is around at this hour?
[12:41]  * stub hides behind the couch
[12:41] <deryck> stub! I see you. :-)
[13:18] <gary_poster> 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] <mup> Bug #541637: searchTasks doesn't return all matching tasks?! <api> <launchpadlib :New> <Launchpad Bugs:New> <https://launchpad.net/bugs/541637>
[13:19] <deryck> gary_poster, yes, thanks!  I was going to ping you today about that one actually.
[13:19] <gary_poster> cool, deryck, on it
[13:35] <sinzui> EdwinGrubbs: bac: stand-up in 2 minutes
[13:49] <barry> 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] <barry> ?
[13:49] <barry> reloading the page shows my comment
[13:59] <sinzui> barry: I do not experience that issue. I think you got a timeout on the callback
[14:03] <barry> sinzui: ok.  i'll keep an eye on it and if it comes up again i'll file a bug
[14:13] <adeuring> stub: still around?
[14:39] <sinzui> Am I insane. Do I really see two identical WindmillTestCase classes defined in lp.testing?
[15:04] <didrocks> 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
[15:29] <bigjools> didrocks: you're best asking in #launchpad-reviews
[15:29] <didrocks> bigjools: doing that now, thanks
[15:41] <jml> !!!
[15:41] <jml> http://launchpadlibrarian.net/41290965/buildlog_ubuntu-hardy-i386.subunit_0.0.5-1~ppa1_FAILEDTOBUILD.txt.gz
[15:42] <jml> my life is strewn with cowpats from the devil's own satanic herd.
[15:48] <persia> Have you considered going into the home fueling business?
[16:12] <barry> james_w: ping
[20:06] <sinzui>  gary-lunch: ping
[20:07] <gary-lunch> sinzui: oops, not been at lunch for quite awhile now
[20:08] <sinzui> 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] <sinzui> This is what I have tried: https://pastebin.canonical.com/29442/
[20:09] <gary_poster> looking
[20:13] <gary_poster> 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] <gary_poster> 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] <gary_poster> In this case, maybe LaunchpadView actually does something interesting.
[20:15] <gary_poster> 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] <sinzui> 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] <gary_poster> sinzui: ack, like I said, it didn't look wrong, but that's the kind of thing I'm suspicious of first
[22:04] <wgrant>         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] <wgrant> Hmmm.
[22:12]  * maxb raises an eyebrow at no one complaining that lp-dev-deps is currently uninstallable on karmic
[22:39] <wgrant> Anybody around who can look at the traceback for OOPS-1539L2382?
[22:48] <beuno> wgrant, sure
[22:48] <beuno>   LocationError: (None, 'filesize')
[22:49] <beuno> wgrant, http://paste.ubuntu.com/398034/
[22:50] <wgrant> Huh.
[22:51] <wgrant> Looks like the librarian GC is being overzealous?
[23:22] <maxb> Poll for anyone who's listening: How much do you care about using versions that mention launchpad in the launchpad PPA, rather than generic ones like 0.0.5-1~ppa1 ?
[23:23]  * wgrant likes having the PPA name in there, but doesn't really care.
[23:25]  * maxb wonders if there's a ~launchpad member who could delete subunit 0.0.5-1~ppa1 (which FTBFS, so no binary packages exist) so it can be replaced with 0.0.5-1~hardy+launchpad1
[23:27] <beuno> maxb, sure, point me to it
[23:28] <maxb> https://edge.launchpad.net/~launchpad/+archive/ppa/+delete-packages?field.name_filter=subunit&field.status_filter=published&field.series_filter=
[23:28] <wgrant> maxb: Ah, you only have launchpad.Append, and that doesn't grant you deletion rights?
[23:28] <wgrant> That's unfortunate.
[23:28] <maxb> (URL by construction, since I don't have permission to visit it)
[23:29] <beuno> maxb, nuked
[23:29]  * maxb will upload a version that builds shortly
[23:29] <beuno> I'm off to dinner
[23:45]  * maxb is more than slightly surprised that we've not needed dh7 in the launchpad ppa before