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