| 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:34 |
|---|---|---|
| vila | wgz: i.e. removing the 'import win32utils' was the only needed bit apparently | 08:35 |
| 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:40 |
| 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:47 |
| 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/ | 08:48 |
| mgz | morning all | 09:09 |
| vila | hey mgz :) | 09:09 |
| vila | mgz: let me re-paste previous remarks | 09: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 now | 09:10 |
| vila | <vila> wgz: i.e. removing the 'import win32utils' was the only needed bit apparently | 09: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 jobs | 09: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 now | 09: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 leak | 09:10 |
| vila | <vila> s/in the/on the/ | 09:10 |
| mgz | yeah, seemed like the compiled modules were just sticking around from an older build and breaking things | 09:13 |
| vila | yup, caused by the removed 'make' | 09:16 |
| vila | but debug-windows jobs 100, 101, 102 failing when no tests failed... ? | 09:17 |
| vila | jelmer: around ? | 09:17 |
| 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:20 |
| vila | realclean deletes the .pyd files ? | 09:22 |
| 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:23 |
| mgz | vila: possibly something is wrong with the pipeline for subunit handling | 09:57 |
| mgz | (causing the 'lost connection' issue) | 09:57 |
| mgz | the output text on the server at least contains \r\n and \r\r\n rather than the expected line endings | 09:58 |
| vila | ha ha, progress ? | 09:59 |
| vila | 'server' ? | 09:59 |
| mgz | if you do view console output as text on babune and download it | 10:01 |
| 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:04 |
| mgz | I note the current selftest template doesn't run ./bzr selftest but has a sh script for that as well | 10:05 |
| vila | yup, part of the babune branch bin/selftest.sh | 10:06 |
| vila | do you want a paste ? | 10:06 |
| 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:07 |
| 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:08 |
| mgz | subunit probably forgets to set binary when forwarding from the filters? | 10:09 |
| 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:10 |
| mgz | yup, that'll be it. | 10:11 |
| mgz | what's the easiest way to try out a fixed subunit on babune? | 10:12 |
| vila | ask me :) | 10:13 |
| 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:15 |
| vila | I'm using subunit revno 151 for now | 10:16 |
| vila | could probably update to 156 if it helps | 10:16 |
| vila | testtools revno 224, same remark | 10:17 |
| mgz | vila: lp:~gz/subunit/binary_forward_stream | 10:19 |
| mgz | shouldn't need to update testtools | 10:21 |
| 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:23 | |
| 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:25 |
| vila | the reason I checked is that I wanted to cherry-pick manually for the test ;) | 10:26 |
| 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:28 |
| 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:29 |
| vila | running a windows full test suite to celebrate ;) | 10:30 |
| vila | gee, I'm so glad I nudged you on the reduced run... | 10:31 |
| mgz | I have a nasty feeling I broke this in the first place... | 10:39 |
| vila | bah, as long as it's fixed now... | 10:40 |
| vila | and remember it has been there for.... ages | 10:41 |
| vila | and 'False' for a default value stream.... is suspicious at best | 10:41 |
| mgz | yeah, I'm guessing that's why I made the mistake, why would you want to set binary on a boolean? | 10:46 |
| vila | indeed | 10:47 |
| vila | another case for doc not matching code ;) | 10:47 |
| mgz | okay, I'm out over lunch for a bit | 11:49 |
| 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:20 |
| * jelmer looks | 15:21 | |
| 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:22 |
| vila | well, it seems our parametrized tests (for smart server) covers only BzrBranch7 and 8 | 15:23 |
| vila | and... damn, what was it... | 15:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| vila | ha, good enough then | 15:35 |
| === yofel_ is now known as yofel | ||
| 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:53 |
| vila | BOOM | 15:54 |
| vila | \o/ | 15:54 |
| vila | emacs devs (among others) will be delighted :) | 15:54 |
| vila | jelmer: just found back the bug that makes me hesitant to say we support subtrees in 2a: bug #634470 | 16:39 |
| ubot5 | 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 |
| vila | jelmer: but I can't find your merge proposal about that anymore... | 16:39 |
| vila | jelmer: also look at comments in test_sprout_recursive_treeless in bt.test_bzrdir | 16:41 |
| 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:51 |
| vila | ooooh, sry for the misunderstanding then | 16:52 |
| vila | jelmer: ... but what's the point of having a repo we can't checkout from then ? | 16:56 |
| vila | hmm, I mean, you surely have a use case in mind, what is it ? | 16:57 |
| === deryck is now known as deryck[lunch] | ||
| Wiz_KeeD | hey guys! | 18:25 |
| 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:30 |
| 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:31 |
| 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:35 |
| mgz | `bzr branch X` means 'create a new branch of X in a new location | 18:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| Wiz_KeeD | i know it's different i was just asking cause someone asked me if i had used that | 18:42 |
| Wiz_KeeD | and i use bzr pull inside the directory which was created by bzr branch? | 18:44 |
| === deryck[lunch] is now known as deryck | ||
| mgz | Wiz_KeeD: that's right. | 18:49 |
| Wiz_KeeD | that's cool, at least now i have some sort of control :D | 18:49 |
| mgz | okay, fun done for the day | 19:29 |
| === cody-somerville_ is now known as cody-somerville | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!