[00:28] <poolie> is it normal that i have to run 'bzr update' in download-cache as well as update-sourcecode?
[00:31] <jml> poolie: yes.
[00:37] <wgrant> rocketfuel-get does both.
[00:39] <poolie> but it's deprecated, according to some people?
[00:39] <wgrant> NAFAIK
[00:39] <poolie> spm: when lpnet is deployed, do you run 'make' in an existing tree, or a clean tree?
[00:40] <jml> poolie: I've never used it, since I felt it was a bit crappy to be working on bzr support for Launchpad and not actually using bzr to get my code
[00:40] <spm> poolie: completely clean, the process is something like:
[00:41] <spm> copy new tree as launchpad-revno-<revno>; make build in that; shutdown service; ln -s switchero (launchpad -> newshiny revno); startup
[00:41] <lifeless> mwhudson: hi
[00:41] <lifeless> mwhudson: re apache mangling; is there a bug for codebrowse?
[00:41] <mwhudson> lifeless: hi
[00:41] <spm> poolie: I grossly simplfy, but that's the gist.
[00:41] <mwhudson> ah no, i don't think so
[00:41] <mwhudson> let me search a bit
[00:41] <lifeless> mwhudson: we'll need one marked as a blocker for becoming an open id consumer
[00:42] <lifeless> mwhudson: probably needs a task on foundations
[00:42] <lifeless> not because they should do it but because they are doing the openid stuff and need to see it
[00:42] <poolie> spm that's what i thought
[00:43] <poolie> i was just trying to work out bug 680339, but
[00:43] <_mup_> Bug #680339: 'Entry' object has no attribute 'markAsDuplicate' <Launchpad Bugs:New> <https://launchpad.net/bugs/680339>
[00:43] <poolie> i suspect it's an interaction thing and not a real bug
[00:45] <wgrant> poolie: markAsDuplicate is a mutator.
[00:45] <wgrant> It's not exposed as a method; you just set the attribute.
[00:48] <StevenK> I thought that changed, depending on the API version used?
[00:49] <wgrant> Probably.
[00:49]  * jml gone again, back slightly later than UK starting time tomorrow morning
[00:50] <wgrant> But I really hope not.
[00:50] <wgrant> But probably.
[00:51] <poolie> wgrant: it was exposed as a method
[00:51] <poolie> it is now exposed as .duplicate = ...
[00:51] <StevenK> wgrant: Would you believe I still can't nail down where the spph is created for an nascent upload
[00:51] <poolie> when i first wrote my client code, the mutator didn't exist
[00:52] <wgrant> StevenK: PackageUploadSource.blahblah
[00:52] <poolie> now the method seems to have disappeared from the 1.0 api
[00:52]  * StevenK declares tea will magically point it out to him
[00:52] <wgrant> poolie: Well, did you know that Launchpad likes to make API stability guarantees without actually thinking about whether it can support them?
[00:52] <poolie> i was kind of suspecting that
[00:53] <poolie> the "api stability" thread prompted me to think about it again
[00:53] <poolie> but that turned out to be a somewhat different question
[00:55] <wgrant> AIUI the discussion basically went like this: "We need to have a stable API for Ubuntu releases to use." "OK, you can now annotate methods as being for a particular version." "OK, you must now support beta and 1.0 for 5 years, with no warning."
[00:55] <wgrant> Now we cannot change our datamodel.
[00:56] <lifeless> so
[00:56] <lifeless> thats an exaggeration, and you know it :)
[00:57] <poolie> i'm curious where those annotations go
[00:57] <lifeless> in the export() call
[00:57] <lifeless> see salgados blueprint branch, for instance.
[00:57] <lifeless> that exports only on devel (at my request)
[00:59] <wgrant> API stability guarantees are good. Simply freezing an entire API version is not.
[01:00] <lifeless> agreed
[01:00] <lifeless> EBeforeMyTime
[01:00] <wgrant> The bits of the 1.0 API that need to be stable for 5 years are probably limited to a couple of methods.
[01:00] <lifeless> perhaps
[01:03] <wgrant> StevenK: Found it yet?
[01:03] <StevenK> wgrant: Nope
[01:04] <wgrant> StevenK: It should be in queue.py somewhere.
[01:04]  * wgrant looks.
[01:04] <wgrant> PackageUploadSource.publish
[01:04] <wgrant> newSourcePublication
[01:05] <StevenK> Ah ha. There we get the SPR, so digging back for the history should be easy
[01:07] <wgrant> HA HA HA
[01:20] <thumper> gah
[01:20] <thumper> I have a test that regularly fails in ec2 but passes locally
[01:20] <thumper> s/regularly/always
[01:20] <thumper> has to do with recipe breadcrumbs of all things
[01:27] <poolie> lifeless: you're saying the export decorator controls which versions it appears in
[01:27] <poolie> that seems plausible but markAsDuplicate calls it with no parameters
[01:28] <wgrant> lib/canonical/launchpad/rest/configuration.py:    last_version_with_mutator_named_operations = "beta"
[01:28] <wgrant> So in beta, mutators appear as named operations.
[01:28] <wgrant> In 1.0 and devel they do not.
[02:12] <thumper> wallyworld_: ping
[02:12] <wallyworld_> thumper: hello
[02:12] <thumper> wallyworld_: we should have a chat
[02:12] <thumper> although I might go make a coffee first
[02:12] <wallyworld_> thumper: ok
[02:12] <thumper> sound good?
[02:12] <wallyworld_> thumper: ack
[02:24] <thumper> wallyworld_:  bzr+ssh://bazaar.launchpad.net/~thumper/launchpad/recipe-binary-builds r11904
[02:24] <thumper> TestSourcePackageRecipeView
[02:34] <thumper> ICanHasLinkedBranch(product).branch
[02:35] <thumper> ICanHasLinkedBranch(sourcepackage).branch
[02:36] <thumper> ICanHasLinkedBranch(productseries).branch
[02:39] <lifeless> [02:39] <lifeless>     Hard / Soft  Page ID
[02:39] <lifeless>      260 / 6568  Archive:+index
[02:39] <lifeless>      142 /  301  BugTask:+index
[02:39] <lifeless>       26 /  290  Distribution:+bugs
[02:39] <lifeless>       26 /  126  ProjectGroupSet:CollectionResource:#project_groups
[02:39] <lifeless>       10 /    4  Cve:+index
[02:39] <lifeless>        9 /   29  Milestone:+index
[02:39] <lifeless>        9 /   15  DistroSeries:+queue
[02:39] <lifeless>        8 /  107  Archive:+packages
[02:39] <lifeless>        8 /   12  DistroSeriesLanguage:+index
[02:39] <lifeless>        6 /    3  Person:+bugs
[02:41] <thumper> Difference: !=:
[02:41] <thumper> reference = 'Request builds for cake_recipe\nMaster Chef\nRecipes\ncake_recipe\nRequest builds for cake_recipe\nArchive:\nSecret PPA (chef/ppa)\nDistribution series:\nSecret Squirrel\nHoary\nWarty\nor\nCancel'
[02:41] <thumper> actual = u'Request builds for cake_recipe\nMaster Chef\nRecipes\ncake_recipe\nArchive:\nSecret PPA (chef/ppa)\nDistribution series:\nSecret Squirrel\nHoary\nWarty\nor\nCancel'
[02:41] <wallyworld_> lifeless: aren't you meant to be on leave?
[02:41] <lifeless> wallyworld_: I am
[02:41] <wgrant> wallyworld_: He's not very good at it.
[02:41] <thumper> lifeless: if you want something to do, fix my bug
[02:42] <thumper> lifeless: it passes for me and wallyworld_ but fails in ec2
[02:42] <lifeless> thumper: I'm not doing work
[02:42] <wallyworld_> lifeless: well fcuk off then and enjoy your break :-)
[02:42] <thumper> lifeless: no, this would be fun :)
[02:42] <lifeless> wallyworld_: I am, I've scrastched a bunch of itches in lp:testrepository
[02:42] <lifeless> and watched a movie and a half, plus judge john deed
[02:42] <lifeless> cleaned up a bit in my office
[02:43] <lifeless> and got wow reinstalled.
[02:43] <wallyworld_> lifeless: i still think you need some "downtime" :-)
[02:45] <StevenK> lifeless: O.O at the last one
[02:45] <ajmitch_> StevenK: you managed to break free from that?
[02:45] <StevenK> ajmitch_: Er, not quite
[02:45] <lifeless> StevenK: google for wine + could not fix permissions, or thereabouts - launcher.exe fail.
[02:45] <ajmitch_> let me guess, waiting impatiently for the 7th?
[02:45] <StevenK> ajmitch_: Yes :-)
[02:46] <lifeless> wallyworld_: thats why I have a long block of leave. It takes me weeks to spin down.
[02:46]  * wgrant never fell into the WoW trap.
[02:46] <lifeless> we can help
[02:46] <StevenK> lifeless: Is that what you're currently tripping on?
[02:46] <StevenK> Haha
[02:46] <lifeless> StevenK: was
[02:46] <ajmitch_> wgrant: be glad :)
[02:46] <lifeless> StevenK: thus the reinstall.
[02:46] <StevenK> lifeless: Has it downloaded the 10GiB of patches it needs?
[02:46] <lifeless> the incremental downloader is damn awesome
[02:46] <lifeless> yeah
[02:47] <lifeless> its all good, I logged in and checked its working. Still haven't decided if 'm going to get the upgrade or not.
[02:47] <wgrant> StevenK: Ah, so crazy Blizzard patches aren't just limited to SC2? When I reinstalled last week it must have reached 100% eight or nine times...
[02:47] <StevenK> wgrant: Oh no, WoW is where they perfected that
[02:48] <lifeless> wgrant: on wine or windows?
[02:48] <wgrant> lifeless: Both.
[02:51] <StevenK> ajmitch_: Does that mean you pulled yourself out of it?
[02:51] <ajmitch_> StevenK: well I stopped raiding at least, that has to count for something?
[02:51] <StevenK> Haha
[03:02] <StevenK> Neat. parallel-test #16 has been building for 2 days 18 hours
[03:02]  * StevenK kills it with fire
[03:02] <LPCIBot> Project parallel-test build (16): ABORTED in 2 days 18 hr: https://hudson.wedontsleep.org/job/parallel-test/16/
[03:10] <lifeless> ajmitch_: I found getting a new job worked wonders
[03:10] <ajmitch_> lifeless: worked wonders for getting you away from wow for a bit?
[03:11] <StevenK> A bit?
[03:11] <StevenK> Like 10 months, more like
[03:11] <lifeless> moving country helped too
[03:11] <lifeless> StevenK: 6
[03:11] <lifeless> StevenK: april
[03:13] <StevenK> lifeless: That's 7, nearly 8 :-P
[03:13] <ajmitch_> I would complain about the state of internet connectivity here, but it wasn't much different in .au I guess
[03:13] <lifeless> I had a loose heatsink then
[03:13] <lifeless> wondered why I was getting thermal dmesgs and low performance
[03:14] <LPCIBot> Project parallel-test build (17): ABORTED in 12 min: https://hudson.wedontsleep.org/job/parallel-test/17/
[03:14] <LPCIBot> * William Grant: PgTestSetup needs BaseLayer now, so set up BaseLayer and use the PID when checking that it respects LP_TEST_INSTANCE.
[03:14] <LPCIBot> * William Grant: test_mlists now invokes scripts with the correct appserver config.
[03:15] <LPCIBot> * William Grant: Fix restful-cache.txt to not depend on 'testrunner'.
[03:15] <LPCIBot> * William Grant: Fix missed rename.
[03:15] <LPCIBot> * Robert Collins: Merge wgrants fixes.
[03:15] <LPCIBot> * Robert Collins: Refactor db layer db setup/teardown to make the db available to subordinate layers.
[03:15] <LPCIBot> * William Grant: Scripts' -d arguments now properly override the DB name again.
[03:15] <LPCIBot> * William Grant: Fix two missed canonical.lp.dbname references.
[03:15]  * StevenK blinks.
[03:15] <StevenK> I didn't do that
[03:16] <lifeless> I did
[03:16] <lifeless> the branch it was testing has landed in db-stable
[03:16] <lifeless> my librarian branch is the Next Big Thing
[03:17]  * spm gibbers
[03:17] <lifeless> spm: does that mean you need gibbing?
[03:17] <wgrant> The librarian branch seems to work. There's just a couple of dozen tests that need to be dehardcoded, and another one or two which have more complex failures.
[03:18] <StevenK> lifeless: Should I change it to devel, or you've done it?
[03:18] <lifeless> StevenK: i changed it to my librarian branch
[03:18] <wgrant> The main issue after that is the SMTP server.
[03:19] <lifeless> yes
[03:19] <lifeless> bugs filed for that :)
[03:19] <wgrant> Ah, great.
[03:19] <lifeless> which interested people need to do
[03:19] <spm> lifeless: needing gibbing? that sounds a touch personal?
[03:19] <wgrant> It looks like we might have to write out ZCML... or otherwise hack around with Zope internals.
[03:20] <lifeless> spm: hey, you're the gibberer
[03:25] <lifeless> bah
[03:26] <lifeless> OperationalError: FATAL:  database "launchpad_ftest_template" does not exist
[03:26] <wgrant> Hm? Where?
[03:26] <wgrant> In a parallel run?
[03:27] <lifeless> https://hudson.wedontsleep.org/job/parallel-test/18/console
[03:27] <lifeless> theres a test somewhere that removes it
[03:30] <StevenK> lifeless: That might be fallout from using the same build slave as #17
[03:30] <lifeless> StevenK: no
[03:31] <lifeless> I filed a bug on it back a month
[03:31] <lifeless> I was hoping it had been caught
[03:36] <wgrant> Possibly test_sampledata
[03:37] <wgrant> It does a pg_restore
[03:48] <LPCIBot> Project parallel-test build (18): STILL FAILING in 33 min: https://hudson.wedontsleep.org/job/parallel-test/18/
[03:51] <StevenK> That's a bonus, it actually fails
[08:32] <adeuring> good morning
[08:54] <poolie> hi abel
[09:02] <mrevell> Hi
[09:33] <wgrant> bigjools: Morning.
[09:34] <bigjools> morning
[09:49] <wgrant> bigjools: What's the current status of the logparser?
[09:50] <bigjools> wgrant: I landed the gzip fix but we're stuck on that error I showed you
[09:50] <wgrant> Oh, right, forgot about that.
[09:50] <bigjools> steve thinks it might be the 32 bit field I am reading in overflowing but that raises the question about how did gzip itself write the field
[09:51] <wgrant> Hm? gzip rights the lowest 32 bits of the size.
[09:51] <wgrant> Anything higher is stripped.
[09:51] <bigjools> indeed
[09:51] <wgrant> s/rights/writes/
[09:52] <wgrant> It's a completely irrelevant traceback, but that probably is it.
[09:53] <bigjools> it's a Storm traceback
[09:53] <bigjools> so it's caused by writing something bad into the db
[09:56] <wgrant> I wish we could turn off write caching.
[09:56] <wgrant> So we could actually see which line it was.
[09:57] <bigjools> hmmm interesting idea
[09:57] <wgrant> ... oh.
[09:57] <bigjools> there might be a way
[09:57] <wgrant> It's a postgres integer.
[09:57] <wgrant> Which is 32-bit.
[09:57] <wgrant> That would be the problem.
[09:57]  * bigjools gets coffee to think about it
[09:57] <wgrant> Can you alter it to a bigint and see if it works?
[09:58] <wgrant> Although that means we're above the 32-bit limit, so the gzip size calculation will be screwed.
[09:58] <wgrant> Yya.
[12:11] <deryck> Morning, all.
[12:12] <bigjools> wgrant: still there?
[12:12] <bigjools> howdy deryck
[12:13] <wgrant> bigjools: I am.
[12:13] <deryck> gmb, hey, man.  I need to settle in a bit this morning and then I'll turn to that troublesome lazr-js tarball.
[12:13] <bigjools> https://launchpad.net/~openswan/+archive/openswan-testing/+packages
[12:13] <bigjools> observe and wonder
[12:13] <wgrant> Uhoh.
[12:13] <wgrant> What's broken?
[12:13] <wgrant> Why's it not published?
[12:14] <bigjools> two i386 builds ...
[12:14] <wgrant> Oh.
[12:14] <bigjools> one from a different PPA
[12:14] <wgrant> WTF.
[12:14] <wgrant> Yeah.
[12:14] <bigjools> WTF indeed.
[12:15] <gmb> deryck: Sure, no worries. I'm working on other stuff at the moment anyway.
[12:15] <deryck> gmb, ok, cool.
[12:15] <gmb> (I looked at the lazr-js stuff, decided that I didn't have enough brainjuice to comprehend the problem and thought it best to leave it til later)
[12:16] <gmb> deryck: If I can help in any way, though, let me know.
[12:16] <deryck> gmb, sure, thanks!  will do.
[12:17] <wgrant> bigjools: I recall being scared away by SPR.getBuildByArch a few months ago.
[12:18] <wgrant> There was something strange with how it determined the build given published binaries.
[12:18] <wgrant> I don't quite remember what, but it sounds relevant.
[12:18] <wgrant> Let's see...
[12:19] <wgrant> Oh, that's right.
[12:19] <bigjools> wgrant: somehow, the copy he did from his personal PPA to the openswan one  overlapped with a build in the openswan PPA
[12:19] <wgrant> It made me cry because it issues so many damn queries.
[12:19] <wgrant> bigjools: The openswan build is newer.
[12:19] <bigjools> yes
[12:20] <wgrant> Yessssss, I remember this code now.
[12:20] <wgrant> Potentially hundreds of queries per build!
[12:24] <wgrant> bigjools: Hmm. The creation date on the build appears to be ~10min after publication.
[12:25] <wgrant> Oh.
[12:25] <wgrant> No.
[12:25] <wgrant> 1:50 *before*.
[12:25] <wgrant> So it was copied, had the build created, deleted, then copied back.
[12:26] <bigjools> the first had rebuild, the second didn't
[12:26] <wgrant> Presumably.
[12:26] <wgrant> Can you confirm that?
[12:27] <bigjools> no :/
[12:27] <wgrant> Hm, the API should be helpful here.
[12:27]  * wgrant tries.
[12:31] <bigjools> new b-m running as of 30 mins ago BTW
[12:31] <wgrant> What's changed?
[12:31] <bigjools> the extra pre-build ping
[12:32] <wgrant> Oh, right.
[12:33] <wgrant> Does it work?
[12:33] <bigjools> shipova correctly failed
[12:34] <bigjools> needs more load to be certain
[12:34] <bigjools> we'll find out when the faily builds are dispatched
[12:36] <bigjools> wgrant: so I suspect he deleted that package while it had a build in progress.  Will have to play on that and see what DF does.
[12:36] <wgrant> Did you deliberately schedule the daily builds so you're asleep? :P
[12:36] <bigjools> I didn't schedule anything
[12:36] <henninge> jtv: name an arbitrary upstream project, please. ;-)
[12:37] <jtv> openobject-addons
[12:37] <jtv> If this is for verifying the migration script I'd look for at least: one with multiple series, one that's in ubuntu main, and one that's just very big—ideally of course one that has all.
[12:38] <jtv> Are you going to compare exports from staging (post-migration) to ones from production?
[12:38] <jtv> XPI won't work yet; KDE may possibly also still be broken.
[12:39] <henninge> jtv: as a start I wanted to see how the merge affects upstream translatoins.
[12:39] <henninge> openobject-addons is not linked to an ubuntu-packge, though
[12:39] <jtv> No.
[12:39] <jtv> But it's nice and large.
[12:39] <jtv> Just to make sure I'd also see if there's any effect on the Ubuntu package.
[12:40] <jtv> (For a product that _is_ linked to main packages, of course)
[12:40]  * bigjools -> fud
[13:04]  * henninge lunches
[14:20] <bigjools> wgrant: argh
[15:22] <gary_poster> abentley, hi.  Do you happen to know what would happen to a bzr checkout of a branch that is upgraded to 2a after the checkout?  Would bzr up fix it, or would devs need to blow the branch away and check it out again?
[15:24] <abentley> gary_poster: bzr up would not revert it to the previous format.  You'd need to upgrade the branch or downgrade the checkout.  You can downgrade the checkout by blowing it away and re-checking out, or using "bzr upgrade --FORMAT".
[15:24] <lifeless> bzr upgrade should work - we designed it to handle most cases.
[15:25] <gary_poster> abentley: sorry, I meant the original branch was upgraded, but ok, thanks lifeless, sounds like we can make it work one way or another.
[15:25] <abentley> lifeless: well, he was asking about "bzr up", which is "bzr update" IIRC.
[15:26] <gary_poster> that's correct abentley
[15:26] <gary_poster> the story is this:
[15:26] <gary_poster> I check out the download-cache, which is not 2a
[15:27] <gary_poster> I update the launchpad branch of download-cache to 2a
[15:27] <gary_poster> what do I do now to make my local checkout happy?
[15:27] <abentley> gary_poster: "bzr upgrade" in your checkout should do the trick.
[15:27] <gary_poster> ok awesome, thanks abentley
[15:28] <gary_poster> trying :-P
[15:31] <gary_poster> gmb, deryck, did you get the lazr-js version mismatch resolved?
[15:32] <deryck> gary_poster, heh.  I literally *just* worked this out. :-)
[15:32] <gary_poster> heh, ok :-)
[15:32] <deryck> gary_poster, I believe http://pastebin.ubuntu.com/537940/ shows the issue.
[15:32]  * bigjools dances around the room, I finally sorted out buildd-manager timeouts
[15:32] <Ursinha> flacoste, hi
[15:33] <gary_poster> deryck: ah-hah, yes, I agree
[15:33] <deryck> gary_poster, so I'm fixing lazr-js now and will roll a new tarball.
[15:34] <gary_poster> cool deryck.  /me is sympathetic to your many woes with this stuff :-/
[15:34] <deryck> thanks. :-)
[15:35] <deryck> it's been so amazingly painful, I've quit complaining or worrying about it really
[15:35] <gary_poster> probably a good idea. :-
[15:36] <deryck> rockstar`, you around?
[15:36] <bigjools> anyone know if I can turn off caching in storm so the traceback I get on a store flush is attached to the code that caused it?
[15:37] <bigjools> ah nm
[15:41] <gary_poster> Can I have a volunteer to try upgrading your download cache to see if these instructions work for you?  Assuming you have a checkout (which rocketfuel uses), you would do a bzr upgrade followed by a bzr up.  It works for me, but I own the LP branch.  Could someone verify that it works for them too before I send an email out?
[15:41] <abentley> bigjools: mazel tov!
[15:42] <bigjools> abentley: I'm not jewish but thanks :)
[15:44] <bigjools> abentley: feel free to push ahead with your recipe changes
[15:44] <bigjools> I'm landing another branch later that makes all the built file downloads asynchronous
[15:45] <abentley> bigjools: Cool.  Does this mean we can drop this rlimit on recipe memory use?
[15:46] <bigjools> abentley: I don't know, we could try and see what happens.  The worst is that the builder blows up and the manager detects that and fails it
[15:46] <abentley> bigjools: that sounds appropriate.
[15:46] <bigjools> abentley: we need to address the root cause though, is it bzr that eats memory when checking out those big branches?
[15:48] <abentley> bigjools: Yes.  Though another cause is we're using a version of bzr that is 2x worse in that regard.
[15:48] <bigjools> ugh
[15:56] <deryck> rockstar, hey, dude.  If you can spare a moment, can you review  https://code.edge.launchpad.net/~deryck/lazr-js/fix-build-assuming-branch/+merge/42130 ?
[15:57] <rockstar> deryck, did you see my email about this?
[15:57] <deryck> rockstar, yeah, just replied.  That was my plan, too.
[15:58] <rockstar> deryck, okay.
[16:22] <bigjools> gary_poster: I am upgrading mine now, I'll let you know
[16:22] <gary_poster> thanks bigjools
[16:24] <bigjools> gary_poster: seems fine here
[16:24] <gary_poster> great, thank you bigjools
[16:25] <bigjools> my pleasure
[16:43] <bigjools> gary_poster: can I tap you for some help now please? :)
[16:44] <gary_poster> bigjools: sure :-)
[16:45] <bigjools> gary_poster: http://librarian.dogfood.launchpad.net/57530918/1z7LhiYuLtwxWSJXAxHNvbyksXZ.txt
[16:46] <bigjools> that's an error from the apache log parser
[16:46] <bigjools> however i've got no idea what's causing it as the trace is not particularly useful :/
[16:46] <gary_poster> ah, errors during the commit phase are always fun
[16:46] <bigjools> I've tried setting the storm cache size to zero but no difference
[16:47] <bigjools> so if you can offer any help here that'd be great :)
[16:48] <gary_poster> so, bigjools, do I assume correctly that this is some error received under more-or-less unknown circustances, and we don't know how to dupe?
[16:49] <bigjools> gary_poster: I can dupe easily
[16:49] <bigjools> it's processing the production logs that I copied to dogfood
[16:50] <gary_poster> ah ok
[16:53] <gary_poster> bigjools: I'd do the fairly obvious as a first step and try to see what the args to execute are.  If I had to guess, you are trying to store a number that is too big for the DB columb
[16:53] <gary_poster> column
[16:53] <gary_poster> I'd see what the args are by hacking the egg
[16:53] <gary_poster> Because I'm evil that way
[16:53] <bigjools> yeah, that much is obvious I think.  I suspect it's the download counts themselves
[16:53]  * bigjools breaks an egg
[16:55] <bigjools> I presume that DataError is from psycopg
[16:55]  * gary_poster wonders if the re-raise-an-exception-with-the-original-exception in Py 2.7 (IIRC) would make it easier to have reasonable behavior in situations like this, so that you can actually have a traceback that tells you what is going on
[16:56] <gary_poster> yeah, think so.  there is a DataError in that package
[16:57] <bigjools> useful tracebacks?  sounds...useful :)
[16:58] <james_w> does LP_DEBUG_SQL_EXTRA or whatever not work here?
[17:04] <bigjools> james_w: it depends on whether the error is from psycopg or the pg server
[17:05] <bigjools> I'm not sure where it logs, but I might try it if I am desperate, the log will be swamped.
[17:17] <bigjools> gary_poster: so, this is what is failing: args = ('UPDATE ParsedApacheLog SET date_last_parsed=%s, bytes_read=%s WHERE ParsedApacheLog.id = %s', ('2010-11-29 17:13:54.534869+00:00', 2623267714L, 802))
[17:18] <gary_poster> bigjools: looks big. ;-) have you already looked up the ParchedApacheLog table to see what the constraints are?
[17:18] <bigjools> looks like a signed integer overflow
[17:19] <gary_poster> heh, ParsedApacheLog
[17:19] <gary_poster> ParchedApacheLog needs water
[17:19] <bigjools> :)
[17:19] <bigjools> that could be a bigint (?)
[17:19] <bigjools> it's a big freaking log file
[17:20]  * gary_poster will try to find table, but has little Postgres fu atm
[17:22] <bigjools> gary_poster: http://www.postgresql.org/docs/7.4/interactive/datatype.html#DATATYPE-INT
[17:23] <gary_poster> bigjools: right, and this appears to be an integer.  bigint seems to be the way to go if this is not a "rethink the problem" sign
[17:25] <gary_poster> bigjools: is there a reason to not make it a bigint?
[17:25] <bigjools> gary_poster: I can't think of one
[17:25] <gary_poster> then sounds like a win :-)
[17:25] <bigjools> the file it's falling over on is a gzip which is 189M itself
[17:26] <gary_poster> heh
[17:26] <gary_poster> so is it worth doing step-back sorts of questions?
[17:26] <gary_poster> otherwise, +1 on going with a bigint change
[17:27] <bigjools> well it's mainly a question of how big the logs get
[17:27] <bigjools> and if this is a one-off, we can split the log up
[17:27] <gary_poster> well, presumably we'd want to do that in an automated way
[17:28] <gary_poster> why do we care about the precise number of bytes?
[17:28] <bigjools> no idea!
[17:28] <gary_poster> heh
[17:29] <gary_poster> ah, it's to determine if we've read the whole thing or not, it looks like
[17:29] <bigjools> yeah, just saw that too
[17:30] <bigjools> hmmm, I think bigint is safer anyway
[17:30] <bigjools> I think it will Just Work, no Python changes?
[17:30] <gary_poster> bigjools: looks that way to me, yes
[17:31] <bigjools> okidoki, I'll get it sorted
[17:31] <gary_poster> cool
[17:31] <bigjools> thanks gary_poster
[17:31] <gary_poster> np, thank you :-)
[17:31] <bigjools> dogfood FTW
[17:44] <bigjools> oh man, pushing db-devel branches is ball-achingly slow now
[17:45] <lifeless> bigjools: setup the script
[17:45] <bigjools> lifeless: que?
[17:45] <lifeless> I sent a python script to fix it to the dev list
[17:45] <lifeless> days ago :)
[17:45] <bigjools> seems like I missed that
[17:46] <lifeless> in the thread where thumper announce the lp:launchpad change
[17:46] <lifeless> needs someone to do a rt and shepard it through
[17:46] <bigjools> lifeless: I didn't understand who or where it has to run
[17:47] <bigjools> and if it needs something like this running, why don't we just go back to how it was
[17:47] <lifeless> because the way it was causes lots of grief we can't fix.
[17:47] <lifeless> the performance, we can fix.
[17:48] <bigjools> I didn't see much evidence of grief, just a couple of pebkac moments
[17:48] <bigjools> anyway ...
[17:48] <lifeless> alternatively
[17:49] <lifeless> we could stack db-stable on stable
[17:49] <lifeless> thumper: ^
[17:49]  * lifeless shrugs
[17:49]  * lifeless does the on leave dance
[17:50] <bigjools> lifeless: step away from the laptop
[17:55]  * lifeless watches the mentalist and hacks on testtools
[17:56] <lifeless> I love the roomba, its really quite effective
[17:56] <jelmer> 'morning lifeless
[17:56] <lifeless> hi
[17:57] <bigjools> lifeless: I wanted one of those and someone warned me off it!
[17:58] <lifeless> bigjools: they were jealous :)
[17:58] <bigjools> lifeless: no, they already had one!
[17:58] <jelmer> lifeless: which generation do you have?
[17:58] <jelmer> mine has a fondness for cables, I can't leave it alone
[17:58] <lifeless> jelmer: 4 weeks old
[17:58] <bigjools> heh
[17:59] <bigjools> lifeless: timeouts in b-m are no more \o/
[17:59] <lifeless> it will wind them up, but loose cables are fugly anyway, so just routing them along the wall and putting U restraints in is sufficient
[17:59] <lifeless> bigjools: congrats
[17:59] <bigjools> that was a *nasty* bug
[17:59] <bigjools> and I am going to celebrate with a beer now, good ngiht
[17:59] <lifeless> cody reckons theres more to it
[17:59] <lifeless> I reckon fixed is grand
[17:59] <bigjools> well if he wants to contribute something concrete then I'll listen ;)
[18:00] <elmo> bigjools: what was the problem?
[18:00] <bigjools> elmo: the problem is still there, I just worked around it
[18:00] <elmo> oh, I see
[18:00] <bigjools> it sends a dummy connection before the real work starts
[18:00] <bigjools> then waits for it to either work or time out
[18:01] <cody-somerville> I believe the hypothesis was that Xen guests drop the first packet or something?
[18:01] <bigjools> I still see the timeouts in the log but we don't chuck the toys out the pram now
[18:01] <bigjools> cody-somerville: that's the behaviour I was seeing, but only a) randomly, b) when we connect *immediately* after the guest is reset
[18:02] <bigjools> there's some interesting stuff on google about xen and dropped packets
[18:02] <bigjools> anyway, I have to run
[18:02] <bigjools> g'night all
[18:08] <lifeless> jml: hi
[20:11] <cr3> is there a preferred xml parser in launchpad? minidom, expat, cElementTree, etc.?
[20:18] <thumper> abentley: bzr+ssh://bazaar.launchpad.net/~thumper/launchpad/recipe-binary-builds
[20:19] <thumper> TestSourcePackageRecipeView
[20:29] <lifeless> cr3: anything-but-xml ?
[20:31] <cr3> lifeless: heh, I'd normally agree with you, but I'm helping with another project which uses junit xml files and I usually try to inspire myself from the tools used by launchpad :)
[20:32] <lifeless> cr3: outputting or reading?
[20:32] <cr3> lifeless: just reading
[20:32] <cr3> lifeless: come to think of it, you might already have something in subunit
[20:32]  * cr3 looks
[20:32] <lifeless> mmm, I don't htink there is a junit library for python yet - all the code I've seen is like junitxml - output only.
[20:32] <lifeless> however
[20:33] <lifeless> if you are writing parsing support, let me encourage you to submit patches to python-junitxml, I'd be happy to have a parser in there.
[20:33] <cr3> lifeless: ugh, I really don't like the print of xml strings in junitxml :(
[20:33] <lifeless> if the project is python based they may be using subunit anyway and only doing xml casting for hudson
[20:34] <lifeless> cr3: anyhow to answer the qyestion
[20:35] <lifeless> using anything baked into python is going to be tolerable
[20:35] <lifeless> though I'm fairly sure that modelling junit in launchpad would be a mistake ;)
[20:36] <lifeless> jml: https://code.launchpad.net/~lifeless/testtools/listtests/+merge/42166 :) - coming after that, load-list.
[20:36] <cr3> lifeless: different project with the server team
[20:37] <cr3> lifeless: but, for the sake of future considerations, I agree with you. if there's anything junit related, it would be client side
[20:39] <lifeless> cr3: Seriously though, if you do write python modelling code for junit, please supply patches to python-junitxml, I'd be very happy to have a reader exist there.
[20:41] <cr3> lifeless: sure thing
[20:47] <thumper> WARNING:root:Memcache set failed for pt:testrunner:lp/registry/templates.....  WTF??
[20:47] <thumper> seeing lots of these
[20:48] <lifeless> memcache isn't running ?
[20:51] <thumper> I'm running tests
[20:51] <thumper> why isn't it running?
[20:52] <lifeless> dunno, its just a thought
[20:53] <thumper> lifeless: I had that thought too, but not sure why it isn't running
[20:55]  * thumper sighs
[20:55] <thumper> lifeless: the output of --list-tests can't be fed back into --load-list
[20:59] <lifeless> thumper: doctests?
[20:59] <thumper> lifeless: yes, and others
[20:59] <lifeless> https://bugs.launchpad.net/launchpad-foundations/+bug/682772
[20:59] <_mup_> Bug #682772: doctest construction generates duplicate test ids <Launchpad Foundations:New> <https://launchpad.net/bugs/682772>
[20:59] <thumper>   test_unknown_baseurl (lp.bugs.tests.test_bugwatch.SFExtractBugTrackerAndBugTest)
[20:59] <thumper> is another
[20:59] <lifeless> thumper: what else?
[20:59] <thumper> lifeless: abentley helped me debug my test issue a little, and it is a test isolation problem
[20:59] <lifeless> that should work, if thats the test id; its an unusual id but no reason it wouldn't work.
[20:59] <thumper> so I was trying to bisect
[21:00] <thumper> lifeless: it isn't working
[21:00] <lifeless> thumper: why doesn't it work ? [also, file a bug :)]
[21:00] <thumper> lifeless: I don't know, but it just isn't running them
[21:00] <thumper> lifeless: file a bug on what?
[21:00] <lifeless> launchpad-foundations
[21:01] <lifeless> whomever analyses further (not me, I *am* on leave), can move it to some other project if needed - but its probably something in LP.
[21:01]  * thumper sighs agani
[21:02] <Guest66935> lifeless: in bug 638924, you mention that bugs and milestones have existing off-by-default eager loading. I don't know if I'm missing something, but the only eager loading I see for bugs is the indexed_messages attribute, and I don't see any eager loading for milestones.
[21:02] <_mup_> Bug #638924: Milestone:+index timeouts with many bugs <pg83> <timeout> <Launchpad Registry:In Progress by edwin-grubbs> <https://launchpad.net/bugs/638924>
[21:03] <EdwinGrubbs> hmm, I wonder why I was Guest66935.
[21:04] <jelmer> EdwinGrubbs: freenode will rename you when you fail to identify in time
[21:28] <jelmer> bac: Hi!
[21:28] <bac> hi jelmer
[21:29] <jelmer> bac: Thanks for handling CHR today. I noticed you assigned the recipe build issues to Soyuz, they should actually be in launchpad-code.
[21:29] <gary_poster> bac, you back in the states?
[21:29] <bac> jelmer: oh, sorry
[21:29] <bac> gary_poster: yep
[21:29] <gary_poster> cool, bac.  hope it was a good trip
[21:29] <bac> gary_poster: yeah, it was.  glad to be home.
[21:30] <jelmer> bac: No problem, just thought I'd mention it if there are any more.
[21:30] <gary_poster> Great.
[21:30] <bac> jelmer: no more.  thanks for the heads up.
[21:35] <mars> thumper, ping
[21:35] <thumper> mars: hi
[21:36] <mars> Hi thumper
[21:36] <mars> thumper, I was just looking at r11995 of devel, which just got merged into db-devel, and started dying there
[21:36] <thumper> mars: yes...
[21:37] <thumper> mars: my question would be "what else changed around that time?"
[21:37] <mars> thumper, do you see any way that your change may be related?  The suite has failed in a similar place twice in a row
[21:37] <thumper> because that revision touches exactly zero to do with the librarian
[21:37] <thumper> mars: similar, but not the same
[21:38] <mars> yep
[21:39] <mars> thumper, thank you for the info
[21:39] <thumper> np
[21:39] <mars> 'what else changed' is a good question.  But according to buildbot - nothing else changed? :(
[21:40] <lifeless> EdwinGrubbs: hi
[21:40] <lifeless> EdwinGrubbs: searchTasks has eager loading support
[21:41] <lifeless> EdwinGrubbs: and theres an eager load flag I added when improving blueprints performance a couple of months back
[21:44] <gary_poster> deryck: is there a generic "our windmill tests suck" bug?  If there is, I figure you'd know :-) (I would add https://bugs.launchpad.net/launchpad-foundations/+bug/681817 to the list if so?)
[21:44] <_mup_> Bug #681817: lp.registry.windmill.tests.test_team_index.TestTeamIndex.test_addmember fails intermittently <Launchpad Foundations:New> <https://launchpad.net/bugs/681817>
[21:59] <EdwinGrubbs> lifeless: is it prejoins parameter for searchTasks()? That would enable to pull in the BugTask.assignee, but it would be less straightforward to pull out the info from the ValidPersonCache.
[22:00] <lifeless> vpc isn't needed
[22:00] <lifeless> what you need is Person._validity_clauses
[22:02] <lifeless> yes, prejoins is it, I think.
[22:02] <lifeless> for bugtasks
[22:03] <lifeless> see Person._validity_queries
[22:03] <lifeless> for a reused code fragment that will handle validity checks
[22:03] <lifeless> that is in fact used from milestones in milestone prejoining
[22:04] <lifeless>  - grep for it
[22:04] <lifeless> read a bit, theres a lot of unrefactored code, you'll need to page it into your head to see how the bits hang together (sadly)
[22:04] <lifeless> its generally taken me a couple of hours to find a good place to push on, when making these changes.
[22:04] <deryck> gary_poster, no, there isn't a single bug for the issue.  Just individual bugs on trouble tests.
[22:04] <deryck> gary_poster, we should probably use a tag
[22:04] <lifeless> but it gets better each time
[22:05] <gary_poster> ack thanks deryck .  ok, will start with "windmill" ?
[22:05]  * lifeless trolls: windfail
[22:05] <deryck> heh
[22:05] <lifeless> or perhaps failmill
[22:05] <gary_poster> :-P :-)
[22:05] <deryck> windflail
[22:06] <deryck> gary_poster, yeah, just windmill for now works
[22:06] <gary_poster> ok
[22:07] <deryck> ok, out for my evening.  Until tomorrow all.
[22:16] <wgrant> Grarrrrr.
[22:17] <mwhudson> morning william
[22:17] <lifeless> henninge: hai
[22:17] <lifeless> bah
[22:17] <lifeless> wgrant: hai
[22:17] <henninge> ;-)
[22:18] <henninge> hi wgrant ;)
[22:18] <wgrant> Bug #682738
[22:18] <_mup_> Bug #682738: Split the PPA publisher into public/private processes <ppa> <soyuz-publisher> <Soyuz:Triaged> <https://launchpad.net/bugs/682738>
[22:18] <wgrant> Grarrring at the response to that.
[22:18] <lifeless> mine or bigjools?
[22:19] <wgrant> bigjools.
[22:20] <lifeless> well, say so :)
[22:20] <wgrant> Already did.
[22:20] <lifeless> in the bug ?
[22:20] <wgrant> Yeah.
[22:51] <LPCIBot> Project devel build (259): FAILURE in 3 hr 46 min: https://hudson.wedontsleep.org/job/devel/259/
[22:51] <LPCIBot> * Launchpad Patch Queue Manager: [r=henninge][ui=none][no-qa] Convert some webservice tests for
[22:51] <LPCIBot> blueprints into model tests.
[22:51] <LPCIBot> * Launchpad Patch Queue Manager: [r=mwhudson][ui=none][bug=146389] Start exposing ISpecification and
[22:51] <LPCIBot> IHasSpecifications attributes on the webservice API.
[22:52] <wgrant> Hah, ENOSPC
[23:21] <flacoste> wallyworld, thumper: are you guys doing anything special for performance Tue?
[23:21] <thumper> flacoste: no, I'm attempting to find out why I have test isolation failures
[23:22] <flacoste> yeah, that seems sensible
[23:22] <wallyworld> flacoste: not today, i've got a branch to finish and another to start after that
[23:34] <wallyworld> wgrant: seems a build upload is stuck, any ideas? https://launchpad.net/~nova-core/+archive/trunk/+build/2069633
[23:35] <wallyworld> wgrant: it says it finished building over an hour ago
[23:35] <wgrant> wallyworld: Ugggh.
[23:35] <wgrant> Binary builds aren't meant to get stuck :(
[23:35] <wgrant> Can you see if others have been uploading?
[23:35] <wallyworld> not sure how to do that :-)
[23:37] <wallyworld> wgrant: can you tell me where to look?
[23:39] <wgrant> wallyworld: Can you look for process-upload.py logs from cesium?
[23:39] <wallyworld> wgrant: will do
[23:39] <wgrant> Argh, the daily builds have just hit.
[23:40] <wgrant> but they seem to be running OK.
[23:40] <wgrant> THere was a binary build uploaded <30 minutes ago.
[23:40] <wgrant> So it's not a general problem.
[23:40] <wgrant> Any errors in the p-u log?
[23:40] <wallyworld> wgrant: looking....
[23:40] <spm> wgrant (who has not yet started with us...): ref https://bugs.launchpad.net/soyuz/+bug/663562 this appears to have bit again on linux 2.6.24-28.81 in hardy. anything I can poke that may give more useful info?
[23:40] <_mup_> Bug #663562: duplicate orig for "linux" package in hardy <soyuz-core> <soyuz-security> <Soyuz:Incomplete> <https://launchpad.net/bugs/663562>
[23:42] <wgrant> spm: Grar. We'll have to recowboy.
[23:42] <wgrant> I was hoping a real Soyuz person would fix the data before we had to do this again.
[23:43] <wgrant> spm: Do you need a new patch?
[23:43] <spm> there are no real soyuz persons. they're unreal.
[23:43] <spm> wgrant: I suspect so
[23:44] <wgrant> spm: http://pastebin.ubuntu.com/516480/ is what I gave mbarnett last time, and it still works fine.
[23:44] <wgrant> Cowboy it on cocoplum.
[23:44] <wgrant> And get jdstrand to use unembargo-package.py
[23:44] <spm> hookay, ta
[23:45] <wgrant> Myes.
[23:45] <spm> is that something we apply, get the unembargo'd, then revert? or is safe to leave? or?
[23:45] <wgrant> And then uncowboy it. Preferably in quick succession.
[23:45] <spm> great minds.
[23:45] <wgrant> Not safe to leave, no.
[23:45] <spm> it didn't look it, just looking at the removals
[23:46] <wallyworld> wgrant: logs appear to indicate that the ulpoad of the nova ppa went ok. there's some process messages and then "Finished Checking Upload"
[23:46] <wgrant> wallyworld: Yay... might need someone with both log access and uploader knowledge to look at it tonight.
[23:47] <wgrant> spm: Huh?
[23:47] <wgrant> Oh, I see.
[23:47] <spm> yeah - rm'ing those checks was setting off alarm bells for me
[23:48] <wallyworld> wgrant: can i check anything else? this is in response to a question on #launchpad so i'd like to be able to tell them something if possible
[23:48] <spm> and that's *before* coffee too
[23:48] <wgrant> As long as no AAs are doing any copying at the moment (it's rare), it should be fine.
[23:49] <wgrant> wallyworld: Not entirely sure. If the uploader log looks fine, there's something pretty broken.
[23:49] <wgrant> Because there are no binaries.
[23:50] <wallyworld> wgrant: want me to pastebin the log info just so you can eyeball it?
[23:50] <spm> wgrant-aaaaaa.patch <== it seems like a suitable name to give this patch
[23:50] <wgrant> wallyworld: Probably a good idea.
[23:50] <wgrant> spm: Yep.
[23:51] <spm> dry-run applies cleanly. I'll do the juju when jdstrand is around again. thanks muchly wgrant!
[23:51] <mbarnett> hah, i was totally PMing spm this in a far less intelligible way.   Perhaps i should pay attention to what's going on around me...
[23:51] <spm> NEVER
[23:51] <mbarnett> okay, good.
[23:52]  * mbarnett goes back to staring blankly at the floor.
[23:52] <spm> I'd suggest you're a crazy texan, but you might pull a gun on me
[23:52] <wallyworld> wgrant: https://pastebin.canonical.com/40234/
[23:52] <wgrant> wallyworld: That's private.
[23:54] <wallyworld> wgrant: what's the public url?
[23:54] <wallyworld> wgrant: nevermind, found fit
[23:54] <wgrant> paste.ubuntu.com
[23:55] <wallyworld> wgrant: http://paste.ubuntu.com/538151/
[23:58] <wgrant> wallyworld: Those are different builds (same package, different series). Anything mentioning 2069633?
[23:58]  * wallyworld looks