[00:10] <wgrant> Were there insufficient goat sacrifices to make it work, or has it just not been done yet? Natty is suspiciously empty.
[00:14] <lifeless> it wasn't qablessed into prod, so we need a cp
[00:15] <wgrant> The disabled arch i-d-s thing? I thought that was CPd along with my disabled arch indices thing.
[00:18] <lifeless> we're talking different things ;)
[01:11] <thumper> so... any movement on the psychopg problem?
[02:00] <thumper> mwhudson: so... I've been thinking about translatePath again
[02:00] <thumper> mwhudson: I think we can safely ignore any path after a branch if it doesn't start with .bzr
[02:01]  * thumper thinks
[02:01] <mwhudson> thumper: do we care about bzr cat lp:launchpad/README not working?
[02:01] <thumper> oh maybe not
[02:01] <thumper> mwhudson: bzr cat -d lp:launchpad README works
[02:01] <mwhudson> (i'm not sure how related that is, actually)
[02:02] <thumper> I think it may break hitchhiker if we do though
[02:02] <thumper> as hitchhiker sits on the transport
[02:02] <mwhudson> thumper: also at one point http requests to loggerhead went through translatePath
[02:02] <mwhudson> not any more though
[02:02] <lifeless> what are you planning?
[02:02] <poolie> thumper: i was wondering if we should bulk-upgrade all the branches on launchpad sometime
[02:02] <poolie> 2a format came in a long time ago now
[02:02] <thumper> lifeless: I'm trying to get better errors from translatePath
[02:03] <thumper> poolie: perhaps...
[02:03] <lifeless> we should definitely bulk upgrade all the import branches
[02:03] <poolie> that'd be a good starth
[02:03] <poolie> however, some others are stacked on them, so it may get a bit complicated
[02:04] <poolie> hello thumper, lifeless, btw
[02:04] <lifeless> a feature scope using % could do that without overload
[02:04] <lifeless> poolie: yes, thats true. OTOH we have that complexity doing any upgrade.
[02:22] <wgrant> We can't ever bulk-upgrade all of Launchpad.
[02:22] <wgrant> That would break everyone's checkouts.
[02:22] <lifeless> wgrant: why?
[02:23] <wgrant> lifeless: Won't the world end if my non-richroot branch's parent becomes rich?
[02:25] <spiv> Perhaps not quite that bad, but it would cause some grief.  People would need to upgrade their local branches to be able to continue to merge or pull from the upgraded remote branches.
[02:25] <wgrant> Yes. And that's unprecedented.
[02:26] <wgrant> Bazaar's format changes suck enough (although it's pretty good now) without hosting services breaking branches without any action from the project owner.
[02:26] <spiv> Hmm, again I think that's too strong a word.  But I agree it's worth thinking about the impact before doing it.
[02:27] <spiv> (It's not unprecedented because many hosted branches have been upgraded without being able to contact every user of that branch, so people have certainly gone through this before, and the world didn't end ;)
[02:27] <wgrant> A Launchpad change means that my Ubuntu 8.04 LTS systems can no longer access my project's branches.
[02:28] <wgrant> My project was perfectly happy using pack-0.92. Nobody asked for it to be upgraded.
[02:28] <lifeless> wgrant: I think upgrading users branches would be rude
[02:28] <lifeless> wgrant: I'm not, and have never proposed that we do that.
[02:28] <lifeless> wgrant: the branches lp 'owns' though, are different IMNSHO
[02:28] <wgrant> Import branches? Sure.
[02:29] <lifeless> wgrant: and, we can certainly (and should) encourage folk to upgrade
[02:29] <lifeless> and make it easy for them to bulk upgrade
[02:29] <wgrant> Definitely.
[02:29] <wgrant> On all counts.
[02:32] <lifeless> wgrant: however, supporting pack-0.92 etc has serious caveats and consequences (like massive memory bloat) for LP
[02:33] <lifeless> wgrant: so we need to do something about that
[02:35] <poolie> lifeless: could you have a look at https://code.edge.launchpad.net/~mbp/bzr/597791-http-tests/+merge/37941
[02:35] <poolie> you don't need to read it line by line but i would like your thoughts on the general idea
[02:35] <poolie> a line-by-line readthrough would be good
[02:38] <lifeless> line 264 is against PEP8 (vertical WS between class: and the docstring)
[02:44] <poolie> :)
[02:44]  * thumper sighs
[02:45] <lifeless> poolie: the tests are a bit opaque
[02:45] <poolie> it's funny you should mention that, doesn't launchpad insist on having vws there?
[02:45] <poolie> ok
[02:46] <lifeless> I think variations.py would benefit from a module docstring with some overview & pointers in it.
[02:46] <lifeless> poolie: no, LP doesn't.
[02:46] <poolie> true
[02:46] <lifeless> [lp follows PEP8 for its docstring conventiions)
[02:47] <lifeless> one thing I can't tell is whether variations append or multiply
[02:48] <lifeless> that is given two variations that return 2 scenarios each
[02:48] <poolie> multiply
[02:48] <poolie> good point though
[02:48] <lifeless> sorry, 3 variations with 3 scenarios is it 6 or 9.
[02:48] <poolie> heh, were you going to compare 2+2 with 2*2? :)
[02:48] <lifeless> yes :P
[02:48] <thumper> any one else seeing: Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored
[02:49] <lifeless> thumper: yes, for ages.
[02:49] <thumper> what is it?
[02:49] <lifeless> there was a discussion/bug about it
[02:49] <poolie> you could have [AppendVariations(VaryByFruit, VaryByVegetable), VaryByCookingMethod]
[02:49] <mwhudson> thumper: i saw it on my arm board, of all places
[02:49] <lifeless> there is a test which deliberately triggers it.
[02:49] <poolie> it's a test for handling this in the pyrex bencode
[02:50] <poolie> lifeless: the example of concatenating them kind of points to the fact that if they were plain list-returning callables, you could more simply use itertools etc there
[02:50] <lifeless> poolie: I think this is nice.
[02:50] <poolie> but on the whole i think objects are better
[02:51] <lifeless> theres a  bit of stylistic stuff like 'their_variations' (and variations which isn't usefully different to scenarios really) that might be tweakable
[02:51] <poolie> thanks :) i'm very happy with it
[02:51] <lifeless> poolie: I think multiplying is fine, it lets you do cross product well.
[02:51] <poolie> (which is not to say it can't be improved)
[02:51] <poolie> doesn't multiplication mean cross product?
[02:51] <lifeless> yes
[02:52] <thumper> I'm slightly concerned that `bzr revno lp:~thumper/launchpad/foo` never seems to complete
[02:52] <poolie> right, the by-hand multiplication in test_http was what finally got me around to this
[02:52] <lifeless> poolie: I'd really consider using __call__ - that is, having the objects be factories.
[02:53] <poolie> rather than .scenarios()?
[02:53] <lifeless> poolie: and rather than variations, perhaps 'scenario_factories'
[02:54] <lifeless> writing that makes me wonder if instead, just a helper function which gets the scenarios would be better
[02:54] <lifeless> scenarios = multiply_scenarios(VaryByHttpClientImplementation(), VaryByHttpProtocolVersion())
[02:55] <poolie> that would be a bit more explicit
[02:55] <poolie> hm
[02:55] <poolie> bit of a question there about just when it's going to be evaluated
[02:55] <poolie> which may matter wrt registries etc
[02:55] <poolie> that is, at module load time vs later
[02:56] <poolie> of course multiply_scenarios could return a lazy multiplier
[02:56] <poolie> https://bugs.edge.launchpad.net/testscenarios/+bug/658044
[02:56] <_mup_> Bug #658044: want declarative per-test-class variations <testscenarios:New> <https://launchpad.net/bugs/658044>
[02:56] <lifeless> poolie: that sounds nice
[02:56] <lifeless> poolie: (lazy evaluator)
[02:57] <poolie> in that case i'd probably name it like an object, rather than something that sounds imperative
[02:57] <lifeless> poolie: I think there would be less code, and one less class attribute (no need for .variations)
[02:57] <lifeless> poolie: agreed (naming)
[02:57] <poolie> MultiplyScenarios(...)
[02:57] <poolie> does it support .scenarios now?
[02:57] <spiv> thumper: FWIW the test that triggers the __subclasscheck__ warning is suppressed in bzr trunk
[02:57] <lifeless> poolie: ues
[02:57] <lifeless> poolie: yes.
[02:58] <poolie> ah ok
[02:58] <lifeless> 'TestWithScenarios'.
[02:58] <spiv> Or rather, the warning is suppressed, the test is still there :)
[02:58] <poolie> i looked for that in bzr but not in testscenarios
[02:58] <poolie> that sounds better then
[02:59] <poolie> perhaps we should depend on that at some point
[03:00] <lifeless> http://bazaar.launchpad.net/~lifeless/testscenarios/trunk/annotate/head:/lib/testscenarios/testcase.py
[03:00] <poolie> ah i see, this is a bit different to bzr
[03:01] <lifeless> this is an optional helper
[03:01] <lifeless> for doing lazy expansion
[03:02] <lifeless> http://bazaar.launchpad.net/~lifeless/testscenarios/trunk/annotate/head:/lib/testscenarios/scenarios.py is the guts
[03:02] <lifeless> http://bazaar.launchpad.net/~lifeless/testscenarios/trunk/annotate/head:/lib/testscenarios/scenarios.py#L61 specifically.
[03:04] <poolie> so in that code, using generators would perhaps fit more naturally
[03:12] <thumper> spiv: so a daily build soon should fix it?
[03:13] <thumper> spiv or poolie: could one of you skype so I can explain a problem?
[03:13] <spiv> thumper: even a build of 2.3b2 should
[03:13] <thumper> spiv: which is found where?
[03:13] <spiv> I can skype, give me a moment to grab the headset.
[03:15] <thumper> spiv: I have bzr-nightly-ppa and bzr-beta-ppa and no 2.3b2
[03:19]  * spiv wonders why skype is having trouble logging in
[03:19] <spiv> thumper: yeah, I don't think we have anyone spending time to keep the PPAs fully up to date atm.
[03:19] <spiv> Ah, now it's connected.
[03:19] <thumper> spiv: you know we have recipes now right?
[03:21] <thumper> spiv: https://pastebin.canonical.com/38472/
[03:27] <poolie> are you guys ok together?
[03:32] <lifeless> poolie: yes, they have a room

[03:36] <poolie> lifeless: is there cross-product code already in testscenarios?
[03:42] <lifeless> no, there is in bzr and it should be trivially portable
[03:42] <lifeless> or even usable from bzr
[03:42] <poolie> right
[03:42] <poolie> wfm, thanks
[04:00] <thumper> $ bzr revno sftp://bazaar.launchpad.net/~thumper/launchpad/foo
[04:00] <thumper> bzr: ERROR: Not a branch: "sftp://bazaar.launchpad.net/~thumper/launchpad/.bzr/branch/".
[04:00] <spiv> lftp bazaar.launchpad.net:/> cat ~thumper/launchpad/.bzr/branch/location
[04:00] <spiv> cat: Access failed: No such file: u'/.bzr/branch' (~thumper/launchpad/.bzr/branch/location)
[04:28] <thumper> spiv: I'm watching a bzr process take up 2.5 gig of ram
[04:28] <thumper> spm: as a result of that local test
[04:29] <spiv> thumper: congratulations
[04:29] <spiv> thumper: you obviously have a fair bit of ram ;)
[04:29] <thumper> 4 + 8 swap
[04:29] <spiv> thumper: what operation is triggering this?
[04:30] <spm> thumper: ? I assume that was really aimed at sp4 vs sp1000?
[04:30] <thumper> spiv: not sure
[04:30] <thumper> spiv: well, the revno call
[04:31] <thumper> spiv: the BzrDir.open_branchV3
[04:31] <thumper> spiv: call to the server
[04:31] <thumper> spiv: pretty sure it was the 'lp-serve', u'--inet' one that was not stopping
[04:32] <spiv> thumper: related to the recursion them?
[04:32] <spiv> s/them/then/
[04:33] <thumper> yep
[04:35] <thumper> spiv: is there a way to break into the bzr process?
[04:35] <thumper> spiv: I have the pid
[04:35] <thumper> it is in the loop now
[04:35] <thumper> currently at 2.2 gig of ram and growing
[04:35] <spiv> thumper: SIGQUIT is one option, gdb is another
[04:36] <thumper> spiv: what number is siq quit?
[04:36] <spiv> SIGQUIT would be my first choice in this case
[04:36] <spiv> Ctrl-\
[04:36] <spiv> kill -QUIT
[04:36] <spiv> Pick your poison :)
[04:36] <spm> spiv: kill -DIEDIEDIEDIEDIE ?
[04:36] <thumper> in the debugger
[04:37] <thumper> hmm...
[04:37] <thumper> how can I bring the debugger to the foreground?
[04:37] <spiv> spm: that's a lot of "IE DIED" ;)
[04:38] <spiv> thumper: oh, hmm
[04:38] <spiv> With --inet?  That does seem tricky.
[04:38] <spm> spiv: some things need to be stabbed with flaming scissors while running, for extra died.
[04:38] <spiv> Hmm, I bet we can do better there.
[04:39] <thumper> hmm...
[04:39] <thumper> doesn't seem to be in the debugger at all
[04:39] <thumper> still in a tight loop
[04:39] <thumper> seems to be stable around 2.6gig of ram though
[04:39] <thumper> FWIW
[04:40] <thumper> mwhudson: got a minute for some gdb help?
[04:40] <spiv> thumper: I'd resort to gdb at this point
[04:40] <mwhudson> thumper: ok
[04:40] <thumper> mwhudson: I've killed the process, but I can regenerate at will
[04:41] <mwhudson> thumper: run gcore $pid
[04:41] <mwhudson> thumper: then follow the instructions on https://code.edge.launchpad.net/~pygdb-hackers/pygdb/trunk
[04:43] <spiv> I think just 'bt' on maverick system would be a great start in this caes
[04:43] <spiv> gdb on maverick has shiny new python smarts.
[04:43] <thumper> I've not used gdb in years
[04:45] <spiv> thumper: do you have a core file or running process?
[04:45] <spiv> thumper: gdb -c CORE; or gdb -p PID
[04:45] <thumper> $ gcore 1338
[04:45] <thumper> core.6f7KUY:1: Error in sourced command file:
[04:45] <thumper> ptrace: Operation not permitted.
[04:45] <thumper> gcore: failed to create core.1338
[04:45] <spiv> (I usually work with running processes)
[04:45] <spiv> Oh, right, maverick...
[04:46] <thumper> ptrace: Operation not permitted.
[04:46] <thumper> ?
[04:46] <spiv> there's a maverick setting you need to change
[04:46] <spiv> to relax a security setting
[04:46] <spiv> I forget what it is, but if you try to attach e.g. strace to a running process it helpfully reminds you.
[04:47] <spiv> /etc/sysctl.d/10-ptrace.conf I think?
[04:48] <spiv> echo 0 | tee -a /proc/sys/kernel/yama/ptrace_scope
[04:48] <spiv> (the latter will relax it until the next reboot)
[04:49]  * thumper has a core file
[04:50] <spiv> Ok, "gdb -c COREFILE"
[04:50] <spiv> then "bt"
[04:50] <spiv> And pastebin that; that is hopefully enough in this case.
[04:51] <spiv> Otherwise time to play with mwhudson's stuff I guess :)
[04:51] <thumper> spiv: nothing useful at all
[04:52] <thumper> spiv: http://pastebin.ubuntu.com/510610/
[04:52] <spiv> thumper: pastebin?  gdb in maverick ought to be including Python function names automatically now.
[04:53] <spiv> Oh wow, I guess you don't have python2.?-dev installed
[04:53] <spiv> Or, hmm.
[04:53] <spiv> -dbg
[04:53] <thumper> mwhudson: pygdb.mi.GdbError: No symbol table is loaded.  Use the "file" command.
[04:53] <thumper> spiv: I do have python2.6-dev installed
[04:53] <spiv> Yes, python2.6-dbg
[04:53] <spiv> For the debug symbols
[04:53] <thumper> ah
[04:54] <thumper> do I need a new core?
[04:54] <thumper> or just install dbg and try again?
[04:54] <spiv> Yep
[04:54] <spiv> Just install dbg and look at the core file again
[04:54] <thumper> yep to what?
[04:55] <thumper> 52s to go
[04:56] <spiv> Time for Dunedin to get a second wet string to the rest of the internet?
[04:56] <thumper> spiv: no change
[04:57] <thumper> should I have python-gdbm-dbg installed?
[05:00] <spiv> No, unless you really care about getting extra details in tracebacks involving the 'gdbm' module
[05:00] <spiv> (So, no.)
[05:00] <thumper> spiv: I'm not getting anything useful with gdb
[05:00] <spiv> Does gdb say anything about 'loading symbols'?
[05:01] <spiv> Or it is verbatim the same output?
[05:01] <thumper> spiv: same output
[05:01] <mwhudson> then it's not finding the debug symbols somehow
[05:01] <thumper> spiv: perhaps it needs the symbols when generating the core file?
[05:02] <spiv> thumper: no, very much not the case
[05:02] <mwhudson> thumper: when you run gdb /usr/bin/python2.6
[05:02] <mwhudson> do you get a message like:
[05:02] <mwhudson> Reading symbols from /usr/bin/python2.6...Reading symbols from /usr/lib/debug/usr/bin/python2.6...done.
[05:02] <thumper> Reading symbols from /usr/bin/python2.6...Reading symbols from /usr/lib/debug/usr/bin/python2.6...done.
[05:02] <thumper> yes
[05:02] <spiv> Ok
[05:03] <spiv> Now with that gdb process try typing "core core.1338"
[05:03] <thumper> ok
[05:03] <thumper> oh... lots of stuff
[05:04] <spiv> (It seems pretty weird that 'gdb -c CORE' is failing to load debug symbols that gdb normally finds, but so long as we can workaround it I guess we just shrug our shoulders...
[05:04] <spiv> )
[05:04] <thumper> so, can I get the contents of bt to a file?
[05:04] <thumper> there is a lot of stuff there
[05:06] <spiv> Probably, but I'd have to spend too many minutes reading gdb docs to figure it out :/
[05:08] <lifeless> spm: hey
[05:09] <lifeless> spm: do you have any word on where the restrictedlibrarian ticket is up to ?
[05:09] <thumper> spiv: actually, I could paste the first 300 levels of the stack :)
[05:09] <spiv> thumper: sure :)
[05:12] <thumper> spiv: http://pastebin.ubuntu.com/510619/
[05:13] <thumper> spiv: perhaps that makes sense to you :)
[05:16] <spiv> thumper: it's recursing during the str-ification of a NotBranchError
[05:16] <spiv> In a way that tries to open a branch
[05:16] <spiv> And causes another NotBranchError...
[05:16] <spiv> For added confusion, it's happening in a Deferred callback chain.
[05:17]  * thumper facepalms
[05:17] <thumper> spiv: bzr error or lp error?
[05:17] <thumper> spiv: or screwy interaction?
[05:18] <spiv> Screwy interaction, I think :(
[05:18] <spiv> bzr error is definitely part of it.
[05:18] <spiv> NotBranchError(..., detail=None, bzrdir=a_bzrdir) calls a_bzrdir.open_repository during string formatting
[05:19] <thumper> spiv: why?
[05:19] <spiv> Which in this case is presumably triggering a NotBranchError, via a fairly long chain of events.
[05:19] <thumper> to format the error?
[05:19] <spiv> So it can add "location is a repository" to the error message, as a hint to the user
[05:19] <thumper> in this case there is no repository with the bzrdir
[05:19] <spiv> So that someone that tries e.g. 'bzr branch PATH_TO_SHARED_REPO' gets a helpful error
[05:20] <spiv> I'll fix the bzr bug for that right now, it's pretty shallow.
[05:20] <spiv> I'm not sure if LP should do anything differently, actually.
[05:20] <thumper> yeah
[05:20] <thumper> I'm not sure what we would do
[05:21] <thumper> it then seems that python spins somewhat
[05:21] <thumper> when it has hit its limit
[05:21] <spiv> Well, it's doing nasty things
[05:22] <spiv> Like capturing a lightly-strified copy of the entire call stack
[05:22] <spiv> As part of the Twisted callback error handling
[05:23] <thumper> really?
[05:23] <thumper> that sounds kinda icky
[05:23] <spiv> It is a bit :/
[05:23] <thumper> is that twisted?
[05:23] <thumper> or us?
[05:23] <spiv> Hmm
[05:23] <spiv> That's Twisted.
[05:24] <spiv> So I wonder why NotBranchError in the first place.
[05:24] <spiv> And/or, why a_bzrdir.open_repository() would raise NotBranchError
[05:24] <thumper> spiv: could be in the translate path?
[05:24] <thumper> maybe?
[05:25] <spiv> Yeah
[05:25] <spiv> Is it raising NotBranchError itself at any point?
[05:25] <thumper>  self.assertRaises(
[05:25] <thumper>             errors.NotBranchError,
[05:25] <thumper>             BzrDir.open_containing_from_transport, transport)
[05:26] <spiv> Well, that seems fine.
[05:26] <spiv> That's a bzrdir method.
[05:26] <spiv> If a VFS method ever raised it, that would be a problem I think.
[05:27]  * thumper steps out for a minute
[05:27] <spiv> bzrlib's open_repository etc only expect the filesystem to raise filesystem errors, like NoSuchFile and PermissionDenied
[05:27] <spiv> if the filesystem ever raised something like NotBranchError I can understand it getting confused.
[05:34] <thumper> spiv: ok, so should I file a bug for any LP bits?
[05:35] <spiv> thumper: I can't think of anything specific enough
[05:36] <spiv> I did a quick grep and don't see any obvious culprits in the LP code
[05:36] <spiv> The full backtrace, all 1000 frames of it, presumably would tell us.
[05:36] <spiv> If you want to stick "sys.setrecursionlimit(150)" somewhere and regenerate the backtrace, that might be helpful
[05:37] <spiv> Hmm
[05:38] <spiv> If I make a fake bzrdir that raises NotBranchError('path', bzrdir=fake_bzrdir) I get the recursion
[05:39] <spiv> But it copes fairly gracefully
[05:39] <spiv> i.e. stringifying it just gives NotBranchError: <unprintable NotBranchError object>
[05:39] <thumper> hmm..
[05:46] <spiv> Oh, *nice*
[05:46] <spiv> It's Twisted's fault
[05:47] <spiv> Specifically, I think it's the fault of it's "safe_repr" function
[05:48]  * spiv looks more closely
[05:49] <spiv> Oh, no, it's not, phew.  But then why...?
[05:50] <spiv> Ok, so:
[05:50] <spiv>  1) I know that NotBranchError.__str__ can recurse when bzrdir.open_repository raises another NotBranchError
[05:51] <spiv>  2) I don't know why that causes an infinite loop rather than just a recursion error
[05:51] <spiv> I can fix 1)
[05:51] <spiv> But 2) is presumably still an issue in the codehosting server, and will still be lurking to bite us later.
[05:52] <spiv> Unfortunately I think it will take a fair bit of patience to debug 2)
[05:52] <spiv> So I'll fix 1) to avoid recursing
[05:52] <spiv> But it may just change your problem, rather than fix it.
[05:55] <thumper> that's a start
[05:56]  * thumper has dinner on the table
[05:56]  * spiv hmms again.
[05:57] <spiv> Oh, right, it's something like:
[05:57] <spiv> a bad error handler that can infinite loop
[05:57] <spiv> Because str(err) is raising an error
[05:57] <spiv> Which in turn trips the error handler
[05:57] <spiv> which does str(err)
[05:57] <spiv> etc
[05:58] <spiv> The question is "where is the error handler"
[06:00] <spiv> It's not that NotBranchError is particularly special
[06:00] <spiv> Except that it happens to be one of the few errors that can trigger more VFS accesses during formatting.
[06:00] <spiv> The exact error doesn't matter.
[06:13] <spiv> thumper: https://code.edge.launchpad.net/~spiv/bzr/notbrancherror-recursion-2.2/+merge/38094
[06:13] <spiv> thumper: I'd be very interested to know what happens if you apply that patch locally
[06:29] <spm> lifeless: #41379: HA upload configuration for librarian please. ??
[06:29] <_mup_> Bug #41379: partitioning in Polish: explain what K, B and F are <partman-target (Ubuntu):Invalid> <https://launchpad.net/bugs/41379>
[06:53] <lifeless> spm: yes, please do
[06:54] <lifeless> spm: [though perhaps I misunderstand your question :P]
[06:54] <spm> heh, was just identifying if that was it
[06:55] <lifeless> spm: oh, no. thats not the thing I was asking about
[06:55] <lifeless> spm: 41202
[06:57] <spm> ah right. different one. looks like it's been purty much suspended being worked on since the last update at the end of september. which given I've spent maybe 15mins on non ZOMG RT tickets in the past.... month, sounds about right.
[06:58] <lifeless> spm: its zomg in its own way
[06:59] <spm> 90+ is zomg. 89... isn't. :-)
[07:27] <poolie> lifeless: the problem with directly using a generator or similar in .scenarios is the hidden cursor within it will be shared across all the instances...
[07:27] <poolie> perhaps for things that have to be lazy we can just make it a callable that gives back an iterable
[07:28] <poolie> actually->#bzr
[08:36] <poolie> here's an interesting factoid: duplicity backups to s3 are about 5x faster with ssl turned off
[08:36] <poolie> this is pretty much just pumping bulk data intercontinentally
[09:04] <bigjools> morning all
[09:04] <wgrant> Morning.
[09:15] <mrevell> Morning
[10:48] <jml> mrevell: hi
[11:34] <stub> Is the topic out of date, or are we still having test failure issues in stable?
[11:49] <jml> I don't know.
[11:50] <jml> what's wrong with this commit message?
[11:50] <jml> All lines of log output:'Commit message [[release-criticial=bigjools][r=jml][ui=none][bug=574083] Merge fix\n\tfor branch-distro script] does not match commit_re [(?is)^\\s*\\[(?:release-critical=[^\\]]+)\\]\\s*\\[rs?=[^\\]]+\\]]'
[11:51] <jelmer_> jml: criticial?
[11:51] <bigjools> lol
[11:51] <jml> jelmer_: thanks.
[11:51] <bigjools> if I had a penny every time I did that
[13:08] <wgrant> bigjools: \o/ killing partner
[13:38] <maxb> Anyone feel like discussing what I should do in an odd vcs-imports reviewing situation? The problem is that someone asked for a debian packaging branch to be imported rooting the branch inside the "debian" directory -- so I "fixed" it.
[13:38] <maxb> But, then they emailed me saying they needed it otherwise because of bzr-builder infelicities
[13:39] <maxb> I "fixed" it because there is another branch on Launchpad built on the history with it imported the way I fixed it to.
[13:40] <wgrant> Isn't that bzr-builder thing fixed now?
[13:40] <wgrant> Maybe it's not deployed on LP yet.
[13:41] <wgrant> But that may mean that you can just ignore than for four days and then tell them to use the new bzr-builder feature.
[13:41] <wgrant> s/than/them/. what happened there, I wonder...
[13:41] <jelmer> As far as I know the nest-part fix has landed on Launchpad.
[13:42] <maxb> Ah, has it made it out as part of the new qa-blessed frequent rollouts?
[13:43] <wgrant> The UI support may have.
[13:44] <wgrant> But the slave support needs a new bzr-builder in some PPA somewhere.
[13:45] <jml> I discovered the ArchiveAdministration page today
[13:46] <wgrant> Uhoh.
[13:46] <wgrant> Do you like all the workarounds?
[13:46] <jml> well, I haven't read it in detail
[13:47] <jml> but how pleasant to have a list of all the major use cases of an important component of Launchpad
[13:47] <jelmer> maxb: I don't think it can be used in production yet, but it should be in a reasonable period of time.
[13:48] <maxb> I've sent email to the user suggesting the import remain in the form I fixed it to and requesting any followup discussion proceed on launchpad-users
[13:49] <maxb> jelmer: I'd welcome your thoughts on the oldest two vcs-imports in Pending Review state - I've looked at them and put an initial comment in the branch whiteboards
[13:51]  * jelmer takes a quick look before lunch
[13:52] <jelmer> maxb: the iceplayer one appears to've been recreated - did you take a look at it recently?
[13:52] <maxb> 20101011 maxb The origin repository is bizarrely structured. I'm not sure there's a meaningful way to import this as a branch, but it's hard to say for sure given the origin repository only has one revision.
[13:53] <jelmer> maxb: In that case, it doesn't really look all that bizarrely structured to me :-)
[13:53] <jelmer> the version directory directly under trunk is a bit strange, but not too unusual
[13:54] <maxb> jelmer: if you go up a level, and look under /unstable, they have a version directory there too
[13:54] <maxb> If the upstream people continue to do that, the vcs-import would end up being the equivalent of importing multiple versions into one tree
[13:55] <jelmer> maxb: For the jupiter branch, I agree that a root-level import doesn't make sense if we're already importing jupiter-current (apart from any other issues we might have with top-level root directories)
[13:55] <jelmer> maxb: fair enough; it's hard to tell with just one revision though.. can you perhaps one of the lp-code developers?
[13:56] <maxb> perhaps what one of the lp-code developers? :-)
[13:57] <jelmer> maxb: Sorry, I meant /ask/ one of the lp-code developers
[13:57] <maxb> right :-)
[13:57] <jelmer> anyway, lunch!
[15:45] <LPCIBot> Project devel build (102): STILL FAILING in 3 hr 50 min: https://hudson.wedontsleep.org/job/devel/102/
[15:48] <cr3> how can I set someone as administrator of a team when there are no administrator yes/no radio buttons when attempting to modify the person within the team?
[16:13] <jml> bigjools: do you know of any existing diagram kind of like this one: http://people.canonical.com/~jml/soyuz-system-diagram.jpg?
[16:15] <bigjools> jml: there is something, one sec
[16:16] <jml> bigjools: I'm talking to the new Ubuntu release manager, who's keen to understand how all everything fits together
[16:17] <bigjools> I think it's on the old internal wiki
[16:21] <bigjools> jml: and I can't find it :/  I remember cprov doing something
[16:21] <jml> bigjools: what about the thing you did for the 2008 Epic?
[16:21] <bigjools> jml: out of date but might help
[16:22] <jml> bigjools: is that on the net?
[16:22] <bigjools> it's a google doc
[16:22] <bigjools> I'll invite you
[16:28] <bigjools> jml: aha!    the presentation has got cprov's diagram embedded
[16:29] <jml> bigjools: got a link?
[16:29] <jml> oh email
[16:29] <bigjools> jml: you will get email
[16:32] <jelmer> jml: Is it public yet who the new Ubuntu release manager is?
[16:34] <jml> jelmer: Yes. Kate Stewart, aka skaet.
[17:11] <jml> can these bugs be closed now? https://bugs.edge.launchpad.net/soyuz/+bugs?field.tag=partner
[17:12] <bigjools> jml: no
[17:13]  * bigjools reminds jelmer to set bugs "in progress" ...
[17:13] <jelmer> bigjools: sorry, I'm on it.
[17:13] <bigjools> jml: I did it for you
[17:13] <bigjools> jelmer:  even
[17:18] <jml> I have to go. See you all tomorrow.
[17:21] <jelmer> Enjoy your evening jml.
[17:54] <bigjools> good night all
[19:22] <lifeless> moin
[19:27] <lifeless>           https:/​/​dev.launchpad.net/​Getting
[20:03] <maxb> Who is in charge of bzr-buildder in *-cat-lpbuildd ?
[20:04] <lifeless> interesting question
[20:04] <lifeless> cat is the sysadmin archive, so strictly them; but perhaps you mean 'who is responsible for updating it when needed' and that would be, AFAIK, the launchpad team.
[20:05] <maxb> Mainly I'd like to find out why maverick has 0.3.1 but lucid 0.2
[20:07] <lifeless> I'd guess at oversight. I think abentley has been doing a lot in this area recently, he may know.
[20:16] <lifeless> losa ping
[20:16] <lifeless> https://lpbuildbot.canonical.com/builders/lucid_db_lp/builds/304/steps/shell_7/logs/summary
[20:16] <lifeless> xvfb startup failures :(
[20:47] <bdmurray> lifeless: there is an issue getting private bug attachments via the API right?
[20:50] <lifeless> theres an intermittent issue that is being intransigent
[20:51] <lifeless> we want to deploy the token based approach asap but we're starved for LOSA time at the moment.
[20:51] <lifeless> if its not intermittent, please comment on the bug how to reproduce reliably.
[20:51] <bdmurray> I've been seeing the following: httplib2.ServerNotFoundError: Unable to find the server at lplibrarian.internal
[20:51] <bdmurray> lifeless: which bug is that?
[20:51] <lifeless> bdmurray: iz in malone somewhere ;P
[20:52] <lifeless> bdmurray: oh, private bug attachments are DC only too, for now.
[20:52] <bdmurray> lifeless: is there a timeline for fixing that?
[20:53] <lifeless> bdmurray: yes, asap. (Its been asap for a month)
[20:53] <lifeless> bdmurray: its the highest equal RT ticket we have open.
[21:07] <lifeless> bdmurray: it has been a very busy month though
[21:19] <lifeless> bbs
[21:20] <mwhudson> morning
[21:24] <bdmurray> lifeless: well sure, I was just wondering if it'd be this week, this month or ...
[21:24] <thumper> morning
[22:00] <thumper> lifeless: how often is https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html updated?
[22:20] <lifeless> thumper: 5 minutes I think
[22:20] <lifeless> thumper: I've asked urshina to run it as often as possible
[22:21] <lifeless> bdmurray: I wish I knew
[22:21] <thumper> lifeless: ok
[22:59] <wallyworld> morning
[23:26] <poolie> thumper: i'm saying, just once, in the code that runs there
[23:26] <poolie> register_transport('lp:///', ....)
[23:26] <poolie> then on the server side, any attempts to access that will be seen as having the right url, but they can be implemented differently
[23:54] <thumper> wallyworld: morning
[23:54] <wallyworld> yello