[00:00] mtaylor: it may simply be that that is the size of your tree [00:00] mtaylor: how big is a drizzle tarball (gz) [00:01] lifeless: 7M [00:01] hi all [00:02] mtaylor: so before its 178 and after its 164 [00:02] mtaylor: did you perhaps start with all of mysql and *then* delete huge chunks ? [00:02] lifeless: yes. [00:02] thats it then [00:02] (not history of course, but yet) [00:02] yes [00:02] we can't compress changes to the deleted files, cause they aren't changing :) [00:03] ah, fair enough [00:03] was there ever a plan to do partial branches - like a full branch except perhaps going back only 100 revisions or so? [00:04] kindof [00:05] we have ~ 1/2 of it done - stacked branches [00:05] the other half is disconnecting them and allowing user controlled connect/disconnect [00:06] so that I just just pull the stacked branch without pulling the stacked on branch? [00:06] yes. handwaves furiously. [00:06] indeed [00:06] how big was a mysql tarball (gz) [00:08] mtaylor: ^ [00:11] Hi, is there a ticket management system recommended for bazaar? [00:12] bzr can integrate with quite a few - we allow you to configure that. However we ship with built in configuration for launchpad [00:12] and launchpad knows how to read the data back out of bzr pretty well [00:13] lifeless: 19M [00:13] mtaylor: urggle. Ok we should investigate [00:14] mtaylor: 1.18 will convert ok. don't convert with 2.0 or bzr.dev at this time. Brrrroken [00:14] silently too sometimes. [00:14] lifeless: lovely [00:14] yeah [00:15] aliases variable [00:15] alised [00:15] bah. spellink iz broken. [00:15] 'aliased' === kiko is now known as kiko-afk [00:23] spiv: ping [00:25] beuno: what bzr did you use to upgrade lh ? [00:26] beuno: if you used 2.0 or bzr.dev you should redo it with 1.18 [00:26] lifeless, 2.0rc1 :( [00:27] bug 422849 [00:27] Launchpad bug 422849 in bzr "InterDifferingSerializer generates InconsistentDelta error upgrading drizzle repo to 2a - adds a file already versioned" [Critical,In progress] https://launchpad.net/bugs/422849 [00:27] lifeless, and by redo, you mean...? [00:28] back out, restore the backup, convert again. [00:28] theres a high chance it wrote arbitrary data into your history [00:29] and I don't have stats on what % of the time it will catch the error with the inconsistent delta warning. [00:29] ok, sill do it [00:29] thanks lifeless [00:30] dinner now, fix later [00:31] beuno: if you converted over the network its ok [00:31] beuno: its only if you converted locally that its fail [00:31] jelmer: hi, still here? [00:31] hi [00:31] emmajane: still here? [00:31] lifeless, ah, I did. [00:32] more detail coming up on the list soon. [00:32] poolie, barely :) [00:32] ok :) [00:32] don't need to hang around on my accoutn [00:32] if you didn't already do it (i haven't read all my mail) i'm going to forward some screenshots to the list [00:32] i'd like to continue the discussion there [00:33] poolie, I'm making slides explaining square dancing as an analogy for PHP. you're welcome to distract me. :) [00:33] heh :) [00:33] poolie, Oh. the screenshots went to the list this morning. there's been about 10 replies? [00:33] i dont understand the difference between bzr branch -r -5 . ../next; bzr pull . --overwrite -r -5 and bzr branch -r -5 . ../next; bzr uncommit -r -5 # could anyone please explain? [00:34] maybe it's just because i havent slept in 24 hours :-D [00:34] are those two alternative sequences? [00:34] lvh: the uncommit leaves the tree changes in your current directory [00:34] poolie, the two that I sent? one has the carousel and one is closer to the wireframe. [00:35] lifeless: Ah, whereas the former will properly pretend I never changed anything? [00:35] you'll discard your working tree changes as well as the revisions [00:36] as long as 'discard' means 'move into the new branch' thats what I want :-) [00:36] but im guessing thats what the bzr branch -r -5 does [00:37] lvh: heres a better recipe [00:37] bzr branch . ../next [00:37] bzr pull . --overwrite -r -5 [00:37] I have you a buggy recipe before [00:38] okay [00:38] thanks :-) [00:39] lifeless: i wonder if we should remove the downloads for 2.0rc1? [00:39] well done btw [00:40] poolie: that would be a good precautio [00:40] n [00:50] master: Exporting thorough delta revision 93606/133780 with 140/822/110 added/changed/removed files [00:50] still going... [00:57] poolie, the wifi keeps dropping me and i'm going to call it a night. please do eemail if I've missed anything. [01:00] lifeless: pong [01:06] hello spiv [01:06] lifeless, tangentially https://bugs.edge.launchpad.net/launchpad-registry/+bug/422902 [01:06] Launchpad bug 422902 in launchpad-registry "want a way to lock/embargo releases and downloads" [Undecided,New] [01:06] spiv: hi; see the list, and my question about tests :) [01:08] rockstar: how to you create a new pipe and take the uncommitted changes? [01:08] * spiv looks [01:12] oh, the question about tests is in scrollback, not on the list? [01:12] yes [01:14] Something in per_interrepository I think. [01:15] I think .test_fetch.test_fetch_parent_inventories_at_stacking_boundary (and similarly test_fetch_parent_inventories_at_stacking_boundary_smart) [01:21] igc, +1 to you trying to improve the installer [01:21] poolie: yep, somewhat [01:21] poolie: I'll be off irc for a while, learning InnoSetup & reviewing how the current installer hangs together [01:21] it's probably redundant to tell you so but please document or script it so we can reproduce it [01:21] poolie: call me re the content filtering stuff when you want [01:21] i think a big problem here is that this is complex and manual, and requires building up state on a particular machine [01:22] unless lifeless wants help with 2a bugs i'm going to do that today [01:22] ok i will [01:22] s/that/content filterign [01:22] spiv, ^^ that's what i had to say [01:22] how about you? [01:22] poolie: there's 2 patches related to content filtering submitted yesterday for review so starting with those might be good [01:23] poolie: sure, I'll write things up [01:23] bbl [01:23] kk [01:24] igc there is a wiki page about it [01:24] and john said he sent mail to canonical-bazaar recently [01:24] poolie: I have an errand to run in crows nest (my memory); leaving for that shortly. [01:25] k [01:25] we can do lunch if you want [01:25] igc, also, i'll leave it up to you where you want to experiment [01:25] but at some point we need all the dependencies on an ec2 machine [01:26] so, maybe it would save time to do it now... [01:26] otoh if you need to experiment it may be easier to do it locally [01:26] i'll send you the rdesktop command anyhow [01:26] poolie: I just want to make it work locally first [01:26] poolie: I saw the doc re ec2 [01:27] k [01:27] i have some changes locally [01:27] poolie: about to ask for reviews for the chk roots-only commit_write_group check; [01:27] as far as using just a single account etc [01:28] I'm then going to unshelve the changes I have for testing for all relevant chk keys and work on that, the prototype appears to function. [01:28] lifeless: is there anything i should do on 2a? [01:29] i guess primarily, do you think all those failures have the same cause? [01:29] poolie: try my patch [01:29] poolie: see if it addresses the error you had] [01:29] good idea :) [01:31] lifeless: wow. I _really_ love silent mode in automake 1.11 [01:31] mtaylor: :) [01:31] poolie: checking it is on my todo but its easy to parallise on [01:31] https://code.edge.launchpad.net/~lifeless/bzr/bug-422849/+merge/11023 [01:31] sure, that's just the kind of thing i was looking for [01:46] thumper, I shelve the changes, add-pipe, and then unshelve. [02:08] rockstar: ok [02:26] anyone know why we get UnexpectedStderr: Unexpected standard error from subprocess: warnings.warn("%r was gc'd while locked" % self.repr) ?? [02:27] I think the UnexpectedStderr may be ours (LPs) but I'm not sure [02:39] hi [02:39] thumper: i've never heard of UnexpectedStderr [02:39] but the warning is ours [02:39] um [02:39] i thought we got rid of them [02:39] poolie: the UnexpectedStderr are probably our checking of the bzr process for pulling [02:39] if it's your code calling into bzrlib you're probably missing a try/finally: thing.unlock() [02:40] thumper: generally those warnings are associated with other branches that failed to pull [02:40] poolie: we aren't getting it all the time, just a few times [02:41] mm [02:41] for a while, all loom branches did that, but i think that's fixed [02:41] so i'd speculate that either in the puller code or bzr [02:41] something is unlocked normally but not after an exception [02:47] poolie: did it fix your issue [02:47] ? [02:48] [02:55] lifeless: that seems to have fixed it [02:55] poolie: recognising this is a bit of a "how long is a piece of string?", are we expecting to try again on the bzr upgrade to 2a today? Is cool either way, just wanting to get an idea on timing etc. [02:55] spiv, what do you think of http://sourcefrog.net/tmp/20090901-341535-eintr.diff [02:55] spm, if lifeless's patch, which i'm testing now, lands [02:55] and it's the top priority [02:55] that should unblock us redoing the upgrade [02:55] excellent! [02:56] to find the next bug :) [02:56] or not [02:56] ha [03:02] poolie: wow, that seems a bit extreme somehow. But it's probably correct. [03:02] Assuming it does actually work when you test it manually :) [03:02] it does [03:02] see https://bugs.edge.launchpad.net/bzr/+bug/341535 [03:02] Launchpad bug 341535 in bzr "hpss SmartMedium doesn't handle eintr" [Medium,In progress] [03:03] where i also say i'm on the verge of making a decorator object that wraps these methods [03:03] do you know of one? [03:03] that would also make it more testable, though [03:03] :/ it's one of those things where unit testing it does not give great assurance that it actually works [03:05] spiv, what do you think? [03:05] if i make a class i just need to make sure it's used everywhere [03:06] i guess it can be stuck into the constructors fairly easily [03:08] hi people! I'm using version 1.6.1, is there any command that I can see the files that changed between the revisons x..y? [03:08] Hmm, I'm torn. [03:09] Decorating the socket/pipe/etc object is probably cleaner, but on the other hand your patch is nice and straightforward. [03:10] ricardo_br: bzr diff -r x..y | diffstat? [03:10] or 'bzr status -r x..y' [03:10] oh, neat [03:10] spiv, if i thought there would be more cases then i'd do the object [03:10] ricardo_br: you might like to upgrade though, that's a bit old now [03:10] is that the package in a distro? [03:10] If the underlying objects weren't private to the SmartMedium classes, that would be a pretty strong case for decorating. [03:11] poolie: right. [03:11] it's true it's more than 3 cases, strictly speaking [03:11] maybe i'll propose just this for now [03:11] poolie: So, I'm happy with the patch as is. If you feel like writing the decorator I'm happy to look at that page too :) [03:11] But it's not a big deal to postpone that refactoring indefinitely. [03:13] poolie: I think I've installed it through ubuntu apt-get install [03:16] I've changed one file in the rev 61 and another file in the rev 62, when I run "bzr diff -r61..62" I can see only the changes in the file in rev 62 [03:17] ricardo_br: you'll need -r61..63 then [03:17] sorry [03:17] -r 60..62 [03:17] the previous one is "the changes from 61 to 62" [03:19] spiv, but it's not urgent [03:20] poolie: thanks! it worked. Just another question, can I see only the file names? === cprov is now known as cprov-zzz [03:23] rather than what happened to them? [03:23] um [03:23] not super easily, but you could use a shell script [03:23] btw newer versions for ubuntu are in https://launchpad.net/~bzr/+archive [03:25] spm btw the patch i referred to above is https://code.edge.launchpad.net/~lifeless/bzr/bug-422849/+merge/11023 and bug 422849 [03:25] Launchpad bug 422849 in bzr "Incorrect conversions in 2.0rc1 and bzr.dev" [Critical,In progress] https://launchpad.net/bugs/422849 [03:26] thanks for the tips poolie and bob2, I'll checkout the new versions [03:26] just fyi; we'll ping you when we get closer [03:26] poolie: did you mean me? or andrew? I assume the latter. [03:26] no, you [03:26] that's the one that's blocking the upgrade [03:26] you don't need to do anything with it [03:26] just in case you were wondering [03:27] ah, right. wit hthe plot now. [04:14] What is the mailing list and bundle-buggy still the best for patches or merge request in launchpad? === johnf1 is now known as johnf [04:57] johnf: best is merge request [04:58] jam: and a separate branch per feature/bug fix? [04:58] johnf: generally [04:59] hey [05:00] hey jml [05:00] if I wanted to do a patch _right now_ to stop Bazaar from treating directory removal as a conflict when the directory contains pyc files, how should I go about it? [05:00] anyway, off to bed for me [05:00] jam: g'night [05:14] jml: doesn't .bzringore *.pyc mean that that problem goes away? [05:14] bah === AfC1 is now known as AfC [05:15] hmm. does it? [05:15] * jml tries science [05:15] AfC: no [05:15] it's the old "junk vs deliberately unversioned" chestnut [05:17] jml: I think fondly of science. Especially mixing the chemicals together and making them go phoof! [05:17] but it's irritating me enough to do something about it. [05:18] there, I just empirically verified that mwhudson is right. [05:19] AfC, well, in these enlightened times chemicals are entitled to do whatever they want in the privacy of their own home. === thumper is now known as thumper-afk [06:15] ok, so git really is quite fast. [06:25] is there a way to create a branch of bzr inside launchpad without having to branch to my laptop and then push? [06:27] Well, you could do "bzr branch lp:bzr lp:~johnf/bzr/foo", but that still goes via your laptop... [06:28] If you already have bzr on your laptop, it shouldn't be very expensive to do that push, though, because the branch will be stacked on lp:bzr. [06:28] spiv as in 200MB traffic needs to go both ways or does everything happen on the server end? [06:29] ahh it's the stacking that I don't have [06:29] (and even in the lp:bzr -> lp:~johnf/bzr/foo it should still stack, although I can imagine it would fall a fair way short of being full efficient as that case hasn't been tested much) [06:29] You don't? Stacking should be automatic when you push to Launchpad, unless your local copy of bzr is in an old format? [06:30] yeah just realised my bzr.dev wasn't off launchad [06:30] fixing that now [06:31] so if I branch from lp. then branch again on disk and then push to lp will everything remain stacked? [07:04] hi all [07:09] hey vila [07:22] hi spm, vila [07:23] spm, it looks like that patch will work but other stuff came up and we're not likely to attempt the upgrade today [07:23] we'll probably merge it and may try it tomorrow [07:23] fair enough, shame in a way :-/ [07:23] jml, still around? [07:23] poolie, yep [07:24] quick call? [07:25] poolie, sure. [07:25] skype or pots is fine by me [07:25] let's see if skype will play [08:13] bug 422849 is in pqm for 2.0 [08:13] Launchpad bug 422849 in bzr "Incorrect conversions in 2.0rc1 and bzr.dev" [Critical,In progress] https://launchpad.net/bugs/422849 [08:20] lifeless: trivial enough to land without review ? I ask because I read the related mails first thing this morning (before hitting enter on 'bzr upgrade', pfew, lucky me) and couldn't find the merge proposal... [08:22] and didn't notice the linked branch until now :-/ [08:23] lifeless: right, so the patch is indeed trivial and was in the bug comments, good [08:25] lifeless: yet.... fixing a critical bug without adding test[s]... :-/ [08:25] vila: it was reviewed :) [08:25] ok [08:26] vila: I want tests; I'm not done on the bug. If you felt like writing some test during your day that would rock; otherwise I hope to get something that triggers it cleanly etc tomorrow. [08:26] Ha great [08:26] vila: missing tests shouldn't prevent us fixing a problem! [08:26] sure [08:27] obviously I missed some discussion, no worries, just catching up [08:27] happy to see we agree on all fronts :) [08:27] and above all thanks for fixing it since, well, I *was* about to upgrade locally :) [08:28] my pleasure :) [08:28] that close: '' [08:28] poolie: spm: I think we should wait for bzr.dev nightlies to have this fix before executing on 2a for bzr.dev [08:28] Doing otherwise will make it harder for people to be sure they can upgrade cleanly themselves. [08:30] vila: your test spike looked interesting [08:31] lifeless, spm: exactly why I asked to keep notes about what version was used to upgrade. (And I don't pretend my crystal ball warned me, it was just,,, well, prophylactic acting) [08:31] vila: I look forward to seeing it in action. [08:31] shell-like you mean > [08:31] shell-like you mean ? [08:31] vila: I'm hoping that it will be able to be totally simulated in memory :) [08:31] yes [08:32] Many threads are converging in the right direction I think, I like jam ideas about MemoryTree and branch builder, I really think we should upgrade them [08:32] so do I [08:32] I think we should build our testing safety net safety net first [08:32] I mean, add the missing features to MemoryTree and branch builder so they can be used more broadly [08:33] I see the most important things being some additional glue and reporting [08:33] so we can answer questions like 'how important is this test', or 'these tests' [08:33] 'if I delete this test, what coverage do I remove' [08:33] oh yes... [08:33] and 'what tests add no coverage today? [08:33] ' [08:34] an important milestone to reach is to know that all code is covered (even if only once), I have no idea where we are today [08:34] now, we'll need to think about the answers to those questions, but I think you'll agree that they are very interesting questions [08:34] ooooh yes [08:35] andrew wrote a coverage plugin [08:35] and there are some coverage analysis tools in the python testing community [08:35] At the risk of sidetracking you :) [08:35] we have a --coverage option, I need to use it more :) [08:36] well, not only me :) [08:36] --coverage is the plugin [08:36] I think [08:37] nah, bzr help global-options [08:37] available in every good bzr :) [08:37] ah no [08:37] needs to be per test [08:38] or you can't answer those questions [08:38] figleaf sections can do it [08:38] or per test decorators [08:38] with only a moderate failure mode for tests of lsprof [08:43] so, to run test in isolation I use selftest-by-n.py: http://paste.ubuntu.com/263626/ [08:43] ./bzr selftest --list >all-tests [08:43] selftest-by-n.py --starting-with --in-tmp --number 1 all-tests [08:44] I didn't play with it for months but ran it again last time we discussed about that, I need to analyse a bit more, but I already have some leaks identified (the meacs-bzr-send.xxx.el in /tmp for one) [08:45] s/meacs/emacs/ [08:45] and the bzr-limbo ones ! [08:45] pastebin.com/f600ce040 [08:46] thats much/most of my sketch [08:46] enjoy [08:46] :-D [08:46] It needs: [08:46] Yeah, the existing --coverage is pretty basic. [08:46] better data mode [08:47] and thats about it [08:47] per-test collection/reporting would be neat. [08:47] the better model I think would be best to try next is: [08:49] lifeless, spiv: My gut feeling is that trying to de-tangle coverage data is... NP-complete, I'd rather generate coverage data for each test in isolation and work hard to avoid redoing it uselessly [08:49] file_line:file_line_id file_line_id:testid_id testid_id [08:49] vila: I agree; thats what my plugin does [08:50] oh [08:51] but then you don't need to go down to lines, you can just keep 'test -> modules+' [08:55] spiv: --lsprof-tests gives you stome per test stuff today; no consistent reporting [08:57] stome ? [08:58] some [08:58] ha. [09:01] can someone point em to technical information about the default file format that is used by bazaar? I just want to create a little reader application .. [09:01] s/em/me [09:01] look at the developer notes in doc.bazaar-vcs.org [09:04] vila, i might sign off soon [09:04] vila: per line gives you per function when combined with diff [09:04] is there anything you want to talk about? [09:04] vila: which gives you 'run the tests for this change' [09:05] lifeless: If it works, great ! My fear is that it's trickier to get right than just: run these tests because one of their associated module has changed [09:06] poolie: nothing in particular, I think I've got enough feedback on shell-like tests to make a more concrete proposal (without putting too much features yet anyway, mostly doc, look at doctest matching and some polish) [09:07] Overall, the intent is to have something that you can copu/paste your shell session, lightly edit it and a get a runnable test [09:07] vila: the function matching code is done and working [09:07] s/copu/copy/ [09:08] vila: its just an efficient index that is needed [09:08] lifeless: That's how I understood it [09:08] lifeless: err wrong context :) [09:08] I thought you were talking about doctests :) [09:08] nooo [09:09] 31K revisions of netbeans to go [09:09] vila, cool, i was happy to see that posted [09:09] poolie: vila: well done on your progress on the 'shell test' stuff [09:10] poolie: I thought so :-) The trigger was when you said: 'could be used for merge resolution tests' to which I nearly replied 'Will you stop reading my mind ! ' [09:10] vila: I'm yet to look at it but it's very much along the lines of what I've been dreaming of [09:11] igc: not for you ! You're testing at far too high levels already :-P [09:11] vila: I'm sure when it's ready it will help casual contributors write more tests more easily [09:12] igc, something nontechnical came up today so i didn't do anything on filtering :-( [09:12] sorry [09:12] maybe tomorrow [09:12] vila: :-) [09:12] poolie: np [09:12] * igc dinner [09:12] good idea [09:12] igc: yup, casual contributors is definitely the target [09:13] only thing I found is http://doc.bazaar-vcs.org/latest/developers/packrepo.html which didn´t help enough .. [09:15] are there no more detailed docs about the file system? [09:16] or is there already a php script that is able to read bazaar branches? [09:22] NEBAP|work: I believe folk have written php code to call out to bzr [09:23] NEBAP|work: I wouldn't recommend reimplementing the disk format: there is a chunk of code and logic there, its neither small nor simple [09:23] lifeless: yeah [09:24] lifeless: I just want to enable my page to read the format to easily implement some "open source" code viewing .. [09:25] and I didn´t find any implementations in php [09:34] bug fix -> bzr.dev [09:34] lifeless: you may want to review the patch I'm preparing about the leaks to see why you didn't catch these ones (that's for tomorrow) [09:36] vila: I haven't written code to catch os calls yet [09:36] lifeless: at least I *think* you didn't catch them, but since your related patch hasn't landed yet( [09:36] vila: like subprocess :P [09:36] vila: I haven't had time to progress that spike for a few days [09:36] vila: feel free! [09:36] :-) [09:37] not sure the ones I'm catching are in the scope, so far that's tmp files created explicitly but not cleaned up [09:37] seriously though, I think the next step is more protection and or coverage [09:37] after that run-changed-code [09:37] then back to isolation [09:38] vila: my plan there is: hook into file() and open() and unlink() [09:38] + rename [09:38] a create file attempt outside TEST_ROOT and /tmp is an error [09:38] ditto read [09:38] a create file / dir in /tmp that isn't later cleaned up is an error [09:39] TMPDIR not /tmp, just in case :) [09:39] clean up can be mv into TEST_ROOT [09:39] or mv and delete within TMPDIR [09:40] "isn't later cleaned up" is the tricky one since you can't trap it early, you can only whine at tearDown time [09:41] lifeless: but that should work and be quite pleasant, I wonder if I should leave these leaks to server as easy preys... [09:41] s/server/serve/ [09:42] well, they are there already, they can be fixed but not merged where they are needed. [09:53]