[08:34] <vila> wgz: windows slave seems in better shape, as for debug-windows, a bare 'make' has been deleted, just restored it and running a test right now
[08:35] <vila> wgz: i.e. removing the 'import win32utils' was the only needed bit apparently
[08:40] <vila> wgz: oh, and having jenkins version controlled made it trivial to detect the removed 'make' which is a very good example of why I dislike clickety GUI to define jobs
[08:47] <vila> wgz: 'make clean' does not delete .pyd, cleaning up the debug-windows workspace manually was required, something fishy there but probably not worth digging for now
[08:48] <vila> wgz: in the other hand, http://babune.ladeuil.net:24842/job/debug-windows/102/console may give a hint about the (subunit/testtools ?) stream leak
[08:48] <vila> s/in the/on the/
[09:09] <mgz> morning all
[09:09] <vila> hey mgz :)
[09:10] <vila> mgz: let me re-paste previous remarks
 wgz: windows slave seems in better shape, as for debug-windows, a bare 'make' has been deleted, just restored it and running a test right now
 wgz: i.e. removing the 'import win32utils' was the only needed bit apparently
 wgz: oh, and having jenkins version controlled made it trivial to detect the removed 'make' which is a very good example of why I dislike clickety GUI to define jobs
 wgz: 'make clean' does not delete .pyd, cleaning up the debug-windows workspace manually was required, something fishy there but probably not worth digging for now
 wgz: in the other hand, http://babune.ladeuil.net:24842/job/debug-windows/102/console may give a hint about the (subunit/testtools ?) stream leak
 s/in the/on the/
[09:13] <mgz> yeah, seemed like the compiled modules were just sticking around from an older build and breaking things
[09:16] <vila> yup, caused by the removed 'make'
[09:17] <vila> but debug-windows jobs 100, 101, 102 failing when no tests failed... ?
[09:17] <vila> jelmer: around ?
[09:20] <mgz> vila: I'm not sure on that, I only messed around with the make calls after a few runs had already failed
[09:20] <vila> ha !
[09:20] <vila> dependency not correctly tracked then ?
[09:20] <mgz> I had the setup sh script, followed by make realclean; make for a couple of the runs
[09:22] <vila> realclean deletes the .pyd files ?
[09:23] <mgz> it should, but doesn't
[09:23] <mgz> (clean should, but doesn't)
[09:23] <mgz> basically, the makefile isn't written to work on windows
[09:23] <mgz> but something else is going on as well I think
[09:57] <mgz> vila: possibly something is wrong with the pipeline for subunit handling
[09:57] <mgz> (causing the 'lost connection' issue)
[09:58] <mgz> the output text on the server at least contains \r\n and \r\r\n rather than the expected line endings
[09:59] <vila> ha ha, progress ?
[09:59] <vila> 'server' ?
[10:01] <mgz> if you do view console output as text on babune and download it
[10:04] <vila> wow
[10:04] <vila> that's *inside* the multipart stuff, wth ?
[10:04] <mgz> might be after the fact mangling, it's not completely clear
[10:05] <mgz> I note the current selftest template doesn't run ./bzr selftest but has a sh script for that as well
[10:06] <vila> yup, part of the babune branch bin/selftest.sh
[10:06] <vila> do you want a paste ?
[10:07] <mgz> no, it's alright
[10:07] <mgz> well, can look
[10:07] <vila> http://paste.ubuntu.com/792536/
[10:07] <mgz> anyway, this is mostly output log-cosmetic, the junit xml gets generated correctly
[10:08] <mgz> so I'm guessing it's the 2junit | 2pyunit pipe at fault
[10:08] <mgz> I bet splitting into ./bzr selftest > out; 2junit < out; 2pyunit < out; would work.
[10:09] <mgz> subunit probably forgets to set binary when forwarding from the filters?
[10:10] <vila> breaking the pipe means no report while running selftest, better if we can avoid it in the end, yeah, or one of the filters forget to set binary
[10:11] <mgz> yup, that'll be it.
[10:12] <mgz> what's the easiest way to try out a fixed subunit on babune?
[10:13] <vila> ask me :)
[10:15] <vila> the always-falling-down-in-the-stack next task for babune is to add setup/deployment step that could be used for that kind of tests
[10:16] <vila> I'm using subunit revno 151 for now
[10:16] <vila> could probably update to 156 if it helps
[10:17] <vila> testtools revno 224, same remark
[10:19] <mgz> vila: lp:~gz/subunit/binary_forward_stream
[10:21] <mgz> shouldn't need to update testtools
[10:23] <vila> meh, there is already an unconditional make_stream_binary two lines above ?
[10:23] <mgz> it's for a different stream :)
[10:23] <mgz> ...I didn't change it
[10:23]  * mgz corrects
[10:25] <mgz> pull --overwrite as I'm pretending I never made that mistake :)
[10:25] <mgz> thanks for checking vila :)
[10:25] <vila> pull -ooverwrite and I don't know what mistake you're talking about
[10:26] <vila> the reason I checked is that I wanted to cherry-pick manually for the test ;)
[10:28] <vila> running at http://babune.ladeuil.net:24842/job/debug-windows/104/console
[10:28] <vila> looks pretty good no ?
[10:28] <mgz> much more like it
[10:29] <mgz> will propose branch for merging
[10:29] <vila> Really looks pretty good to me and jenkins agrees :)
[10:29] <mgz> thanks vila!
[10:29] <vila> omg, thanks to you !
[10:29] <vila> this one has been such a pita...
[10:29] <vila> ... for so long
[10:30] <vila> running a windows full test suite to celebrate ;)
[10:31] <vila> gee, I'm so glad I nudged you on the reduced run...
[10:39] <mgz> I have a nasty feeling I broke this in the first place...
[10:40] <vila> bah, as long as it's fixed now...
[10:41] <vila> and remember it has been there for.... ages
[10:41] <vila> and 'False' for a default value stream.... is suspicious at best
[10:46] <mgz> yeah, I'm guessing that's why I made the mistake, why would you want to set binary on a boolean?
[10:47] <vila> indeed
[10:47] <vila> another case for doc not matching code ;)
[11:49] <mgz> okay, I'm out over lunch for a bit
[15:20] <vila> jelmer, mgz: https://code.launchpad.net/~mbp/bzr/261315-stacked-hpss weird warning there...
[15:20] <vila> did we break compatibility with BzrBranch6 format at one point ?
[15:21]  * jelmer looks
[15:22] <jelmer> vila: not that I'm aware of
[15:22] <jelmer> vila: I don't see how that's related to BzrBranch6 though
[15:22] <vila> ha, sorry
[15:23] <vila> well, it seems our parametrized tests (for smart server) covers only BzrBranch7 and 8
[15:23] <vila> and... damn, what was it...
[15:24] <vila> while debugging yesterday I went across some piece of code that made me think that the smart server was more or less not supporting anything older than that for branches
[15:25] <vila> coming cross the branch above while trying to understand why Branch.get_stacked_on_url was always called for smart branches
[15:25] <mgz> you mean that it's out of date?
[15:25] <vila> it may just be that this branch is stacked on the old trunk
[15:26] <mgz> yeah.
[15:26] <vila> and something broke around that
[15:26] <mgz> that's the context I've seen that note in before
[15:35] <vila> ha, good enough then
[15:53] <jelmer> hah
[15:53] <jelmer> commit in lightweight checkouts, from 220 to 30 roundtrips
[15:53] <jelmer> with Vincent's config changes, that'll probably end up < 25
[15:54] <vila> BOOM
[15:54] <vila> \o/
[15:54] <vila> emacs devs (among others) will be delighted :)
[16:39] <vila> jelmer: just found back the bug that makes me hesitant to say we support subtrees in 2a: bug #634470
[16:39] <vila> jelmer: but I can't find your merge proposal about that anymore...
[16:41] <vila> jelmer: also look at comments in test_sprout_recursive_treeless in bt.test_bzrdir
[16:51] <jelmer> vila: I don't think we'll be able to use the 2a working tree format for nested trees
[16:51] <jelmer> but we should be able to use the 2a repository format
[16:52] <vila> ooooh, sry for the misunderstanding then
[16:56] <vila> jelmer: ... but what's the point of having a repo we can't checkout from then ?
[16:57] <vila> hmm, I mean, you surely have a use case in mind, what is it ?
[18:25] <Wiz_KeeD> hey guys!
[18:30] <jelmer> hi Wiz_KeeD
[18:30] <Wiz_KeeD> hello jelmer
[18:30] <Wiz_KeeD> i'm going to ask a noob question for which i might be accused but here goes, after downloading a branch (from launchpad) to just update it to the lastest revision
[18:31] <Wiz_KeeD> do i still use bzr branch and be in the same place with the dir that has the same name
[18:31] <Wiz_KeeD> ?>
[18:35] <mgz> nope, you use `bzr pull`
[18:35] <jelmer> Wiz_KeeD: if you want to update an existing branch you created with "bzr branch", you can use "bzr pull"
[18:35] <mgz> from inside the directory where you created the branch
[18:35] <Wiz_KeeD> so i do bzr pull lp:blabla in that directory, but is there something wrong using branch to pull an existing branch?
[18:36] <mgz> `bzr branch X` means 'create a new branch of X in a new location
[18:37] <mgz> `bzr pull` means get the newest revisions of a branch existing in the current directory
[18:37] <mgz> they're for different situations.
[18:37] <Wiz_KeeD> i should have paid more attention, i intend just to get the latest version and use it, thus pull is for me
[18:37] <fullermd> Also, you don't need the lp:Blah on pull.  It'll pull from where you branched from automatically.
[18:38] <mgz> generally you use branch once to get a copy of someone else's work, then pull thereafter to keep it updated
[18:38] <Wiz_KeeD> so i did good by using branch first?
[18:38] <Wiz_KeeD> or should i have used pull from the getgo
[18:38] <fullermd> 'branch' is how you get the branch in the first place.  'pull' is how you update it once you have it.
[18:39] <Wiz_KeeD> then i've got a good start
[18:39] <mgz> yup.
[18:39] <Wiz_KeeD> now i just need to use pull
[18:40] <Wiz_KeeD> what about checkout, what's that about?
[18:40] <fullermd> That's a whole different thing that will probably just add confusion to talk about.
[18:42] <Wiz_KeeD> i know it's different i was just asking cause someone asked me if i had used that
[18:44] <Wiz_KeeD> and i use bzr pull inside the directory which was created by bzr branch?
[18:49] <mgz> Wiz_KeeD: that's right.
[18:49] <Wiz_KeeD> that's cool, at least now i have some sort of control :D
[19:29] <mgz> okay, fun done for the day