[08:33] hi. Internet where I am is very very unreliable and slow. Is there a way to resume a branch that has been cut off? I am trying to branch emacs and it keeps stopping, then I have to start the whole thing over. I can't find anything via search. [08:48] crtxc: you probably want to pull by batches, so: [08:49] bzr init-repo emacs ; cd emacs ; bzr init trunk ; cd trunk ; bzr pull -r100 [08:49] then 'bzr pull -r200' until you get to the tip [08:50] use any increment that your connection can support 1.000 10.000 100.000 [08:50] once you get the full history, things should be more reliable as you'll need to download only the new ones [08:52] discussions about allowing more robust branching by automating the above occur from time to time but I don't remember anybody going ahead and implement it [08:58] morning all [09:01] vila, oh, ok. I never came across -r200, that sounds much better for lower the probability of line failure. Ty very much. [09:03] mgz: _o/ [09:07] vila, is -r revision ARG? I am trying to find it in the man. [09:08] yup [09:09] vila, hats off to ya, that is a very clever solution. :) [09:09] ty [09:11] yeah, I learned a few tricks by lurking in this channel so these kudos are really for more than me (/me blushing) [09:12] if you have a web site or a blog you might want to make a small post and get some traffic with that. I see a few people had trouble with that. :) Then kudos to all who have good brains. :) [09:13] :) [09:14] * fullermd is willing to accept any and all credit. [09:14] :) [09:15] ha, right, yeah, that's all fullermd fault, now that you mention it :) [09:15] 's ? [09:17] fullermd has been so kind for hidding the i an n between the m and d. If fullermd weren't so shy it would be fullermind for all to see. :) [09:19] Here now. *I* handle the bad puns around here. You're on my turf, sparky! [09:19] :) [11:13] hah, finally figured out what the trouble was with those multiple upstream tarballs [11:14] jelmer: \o/ ? [11:15] planets should be well aligned, my wifi problem just... resolved itself (using canal 6 instead of 13 *cannot* be related right ? Not when the only laptop that was hanging trying to connect is mine, right ?) [11:18] wifi goes by water in france :) [11:23] antenna in your laptop is damaged and finds some channels easier to tune than others? [11:24] the breed of chicken you sacrificed was not holy enough to use channel 13? [11:25] goats, I always use goats... But now that you mentioned it I may have to audit my provider... [11:38] I guaranteed the goats for SCSI. I didn't say nuffin' about 802.11. [11:55] vila: Not all wifi adapters can go up to channel 13. [11:55] vila: I've had a few that only went up to 11. [11:55] I thought fullermd said he was in charge of the bad jokes... [11:55] soren: good point, but the router upgrade triggered the issue while the previous was already using channel 13 [11:56] Why don't you just raise the frequency of 10 a little, and have 10 as the top channel? [11:56] vila: Oh. [11:56] fullermd: lol [11:56] soren: still, thanks for pointing that [11:57] SCSI ? Come on ! I still have cables and even scsi drives... in my attic ! But I was clear enough when we engage on this goat deal that they won't be used outside of sabbat where virgin (and not goats) are used anyway [11:58] (the scsi stuff I mean, not the goats) [11:58] jelmer: what's your feeling about your reconcile proposal and bug #897487 ? [11:58] Launchpad bug 897487 in Bazaar "progress indication for Repository packing and reconciliation over HPSS" [Medium,Confirmed] https://launchpad.net/bugs/897487 [11:59] jelmer: should the bug be a pre-requisite ? Do you think you can fix it soon ? Should we just land and see ? [11:59] 4) should we raise the importance to high ? [12:01] writing help thinking, so: I bumped to high and approved ;) [12:09] vila: I wonder what the best way is to provide progress reports [12:09] vila: if it's sufficient to just stream some data, then we can easily do that, even if it's not very useful data [12:10] jelmer: I don't know the code well enough to say if multiplexing data and progress is easy or not, so if there is data you can stream, good enough [12:11] vila: btw, on another note [12:11] vila: if we're looking at fixing the import code in bzr-builddeb, I wonder if we could stream directly from the tarball into commit builder [12:12] vila: I've been wondering about that previously as well, because currently we have to check out the base parent on disk, etc [12:12] so it would improve performance, but it would also help my current work [12:12] my understanding is that import is not simply a commit, there could be renames and kind changes [12:12] and deletions, and so on [12:13] what I don't understand though, is why we can reuse more of our existing stuff. Are renames and the like really the issue again here ? [12:13] vila: deletions and so on shouldn't be a problem, [12:13] as in: some operations cannot be automatically deduced [12:14] vila: ? I don't see how that matters, the only difference is that we're reading the contents for the commit from a tarball rather than off disk. [12:15] ha, let's sync [12:15] I was referring to the actual implementation that seems to use a transform tree to better handle renames and file-id reuses [12:16] you're talking about using a different source for commit, which indeed sounds like a good plan (gmta ;), but what about file-id reuse and renames ? [12:18] are the existing tests good enough to cover that ? (obviously nothing covers bug 800270) [12:18] Launchpad bug 800270 in bzr-builddeb "import-tar incorrectly handles symlinks turned into directories" [High,Triaged] https://launchpad.net/bugs/800270 [12:32] jelmer: still there ? [12:32] I think being able to do certain transforms without having a tree on disk is something we need. [12:34] vila: sorry, back now [12:35] vila: I'm pretty sure there are some tests for preserving file ids [12:36] and renames ? [12:37] mgz: wow, you're raising the bar now ;) [12:38] bah, pqm not using news_merge is now really going on my nerves [12:39] hmm, could it be that pqm is using a too old bzr version... [12:39] ... and we don't want to upgrade until that subunit/testools compat bug is fixed, I've lost track :-/ [12:40] vila: I think the plan also was to look at tarmac [12:41] hehe, reading mgz proposals on the active review page is... funny: fix-bzr-subprocess followed by don-use-bzr-subprocess-after-all :) [12:41] jelmer: yeah, better [12:42] wwooooow, lunch time [12:46] hey, I said it was a bug in two halves, I just fixed both of them :) [12:48] hi. I cloned emacs. I am not a developer. I only want to make a copy, build emacs, then use the original to update any changes on the parent repo. Did I do this right? http://codepad.org/et7ETDzS [12:51] crtxc: you don't really need any of that except `bzr branch` for your use [12:51] all I'd suggest is using the launchpad mirror rather than savannah may still be faster [12:52] oh. So I just do bzr branch everytime I update? [12:52] no, you branch once, then you just `bzr pull` to update [12:52] oh. I overcomplicated it. [12:53] right, but the extra bits you did aren't harmful [12:53] ok :) [12:53] they're just for emacs developers' funny work flows. [12:55] ok. I never did this before I only use bzr to track my text files. [12:57] oops. I just tried to bzr and I got an error. http://codepad.org/0qXcOk71 [12:57] tried to bzr pull^ [12:57] unbind it [12:57] ok. ty. unbind. [13:01] well. Ty very, very much for your insights all. [13:14] ok. That is it. I should do some reading on shell scripting and c++ but my eyes are burning so ty very much [13:14] A little C++ will fix that right up. [13:14] There's no burning left after you gouge them out. [13:14] :) [13:15] I am trying to learn shell scripting, python, and c++. === gthorslund_ is now known as gthorslund [13:45] lunchtime, prize if anyone can guess where I'm going with these mps [13:46] lol, I was reading it and was about to ask :) [13:46] ha, I read only one [13:47] what's the udd mailing list? [13:47] for lp:udd in particular, I mean. [13:48] ubuntu-distributed-devel@lists.ubuntu.com [13:49] mgz: getting encoding right in more contexts ? [13:49] mgz: To lunch. What do I win? [13:50] mgz: rats, lunch of course [14:38] why learn c++ before lisp? === beuno is now known as beuno-lunch === beuno-lunch is now known as beuno [16:43] mgz: I'm still holding my breath [16:43] it will be very exciting... maybe [16:43] hehe [16:44] I dunno, I think holding your breath that long is probably pretty boring. [16:44] Maybe not for your heirs, I guess. [16:44] she looks worried indeed [16:45] jml, is there a convenient way to call testtools.run from python on all of my test_ modules? [16:45] lamalex: 'testtools.run discover [package]' iirc [16:46] lamalex: http://testtools.readthedocs.org/en/latest/for-test-authors.html#running-your-tests will get it righter than me :) [16:46] jml, thats from a shell though [16:47] lamalex: what are you trying to do? [16:48] lamalex: or, is testtools.run.main() not convenient enough for you? [16:49] jml, nevermind that discover thing was exactly what i needed === supton_ is now known as supton [17:08] jml, setUp runs for every test_ method, is there a TestCase wide set up? [17:08] lamalex: no. [17:08] lamalex: having such a thing is a bad idea [17:10] why's that [17:11] lamalex: because it makes test isolation very hard [17:11] lamalex: which in turn makes it very easy to write tests where a failure or mistake in one corrupts the results of others [17:12] jml, yah but we're not writing traditional unit tests [17:12] lamalex: are you not interested in the results of these tests? [17:36] wgz: encoding guessing... to cope with people using wrong fs encodings or not setting any ? [17:36] (I had to breath .... ;) [17:38] not quite yet, but that one is on the list :) [17:39] oooh, at least properly reporting the full string on unicode exceptions ? [17:40] yup, and full unicode output for all errors. [17:41] * vila whistles [17:42] * vila hugs mgz too [17:43] Pah. 7 bits should be enough for anyone. [17:43] now, given that nexuiz-data needs more than 24h and that we kill imports that exceed their 24h quota... we need a finer-grained configuration ;) [17:50] jelmer: pretty cute failure: http://babune.ladeuil.net:24842/job/selftest-chroot-precise/lastFailedBuild/testReport/junit/bzrlib.tests.blackbox.test_checkout/TestSmartServerCheckout/test_lightweight_checkout/ [17:50] jelmer: looks like you did even better than you thought ;-D [17:51] vila: argh [17:52] vila: we'll have to change the lower limit to 34 I guess [17:52] jelmer: yup, not a problem [17:52] vila: there's a lot of variation in a single "bzr co --lightweight" command [17:52] which is not ideal for a test but meh [17:52] the point is to not go up [17:53] do you really need the 9 commits ? [17:53] vila: this is before I worked my magic btw ;-) the hpss-get-inventories branch brings it down to 15 [17:54] woohoo [17:55] jelmer, mgz : would you mind clearing the active reviews page guys, you have 7 approved reviews ready to land there :) [17:55] I'm trying to get everything ready all at once :D [17:56] hehe, beware of conflicts when landing... the more you land before hand the less conflicts you bump into ;) [17:57] on top of that you have one for 2.4 that will need to be merged up ;-p === Quintasan_ is now known as Quintasan [19:07] hmm [19:08] vila: I wonder if that RevisionNotPresent issue we've been hitting with the importer is related to the repository not clearing it's caching of negative revids in the parent map cache [19:33] vila: it looks like the "PoMerger created" message made it into bzr.dev, btw [20:30] okay, a couple of bzr fast-import questions, from git [20:30] I've done the fast-export from git, and then fast-import into bzr [20:30] I now have a directory of a bunch of branches/tags, I think [20:33] I guess I'm trying to figure out what/how to do with those [20:37] hi Dustin [20:38] kirkland: You should be able to just use those branches like you normally would [20:38] kirkland: if they don't have a working tree yet, you can use "bzr co" to create one [20:38] jelmer: oh, hmm, okay [20:38] jelmer: let me try those [20:38] jelmer: all of them looked "empty" except for .bzr [20:38] jelmer: i guess i just needed to co them [20:42] kirkland: we should have bzr-fastimport hint that the branches created are tree-less, just like most other bzr import tools do [20:43] kirkland: this is done for space reasons, btw - you don't want to end up with 20 copies of the kernel if you're fastimporting a kernel repo with 20 branches [20:56] jelmer: I left it there on purpose, I still have doubts about whether it's created only once and it's the cheapest way to gather data. Once I get this feedback, I'll address the issue one way or the other (remove the message or fix the duplicated creation) [20:56] jelmer: hence my reply to your review: "It's not useless noise" ;) [20:58] vila: it should at least be hidden behind a debug flag in that case I think [20:58] vila: it's showing up for every revision processed by the udd importer [20:58] it's one line per merge and will be useless if hidden behind a debug flag... [20:58] what's the easiest way to run Bzr server as a Windows Service? [20:59] vila: that's the case for lots of things [20:59] vila: doesn't mean we have them enabled by default :_) [21:00] then consider that I put a debug flag active by default and that this will be revisited [21:00] vila: sure, I'll file a bug [21:01] if you're really searching to reduce the size of the import logs, there are far bigger targets though [21:04] vila: sure, I'm just saying it's noise unless you're actually trying to debug something related to pomerge [21:04] I *am* :) [21:05] I mentioned that I've seen at least one case where the message where there twice for the same merge [21:06] but to avoid chasing ghosts for too long I submitted without digging further (nothing in my proposal should trigger such a behavior) [21:06] and there is one spurious merge in this sentence [21:06] ghaa, where not merge [21:07] way past EOD ;) [21:08] vila: I still don't think that's a good reason, by that reasoning we might as well enable a whole bunch of things because they will help with debugging - like -Dhpss and -Devil [21:08] vila: if there was a -Dpo_merge flag, *you* could enable it [21:08] anyway, it is indeed well past EOD :-)