[00:02] <mwhudson> thumper: is there a bug report for the fact that i can be requested to review a branch i can't see?
[00:03] <thumper> mwhudson: probably
[00:03] <lifeless> mwhudson: I don't remember one
[00:04] <thumper> it rings a vague bell
[00:06] <mwhudson> yeah, me too
[00:10] <mwhudson> thumper: can't you actually fix https://bugs.edge.launchpad.net/launchpad-code/+bug/624009 now?
[00:10] <_mup_> Bug #624009: Email should not be sent for new WIP merge proposals <code-review> <email> <Launchpad Bazaar Integration:In Progress by thumper> <https://launchpad.net/bugs/624009>
[00:10] <thumper> yeah...
[00:10] <thumper> it is still showing on our kanban board :)
[00:10] <mwhudson> and my bug is there https://bugs.edge.launchpad.net/launchpad-code/+bug/330290
[00:10] <_mup_> Bug #330290: Can request a review from someone who can't see the merge proposal <code-review> <confusing-ui> <privacy> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/330290>
[00:31] <mwhudson> $ time ./bin/py -c pass
[00:31] <mwhudson> real	0m0.610s
[00:31] <mwhudson> that's quite slow...
[00:33] <mwhudson> $ strace ./bin/py -c pass 2>&1 | grep -c stat
[00:33] <mwhudson> 19347
[00:33] <mwhudson> that's quite a lot of stats
[00:33]  * mwhudson wonders if this has regressed again
[00:37] <lifeless> buildout ftw
[00:37] <lifeless> ?
[00:37] <mwhudson> yeah, to some extent certainly
[00:37] <lifeless> (by which I mean pth files, egg lookups etc)
[00:37] <mwhudson> stat()ing /home/mwh/canonical/checkouts/trunk/eggs/RestrictedPython-3.5.1-py2.6.egg three times seems a bit silly
[00:37] <lifeless> that stack needs to be tuned and optimised for everyones sske
[00:39] <mwhudson> there is this pattern of stats for every egg afaics: http://pastebin.ubuntu.com/515317/
[00:44]  * thumper has errands in town, back soonish
[01:00] <wallyworld> lifeless: can you please look at https://pastebin.canonical.com/38714/
[01:00] <wallyworld> do you agree with the approach?
[01:00] <lifeless> mmm
[01:01] <lifeless> a few concerns
[01:02] <lifeless> 'config' is establish as an idiom meaning 'the current config'
[01:02] <lifeless> so overloading that will confuse people
[01:02] <lifeless> lets not do that
[01:02] <wallyworld> so i just don't use the alias?
[01:02] <lifeless> secondly, testrunner-appserver is hopefully deletable
[01:02] <lifeless> see the current thread on the list
[01:02] <lifeless> even if isn't deletable, it won't be usable because its still going to be static
[01:03] <lifeless> that said, I'd expect that individual tests *already* are running in that config, aren't they ?
[01:03] <wallyworld> not sure. i can check.
[01:03] <lifeless> (if not, how are they managing to connect at all ?)
[01:04] <wallyworld> one of the ones i'm looking at to start is lib/canonical/launchpad/doc/launchpadlib.txt
[01:04] <lifeless> if the answer is 'a subprocess is run in that config' then the approach of instantiating a specific config to let us refer to the config the external process is using makes sense, but lets not make it a global
[01:04] <lifeless> for tw oreasons
[01:04] <lifeless> two reasons
[01:05] <lifeless> firstly, I'm this || close to sending in a patch to dynamically generate configs in the test run, so any global like that will be stale
[01:05] <lifeless> secondly we have way too many globals, lets reduce them.
[01:05] <wallyworld> sure, i was trying to fit in with how stuff had been done previously
[01:06] <lifeless> I appreciate that :)
[01:06] <lifeless> and I'm glad -very glad- you're looking at this
[01:06] <wallyworld> i can just create a config instance on the fly: config = CanonicalConfig('testrunner-appserver')
[01:06] <lifeless> something like
[01:06] <lifeless> appserver_config = BaseLayer.getAppserverConfig()
[01:06] <lifeless> is probably whats needed
[01:07] <lifeless> the hard coded string there would be a problem
[01:07] <wallyworld> ok. my exposure to this stuff is still very limited :-)
[01:07] <lifeless> mine too
[01:08] <lifeless> I started looking at the config system code on sunday :)
[01:08] <wallyworld> so the BaseLayer.getAppServerConfig() should return me the correct config instance?
[01:08] <wallyworld> i started 30 minutes ago :-)
[01:08] <lifeless> I think that that will work
[01:08] <wallyworld> ok. thanks. i'll suck it and see
[01:09] <wallyworld> there's quite a few hard coded urls to fix. that's why i wanted to ask first :-)
[01:10] <thumper> wallyworld: want a chat?
[01:10] <lifeless> wallyworld: yeah
[01:10] <lifeless> wallyworld: what I'm suggesting will give us one place to change if we need to change
[01:11] <lifeless> \o/ databasefixture has landed
[01:11] <wallyworld> thumper: ok
[01:12] <wallyworld> lifeless: that's what i was looking for too. i'll let you know how i get on. thanks for the input
[01:33] <thumper> lifeless: compile failed?
[01:34] <lifeless> thumper: did it?
[01:34] <thumper> lifeless: aye
[01:35] <thumper> lifeless: can you parse the error?
[01:36] <lifeless> Could not locate /srv/buildbot/slaves/launchpad/lucid-devel/build/orig_sourcecode/eggs/setuptools-0.6c11-py2.6.egg/setuptools/package_index.py:155: UserWarning: Unbuilt egg for ClientCookie [unknown version] (/usr/lib/python2.6/dist-packages)
[01:36] <lifeless> ops issue i think, machine was being upgraded or some such
[01:37] <spm> hmm?
[01:40] <mwhudson> lifeless: i presume the plan after edge and lpnet are running the same code is to remove the edge.launchpad.net domain?
[01:40] <mwhudson> well, not remove, deprecate & redirect from
[01:40] <thumper> wallyworld: https://dev.launchpad.net/Code/BranchRevisions
[01:43] <lifeless> mwhudson: yes
[01:44] <lifeless> spm: was any maintenance being done on that machine
[01:44] <lifeless> spm: that could cause that crazy output
[01:46] <spm> the lucid-devel slave?
[02:06] <lifeless> spm: yes
[02:07] <lifeless> wallyworld: I'm exposing the config for you as BaseLayer.appserver_config_name
[02:08] <wallyworld> lifeless: ok. i'm just coding everything now. i can make my branch dependent on yours?
[02:08] <lifeless> sure
[02:08] <wallyworld> for now i'll use a string literal in the getAppServerConfig, just to get stuff working
[02:08] <lifeless> sure
[02:10] <wgrant> How often will qastaging's DB be clobbered?
[02:14] <LPCIBot> Project db-devel build (78): STILL FAILING in 4 hr 4 min: https://hudson.wedontsleep.org/job/db-devel/78/
[02:25] <spm> lifeless: is that a moderately recent error? because there hasn't been any work on the slaves in ~ 4 days ish. afaict/find
[02:25] <lifeless> spm: today
[02:25] <lifeless> wgrant: same time stagings is
[02:27] <spm> lifeless: http://www.mail-archive.com/launchpad-dev@lists.launchpad.net/msg02726.html ??
[02:28] <spm> ie. lmgtfy ;-)
[02:28] <lifeless> spm: huh?! *today*
[02:28] <spm> same error
[02:29] <spm> we've seen this beofre. it's funky crap inside the test suite
[02:29] <lifeless> so you're thinkinging dirt in the lp buildbot build area?
[02:29] <spm> no. I'm thinking funky crap inside the test suite(s)
[02:30] <lifeless> spm: the only change was mine, and it passed ec2.
[02:33] <spm> lifeless: not sure. All I can say is that we've seen that error at least once before, back in March. it was weirdness inside the lp code/tests/includes/whatevers. I'd focus there.
[02:33] <thumper> lifeless: what are we doing about the thread garbage in ec2 tests?
[02:39] <wgrant> The current policy seems to be "lalalala I'm going to throw it at the wall until it sticks"...
[02:40] <thumper> :(
[02:40] <wgrant> Although Hudson's incessant whinging has almost convinced me to dig into it.
[02:42] <lifeless> thumper: I'm going to talk with stub again
[02:42] <thumper> ack
[02:42] <lifeless> I was advocating disabling the check last week
[02:43] <lifeless> I think it has to be downgraded to a warning for now, at most.
[02:43] <lifeless> but I need data
[02:43] <wgrant> The remaining failures are just Windmill, aren't they?
[02:48] <lifeless> I think so
[02:57] <rockstar> poolie, hi. Do feature flags also work with the API?
[02:58] <poolie> what do you mean?
[02:58] <poolie> can code called by the api consult flags?
[02:58] <poolie> i think it will work, but you may be the first to do it
[03:08] <rockstar> poolie, I mean the web api.  If I land my work, it's going to show up in the web api, isn't it.
[03:10] <thumper> rockstar: yes, I think so
[03:10] <rockstar> thumper, yeah, that's what I figured.
[03:11] <rockstar> I'm not sure whether or not I care enough to try and fix it.  I mean, merge queues have been available through the API for a while.  :)
[03:11] <rockstar> I guess I'll just need to be quick.
[03:13] <poolie> rockstar: i think it should just work but it depends on to what extent the web api uses the standard publication stuff
[03:14] <poolie> i would really appreciate hearing that either works, crashes, or silently fails
[03:14] <thumper> rockstar: just be quick :)
[03:14] <poolie> ... by way of a bug in the latter two cases
[03:15] <rockstar> poolie, how do you specify in an interface that a property is only accessibly through a feature flag?
[03:15] <wgrant> You can't.
[03:16] <wgrant> You have to check the flag inside the method.
[03:16] <mwhudson> i guess you can make a method error in some meaningful way if a flag is not in effect
[03:16] <mwhudson> a property... dunno
[03:21] <wgrant> (I believe the DistroSeriesDifference API stuff is currently protected by flags)
[03:22] <poolie> right
[03:22] <thumper> lifeless: do you think calls like https://lp-oops.canonical.com/oops.py/?oopsid=1751XMLP32 could block the xmlrpc server for the other calls?
[03:22] <poolie> rockstar: i mean presumably you would get... an AttributeError... if it didn't exist at all?
[03:22] <poolie> you could raise that? or Unauthorized, perhaps?
[03:25] <lifeless> rockstar: you'd need to change the wadl processing to use a flag in that fashion
[03:25] <lifeless> rockstar: as wgrant says, its not designed for static things like that, because it depends on the db
[03:25] <lifeless> I'd just do your things, merge queues are classified as unsupported by thumpers fiat ;)
[03:25] <rockstar> lifeless, yeah.
[03:26] <lifeless> as long as what you land is working at any point, its ok
[03:26] <rockstar> lifeless, yeah, that's the plan.
[03:29] <thumper> lifeless: did you boot buildbot?
[03:30] <lifeless> yes
[03:30] <lifeless> hoping its nonsense
[03:30] <lifeless> which it looks like it was
[03:50] <bac> good morning rockstar + antipodes
[03:50] <wgrant> Afternoon.
[03:54] <bac> wgrant: did you get all three of your branches landed, after the annoying ec2 faliures?
[03:55] <thumper> hi bac
[03:57] <wgrant> bac: And other three after that, yeah.
[03:57] <rockstar> bac, are you in Japan?
[03:57] <wgrant> After a couple of runs.
[03:57] <bac> rockstar: while i am big in japan i'm actually in vietnam
[04:30] <lifeless> wallyworld: rev 11741 in lp:~lifeless/launchpad/uniqueconfig is pushing now
[04:30] <lifeless> wallyworld: I'm not done, but the bits you need are done.
[04:31] <wallyworld> lifeless: thanks. only 100+ more tests to fix :-)
[04:31] <wallyworld> lifeless: i'm just assuming your rev with include the app config name - i've got methods for all the rest i need
[04:32] <wallyworld> s/with/will
[04:32] <rockstar> wallyworld, did you get your windmill issues fixed?
[04:32] <wallyworld> rockstar: no :-( but i talked to adam from the windmill devs and he suggested a windmill proxy issue may be the cause
[04:32] <wallyworld> i'm not 100% sure exactly what that means just yet
[04:33] <wallyworld> all i know is YUI and windmill don't play nicely together
[04:33] <rockstar> wallyworld, yeah.  Here's what I've found.  The same tests fail (relatively) consistently on my machine, but ec2 has failed 6 different runs with different tests failing each time with no changes from me.
[04:34] <rockstar> wallyworld, I don't see how YUI and windmill wouldn't play well together.  windmill doesn't know YUI from Adam.
[04:34] <wallyworld> rockstar: the same general failure mode? ie YUI breaks somehow?
[04:34] <wallyworld> from what adam said, there's some proxying the windmill does
[04:35] <wallyworld> s/the/that
[04:37] <wallyworld> rockstar: adam talked about needing to blacklist a url to prevent windmill proxying it and gave this reference
[04:37] <wallyworld> http://github.com/windmill/windmill/wiki/Preferences-File
[04:37] <rockstar> wallyworld, hm, I was under the impression that the windmill proxy was important.
[04:38] <wallyworld> i'm not sure - i haven't devoted enough brainspace to understanding the windmill architecure at this point
[04:39] <wallyworld> i was hoping it would make more immediate sense to you :-)
[04:41] <rockstar> wallyworld, it doesn't make much sense to me now, but it's also a bit late right now.  Maybe I can make some sense of it tomorrow.
[04:41] <wallyworld> rockstar: ok. we'll talk then. have a good evening
[04:47] <lifeless> wallyworld: it generates unique testrunner-appserver configs in BaseLayer.setUp
[04:47] <lifeless> wallyworld: it doesn't allocate unique ports in the generated config [yet]
[04:47] <lifeless> wallyworld: and really the whole config thing is backwards here, we want to start the server and readback the port as I described on the list
[04:47] <lifeless> EFUTURE
[04:49] <wallyworld> lifeless: np. i'll look at the branch to see what's there. atm, i'm fixing the test logic but the expected results still contain the hardcoded 8085. if the ports are generated, i'll have to come back and deal with that too
[04:50] <lifeless> wallyworld: what do you mean by 'expected results' ?
[04:50] <lifeless> wallyworld: the goal is to use different ports so we can run tests in parallel
[04:50] <wallyworld> lifeless: yeah, i realise that. here's a snippet from on e of the doc tests
[04:51] <wallyworld>     >>> browser.url
[04:51] <wallyworld>     'http://launchpad.dev:8085/~stimpy'
[04:51] <wallyworld> see how the expected url value is hard coded
[04:51] <lifeless> ok
[04:52] <wallyworld> i can deal with that. my first aim is to get the test logic sorted out, then come back around and fix this other stuff
[04:52] <lifeless> ok
[04:52] <lifeless> nuking the darn doctests would be one way ;)
[04:52] <wallyworld> well, the unit tests do the same thing :-)
[04:52] <lifeless> wallyworld: except assertions are easier there
[04:52] <wallyworld> +1
[04:53] <lifeless> perhaps browser could grow some support
[04:53] <lifeless> like
[04:53] <lifeless> vhost : launchpad.dev / bugs.launchpad.dev etc
[04:53] <lifeless> urlpath : /~stimpy
[04:54] <wallyworld> the windmill layer setup does this sort of thing
[04:55] <lifeless> if browser had that
[04:55] <lifeless> then you could write the above as
[04:55] <lifeless>  >>> browser.vhost
[04:55] <lifeless>   launchpad.dev
[04:55] <lifeless>   >>> browser.urlpath
[04:55] <lifeless>   /~stimpy
[04:55] <lifeless> which would probably be easier than converting to unittest in the short term
[04:56] <lifeless> or even have a normalise_url, or something.
[04:56] <wallyworld> yes. doc tests are here for a while yet given how much is in them
[04:58] <wallyworld> what i am playing with now is I have a method called getRootLaunchpadUrl(sitename='mainsite') which delgates to BaseLayer.xxx
[04:58] <wallyworld> so with one line of doc in doc tests i can get the url i needed
[04:58] <wallyworld> but i could look at adding that to the browser as you suggest
[04:58] <lifeless> the main thing for doctests is that you need to be able to write the literal expected value
[04:59] <lifeless> if you can do that, awesome
[04:59] <lifeless> I'm just riffing on the approach is all
[04:59] <wallyworld> np. it's always very good to discuss different ideas
[05:06] <lifeless> https://code.edge.launchpad.net/~lifeless/launchpad/uniqueconfig/+merge/38689 \o/
[05:06] <lifeless> jml: testtools upgrade broke bizarrely
[05:20] <LPCIBot> Project devel build (124): STILL FAILING in 4 hr 9 min: https://hudson.wedontsleep.org/job/devel/124/
[05:22] <lifeless> is there a config serialiser class ? for writing to the configs ?
[06:25] <wgrant> spm: Around?
[06:25] <spm> wgrant: ish...
[06:25] <wgrant> spm: The reporter of https://bugs.edge.launchpad.net/ubuntu/+source/beryl-core/+bug/109550 needs your magical banhammer.
[06:25] <_mup_> Bug #109550: Black/White/unrendered windows in Beryl  <beryl-core (Ubuntu):Invalid> <https://launchpad.net/bugs/109550>
[06:26] <spm> ahh. a special person eh?
[06:26] <wgrant> Spam of some variety.
[06:26] <wgrant> Only to that bug, that I've seen.
[06:26] <spm> awesome. ta.
[06:33] <wgrant> StevenK: Ohloh seems to be less glacial now... might be done tomorrow.
[06:33] <StevenK> Colour me suprised.
[06:34] <StevenK> http://paste.ubuntu.com/515453/ :-(
[06:35] <wgrant> StevenK: That can mean a missing export_as_webservice_entry()
[06:36] <wgrant> I think.
[06:36] <wgrant> What's your diff?
[06:37] <wgrant> It can also happen if your thing doesn't get imported into canonical.launchpad.interfaces.*
[06:37] <wgrant> But your diff will tell me everything.
[06:38] <StevenK> https://code.edge.launchpad.net/~stevenk/launchpad/db-add-derivedistroseries-api/+merge/38189
[06:38] <StevenK> wgrant: It's messy due to the MP being targetted at db-devel, but now I'm free to land on devel, so read with caution
[06:44] <wgrant> StevenK: What's the real diff?
[06:45] <StevenK> wgrant: The test changes and lib/lp/registry/{interfaces,model}/distroseries.py
[06:45] <StevenK> Addition of deriveDistroSeries()
[06:49] <wgrant> Ah.
[06:50] <wgrant> StevenK: You probably need to patch your 'distribution' argument's interface.
[06:50] <wgrant> Since IDistroSeries.distribution is an Interface for circular import reasons.
[06:50] <spm> wgrant: fyi. account zotted; old comments zotted as well
[06:51] <wgrant> You know about the _schema_circular_imports fun, right?
[06:51] <wgrant> spm: Thanks.
[06:57] <StevenK> wgrant: Oh, right, so I can copy_field, as long as I also deal with circular_imports?
[07:01] <wgrant> I think so.
[07:01] <wgrant> Anyway, I need to run.
[07:28] <lifeless> \o/
[07:28] <lifeless> dynamic db names working.
[07:28] <lifeless> in tests as in.
[07:29] <lifeless> lets see if it works for the librarian too
[07:32] <lifeless> seems too, but something remade the ftest db. Hmm.
[07:53] <lifeless> O M G
[07:53] <lifeless> lp test start reads from dev/random
[07:55] <jpds> lifeless: Does it support sharding?
[07:59] <lifeless> jpds: it must. Its web scale.
[07:59] <lifeless> :!bin/test -vvt test_pgsql --parallel
[07:59] <lifeless> Tests running...
[07:59] <lifeless> Ran 15 tests in 27.225s
[07:59] <lifeless> ^- woo
[08:00] <lifeless> StevenK: hey, what instance size are you using in hudson ?
[08:31] <adeuring> good morning
[08:32] <StevenK> lifeless: The largest
[08:32] <StevenK> lifeless: If you're running out of space on /, fiddle things to use /mnt
[08:33] <lifeless> StevenK: well, its just that I'm curious how many cores it will get
[08:34] <StevenK> lifeless: Oh, right. Lemme check
[08:34] <lifeless> StevenK: largest is ill defined
[08:34] <lifeless> there are ;argest-cpu, largest-memory etc
[08:35] <lifeless> m1.xlarge ?
[08:35] <StevenK> lifeless: Picking on one of the running instances, it has 2GB of RAM and 4 QEMU cores.
[08:35] <lifeless> c1.xlarge would be interesting to try
[08:35] <lifeless> 8 cores
[08:36] <StevenK> That is c1.xlarge
[08:36] <lifeless> surely not
[08:36] <StevenK> Yes
[08:36] <lifeless> http://aws.amazon.com/ec2/instance-types/
[08:36] <StevenK> It isn't using ec2
[08:37] <lifeless> oh
[08:37] <lifeless> thats right
[08:37] <lifeless> it would be nicer if they matched up
[08:37] <StevenK> File a ticket? :-)
[08:37] <StevenK> But I daresay, it's a problem of resource management
[08:37] <lifeless> StevenK: btw
[08:37] <lifeless>  https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html
[08:38] <lifeless> blames you for needing to QA :)
[08:38] <StevenK> lifeless: Yes, I'm blocked on dogfood, I'm waiting for Julian and Tom.
[08:38] <lifeless> ok
[08:38] <lifeless> please file a bug / RT ticket explaining what we need to change to let this get qa'd on qastaging.
[08:38] <lifeless> we /have/ to fix this pipeline
[08:39]  * wgrant can hear people crying already.
[08:39] <StevenK> lifeless: Shell access
[08:39] <lifeless> StevenK: surely you can come up with a better answer
[08:39] <lifeless> StevenK: like 'this is a shell script, so I can write a test driver for it that the losas can run on request'
[08:40] <StevenK> lifeless: No, I can't. The bits are infrastructure and I need to reach in and rummage around.
[08:40] <lifeless> StevenK: why?
[08:40] <StevenK> lifeless: Because I'd like to confirm things look good at a database level before I kick off a script, etc, etc.
[08:40] <StevenK> I'd like to be perfectly clear the right things are happening
[08:41] <lifeless> StevenK: this sounds automatable
[08:41] <wgrant> (also, most of the archive admin tools still require shell access)
[08:41] <lifeless> but even if its not, we need to be able to qa on qastaging
[08:41] <lifeless> this is a fundamental tenant of being able to do continuous deployment.
[08:41] <persia> (wgrant: most of them can be run by waldo though, by someone else if given the arguments)
[08:42] <lifeless> it needs to be written down
[08:42] <lifeless> handed off to a losa
[08:42] <lifeless> -or something-
[08:42] <StevenK> lifeless: In other news, can you poke at http://people.canonical.com/~stevenk/windmill-thread-debug-r11734.subunit.gz
[08:43] <lifeless> forbidden
[08:43] <lifeless> mail it to me or something
[08:43]  * StevenK curses
[08:43] <StevenK> lifeless: Fixed, please retry
[08:44] <lifeless> so what do you want me to see?
[08:45] <StevenK> lifeless: I added some more debugging to the windmill teardown, there's an oddness with a Timer thread there
[08:46] <lifeless> I'd say thats a threading subclass
[08:46] <StevenK> lifeless: And I also got 'test process died with exit code 2, but no tests failed', which I don't believe.
[08:46] <lifeless> used by windmill
[08:47] <lifeless> I think that test process thing is damage in zope.testing's subunit support, which I put a patch up for months ago
[08:47] <lifeless> benji landed it in the weekend I think
[08:47] <StevenK> Oh, damn it
[08:47] <StevenK> That revision is qa-ok, but Ursinha's script munged it
[08:48] <StevenK> lifeless: When does that page get re-generated?
[08:50] <lifeless> StevenK: 10 minutes or so
[08:50] <lifeless> Ursinha-afk: can you run it any more frequently now?
[08:50] <StevenK> lifeless: As in, 'in ten minutes' or 'every ten minutes' ?
[08:50] <lifeless> StevenK: its in cron, I think its a 10 minute frequency
[08:53] <lifeless> grr wtf OperationalError: FATAL:  database "launchpad_ftest_template" does not exist
[08:55] <StevenK> Right, now that page doesn't blame me, excellent.
[08:56] <wgrant> Does it blame me instead?
[08:56] <StevenK> No, sinzui
[08:56] <lifeless> sinzui
[08:56] <wgrant> Ah.
[08:56] <lifeless> however, anyone can qa
[08:56] <lifeless> in principle
[08:56] <StevenK> wgrant: We can change it so it always blames you
[08:56] <lifeless> Bug 46581 is marked as not-ok.
[08:56] <_mup_> Bug #46581: Change a poll type URL manually crashes <oops> <polls> <qa-needstesting> <Launchpad Registry:Fix Committed by sinzui> <https://launchpad.net/bugs/46581>
[09:01] <lifeless> I gotta say, wtf is dropping the template db
[09:03] <StevenK> Crash dump was written to: erl_crash.dump
[09:03] <StevenK> Kernel pid terminated (application_controller) ({application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}})
[09:03] <StevenK> Wheee, yay for readable logs, rabbitmq
[09:04] <StevenK> -rw-r----- 1 rabbitmq rabbitmq 243K 2010-10-18 08:02 /var/lib/rabbitmq/erl_crash.dump
[09:04]  * StevenK sobs
[09:04] <LPCIBot> Project devel build (125): STILL FAILING in 3 hr 44 min: https://hudson.wedontsleep.org/job/devel/125/
[09:04] <LPCIBot> * Launchpad Patch Queue Manager: [r=henninge][ui=henninge,
[09:04] <LPCIBot> sinzui][bug=639703] Correctly report bug tracking status for project
[09:04] <LPCIBot> groups.
[09:04] <LPCIBot> * Launchpad Patch Queue Manager: [r=mwhudson][ui=none][no-qa] Cleanup some partially-migrated-from\n\ttest support code.
[09:05] <LPCIBot> * Launchpad Patch Queue Manager: [r=mwhudson][ui=none][bug=660843][no-qa] Move the garbo scripts into
[09:05] <LPCIBot> lp.scripts
[09:05] <StevenK> Hm, I think I need to turn that off.
[09:09] <lifeless> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/662519 made me cry
[09:09] <_mup_> Bug #662519: lp test startup exhausts dev/random <Launchpad Foundations:New> <https://launchpad.net/bugs/662519>
[09:21] <lifeless> test run should be finished soon.
[09:21] <lifeless> \o/
[09:24] <StevenK> lifeless: I can kill that parallel-test build if you wish
[09:24] <lifeless> nono
[09:24] <lifeless> its nearly done
[09:25] <StevenK> Even with the no _template db errors?
[09:25] <lifeless> need to get the details and debug them
[09:25] <lifeless> most tests are passing
[09:25] <lifeless> its probably the tests that sampledata loading/dumping works, or some such
[09:26] <lifeless> hmm https://hudson.wedontsleep.org/job/parallel-test/4/ took 2 hours
[09:26] <lifeless> so it may have an hour to go
[09:33] <bigjools> wgrant: how much testing have you done on bug 655690?
[09:33] <_mup_> Bug #655690: release_files_needed shouldn't live on FTPArchiveHandler <qa-needstesting> <soyuz-publisher> <tech-debt> <Soyuz:Fix Committed by wgrant> <https://launchpad.net/bugs/655690>
[09:36] <lifeless> Announcing Amazon SNS Management Console looks interesting
[09:42] <wgrant> bigjools: I've tested both a-f and NMAF fairly thoroughly.
[09:42] <wgrant> Plus the tests are a bit better now.
[09:44] <jml> want to see a blast from the past? https://devpad.canonical.com/~jml/mirror-failure.png
[09:45] <lifeless> meep
[09:49] <mwhudson_> jml: wow
[09:49] <jml> lifeless: fwiw, something else weird is going on with your branch. You should definitely not get an email like that for test failures.
[09:51] <lifeless> jml: the long spew of info? i filed a bug, its having a root logging handler installed that uses std*
[09:51] <jml> lifeless: no, not the root logger
[09:52] <jml> lifeless: although that's another problem
[09:52] <jml> lifeless: I changed the email so that it should start with a list of failing tests, and then have only the error info for those tests
[09:52] <jml> lifeless: it sends out the full horrible dump only when something surprisingly bad happens.
[09:53] <jml> but a quick scan of the full log doesn't reveal anything
[09:55] <lifeless> jml: what full horrible dump ?
[09:56] <jml> lifeless: this is what a failing branch email is supposed to look like: Tests started at approximately 2010-10-16 10:04:52.243410
[09:56] <jml> Source: bzr+ssh://bazaar.launchpad.net/~wgrant/launchpad/better-publisher-index-tests r9886
[09:56] <jml> Target: bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/ r11722
[09:56] <jml> 10565 tests run in 3:58:20.128578, 0 failures, 1 errors
[09:56] <jml> Tests with errors
[09:56] <jml> -----------------
[09:56] <jml>  lp.code.windmill.tests.test_branchmergeproposal_commitmessage.TestQueueStatus.test_inline_queue_status_setting
[09:56] <jml> [09:56] <jml> ERROR: lp.code.windmill.tests.test_branchmergeproposal_commitmessage.TestQueueStatus.test_inline_queue_status_setting (subunit.RemotedTestCase)
[09:56] <jml> ----------------------------------------------------------------------
[09:56] <jml> _StringException: Text attachment: garbage
[09:56] <jml> ------------
[09:56] <jml> [<Thread(Thread-1110, started daemon 47989191493392)>]
[09:56] <jml> ------------
[09:56] <jml> **NOT** submitted to PQM:
[09:56] <jml> [r=bac][ui=none][no-qa] Start de-duplicating the apt-ftparchive and native publishing tests, and add more thorough index generation tests.
[09:56] <jml> (See the attached file for the complete log)
[09:56] <jml> sorry
[09:56] <jml> http://paste.ubuntu.com/515540/ ← I meant to paste that
[09:56] <wgrant> Severe chastisement.
[09:57] <lifeless> jml: thats what mine looked like
[09:57] <jml> lifeless: no, it didn't. the testtools -> devel email has stdout in it, for example
[09:57] <lifeless> ah
[09:57] <jml> lifeless: it does not have a list of tests with errors, for another example :)
[09:58] <lifeless> so, I think its because the *submitting tree* is used to control stuff
[09:58] <lifeless> not the target/source branch
[09:58] <jml> I don't follow
[09:59] <lifeless> I can't ec2 submit from my dev environment
[09:59] <jml> oh, you mean it's using remote.py from your branch? yes, that would be it.
[09:59] <jml> your local working tree, in fact
[09:59] <lifeless> I have a very old tree I never touch, because it 'works'
[09:59] <lifeless> its outside my dev vm
[10:00] <lifeless> generally when I touch it, it breaks. so I dont
[10:00] <jml> lifeless: ahh, ok.
[10:00] <jml> lifeless: well the new pretty email is very pretty and helpful.
[10:00] <jml> lifeless: but I can understand not wanting to mess about
[10:01] <lifeless> jml: testr looks after me ;)
[10:26] <jml> lifeless: I've updated run-test-improvements
[10:28] <LPCIBot> Project parallel-test build (5): STILL FAILING in 2 hr 15 min: https://hudson.wedontsleep.org/job/parallel-test/5/
[10:29] <lifeless> jml: how about run_with rather than run_test_with ? just a thought
[10:31] <lifeless> jml: def _run_test_method(self, result):
[10:31] <lifeless> jml: doesn't use result
[10:42] <jml> lifeless: thanks.
[10:42] <jml> lifeless: it never did.
[10:42] <lifeless> jml: interesting
[10:43] <jml> lifeless: also, _run_setup and _run_teardown
[10:59] <bigjools> jml: helleau.  Did you by any chance get to look further at the buildd-manager branch?  I'm about to run it on dogfood again, when DF is working.
[11:00] <jml> bigjools: no, not yet. how about I do that now :)
[11:00] <bigjools> jml: that'd be smashing
[11:03] <lifeless> nightish, all.
[11:03] <wgrant> Night lifeless.
[11:03] <jml> lifeless: g'night
[11:08] <jml> bigjools: you're landing it on devel, I take it?
[11:08] <bigjools> jml: that's the plan
[11:25] <jml> bigjools: you're not doing getFile => deferred as part of this branch, right?
[11:25] <bigjools> jml: no, it's a lot of work
[11:25] <jml> bigjools: ok.
[11:26] <jml> bigjools: have you filed a bug about it?
[11:26] <bigjools> jml: no
[11:26] <jml> bigjools: that might be a good idea. you've noted a few places where it needs to change in this branch.  A bug number will make grepping easier later :)
[11:27] <wgrant> bigjools: Can you think of a good reason to keep the behaviour where we skip publication of series without a lucilleconfig? An uninitialised series can't have any publications, so there's nothing to be published, so it seems pointless.
[11:27] <bigjools> jml: I don't care about grepping, the few XXXes that are there are the tip of the iceberg.  I have a list on my desk of what needs to change on the delightful piece of cardboard that we used :)
[11:27] <wgrant> (plus it's all that's keeping me from dropping the column)
[11:28] <bigjools> wgrant: it was only being skipped to stop the publisher blowing up when it tried to get one that was not there
[11:28] <wgrant> bigjools: That's what I thought, thanks.
[11:28] <jml> bigjools: the bus factor for that is dangerously high
[11:28] <bigjools> jml: I know.
[11:29] <bigjools> jml: but it's not like someone else couldn't do what I did
[11:29] <bigjools> I can add XXXes though
[11:30] <bigjools> BTW I can thoroughly recommend the Finca El Fany from Hasbean.  Apart from having a hilarious name, it tastes delicious.
[11:31] <jml> :D
[11:31] <wgrant> Hmm. What's archivepublisher.root set to in the 'ppa' prod config?
[11:31] <jml> I'm on Sainsbury's coffee until I return from the states
[11:32] <bigjools> wgrant: why?
[11:32] <jml> the slave api needs to change
[11:33] <bigjools> the Sainsbury's ground colombian is very nice
[11:34] <wgrant> bigjools: I believe the code currently uses Ubuntu's lucilleconfig's temp directory (/srv/launchpad.net/ubuntu-archive/ubuntu-temp) for PPAs.
[11:34] <bigjools> wgrant: for doing what for PPAs?
[11:34] <wgrant> bigjools: One of my next few branches switches to ${archivepublisher.root}/ubuntu-temp instead.
[11:34] <wgrant> bigjools: It puts Sources and Packages in there first.
[11:34] <bigjools> oh ok, before the atomic-ish mv
[11:34] <wgrant> Yep.
[11:35] <bigjools> it's set to the directory that contains all the repos
[11:35] <bigjools> there's also a private_root
[11:35] <wgrant> It isn't in my old copy.
[11:35] <wgrant> That's the PPA root.
[11:35] <wgrant> Not archivepublisher.root.
[11:35] <bigjools> oh, meh
[11:36] <wgrant> I could change it, but we probably don't want the temp directory showing up under the Apache-served root...
[11:36] <bigjools> wgrant: ppa does not override the values used in the ubuntu publisher
[11:36] <wgrant> bigjools: Does it inherit from ftpmaster?
[11:36] <bigjools> yes
[11:37] <bigjools> well
[11:37] <wgrant> Ah.
[11:37] <bigjools> no
[11:37] <bigjools> I can't read today
[11:37] <wgrant> My copy of the configs is a year old, and I believe things have changed a bit since then.
[11:37] <wgrant> But by my reading it will inherit schema-lazr.conf's archivepublisher.root, which is /var/tmp/archive, which is probably wrong.
[11:38] <bigjools> yes it will use that
[11:38] <bigjools> even dogfood's config sets it.  Ha.
[11:38] <wgrant> :(
[11:38] <wgrant> Hah, to /srv/launchpad.net/ppa. How odd.
[11:39] <bigjools> not really
[11:39] <wgrant> But the PPA config doesn't set it to that...
[11:39] <bigjools> jml: what's up with the slave api, apart from the fact it's crap?
[11:39] <jml> bigjools: potato programming
[11:39] <jml> sendFile, sendFile, sendFile, sendFile, ...
[11:40] <bigjools> yeah that blows
[11:40] <jml> why not sendFiles?
[11:40] <jml> not only is it slower but it makes the client-side harder to write.
[11:41] <jml> I guess a good thing about this change is that now everything goes through BuilderSlave, so you could change the API for BuilderSlave to look like what you want the XML-RPC API to look like
[11:43] <bigjools> indeed, it's a nice layer of abstraction
[11:43] <wgrant> RecordingSlave is gone?
[11:43] <wgrant> Yay.
[11:43] <bigjools> totally gone
[11:43] <bigjools> the new manager.py is about 30% of the size
[11:43] <wgrant> I meant to read the diff, but it's sort of big.
[11:43] <jml> yeah
[11:44] <jml> wgrant: I'm skimming the diff and then going to look at the new manager.py & test_manager.py – the diffs for those are so big as to be useless
[11:44] <bigjools> jml: there's one more bug I need to fix in the code - the failure counting assumes there's always a job on the builder, but the scan can fail before that happens
[11:45] <bigjools> also I want to make it allow a few more failures on builders before killing them
[11:46] <jml> bigjools: isn't that last one just changing a constant somewhere?
[11:46] <bigjools> no
[11:46] <bigjools> the current code just checks that one is bigger than the other
[11:47] <bigjools> jobs hopping around builders failing need to be culled quickly.  builders  need a bit more leeway
[11:48] <wgrant> I think we need to be more careful about that, though.
[11:48] <wgrant> Since network issues can kill lots of builds that way.
[11:50] <bigjools> yes, I know, which is why builders need more leeway
[12:04] <deryck> Morning, all.
[12:42] <Ursinha> lifeless, running every 5 minutes now
[12:49] <LPCIBot> Project devel build (126): STILL FAILING in 3 hr 44 min: https://hudson.wedontsleep.org/job/devel/126/
[12:49] <LPCIBot> Launchpad Patch Queue Manager: [r=lifeless][ui=none][bug=631301] Prune CodeImportEvents.
[12:55] <wgrant> The PQM regex doesn't actually confirm that there's a commit message?
[13:11] <LPCIBot> Project db-devel build (79): STILL FAILING in 4 hr 8 min: https://hudson.wedontsleep.org/job/db-devel/79/
[13:16] <Ursinha> good morning launchpad
[13:22] <jml> done
[13:23] <wgrant> You finished Launchpad?
[13:23] <jml> Yeah, the end boss is tough
[13:24] <jml> actually, I finished reviewing the new buildd-manager code
[13:24] <wgrant> !!
[13:25] <jml> not as thoroughly as I'd review a normal branch, of course, but thoroughly enough.
[13:27] <wgrant> I feel that the branch could have a better name.
[13:27] <wgrant> It's a bit deceptive.
[13:27] <jml> yeah
[13:30] <jml> lazr.config.interfaces.ConfigErrors: ConfigErrors: schema-lazr.conf does not have a initialisedistroseries section.
[13:31] <wgrant> jml: That was fixed in devel r11715
[13:32] <wgrant> 11712, even.
[13:32] <jml> ahh right.
[13:32] <jml> hasn't made it to bigjools' branch then
[13:33] <bigjools> I've not merged devel today
[13:38] <bigjools> jml: pushed a new one up
[13:40] <jml> ta
[13:55] <bigjools> "make check" is still screwed. Grar.
[14:12] <mars> bigjools, 'make check' is deprecated.  We will not be fixing it.
[14:13] <bigjools> mars: wtf?
[14:13] <bigjools> so how do I run tests locally?
[14:13] <mars> bigjools, bin/test is the recommended way.
[14:14] <bigjools> mars: provided running it with no args runs all the tests, then fine.
[14:14] <bigjools> but I am intrigued as to why make check hangs half way through.
[14:15] <mars> bin/test runs everything.  IIRC there was no obvious reason behind the test hang.
[14:16] <mars> especially since bin/test had no issue
[14:17] <bigjools> indeed
[14:21] <jml> mars: why not delete it now?
[14:22] <mars> jml, the make check target?
[14:22] <jml> mars: yes
[14:22] <mars> it is still used by automated systems
[14:22] <bigjools> what does ec2/buildbot use?
[14:22] <mars> same
[14:22] <mars> 'make check'
[14:22] <bigjools> hmmm then I am quite concerned
[14:23] <mars> ?
[14:23] <mars> about what?
[14:23] <bigjools> why does it work for those and not locally, basically
[14:24] <bigjools> jml: I don't understand why you think some of the comments are obsolete in this branch.
[14:25] <jml> bigjools: hmm. gimme a sec and I'll explain why.
[14:26] <mars> jml, I should not have used the word 'deprecated'.  'make check' is not deprecated, but its use is not recommended for developer systems.  It is only intended for automated ones.
[14:26] <jml> bigjools: e.g.
[14:26] <jml> >     def _startCycle(self):
[14:26] <jml> >         # Same as _startCycle but the next cycle is not scheduled.  This
[14:26] <jml> >         # is so tests can initiate a single scan.
[14:26] <bigjools> jml: that one is ok
[14:26] <bigjools> jml: it's the "# Trap known exceptions..." one
[14:27] <bigjools> anyway I like lots of comments.  Comments are rarely bad unless they're misleading.
[14:27] <jml> bigjools: ahh right. What I mean there is that though the words are correct, it's incomplete, and the traceback/no-traceback thing isn't very interesting
[14:27] <bigjools> I think it is :)
[14:28] <bigjools> bitter experience of coming back to my own code 1 year later
[14:28] <jml> bigjools: in that case, fix the grammar :)
[14:29] <jml> bigjools: "Trap all errors. If it's a known error, log it; if it's not known, log it and include a traceback."
[14:29] <jml> bigjools: but the main point of the review comment is that _scanFailed does much more now.
[14:29] <bigjools> I love seeing a well placed semicolon.  I'm still searching. :)
[14:29] <bigjools> indeed, I'll spruce it up
[14:45] <jml> jelmer: is there a PPA somewhere with a version of testr with streaming result support?
[14:46] <jelmer> jml: Not that I'm aware of. Rob has done all of the testrepository packaging so far. AFAIK there are only packages in Debian and Ubuntu's main archive.
[14:47] <jelmer> It might be nice to set up a recipe build for testr.
[15:04] <jml> jelmer: yes
[15:32] <cody-somerville> jml, What you ever used twill? If so, whats your opinion of it?
[15:32] <cody-somerville> err
[15:32] <cody-somerville> *Have
[16:01] <jml> deryck: hello
[16:01] <deryck> hi jml.  on call
[16:01] <jml> deryck: can we have a call sometime this week to talk about UDS?
[16:01] <sinzui> jml, mumble?
[16:02] <jml> sinzui: yep
[16:02] <jml> sinzui: waiting
[16:03] <jml> cody-somerville: never used twill.
[16:04] <jml> sinzui: hello?
[16:06] <gary_poster> deryck: I decided to push bug 659697 back to you.  Maybe I'm being dense about our options, but right now I don't see a clear foundational solution, and even if it were, I think the degree we care about this use case is also an application-level decision.  Tell me what you think when you get around to it. :-)
[16:06] <_mup_> Bug #659697: [Wish] On-the-fly decompression of compressed attachments <Launchpad Bugs:New> <https://launchpad.net/bugs/659697>
[16:23] <deryck> jml, sure, I'd love to chat.  Early as possible this week actually.  Meant to ping already.
[16:24] <deryck> jml, can you calendar me a time that works for you?
[16:24] <deryck> gary_poster, I was wondering at first if it was apache settings to get content-type and content-encoding right so the brower would do the work....
[16:25] <jml> deryck: sure thing
[16:25] <deryck> gary_poster, but having poked briefly at it, I guess the change has to happen in the librarian server itself.
[16:25] <deryck> jml, thanks!
[16:26] <gary_poster> deryck: right, and if I understood correctly, the proposal was to always unzip, and then let the server do gzip encoding if the browser supports it
[16:27] <deryck> gary_poster, right.  As I understand it, too. :)
[16:27] <deryck> gary_poster, so I'm happy for bugs to own it, but like you, I doubt we'll make it a priority anytime soon.
[16:28] <deryck> I didn't know with the librarian being a shared resource who should own it either.
[16:28] <deryck> the whole "own" thing is silly, I know.
[16:28] <gary_poster> which...seems questionable, from the perspective of someone who feels fuzzy about the use cases.  My concerns would be how many browsers don't accept gzip, and how many people would *want* their browsers to display an arbitrarily-sized attachment rather than downloading it...
[16:29] <gary_poster> (sorry, that was a follow on from my first statement)
[16:29] <deryck> right, I agree with that, too.  Maybe we shouldn't do it.
[16:29] <deryck> aribitrary files are much different that static resources of css or js which other sites gzip and decompress on the fly.
[16:30] <gary_poster> right
[16:31] <gary_poster> but so, even if you kicked something off to us for implementation, my concerns were whether we *should* do it from an application/usability perspective.  Which seemed to be Not Me. ;-)
[16:33] <deryck> heh
[16:33] <deryck> gary_poster, I didn't think about the arbitrary size issue before.  You having said that makes me agree.
[16:34] <gary_poster> ok cool deryck :-)
[16:34] <deryck> I'm not even sure the alternate link idea is worth the effort either.  How much trouble is it letting the browser dialog guide you?
[16:39] <LPCIBot> Project devel build (127): STILL FAILING in 3 hr 49 min: https://hudson.wedontsleep.org/job/devel/127/
[16:39] <LPCIBot> * Launchpad Patch Queue Manager: [r=jtv,lifeless][ui=none][bug=652280]
[16:39] <LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][ui=None][bug=644196] Allow derivers to create a derived
[16:39] <LPCIBot> distroseries via the API.
[16:39] <gmb> Dear LPCIBot: Please stop setting off my highlight.
[16:47] <jtv> And mine.
[16:52] <maxb> lpcibot sould send notices, not messages
[17:09] <jml> and we should have a landing system that doesn't require reviewer nicks in the first line of the commit message
[17:15] <LPCIBot> Project db-devel build (80): STILL FAILING in 3 hr 44 min: https://hudson.wedontsleep.org/job/db-devel/80/
[17:15] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 11735,
[17:15] <LPCIBot> 11736, 11737, 11738 included.
[17:53] <jml> g'night all
[17:56] <bigjools> night from me too
[19:06] <sinzui> jcsackett, how many hours do you estimate it would take you to update that JoinNotAllowed raises a 403 over the API https://bugs.edge.launchpad.net/launchpad-registry/+bug/244527
[19:06] <_mup_> Bug #244527: JoinNotAllowed should cause a 400 response when raised on the API layer <api> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/244527>
[19:10] <jcsackett> sinzui: the exception just needs to be moved into lp.registry.errors and have a webservice code assigned to it.
[19:10] <sinzui> jcsackett, 2 hours?
[19:10] <jcsackett> assuming i don't get into import hell and the tests are easy, probably 1-2, yes.
[19:10] <sinzui> okay. thanks
[19:44] <lifeless> moin
[19:44] <lifeless> Ursinha: awesome
[19:56] <mtaylor> moin lifeless
[20:06] <lifeless> hi mtaylor
[20:14] <LPCIBot> Project devel build (128): STILL FAILING in 3 hr 35 min: https://hudson.wedontsleep.org/job/devel/128/
[20:14] <LPCIBot> * Launchpad Patch Queue Manager: [r=jelmer][ui=none][no-qa] Extract a few refactorings and tests from
[20:14] <LPCIBot> the abandoned check-in-wadl branch.
[20:14] <LPCIBot> * Launchpad Patch Queue Manager: [r=gary][ui=none][no-qa] update lazr.restful to the latest released
[20:14] <LPCIBot> version (0.14.0)
[20:15] <LPCIBot> * Launchpad Patch Queue Manager: [r=michael.nelson, stevenk,
[20:15] <LPCIBot> julian.edwards][ui=none][bug=653720] Commit after changing build
[20:15] <LPCIBot> status in the upload processor.
[20:15] <lifeless> bac: hi
[20:26] <gary_poster> Is this kind of thing expected when you try to view MPs on staging?  If not, is it indicative of staging's librarian having fallen over?  That's my impression of the traceback a skim of the pertinent code: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1752S202
[20:28] <lifeless> mmm
[20:28] <lifeless> no, its a 404
[20:28] <lifeless> it means 'the librarian is running but couldn't get your shit'
[20:29] <lifeless> now the staging librarian is /meant/ to fallback, at least for public stuff, to the main librarian.
[20:31] <gary_poster> oh, just saw reply
[20:56] <jam> abentley: ping
[20:56] <jam> mwhudson: ping about lp-service
[20:57] <abentley> jam: pong
[20:57] <mwhudson> jam: ping
[20:57] <mwhudson> jam: ah crap, i didn't reply in the end did i?
[20:57] <mwhudson> jam: basically i think it looks ok
[20:57] <jam> mwhudson: I updated the test suite, I'm not sure if it is fully tasteful, but the test suite passes for me
[20:58] <jam> abentley: want to skype? I responded to your email, but it may be faster to iterate vocally
[20:58] <mwhudson> jam: using fixed paths to communicate between subprocesses is (sadly) how it's done in lp tests currently
[20:58] <jam> mwhudson: le sigh
[20:58] <abentley> jam, sure.  I don't see your reply yet.
[20:58] <jam> abentley: just sent, may take a couple mins
[20:58] <mwhudson> jam: lifeless is fixing that right now though :-)
[20:59] <jam> yeah, I've been reading the discussion on the parallel running, etc.
[20:59] <mwhudson> jam: he also suggested that you might want to make your helper class subclass Fixture
[20:59] <mwhudson> to make the transition away from layers that smidgeon easier
[21:00] <jam> mwhudson: I'd be happy to if I understood Fixture. Can you give any pointers there?
[21:00] <mwhudson> jam: http://pypi.python.org/pypi/fixtures/0.3.2
[21:01] <flacoste> lifeless: hi
[21:01] <mwhudson> jam: oh yeah, at the atexit calls are a bit crazy
[21:06] <lifeless> flacoste: hi
[21:07] <flacoste> lifeless: skype?
[21:07] <lifeless> yes, its hanging there o connecting
[21:09] <mwhudson> jam: i posted another comment on the mp
[21:57] <wgrant> abentley: The chroot *does not provide security*.
[22:05] <wallyworld_> morning
[22:09] <abentley> wgrant: elmo appears to believe otherwise, because he didn't have a problem with it being possible to run that code inside a chroot on a non-VM machine.
[22:12] <wgrant> elmo: We install build-deps as root. Are the buildd kernels somehow protected from usual chroot escapes?
[22:15] <rockstar> mars, gary_poster, FYI, I've seen your emails, and will make sure you have a reply in the morning.  Is that okay?
[22:15] <gary_poster> rockstar: absolutely.  thank you
[22:16] <gary_poster> rockstar: we're intending to have hands ready to work on this on Wednesday, so you know.
[22:34] <LPCIBot> Project db-devel build (81): STILL FAILING in 4 hr 7 min: https://hudson.wedontsleep.org/job/db-devel/81/
[23:00] <mwhudson> Conflict adding file lib/canonical/launchpad/apidoc.  Moved existing file to lib/canonical/launchpad/apidoc.moved.
[23:00] <mwhudson> what *again*?
[23:02] <benji> mwhudson: that's my fault; a fix will be comitted momentarily
[23:02] <mwhudson> benji: heh, i don't know if it's worth fixing once the deed is done
[23:03] <benji> there are other bits that *are* worth fixing :/
[23:21] <mwhudson> hey guess what
[23:21] <mwhudson> there's a blueprints pagetest that's misnamed and not run by default (i think)
[23:21] <mwhudson> surprise surprise it fails
[23:22] <mwhudson> ah maybe not
[23:27] <thumper> testfix mode :-(
[23:49] <LPCIBot> Project devel build (129): STILL FAILING in 3 hr 34 min: https://hudson.wedontsleep.org/job/devel/129/
[23:49] <LPCIBot> Launchpad Patch Queue Manager: [r=edwin-grubbs][ui=none][bug=612754] remove the trailing whitespace
[23:49] <LPCIBot> as
[23:49] <LPCIBot> part of the newline canonicalization when checking the GPG signature of
[23:49] <LPCIBot> incoming email