[00:56] <igc> morning
[00:57]  * fullermd waves at igc.
[00:57] <igc> fullermd: hi
[02:52] <thumper> igc: hey
[02:53] <thumper> igc: how are you feeling today?
[02:53] <igc> hi thumper
[02:53] <igc> thumper: I'm feeling good today thanks
[02:53] <thumper> cool
[02:53] <thumper> igc: I'm getting closer to announcing 0.1 of wikkid
[02:53] <thumper> igc: but hit a line ending snag
[02:54] <thumper> igc: how much do you know about the bzr line ending magic?
[02:54] <igc> thumper: a fair amount
[02:54] <thumper> it seems that http posts send '\r\n'
[02:54] <thumper> and I want to normalise the http post to whatever the current file is using
[02:55] <thumper> is there bzrlib magic that could help?
[02:55] <igc> thumper: probably not
[02:55] <thumper> hmm.. ok
[02:56] <thumper> I'll work on it tonight I think
[02:56] <igc> thumper: we don't support branch-specific rules yet so ...
[02:56] <thumper> igc: where in bzrlib is the line ending work?
[02:56] <igc> newline handling is defined by each user in their ~/.bazaar/rules file
[02:56] <thumper> I may nick some code
[02:57] <igc> thumper: bzrlib/filters may help?
[02:57] <thumper> thanks, I'll look later
[02:57] <thumper> hi lifeless
[02:57] <thumper> lifeless: home?
[03:01] <lifeless> thumper: yes
[03:01] <lifeless> just walked in ze door
[03:02] <thumper> and straight onto irc?
[03:02] <lifeless> well, it is a work day
[03:02] <lifeless> clothes into laundry pile
[03:02] <lifeless> laptop on charger, fire up the standard work env
[03:05] <lifeless> I doubt I'll get all that much done 'today' though
[03:06] <igc> hi lifeless
[03:08] <lifeless> hiya
[03:13] <lifeless> igc: are you home now?
[03:16] <igc> lifeless: yes indeed
[03:16] <igc> lifeless: and back at work at last
[03:16] <lifeless> cool
[03:22] <lifeless> is it just me, or is the emacs-editor-locking thread a little high in the handwavy, little low in the read-whats-been-written-about-the-guts stakes?
[03:25] <spiv> lifeless: it's not just you
[03:26] <spiv> I think my main work for the day will be making sure I take cold & flu pills regularly...
[03:26] <igc> hi spiv
[03:26] <spiv> Hey igc
[03:33] <lifeless> spiv: ubuflued?
[03:42] <spiv> lifeless: mildly, I hope.
[03:42] <spiv> It feels like something that a good night's sleep might fix.
[03:54] <Peng_> With bzr-search indexing committers and stuff, does that mean we have to delete and recreate the indexes or something?
[03:59] <Peng_> Or run "bzr index" again or...?
[04:01] <Peng_> (Although, with bug #580534, that might not work anyway...)
[04:04]  * igc lunch
[04:09] <mwhudson> igc: great to see you back online again!
[04:10] <lifeless> Peng_: delete the index
[04:12] <Peng_> lifeless: Do you know where #580534 fits in? I don't want to delete everything and then discover I can't recreate it.
[04:12] <lifeless> bug 580534
[04:12] <lifeless> bah caches
[04:12] <lifeless> its fixed
[04:13] <lifeless> it was broken by the index reordering stuff in trunk
[04:13] <Peng_> Oh, awesome.
[05:17] <igc> hi mwhudson: thanks!
[05:57] <lifeless> ok, halt(); am naffed
[07:00] <igc> bbl
[07:22] <vila> hi all
[13:48] <vila> fullermd: ping
[13:49] <vila> fullermd: gmp conflict while trying to upgrade freebsd8 (gmp-5.0.1 with libgmp-4.3.2 involved for py-pycrypto and bazaar-ng)
[13:55] <vila> fullermd: nm, pkg_delete -f libwhatver ; pkgdb -F ; portupgrade py-pycrypto appears to do the trick, sanity check welcome though
[14:45] <guijemont> hi
[14:45] <guijemont> are there bzr-gtk people here?
[14:46] <jelmer> guijemont: hi
[14:46] <jelmer> yep
[14:46] <guijemont> cool
[14:47] <guijemont> I've been scratching an itch lately
[14:48] <guijemont> that is, I want bzr viz to have the history graph "collapsed"
[14:48] <guijemont> like qlog does
[14:48] <guijemont> am starting to have something working
[14:49] <guijemont> though not finished yet
[14:49] <guijemont> dunno if you would be interested in integrating such a patch when it's finished
[14:50] <jelmer> Yeah, we'd definitely be interested in something like that
[14:50] <guijemont> I found myself refactoring things quite a bit in the TreeModel
[14:50] <jelmer> though I would encourage you to move the logic to determine those graphs from qbzr into bzrlib
[14:50] <jelmer> and then use that logic from both qbzr and bzr-gtk
[14:50] <guijemont> yeah, would probably be clever
[14:50] <guijemont> do you know how the graph is generated in qbzr?
[14:51] <jelmer> you might also want to talk to garvdm
[14:51] <jelmer> he is the author of that code in qbzr and is also interested in moving the qbzr logic up
[14:51] <guijemont> haven't lkooked at the code, but it's much faster to start: does it generate the graph on the fly when expanding a node ?
[14:52] <guijemont> oh, and also, are there code standards to respect in bzr-gtk?
[14:53] <guijemont> would that be the same as the ones for bzr?
[14:53] <mgz> vila: did we mess something up with babune? because it looks like everything *but* windows is deadlocking in bt.per_repository now
[14:53] <mgz> hey gary.
[14:53] <jelmer> guijemont: basically the coding standard would be the same
[14:53] <vila> mgz: no idea, I'm currently upgrading a lot of various things and haven't investigated yet
[14:54] <jelmer> speaking ofthe devil...
[14:54] <vila> mgz: and congrats for your new and shiny and easy to recognize nick :-P
[14:54] <mgz> ehehe :)
[14:54] <GaryvdM> Hi mgz  (are you Martin GZ?)
[14:54] <mgz> yeah, vila made me get a non-ridiculous nick
[14:54] <GaryvdM> Oh - ok
[14:55] <GaryvdM> Hi vila, jelmer
[14:55] <vila> mgz: but to answer to your first question, I don't think we've messed up anything, most probably an unfortuante coincidence
[14:55] <jelmer> hi vila, GaryvdM, mgz
[14:55] <vila> hey jelmer, GaryvdM  :)
[14:55] <vila> mgz: but if you feel otherwise, I'm all ears
[14:55] <mgz> ehehe
[14:55] <guijemont> yeah, hi .*
[14:56] <guijemont> GaryvdM: so, are you the one who knows about the visual graph generation stuff in qbzr?
[14:56] <mgz> I looked at the history and didn't see anything likely, but yell if you want me to try poking anything here
[14:56] <vila> guijemont: wow, yeah, there is definetly interest for that and GaryvdM's brain is the one you want to suck from :)
[14:57] <GaryvdM> guijemont: I wrote the code...
[14:57] <vila> mgz: I'd like to setup debug-windows to a branch of yours so you and modify it so you can add a test.this file with the tests you're interested in instead
[14:57] <guijemont> if ppl want to play with where I'm at (quite functional) for collapsing in bzr viz, it's at lp:~guijemont/bzr-gtk/collapsed-merges
[14:58] <GaryvdM> vila: If I want to run some test code in a subprocess, should I create a hidden command, and have a blackbox test, or is there an easier way.
[14:58] <vila> mgz: AIUI we now have ~260 new failures we didn't see before
[14:58] <guijemont> GaryvdM: does it generate the graph info on the fly, or is it just better than bzr viz to precompute that?
[14:58] <mgz> yeah, I put a message in a bug about that. fixing the reporting stuff means we're now seeing them all.
[14:59] <vila> GaryvdM: ECONTEXT, don't you enough support in qbzr with qrun or something ?
[14:59] <mgz> vast majority are thread-leak related, makes me wonder if your chunking of tests into small groups workaround has slipped?
[15:00] <GaryvdM> guijemont: Will respond in a sec
[15:00] <vila> guijemont: I think GaryvdM tested qlog with some mysql branch, you should try and see if you get comparable results
[15:00] <mgz> put up branches for some of the others that I can repo here.
[15:00] <vila> mgz: leaks coming back is what I fear the most
[15:01] <GaryvdM> vila: no. qrun is a dialog for running a arbertery bzr command,
[15:01] <GaryvdM> vila: qlog is to big
[15:01] <guijemont> vila: well, for now, my changes in viz are purely graphical, it's still as slow (or maybe slower) as before
[15:02] <vila> mgz: but thinking about hudson hanging on zombies made me realized I should file a bug there as that's clearly a blocking one
[15:02] <GaryvdM> vila: I want a test for the threading infrastructure, not the threading infrastructure and qlog. :-)
[15:02] <vila> mgz: (not that I suspect zombies right now, but you never know with those undeads...)
[15:03] <GaryvdM> guijemont: When I wrote qlog, I refactored the code so that the logic could easily be reused in bzr-gtk, and others.
[15:03] <vila> GaryvdM: hmm, but do you still need to use bzr to launch your main then ?
[15:03] <GaryvdM> vila: yes, because it needs to know how to import qbzr
[15:03]  * vila hugs GaryvdM for thinking about reuse
[15:04] <vila> GaryvdM: ouch, ok, I see
[15:04] <guijemont> GaryvdM: yeah, jelmer was talking about the idea of merging it in bzrlib
[15:04] <guijemont> GaryvdM: do you know what still needs to be done to make that happen?
[15:04] <GaryvdM> guijemont: I plan to move this logic into bzrlib, but I'm going to need a better test suit.
[15:04] <vila> GaryvdM: then an hidden command is probably your best bet.... can you lazy register a test command ?
[15:05] <vila> GaryvdM: do you start to see why you may want to address the root bug instead of going with a work-around :-} :-/
[15:05] <mgz> vila: I'm going to do a complete test run on my machinary just to confirm that nothing on trunk has affected thread-problems
[15:05] <guijemont> GaryvdM: ok. I think I will have a look at that code and try to make bzr-gtk work with it in the meantime
[15:05] <GaryvdM> vila: Yes - but fixing the root bug is hard
[15:06] <GaryvdM> guijemont: The relevant code it the qbzr branch is lib/loggraphprovider.py
[15:06] <GaryvdM> *in the
[15:06] <guijemont> ok
[15:06] <vila> GaryvdM: may be you can register the command just before launching the test subprocess and avoid polluting the name space ?
[15:07] <vila> vila: Did I really just suggest such an idiotic idea ?
[15:07] <GaryvdM> vila: but that would need to happen in the subprocess,
[15:07] <guijemont> is qbzr at lp:qbzr?
[15:07] <guijemont> I guess so, seems to work
[15:08] <GaryvdM> guijemont: yes
[15:08] <GaryvdM> guijemont: There are 2 qbzr imports in that file that we would need to do something about.
[15:10] <GaryvdM> LogGraphProvider is a base class, and there is a specific qbzr LogGraphProvider in lib/logmodel.py
[15:11]  * GaryvdM looks at lp:~guijemont/bzr-gtk/collapsed-merges
[15:11] <guijemont> GaryvdM: I barely touched the graph generation stuff  though
[15:12] <guijemont> the code didn't look like it wanted to be changed (it's basically one huge function)
[15:12] <mgz> I do wonder whether it might not be easier to just rewrite all client-server tests to use a subprocess server, which can just be killed on teardown
[15:12] <vila> guijemont, GaryvdM : If you manage to share the exact some code, there will be a strong case to include it in the core
[15:13] <guijemont> I think I'll try to go in that direction
[15:13] <vila> mgz: easier, may be (there are a few tests that directly talk to the server though) but the performance will surely suffer
[15:13] <guijemont> might find bugs in the process, who knows
[15:13] <mgz> can't perform worse than a hang ;)
[15:14] <vila> mgz: hehe, hangs are generally due to uncaught exceptions which is the first thing I want to address
[15:17] <mgz> selftest-freebsd looks stuck to me, probably needs killing.
[15:18] <vila> mgz: yeah, as soon as I get a free hand :)
[15:19] <vila> mgz: it was my last hope for a blue icon :-/
[15:20] <GaryvdM> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~guijemont/bzr-gtk/collapsed-merges/". :-(
[15:20] <vila> mgz: I'm about to upgrade to lucid and will come back later
[15:21] <guijemont> hmm, did I mistype it?
[15:21] <guijemont>     push branch: bzr+ssh://bazaar.launchpad.net/~guijemont/bzr-gtk/collapsed_merges/
[15:22] <guijemont> haha
[15:22] <guijemont> _ not -
[15:22] <guijemont> sorry
[15:22] <GaryvdM> ok - np
[15:22] <jelmer> vila: quickest upgrade ever!
[15:23] <GaryvdM> jelmer: vila is offline
[15:23] <vila> hehe, isn't it ? lucid rocks !
[15:23] <GaryvdM> Oh wow back allready!!!!
[15:23] <vila> GaryvdM: I rejoined from my laptop while upgrading the desktopn :)
[15:23] <GaryvdM> Oh - very pro...
[15:23] <vila> ...and will soon update babune too
[15:24] <vila> GaryvdM: hehe, the joy of versioned setups :)
[15:25] <mgz> dammit, testtools change has borked my setup again.
[15:26] <mgz> now seems like there's no way at all of getting a stack from an expected failure
[15:29] <GaryvdM> guijemont: fyi qbzr/lib/loggraphprovider.py was derived from bzr-gtk/branchview/linegraph.py, but has change substantially.
[15:30] <guijemont> ok
[15:30] <guijemont> to be honest, I don't like much the code in bzr-gtk/branchview/linegraph.py though
[15:31] <vila> mgz: are you sure stack backtraces are available to testtools ? I would have tought that only the tests themselves could get them, and even that...
[15:31] <guijemont> a huge function with tuples everywhere, and variable names that tend to look like each other
[15:32] <vila> wow, first time ever I'm able to get gdm working on gentoo...
[15:32] <GaryvdM> guijemont: Sorry - I'm partially to blame for that. loggraphprovider.py is better at that.
[15:32] <mgz> they're not really, I've had to add hacks to get them back unmangled
[15:33] <mgz> there's a 'wishlist' bug on testtools to restore things to how they were before
[15:34] <GaryvdM> guijemont: LogGraphProvider loads a lot of data at load and caches it. Each time you colapse and expand in qlog, the whole graph layout is recomputed, but because of the caches, that is very fast.
[15:36] <guijemont> ok, that is the secret
[15:36] <GaryvdM> guijemont: These are the entry points for LogGraphProvider:
[15:36] <GaryvdM> open_branch or open_locations
[15:37] <GaryvdM> load_graph_all_revisions or load_graph_all_revisions_for_annotate
[15:37] <GaryvdM> Those are called on load^
[15:37] <vila> mgz: an old or a recent bug ?
[15:38] <GaryvdM> compute_graph_lines is call each time you collapse or expand.
[15:38] <GaryvdM> guijemont: ^
[15:38] <mgz> vila: old, from r4920 when testtools was merged and broke a bunch of things for me
[15:38] <mgz> I still have bugs to file on other issues too.
[15:39] <vila> mgz: ok, may be you should start with that then ? :-/
[15:39] <guijemont> GaryvdM: ok
[15:39] <guijemont> will try playing a bit with it
[15:40] <guijemont> after having cleaned the flat, that is...
[15:43] <GaryvdM> guijemont: Good luck. Fell free to bug me when I am on irc, or mail me on either the bzr, bzr-gtk or qbzr mailing lists
[15:44] <guijemont> ok, thanks
[15:45] <GaryvdM> guijemont: Btw qlog is missing 2 features that bzr-gtk has:
[15:45] <GaryvdM> guijemont: a Progress bar
[15:45] <GaryvdM> guijemont: and filtering revisions from the command line.
[15:46] <mgz> selftest related - am I mad, or does --strict do absolutely nothing?
[15:47] <mgz> I want to see a real traceback for this expected failure, and can't work out a way to make bzr let me
[16:54] <nessita> hello everyone! I need help on the following: I have a branch of a project X where I need to moved out a subfolder to another subfolder in project Y. I've tried bzr split but I can't push the splitted folder into a branch subfolder. Any ideas how can I workaround this? (I need to preserve the history from the source project)
[16:58] <nessita> this is basically what I need to do https://pastebin.canonical.com/32341/
[16:59] <nessita> oops, that link is not open to everyone, this is public: http://nessita.pastebin.com/nmRpjHXa
[17:26] <vila> mgz: sry to have missed that earlier, but why do you want to see a traceback on an expected failure ? The test pass (its failure is expected) so nothing should be output
[17:26] <vila> mgz: may be you *had* tracebacks when *trying* to handle the expected failure and things are now working correctly ?
[17:26] <mgz> ha, you ask just as I have bent testtools to my will
[17:27] <jelmer_> :-)
[17:27] <mgz> I want it because there's some useful information in there, particularly what the failure is exactly and what line it came from
[17:28] <mgz> so, the code I needed was:
[17:28] <mgz> if _post_testtools_apocalypse:
[17:28] <mgz> 	test.addOnException(self._set_real_exc_info)
[17:28] <mgz> and:
[17:28] <mgz> def addExpectedFailure(self, test, err=None, details=None):
[17:28] <mgz> 	if err is None:
[17:28] <mgz> 		err = getattr(self, "_real_exc_info", None)
[17:28] <mgz> 		olderr = err[1].args[0]
[17:28] <mgz> 		if isinstance(olderr, tuple) and len(olderr) == 3:
[17:28] <mgz> 			# This is the knock-on ExpectedFailure, but it's passed the
[17:28] <mgz> 			# original exc_info for some reason, so get that back
[17:28] <mgz> 			err = olderr[0], olderr[1], err[2]
[17:43] <vila> mgz: hmm, this is really ugly, it may be correct though, I have no idea :D
[17:44] <vila> what is post_testtools_apocalypse ?
[17:44] <mgz> well, with a few more pokes looks like I've finally got full test run going
[17:44] <mgz> will give result when I get back in an hour and a half
[17:45] <mgz> ^just a check to see if we're post r4920 or not, my tests for this code run it against multiple bzrlib versions to make sure I don't regress
[17:45] <vila> ho, ok
[17:46] <vila> mgz: I may not be there anymore in far less than an hour :) But if you post to the list, I will certainly read
[17:46] <mgz> will do if I find anything interesting, otherwise I'll just file bugs
[17:47] <mgz> (my aborted run earlier got thread leaks as normal, but no "failed to start thread" stuff, so I think we've not regressed that, so probably an environment change causing it rather than code)
[17:48] <mgz> right, gotta go.
[18:11] <fullermd> vila: Yes, gmp rename.
[18:11] <vila> fullermd: wait... were you *sleeping* ???? :-P
[18:11] <vila> fullermd: thanks for the confirmation ;)
[18:11] <vila> err, the *explanation*
[18:12] <vila> fullermd: as you can guess, I shot in the dark hoping for the best :)
[18:13] <fullermd> I wasn't sleeping.  I was just resting my eyes.
[18:14] <vila> an thinking so deeply you were making some weird noise, yeah, I do that too, I don't understand why they call it snoring...
[18:15] <fullermd> I know!  My, uh, engine is just a little imbalanced when it's running that hard!
[18:15]  * fullermd nods at himself.
[18:47] <Lor> Is there a simple way to make a merged-in branch the mainline?
[18:48] <Lor> The non-simple way would be to just merge in the other direction, but this might require setting up another branch locally.
[18:50] <GaryvdM> Lor
[18:51] <GaryvdM> Lor: Unfortunatly not.
[18:51] <GaryvdM> Lor: There has been talk of a "land" command though.
[18:53] <Lor> Right. The problem is how to merge stuff into the true mainline from a feature branch. A merge + push will turn the feature branch into the new mainline.
[18:53] <Lor> A pqm would of course solve this, but it's pretty heavyweight.
[18:56] <maxb> Yes. It's rather annoying. You'll have to have another branch locally
[18:57] <Lor> It's not really a big deal, of course.
[18:58] <Lor> Branches are conceptually a bit heavyweight, though.
[18:58] <Lor> I'm not sure if it's a good idea to require them all to have a separate directory with its own .bzr.
[18:59] <Lor> I'd appreciate fuller support for lightweight heads (after all, a branch is really just a head) like the ones loom uses.
[19:10] <GaryvdM> sigh - I have way to many in progress qbzr branches ...
[19:28] <nessita> anyone around with knowledge in bzr-fastimport plugin?
[19:30] <mgz> oooh, good news, I got the hang, and the thread problems
[19:32] <mgz> and Alexander's diff problems with newlines
[19:39] <mgz> hang in bt.test_lockable_files.TestLockableFiles_RemoteLockDir.test_break_lock but that's probably just going to be any unlucky smartmedium using test
[19:42] <mgz> okay, the only revs between my last good full run and this in the blame for bzrlib/tests/test_smart.py are r5223 and r5232
[19:45] <mgz> hm... both look reasonably innocent. will try backing out Robert's change and see if that helps.
[19:47] <jelmer> nessita: you probably want to talk to igc when he's around
[19:48] <nessita> jelmer: thanks! I'll try ping him
[19:56] <mgz> hey Alexander.
[19:56] <mgz> I think I understand those test failures you were getting with merges
[19:57] <mgz> they were all (diff3) paramatised ones right? I see them now, so will file a bug and patch later.
[19:59] <bialix> hey mister
[20:00] <bialix> will be nice, thanks
[20:00] <bialix> how's your trip back to home?
[20:00] <bialix> mgz: ^
[20:01] <mgz> a lot less stressful than the one over :)
[20:02] <bialix> :-)
[20:03] <bialix> you finally found the right nick ;-)
[20:04] <mgz> blame vila!
[20:04] <bialix> :-D
[20:08] <bialix> my home internet is sooooooo sloooooooooooow after uds one :-(
[20:11] <mgz> my home internet is very fast compared to UDS. terrible latency there, had to wait till someone had left their laptop unattended ;)
[20:16] <bialix> :-)
[20:34] <GaryvdM> bialix: Hi
[20:34] <GaryvdM> mgz: lol
[20:34] <bialix> heya
[20:35] <bialix> GaryvdM: I've missed a good joke?
[20:35] <GaryvdM> internet was slow for mgz...
[20:35] <GaryvdM> bialix: ^
[20:36] <bialix> ah, yes
[20:36] <bialix> terribly slow
[20:37] <bialix> GaryvdM: it was true about my hangover
[20:37] <bialix> I'm trying to talk in English with people here in Ukraine. crazy
[20:37] <GaryvdM> bialix: Made some progress with the threads branch. Error reporting better, got tests passing, and have push branch to lp.
[20:37] <GaryvdM> bialix: lol...
[20:37] <bialix> wow
[20:48] <Lor> What is the easiest way to get rid of a big file that was accidentally added to a branch and takes inordinate amounts of space in a repository?
[20:48] <Lor> I know that it is in principle possible to rewrite history and alter the commit that added the file, and then replay everything back.
[20:48] <LeoNerd> Heh... fun
[20:49] <LeoNerd> You'll change the commit IDs, and anyone who's branched from you since then will shoot you
[20:49] <Lor> This is for private development, so that's not a huge problem.
[20:49] <LeoNerd> search for "bzr obliterate"
[20:49] <Lor> But still, it would be even better if it was just possible to tell the repository to get rid of the text of that file.
[20:50]  * LeoNerd runs away
[20:51] <mgz> okay, not r5222 at fault, will probably just do 5222 + (5222-5200)/2 next
[20:53] <mgz> *r5223
[21:15] <prkos> Hi! How do I get just the source of an application every once in a while but so it's fast to download, I only need it to compile, I won't do dev work on it so I don't need history
[21:23] <bialix> try `bzr checkout --lightweight`
[21:25] <prkos> bialix: thanx, what's the workflow with that, I always do it in the same folder, and compile somewhere else?
[21:25] <bialix> I don't understand\
[21:25] <bialix> it's like doing `cvs checkout
[21:26] <prkos> I tried it one before but it compile with some features missing
[21:27] <prkos> I've read about the lightweight option but it's not easy to understand from a non-dev point of view
[21:27] <bialix> what is `source of an application`?
[21:28] <prkos> source code
[21:28] <prkos> so I can compile the application
[21:29] <prkos> I'm not sure if that's the tree in bzr?
[21:29] <prkos> working tree?
[21:29] <bialix> so you'd better download tarball with the sources
[21:29] <bialix> working tree, yes, -- it's the files under version control
[21:30] <bialix> lightweight checkout creates working tree without history
[21:30] <prkos> is there a bzr command for the tarball source for an application on lp?
[21:31] <bialix> `bzr export` but I'm not sure about lp
[21:31] <bialix> there was feature request for loggerhead to add the option: download sources as tarball
[21:31] <bialix> hey loggerhead devs, are you here?
[21:34] <prkos> once I do a lightweight checkout, how do I update to get the new code - bzr update?
[21:35] <prkos> will it only download the source without history as the first time?
[21:36] <bialix> yep
[21:46] <bialix> ~~~
[22:24] <MvG> jam: Are you this week's patch pilot, as the wiki claims?
[22:24]  * jelmer waves
[22:25]  * MvG notices the away state of jam
[23:02] <MvG> jam: Now that you seem to be back from away: are you this week's patch pilot? If so, shouldn't the topic reflect this fact?
[23:03] <MvG> :-)
[23:03] <jam> MvG: yeah, I'm this weeks pp
[23:03] <jam> I'm mostly recovering from traveling today, but I'll certainly be giving it some attention this week
[23:04] <MvG> Happy to hear that.
[23:04] <MvG> I'll particularly appreciate any comments on my outstanding merge requests.
[23:05] <MvG> Those about bash_completion plugin.
[23:06] <MvG> https://code.launchpad.net/~gagern/bzr/bug560030-include-bash-completion-plugin/+merge/23912 was already approved by vila, but will need a second opinion.
[23:06] <MvG> https://code.launchpad.net/~gagern/bzr/bash_completion-ExecutableFeature/+merge/24951 depends on the former, and might benefit tests beside those for bash_completion.