/srv/irclogs.ubuntu.com/2012/01/04/#bzr.txt

vilawgz: windows slave seems in better shape, as for debug-windows, a bare 'make' has been deleted, just restored it and running a test right now08:34
vilawgz: i.e. removing the 'import win32utils' was the only needed bit apparently08:35
vilawgz: 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 jobs08:40
vilawgz: 'make clean' does not delete .pyd, cleaning up the debug-windows workspace manually was required, something fishy there but probably not worth digging for now08:47
vilawgz: in the other hand, http://babune.ladeuil.net:24842/job/debug-windows/102/console may give a hint about the (subunit/testtools ?) stream leak08:48
vilas/in the/on the/08:48
mgzmorning all09:09
vilahey mgz :)09:09
vilamgz: let me re-paste previous remarks09:10
vila<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 now09:10
vila<vila> wgz: i.e. removing the 'import win32utils' was the only needed bit apparently09:10
vila<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 jobs09:10
vila<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 now09:10
vila<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 leak09:10
vila<vila> s/in the/on the/09:10
mgzyeah, seemed like the compiled modules were just sticking around from an older build and breaking things09:13
vilayup, caused by the removed 'make'09:16
vilabut debug-windows jobs 100, 101, 102 failing when no tests failed... ?09:17
vilajelmer: around ?09:17
mgzvila: I'm not sure on that, I only messed around with the make calls after a few runs had already failed09:20
vilaha !09:20
viladependency not correctly tracked then ?09:20
mgzI had the setup sh script, followed by make realclean; make for a couple of the runs09:20
vilarealclean deletes the .pyd files ?09:22
mgzit should, but doesn't09:23
mgz(clean should, but doesn't)09:23
mgzbasically, the makefile isn't written to work on windows09:23
mgzbut something else is going on as well I think09:23
mgzvila: possibly something is wrong with the pipeline for subunit handling09:57
mgz(causing the 'lost connection' issue)09:57
mgzthe output text on the server at least contains \r\n and \r\r\n rather than the expected line endings09:58
vilaha ha, progress ?09:59
vila'server' ?09:59
mgzif you do view console output as text on babune and download it10:01
vilawow10:04
vilathat's *inside* the multipart stuff, wth ?10:04
mgzmight be after the fact mangling, it's not completely clear10:04
mgzI note the current selftest template doesn't run ./bzr selftest but has a sh script for that as well10:05
vilayup, part of the babune branch bin/selftest.sh10:06
vilado you want a paste ?10:06
mgzno, it's alright10:07
mgzwell, can look10:07
vilahttp://paste.ubuntu.com/792536/10:07
mgzanyway, this is mostly output log-cosmetic, the junit xml gets generated correctly10:07
mgzso I'm guessing it's the 2junit | 2pyunit pipe at fault10:08
mgzI bet splitting into ./bzr selftest > out; 2junit < out; 2pyunit < out; would work.10:08
mgzsubunit probably forgets to set binary when forwarding from the filters?10:09
vilabreaking 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 binary10:10
mgzyup, that'll be it.10:11
mgzwhat's the easiest way to try out a fixed subunit on babune?10:12
vilaask me :)10:13
vilathe always-falling-down-in-the-stack next task for babune is to add setup/deployment step that could be used for that kind of tests10:15
vilaI'm using subunit revno 151 for now10:16
vilacould probably update to 156 if it helps10:16
vilatesttools revno 224, same remark10:17
mgzvila: lp:~gz/subunit/binary_forward_stream10:19
mgzshouldn't need to update testtools10:21
vilameh, there is already an unconditional make_stream_binary two lines above ?10:23
mgzit's for a different stream :)10:23
mgz...I didn't change it10:23
* mgz corrects10:23
mgzpull --overwrite as I'm pretending I never made that mistake :)10:25
mgzthanks for checking vila :)10:25
vilapull -ooverwrite and I don't know what mistake you're talking about10:25
vilathe reason I checked is that I wanted to cherry-pick manually for the test ;)10:26
vilarunning at http://babune.ladeuil.net:24842/job/debug-windows/104/console10:28
vilalooks pretty good no ?10:28
mgzmuch more like it10:28
mgzwill propose branch for merging10:29
vilaReally looks pretty good to me and jenkins agrees :)10:29
mgzthanks vila!10:29
vilaomg, thanks to you !10:29
vilathis one has been such a pita...10:29
vila... for so long10:29
vilarunning a windows full test suite to celebrate ;)10:30
vilagee, I'm so glad I nudged you on the reduced run...10:31
mgzI have a nasty feeling I broke this in the first place...10:39
vilabah, as long as it's fixed now...10:40
vilaand remember it has been there for.... ages10:41
vilaand 'False' for a default value stream.... is suspicious at best10:41
mgzyeah, I'm guessing that's why I made the mistake, why would you want to set binary on a boolean?10:46
vilaindeed10:47
vilaanother case for doc not matching code ;)10:47
mgzokay, I'm out over lunch for a bit11:49
vilajelmer, mgz: https://code.launchpad.net/~mbp/bzr/261315-stacked-hpss weird warning there...15:20
viladid we break compatibility with BzrBranch6 format at one point ?15:20
* jelmer looks15:21
jelmervila: not that I'm aware of15:22
jelmervila: I don't see how that's related to BzrBranch6 though15:22
vilaha, sorry15:22
vilawell, it seems our parametrized tests (for smart server) covers only BzrBranch7 and 815:23
vilaand... damn, what was it...15:23
vilawhile 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 branches15:24
vilacoming cross the branch above while trying to understand why Branch.get_stacked_on_url was always called for smart branches15:25
mgzyou mean that it's out of date?15:25
vilait may just be that this branch is stacked on the old trunk15:25
mgzyeah.15:26
vilaand something broke around that15:26
mgzthat's the context I've seen that note in before15:26
vilaha, good enough then15:35
=== yofel_ is now known as yofel
jelmerhah15:53
jelmercommit in lightweight checkouts, from 220 to 30 roundtrips15:53
jelmerwith Vincent's config changes, that'll probably end up < 2515:53
vilaBOOM15:54
vila\o/15:54
vilaemacs devs (among others) will be delighted :)15:54
vilajelmer: just found back the bug that makes me hesitant to say we support subtrees in 2a: bug #63447016:39
ubot5Launchpad 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/63447016:39
vilajelmer: but I can't find your merge proposal about that anymore...16:39
vilajelmer: also look at comments in test_sprout_recursive_treeless in bt.test_bzrdir16:41
jelmervila: I don't think we'll be able to use the 2a working tree format for nested trees16:51
jelmerbut we should be able to use the 2a repository format16:51
vilaooooh, sry for the misunderstanding then16:52
vilajelmer: ... but what's the point of having a repo we can't checkout from then ?16:56
vilahmm, I mean, you surely have a use case in mind, what is it ?16:57
=== deryck is now known as deryck[lunch]
Wiz_KeeDhey guys!18:25
jelmerhi Wiz_KeeD18:30
Wiz_KeeDhello jelmer18:30
Wiz_KeeDi'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 revision18:30
Wiz_KeeDdo i still use bzr branch and be in the same place with the dir that has the same name18:31
Wiz_KeeD?>18:31
mgznope, you use `bzr pull`18:35
jelmerWiz_KeeD: if you want to update an existing branch you created with "bzr branch", you can use "bzr pull"18:35
mgzfrom inside the directory where you created the branch18:35
Wiz_KeeDso i do bzr pull lp:blabla in that directory, but is there something wrong using branch to pull an existing branch?18:35
mgz`bzr branch X` means 'create a new branch of X in a new location18:36
mgz`bzr pull` means get the newest revisions of a branch existing in the current directory18:37
mgzthey're for different situations.18:37
Wiz_KeeDi should have paid more attention, i intend just to get the latest version and use it, thus pull is for me18:37
fullermdAlso, you don't need the lp:Blah on pull.  It'll pull from where you branched from automatically.18:37
mgzgenerally you use branch once to get a copy of someone else's work, then pull thereafter to keep it updated18:38
Wiz_KeeDso i did good by using branch first?18:38
Wiz_KeeDor should i have used pull from the getgo18:38
fullermd'branch' is how you get the branch in the first place.  'pull' is how you update it once you have it.18:38
Wiz_KeeDthen i've got a good start18:39
mgzyup.18:39
Wiz_KeeDnow i just need to use pull18:39
Wiz_KeeDwhat about checkout, what's that about?18:40
fullermdThat's a whole different thing that will probably just add confusion to talk about.18:40
Wiz_KeeDi know it's different i was just asking cause someone asked me if i had used that18:42
Wiz_KeeDand i use bzr pull inside the directory which was created by bzr branch?18:44
=== deryck[lunch] is now known as deryck
mgzWiz_KeeD: that's right.18:49
Wiz_KeeDthat's cool, at least now i have some sort of control :D18:49
mgzokay, fun done for the day19:29
=== cody-somerville_ is now known as cody-somerville

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!