[12:07] <gary_poster> frankban, I approved your charm change a few minutes ago fwiw.
[12:08] <gary_poster> bac frankban, call in 2
[12:08] <bac> ok
[12:10] <frankban> gary_poster: thanks, could you please approve the slave's one too, same change: https://code.launchpad.net/~frankban/charms/oneiric/buildbot-slave/apt-sources/+merge/102074
[12:10] <gary_poster> frankban, done.  Sorry, I thought the two emails were the same :-P
[12:25] <bac> and, i'm back
[13:38] <bac> hey gary_poster, these results look promising.  do you think they are correct?  http://ec2-107-21-142-169.compute-1.amazonaws.com:8010/builders/lucid_lp/builds/1/steps/shell_9/logs/stdio
[13:38] <gary_poster> looking
[13:40] <gary_poster> bac, great! yes, that's in line with our past experiences, if nothing new went wrong.  We know we have intermittent errors, and this triggered one of them.
[13:40] <gary_poster> one of the known ones, even.
[13:40] <bac> ok, cool
[13:41] <bac> that was with my whoami fix (merged) and a manual fstab fix for celery
[13:41] <gary_poster> great bac
[13:41] <bac> gary_poster: do we want to log these results somewhere?
[13:42] <bac> results saved for posterity at http://paste.ubuntu.com/932523/
[13:44] <gary_poster> bac, feel free to argue differently, but my opinion is that we should file bugs only for now.  When we have our first real green buildbot run, I'd be +1 with starting a log.  This is darn close, I grant you, which might alone be an argument to start.  Well you made a pastebin...if you like, you could start (or expand) a wiki page to record the pastebin, the names of the failing tests, and the bug for each test.
[13:44] <gary_poster> This one is bug 974585 fwiw
[13:44] <_mup_> Bug #974585: test_openFileInNonDirectory has UncleanReactorError <paralleltest> <Launchpad itself:Triaged> < https://launchpad.net/bugs/974585 >
[13:45] <gary_poster> The date & LP revision of the run too, mayhap
[13:46] <bac> gary_poster: wiki is a good idea
[13:55] <bac> gary_poster, frankban: pretty basic wiki for result tracking: https://dev.launchpad.net/ParallelTests/ResultsLog
[13:56] <gary_poster> thank you bac.  Quick email to yellow (or -dev?)
[13:56] <gary_poster> ?
[13:56] <gary_poster> please?
[13:57] <bac> sures
[14:01] <bac> gary_poster: why all of the 'skips' shown in that result?  http://paste.ubuntu.com/932523/
[14:05] <gary_poster> bac, I think they are for the layer setup and teardown bits.  One of the very first things we identified at the Budapest sprint was the fact that the testr stack does not understand tags sufficiently, and cannot filter out tags.  This caused confusion in one dimension and we filed bugs; I *think* this is another dimension.
[14:05] <bac> gary_poster: oh, ok. didn't realize it was part of that problem.
[14:05] <gary_poster> bac, yeah.  call my answer an educated guess.  I put it at 80% likelihood.
[14:16] <gary_poster> bac, wife and I have to perform the take-two-cars-to-shop-and-return-home-in-one maneuver.  I have testrepository tests passing locally now (I had to install apt packages) and so I'll be writing tags test next.  I'll ping when I return.  If looking for task you could investigate subunit/subunit-filter in preparation for that task.
[14:17] <bac> gary_poster: ok
[14:23] <benji> I'm not really here but if you desperately need anything, ping me.
[15:02] <gary_poster> benji, ok, oh ethereal one, thank you
[15:03] <gary_poster> bac, I'm back at it.
[15:03] <bac> ok gary_poster
[15:04] <bac> hey doesn't our moin support LP bug linking automatically? if so, anyone remember the syntax?
[15:05] <gary_poster> bac, I think it is "Bug:NUMBER" but if that doesn't work, find previous examples around.
[15:05]  * gary_poster looks
[15:05] <bac> gary_poster: i looked but couldn't find anything
[15:06] <gary_poster> bac, yeah "Bug:534363 no easy way to call destructor" results in
[15:06] <bac> yes Bug:1 works.  (must be capitalized)
[15:06] <gary_poster> 534363 no easy way to call destructor with link for number
[15:06] <gary_poster> 534363 no easy way to call destructor [with link for number]
[15:07] <gary_poster> cool
[15:28] <bac> gary_poster: you have time for a quick hangout to talk about subunit-filter?
[15:29] <gary_poster> sure bac
[15:29] <gary_poster> bac, I'm in foldenhorde
[15:30] <gary_poster> or goldenhorde
[15:30] <bac> me too
[15:49] <frankban> gary_poster, I don't remember, in parallel tests we are changing the temp dir?
[15:50] <gary_poster> frankban, the temp dir as used by testr, yes.  is that what you mean?
[15:50] <frankban> gary_poster: yes, I don't remember where we set the temp dir
[15:50] <gary_poster> frankban, build/temp
[15:51] <frankban> gary_poster: thanks, but I meant, what is the code that actually change the temp dir?
[15:52] <gary_poster> retrieving...
[15:53] <frankban> gary_poster: ah... it could be buildbot
[15:53] <frankban> I've found this line in master.cfg:  env={'TEMP': properties.WithProperties('%(build_dir)s/temp')}
[15:53] <gary_poster> frankban, yes, I was about to say that. :-) that's it
[15:54] <frankban> gary_poster: so I am right if I say that each test is run using TEMP=new_dir
[15:55] <gary_poster> frankban, fwiw, we are following the same pattern as in "Running tests" at bottom of https://dev.launchpad.net/ParallelTests .  Probably not relevant to you
[15:55] <gary_poster> frankban, yes, in master.cfg
[15:55] <gary_poster>     fac.addStep(bzrbuildbot.shell.ShellCommand(
[15:55] <gary_poster>         command=['mkdir', 'temp']))
[15:55] <gary_poster> we do that every test run
[15:56] <frankban> gary_poster: TEMP=./temp bin/test -vv -t lib/lp/soyuz/doc/soyuz-upload.txt fails each time in my local machine
[15:57] <gary_poster> frankban, wow!  what does the failure look like?
[15:58] <gary_poster> frankban, note that it is passing more often than failing in our parallel test runs on ec2
[15:59] <frankban> gary_poster: it looks like an explosion, and yes, the fact that it often passes confuses me
[16:01] <frankban> gary_poster: http://pastebin.ubuntu.com/932685/
[16:01] <gary_poster> frankban, heh.  perhaps TEMP is not passed through?  We could maybe change how the files are stashed, but I'd like some belief that it will actually help before we go to the trouble.  I can describe the options that I'm thinking of.  Looking...
[16:05] <gary_poster> With doctests the first failure is usually the only interesting one--or at least one of the few.  You can pass -1 to bin/test to only show the first failure.  In this case, it looks like the actual failure is even earlier: something should not be None.  If you can determine what is None (I suspect you have already) and why (probably more difficult) then we can evaluate the options for getting rid of TEMP.  Basica
[16:05] <gary_poster> lly, we'd want to set the normal location for sharing those files (/tmp, I assume?) to be bind mounted in the core fstab.  Once we did that, the ephemeral instances would switch that to an ephemeral mount
[16:06] <gary_poster> so they would get the information
[16:06] <gary_poster> but any writes to /tmp would be isolated to their processes
[16:06] <gary_poster> It should be easy to set up.
[16:06] <gary_poster> It would mean a change to setuplxc to change the root container's fstab
[16:07] <gary_poster> frankban, ^^
[16:11] <frankban> gary_poster: I see. I want to further investigate, because it is strange we are not seen this errors in real parallel test runs
[16:11] <frankban> s/seen/seeing/
[16:11] <frankban> s/this/theese, aargh
[16:12] <gary_poster> L0(
[16:12] <gary_poster> :-)
[16:12] <gary_poster> off by one smiley
[16:36] <frankban> and the result is: it works on parallel tests because buildbot is not as lazy as me and uses an absolute path for the temp env var :-(  so sad
[17:09] <gary_poster> :-) :-/
[17:23] <frankban> gary_poster: I will run the soyuz doctests continuously during the night using shuffle. Without errors, Julian's suggestions it the think to do IMHO.
[17:30] <bac> hello, i'm back.  in-laws are in the house...so there's a little confusion
[17:37] <gary_poster> frankban, great, +1 on all of that.  bac, cool, lemme know when you want to refocus.  I'm looking at the filtering thing now
[17:38] <bac> gary_poster: ok
[17:54] <bac> gary_poster: ok, i'm all caught up.  re-read your email.  do you want to chat again so i can go off and do something good?
[17:55] <gary_poster> bac, heh, yeah, and there are more developments since that last email.
[17:55] <bac> it's a fast-moving world
[17:55] <gary_poster> bac, goldenhorde awaits
[21:01] <gary_poster> bac, could you shoot me or yellow a diff of that simple change?
[21:02] <bac> gary_poster: ok
[21:02] <gary_poster> ty
[21:08] <bac> gary_poster: http://pastebin.ubuntu.com/933147/