[00:02] <Peng> At least Freenode isn't read-only too. :D
[00:03] <jml> hahaha
[00:23] <jml> is there a standard Python way of parsing a __version__ string like '1.5.1'?
[00:27] <james_w> jml: parsing in to parts, or parsing for comparison?
[00:27] <maxb> I think the standard way would be to beat the originating app over the head until it provides a version tuple
[00:27] <jml> comparison
[00:27] <poolie> jml, not that i know of but there is often a tuple-based version
[00:28] <james_w> you can compare it as a Debian version number, but modules for that aren't likely to be available everywhere
[00:28] <james_w> I don't know of a standard python one
[00:28] <jml> ok, thanks guys.
[00:28]  * jml proceeds to beat the app over the head
[00:29] <jml> oh crap
[00:29] <jml> launchpad is going to make that hard
[00:32]  * jml splits and map ints for the time being
[01:07] <Peng> jam: Is there supposed to be a test in lp:~jameinel/bzr/2.0.4-495000-win32-autopack? Cuz there ain't.
[01:17] <jml> you know
[01:17] <jml> bzrlib is nice
[01:18] <jml> it's a bit of a wart that there are errors with "NotFound", "NotPresent" and "Missing" in their names.
[01:19] <spiv> jml: Also, "Absent"
[01:20] <spiv> jml: But we're lacking an error with "Lacking"
[01:22] <jml> spiv, good catch.
[01:23] <ronny> are those at least subclasses of lookuperror?
[01:23] <Peng> raise errors.LackingConfusingErrorClass.
[01:23] <Peng> ;D
[01:23] <jml> ronny, no, I don't think so.
[01:23] <jml> ronny, and I'm not sure they should be.
[01:24] <ronny> hmm, it woud certainly give more meaning
[01:24] <ronny> man
[01:25] <jml> ronny, e.g. DependencyNotPresent -- is that _really_ a lookup?
[01:25] <ronny> jml: im not yet at that one
[01:26] <spiv> I'd be pretty hesistant to use LookupError for anything that wasn't implementing the __getitem__ operator
[01:26] <ronny> jml: but for example NoSuchId/NoSuchIdInRepository
[01:26] <jml> spiv, yeah
[01:27] <jml> spiv, I've never really found much value in rich exception hierarchies anyway, still less ones inheriting from the stdlib exceptions.
[01:27] <spiv> Yeah.
[01:27] <ronny> i like to put more meaning in things
[01:28] <jml> ronny, I like motherhood and apple pie.
[01:29] <ronny> i grender-missmatch for the first one, but i agree on the second one
[01:37] <onox> how can I tell bzr which key to use to sign revisions?
[01:40] <jml> spiv, may I encourage you to do something about https://code.edge.launchpad.net/~spiv/pyflakes/detect-broken-string-formatting/+merge/580
[01:40] <spiv> jml: you may
[01:40] <jml> spiv, If you do something about your pyflakes branch, you will help thousands.
[01:41] <spiv> onox: hmm, not sure.  Maybe you can specify it on the command line in the gpg_signing_command option in bazaar.conf?
[01:58] <lifeless> poolie: are you happy with my fixes to the subunit branch?
[02:50] <poolie> lifeless: i haven't reread your patch but based on what you said it sounds good
[02:54] <lifeless> python-testtools is in  the bzr beta ppa
[02:54] <lifeless> for hardy intrepid jaunty karmic
[03:00] <jml> is there a test decorator for feature availability.
[03:01] <lifeless> no
[03:01] <lifeless> either set _test_needs_features
[03:02] <lifeless> or call self.requireFeature(feature)
[03:03] <jml> thanks.
[03:03] <lifeless> spm: you have mail; I suspect you can't do it? can pjdc?
[03:03] <spm> pjdc is away this week
[03:05] <lifeless> anything you can do to expedite it would be appreciated ;)
[03:06] <spm> lifeless: when/where did you send this email? > 5-10 mins ago?
[03:06] <lifeless> about that
[03:06] <lifeless> you and rt
[03:07] <lifeless> I hope this DDos gets shut down soon
[03:09] <spm> lifeless: tada. arrived. :-)
[03:09] <cody-somerville> lol
[03:44] <jml> you know what would be cool to do once this branch lands?
[03:45] <jml> a branch directory service that takes launchpad bug numbers and looks up the corresponding branch
[04:01] <poolie> oh
[04:01] <poolie> yeah
[04:01] <poolie> more useful for push than for pull
[04:01] <poolie> or indeed a bzr command (something like diff -rsubmit: ) that gives you the diff
[04:01] <poolie> spiv, so, patch piloting...
[04:01] <poolie> if i take next week will you do the 1st week back?
[04:02] <poolie> subject to chestbursters
[04:02] <spiv> poolie: sure
[04:39] <jml> ok.
[04:39] <jml> one completely distracted day later, I've replied to the last comment on lp-login-oauth-2
[04:39] <jml> that only took four hours :(
[04:42]  * jml -> router replacement
[05:33]  * jml is back w/ adsl2 goodness.
[05:34] <jml> remind me, are there any conventions for pqm submit messages?
[05:36] <jam> Nothing like lp
[05:36] <jam> we often put our name in
[05:37] <jam> 'bzr log -n1' would give you a hint :)
[05:37] <spiv> "(author) One line description (#bugnum)" is pretty common.
[05:38] <jml> jam: aww man, and here's me being proud for RTFMing first :)
[05:39] <spiv> It'd be nice to improve the PQM process enough that the "(author)" bit is unnecessary, probably by making PQM set the author property.
[05:39] <jml> spiv, that's been discussed in the past.
[05:39] <jml> spiv, it's philosophically unclear who the author of the merge is.
[05:40] <jml> spiv, and anyway, we should look up the authors of the merged revisions.
[05:40] <jml> spiv, or at least, that's what I recall from the last time this went round the rounds.
[05:41] <spiv> jml: it's whoever I say it is when I do "bzr pqm-submit --the-author-is=..." :P
[05:42] <jml> spiv, you're such a relativist.
[07:14] <jml> All lines of log output:Sender not authorised to commit to branch http://bazaar-vcs.org/bzr/bzr.dev
[07:15] <jml> which branch should I submit to?
[07:19] <lifeless> its in the docs
[07:25] <poolie> got to go, anniversary date
[07:25] <poolie> good night
[07:26] <lifeless> ciao
[07:29] <lifeless> jml: did that help you
[07:36] <jml> lifeless, not yet.
[07:38] <jml> lifeless, given that the URL in my error message matches the URL in the docs.
[07:42] <vila> jml: I'll check with a losa if you *still* have access to that branch, I'm pretty sure there have been some updates when we switched
[07:43] <vila> well, the assumption here is that you didn't use pqm since you were RM, if you did, I'm wrong :)
[07:45] <vila> lifeless: You broke my toy >-/ I have persistent failures on babune for hardy, jaunty. karmic, gentoo related to _StringException: lost connection during test
[07:45] <vila> To be honest, I don't think you (or rather your patch) are directly responsible for that but yet...
[07:46] <lifeless> jml: http://bazaar-vcs.org/bzr/bzr.dev isn't in the docs now I think
[07:46] <vila> The selftest run stops with 4 ERRORs like the above but only after running 4135 tests
[07:46] <vila> It completes for FreeBSD[78] though
[07:48] <lifeless> ugh
[07:48] <lifeless> HACKING.txt specifies http://bazaar-vcs.org/bzr/bzr.dev still
[07:48] <vila> lifeless: You did fix the verbose output for SKIP/XFAIL is was it that random that it doesn't occur anymore ?
[07:48] <lifeless> jml: it should be http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev
[07:48] <lifeless> vila: it is actually meant to be verbose
[07:48] <lifeless> vila: so I deliberately broke it.
[07:48] <lifeless> vila: (it will no longer show the backtrace to you)
[07:49] <vila> lifeless: thanks !
[07:49] <lifeless> the reason it wasn't showing it without --subunit was ...
[07:49] <lifeless> that the ui factory was replaced by the tests
[07:49] <lifeless> global state ftw
[07:49] <vila> I read tht in the comment >-/
[07:50] <vila> I knew I wasn't comfortable with that global stuff but until it break...
[07:50] <vila> About ' lost connection during test', any idea about when it could occur ?
[07:51] <lifeless> lost connection means
[07:51] <vila> s/when/& why how anything/
[07:51] <lifeless> subunit saw:
[07:51] <lifeless> test: FOO
[07:51] <lifeless> EOF
[07:51] <lifeless> so, possibilities are:
[07:51] <vila> endless ;-(
[07:53] <vila> given the vbox behaviours I'm observing these days... up to a VM responding to a click and then going flat, nothing in any log I can think of, leading to... a reboot :-(
[07:53] <lifeless> not flushing a file
[07:53] <lifeless> process termination
[07:54] <lifeless> what test is it erroring on
[07:54] <vila> !pate
[07:54] <vila> !paste
[07:54] <vila> On hardy32: http://paste.ubuntu.com/343356/
[07:55] <vila> On jaunty64: http://paste.ubuntu.com/343357/
[07:56] <vila> On karmic64: http://paste.ubuntu.com/343358/
[07:56] <lifeless> how many cpus does the vm think it has?
[07:56] <vila> Also on karmic64: http://paste.ubuntu.com/343359/ :-(
[07:56] <vila> 4 for all 3
[07:57] <vila> On gentoo: http://paste.ubuntu.com/343360/ 4 CPUs too
[07:59] <lifeless> this is using =fork or =subprocess
[07:59] <vila> =fork
[07:59] <lifeless> so
[07:59] <lifeless> try =subprocess
[07:59] <lifeless> its worrying similar numbers
[08:00] <lifeless> I'd kindof like to see the end of the stream
[08:00] <lifeless> does anything show up on stderr?
[08:01] <vila> Nothing special, but SKIP tests verbose on hardy too :-/
[08:01] <lifeless> does it
[08:01] <vila> revno 4905 for bzr
[08:02] <lifeless> so for that one
[08:02] <lifeless> changing addSkip to take details
[08:02] <lifeless> is the best way to fix it
[08:02] <lifeless> I don't really want to keep tweaking the patch :)
[08:03] <vila> You landed it so now is not tweaking is writing new ones :-D
[08:03] <vila> s/is/it's/
[08:04]  * vila feels babune citizens will undergo massive reboots just because
[08:04]  * vila kills one more chicken first
[08:04] <lifeless> vila: I haven't landed it
[08:04] <lifeless> vila: waiting on pqm to have testtools installed in it
[08:05] <vila> wowwwwww, backtrack, backtrack
[08:05] <lifeless> what you are seeing is bzr.dev without the patch + newer subunit
[08:05] <vila> Exactly !
[08:05] <vila> pfew, I prefer that !
[08:06] <vila> sorry for the confusion but suddenly seeing SKIP verbose tricked me
[08:06] <lifeless> you are seeing verbose skip because thats what trunk does
[08:07] <vila> I don't think we should spend time understanding this weird config, unless you're really interested... I'd prefer coming back to the SKIP/XFAIL verbose stuff
[08:12]  * vila redirects babune to lifeless branch and updates it
[08:15] <vila> lifeless: it's amazing that mix works on FreeBSD and nowhere else.... new bug family: raising when they want just because they can
[08:30] <vila> lifeless: http://paste.ubuntu.com/343390/
[08:37] <lifeless> vila: I think its likely an environmental bug
[08:38] <vila> lifeless: So, SKIP/XFAIL is indeed random
[08:38] <lifeless> such as not flushing stdout on _exit
[08:38] <lifeless> vila: its very deterministic for me :)
[08:38] <vila> hehe
[08:38] <vila> random as in: I don't yet understand when it occurs :)
[08:38] <lifeless> when ui_factory != SilentUIFactory
[08:39] <lifeless> e.g. always with --parallel
[08:39] <vila> no, I don't get it when running on saw (the real host for babune, running karmic)
[08:40] <vila> ha, it may be related to babune's VM *not* running with a tty
[08:41] <vila> yeah, the karmic VM output contains the versbose part but the karmic host doesn't
[08:42] <vila> This is going to be a long day...
[08:42] <vila> Xchat crashing (yes it's yet another VM)
[08:42] <lifeless> :P
[08:43] <vila> Well, thinking more about it, It may be a good idea to keep those outputs anyway, I would prefer to be able to control it via selftest -v, but I won't block on that.
[08:44] <vila> As long as selftest finally returns success (which it does), it makes sense to be able to see why tests are skipped with more details
[09:10] <lifeless> vila: -v has a different reporter
[09:10] <lifeless> and in non parallel mode the things don't show anyhow
[09:11] <vila> Well, I'm not sure these are good reasons to make --parallel=fork a second class citizen :-D
[09:12] <lifeless> but its not - we're just making it the same
[09:13] <vila> Where ?
[09:13] <vila> Did I miss a commit ?
[09:25] <Jordan_U> Is there a way to checkout a branch without creating any .bzr directory at all?
[09:28] <lifeless> Jordan_U: no
[09:29] <lifeless> vila: 'normal' test runs try to show skip and xfail details, but fail because the ui factory is silent
[09:29] <Jordan_U> lifeless: Thanks
[09:29] <lifeless> vila: --parallel succeed at showing it because no tesets run in the parent process
[09:29] <lifeless> vila: this disabling the attempt makes it behave the same
[09:33] <vila> lifeless: this doesn't explain the difference between karmic host and karmic guest, the former being silent and the later being verbose for the *exact* same command 'bzr selftest --parallel=fork', I understand the root cause is highly obscure, I'm just saying some people may be surprised especially if it occurs *only* for --parallel=fork
[09:33] <vila> I may still misunderstand who and when ui_factory is set and why I can observe such a difference...
[09:34] <vila> but that's minor
[09:34] <vila> lifeless: unless there are other tweaks required by others I'm ok to land it as is (with s/log_log/get_log),
[09:34] <vila> babune is quite happy with that so far
[09:35] <ronny> lifeless: what would you think about a tool that would automatically distribute instant test runs to computers/vm's with different platforms (so each time a developer runs the suite it gets executed on all targets)
[09:36] <vila> ronny: I think lifeless will point you to babune which is BAzaar BUild botNEt : a set of VM/hosts running the test suite daily :)
[09:37] <ronny> vila: im not talking about dayly runs but instany on demand runs
[09:38] <vila> ronny: with infinite power you can achieve that, but currently it take ~6 hours wall-time to run on hardy, jaunty, karmic, FreeBSD7, FreeBSD8, gentoo, OSX 10.4, OSX 10.5
[09:38] <ronny> i.e. one would need something like 24 boxes per platform to get it down to a worthwile timeframe?
[09:39] <vila> If you got the boxes, I'm happy to provide help to set that up :D
[09:40] <ronny> im not yet the man in the middle on the international money transfer lines
[09:40] <lifeless> vila: thanks; I am pushing your log fix now; will land when pqm is fixed ;)
[09:40] <vila> lifeless: thanks, ETA ?
[09:41] <lifeless> seconds
[09:41] <vila> cool :D
[09:41] <lifeless> ronny: so, those tools exist. I recommend using them.
[09:41] <lifeless> there are various ones with various forms.
[09:41] <ronny> lifeless: im not aware of some that work for python and work on demand
[09:42] <lifeless> so, offhand; bzr selftest --parallel=ec2 is easily tweaked to run different vms
[09:42] <lifeless> py.test has a remoting API
[09:42] <lifeless> pandokia too
[09:42] <lifeless> hudson and other such CI tools have on-demand modes
[09:43] <ronny> lifeless: the py.test one is supposed to be massively changed (cause atm it still used local collect)
[09:43]  * lifeless has to go. bye
[09:43] <ronny> bye
[09:44] <ronny> hmm, pandokia looks interesting
[09:45] <lifeless> its a bit crude
[09:46] <lifeless> but I'm considering a subunit2pandokia for folk that want to use it :P
[09:47] <ronny> lifeless: we are trying to outline a new model for py.test distributed testing, with better controll about things like collect/shedule
[09:47] <lifeless> ronny: cool; testing-in-python :)
[09:47] <ronny> hmm, right
[09:47] <lifeless> a local collector isn't really an issue IMO.
[09:47] <ronny> oh, im actually subscribed to that ml
[09:48] <ronny> lifeless: it is if the collect phase is partially platform-depend
[09:48] <lifeless> ronny: btw, subunit 0.0.3 - has structured space for stdout or whatever you want.
[09:48] <lifeless> ronny: I may not know what you mean by collect. And while I find this fascinating, I can't focus on this right now - sorry.
[09:48] <ronny> ok
[09:48] <ronny> can you ping me later?
[09:49] <lifeless> I'd be delighted to discuss it on the list, or perhaps later
[09:49] <lifeless> for me, later may be 12+hours
[09:49] <ronny> so in case of doubt the next day
[09:53] <lifeless> well thats the early estimate :O)
[09:54] <lifeless> I'm on leave and bumming around etc
[10:03] <vila> lifeless: hmm, ETA was  about ' when pqm is fixed ', that wasn't what your replied to right ? :D
[10:12] <Peng> vila: What do you mean by "hpss remote repositories doesn't raise the warning locally"?
[10:12] <Peng> vila: Which side os "local", the client or server?
[10:13] <Peng> ...Oh, I get it. Since the client side just sees Remote objects, it won't know they're really deprecated... Sorry. I haven't slept much today.
[10:14] <vila> client, did you observe something different ?
[10:16] <Peng> vila: I don't interact with deprecated repos over the hpss much, so I dunno. Besides, last time I did, _ensure_real was probably much more common.
[10:16] <Peng> My sleepy brain just didn't know what you meant.
[10:16] <vila> ok. Thanks for caring anyway :)
[10:19] <Peng> vila: I just tested it. I got the warning, but apparently only after VFS access was triggered.
[10:19] <vila> Peng: can you redo that test with my branch ?
[10:19] <Peng> Erk.
[10:20] <Peng> vila: Does the branch need to be on the client, server or both?
[10:21] <vila> good question :)
[10:21] <Peng> :(
[10:21] <vila> Client at least, bonus points if both, extra bonus points for server only :)
[10:25] <Peng> ...Do I need to actually use the new setting?
[10:25] <vila> no
[10:25] <vila> at least to begin with we want to see the warning, then we can try to suppress it
[10:28] <Peng> Branch on client-side: The client displays both the warning generated on the server and the warning generated on the client.
[10:28] <Peng> Branch on both: Same.
[10:29] <Peng> Branch on server-side: Same.
[10:29] <Peng> vs. lp:bzr, this means two warnings instead of one, for one branch. Ick.
[10:30] <Peng> Presumably there would only be 1 warning of the client didn't do any VFS requests.
[10:37] <vila> Peng: Weird, I can't imagine why two warnings are emitted instead of one since this is controlled by a global which means it can't be emiited twice by the same code base
[10:38] <Peng> vila: When using bzr+ssh, the client sees the server's stderr. Or something.
[10:38] <vila> that means client and server can emit one each, but I fail to see where my changes can trigger than
[10:38] <vila> s/than/that/
[10:38]  * Peng shrugs.
[10:39] <Peng> I'm too sleepy to brainstorm.
[10:39] <vila> Peng: anyway, that's certainly a bug, so please report it or comment at bug #497694
[10:40] <vila> the patch is on its way to pqm as we speak, so in less than an hour, the bug will be on bzr.dev
[10:40] <Peng> \o/
[10:41] <vila> Peng: have some rest :)
[10:41] <Peng> Waitwaitwait. Peng is dumb. I get the double warnings in bzr.dev too.
[10:41] <Peng> I initially didn't notice because I ran with -Dhpssvfs and the traceback pushed the first one off the screen...
[10:41] <vila> I'm pretty sure the patch also provides a way to suppress both warnings by configuring both the client and the server:)
[10:42] <vila> haaaaaaa, great !
[10:42] <Peng> Sorry for the confusion.
[10:42] <vila> no problem, by the way may be you're seeing the two warnings because you run the server locally and in the same terminal >
[10:42] <vila> no problem, by the way may be you're seeing the two warnings because you run the server locally and in the same terminal ?
[10:43]  * vila yells at keyboard
[10:43] <Peng> vila: bzr+ssh from one machine to another.
[10:43] <vila> ok
[10:43] <lifeless> vila: eta for pushing the log_log fix
[10:43] <lifeless> vila: pqm depends on sysadmins
[10:43] <vila> lifeless: yeah, I thought so ;)
[10:43] <vila> lifeless: but it's in the pipe right ?
[10:44] <vila> lifeless: I ask to know if I should revert babune's subunit and testtools or not... :-/
[10:46] <Peng> vila: Brushing my teeth and going to bed takes more effort than staying awake and being an IRC zombie.
[10:47]  * vila frantically searches what is needed against zombies
[10:53] <Peng> vila: I'm a tired, lazy Internet zombie. I only eat presliced brains that are within arm's reach.
[10:53] <ad-530> hiho
[10:54] <ad-530> have a little problem in understanding how bzr works
[10:54] <ad-530> say i have a branch trunk/
[10:55] <ad-530> and a subdir trunk/somedir
[10:55] <ad-530> how to turn trunk/somedir/ in a branch with the same revno as trunk/ ?
[10:56] <Peng> ad-530: You want to split somedir out into its own branch?
[10:56] <Peng> ad-530: Why?
[10:56] <ad-530> for use with builder/dailydeb
[10:56] <ad-530> in the source package i need the trunk/somedir/ not the trunk/
[10:57] <ad-530> but then i got trunk/somedir/ is not a branch
[10:57] <ad-530> *get
[10:58] <ad-530> and i need to check out the whole repository because it's a svn repos. checking out just the trunk/somedir/ results in a borked revno of trunk/somedir/
[10:59] <Peng> ad-530: Well...There's "bzr split", but there might be a better solution.
[10:59] <ad-530> ok, what's the better solution? ^^
[11:02] <Peng> I have no idea.
[11:02] <ad-530> lol
[11:03] <lifeless> vila: I have no eta for pqm getting the library
[11:04] <vila> lifeless: k, thanks, that's the worse kind of ETA :)
[11:16] <Peng> vila: BTW, thanks for doing this. :) I have a couple of branches intentionally using ancient formats; it'll be nice to shut the warnings up.
[11:17] <Peng> (And thanks to the other people who worked on it before.)
[11:17]  * vila redirects to fullermd and ted :)
[11:33] <lifeless> vila: you could talk to #is if you want to steer it along
[11:38] <bialix> hi bzr
[11:40] <jelmer> 'morning bialix
[12:30] <cody-somerville> jelmer, hey
[12:31] <jelmer> Hi Cody
[12:31] <jelmer> How are things?
[12:31] <cody-somerville> Not too shabby. How are things with you?
[12:31] <jelmer> Good, having fun doing Launchpad hacking :-)
[12:33] <cody-somerville> jelmer, I think an upstream has changed what the git master is on a particular branch and now my branches no longer have common ancestry. Do you have any suggestions?
[12:34] <jelmer> cody-somerville: they've basically done a rebase of the full branch?
[12:36] <cody-somerville> jelmer, I'm not entirely sure. It looks like they had 'master' and 'debian' where 'debian' has been merging 'master' everytime they upload to debian. Now, it seems 'master' became 'debian' when they started on version "2.0".
[12:37] <jelmer> and yo
[12:37] <jelmer> ur branch is based on debian?
[12:37] <cody-somerville> no, it was based on master since thats where all the commits were occurring.
[12:38] <cody-somerville> If I based on debian I wouldn't have been able to cherrypick revisions and what not
[12:38] <bialix> рш оудьук
[12:38] <bialix> hi jelmer
[12:46] <jelmer> cody-somerville: I'm a bit surprised there's no common history at all in that case
[12:46] <jelmer> cody-somerville: is your branch available somewhere?
[12:48] <cody-somerville> jelmer, https://code.edge.launchpad.net/~oem-solutions-releng/live-helper/live-helper
[13:03] <rubbs> Good morning
[13:05] <jelmer> hi rubbs
[13:42] <jelmer> cody-somerville: Sorry for the delay, still cloning your branch.
[14:11] <vila> jelmer: ping, regarding bug #496827, what do you mean ? I'm pretty sure I fixed that and InfoHooks *calls* super().__init__
[14:11] <jelmer> vila: before 2.0.2 ?
[14:12] <vila> jelmer: not sure about that, but then it's a dupe ?
[14:13] <jelmer> vila: Yeah, it's definitely a dupe
[14:13] <vila> yup, #389648 is part of 2.1.0b3
[14:13] <jelmer> I couldn't find the original bug report
[14:13] <jelmer> (probably because it's marked fixreleased by now)
[14:13] <vila> hey ubottu wake up, bug #389648
[14:13] <vila> thanks
[14:15] <vila> jelmer: thanks, by the way, searching NEWS worked for me here :)
[14:15] <mindlace> Is the push-and-update plugin still required?
[14:15] <jelmer> vila: I probably should've tried that
[14:15] <jelmer> vila: I honestly hadn't considered that the bug might have already been fixed
[14:16] <vila> jelmer: no worries, I was just scared about a possible regression :)
[14:17] <vila> mindlace: well, it's hard to tell without more context but I see no reason why it wouldn't be required if it was...
[14:17] <jelmer> cody-somerville: Ideally you should be able to rebase your branch onto the new git import
[14:19] <mindlace> was looking at a "bazaar in 5 minutes for web developers" … doesn't seem like push/pull is required any more
[14:20] <vila> url ?
[14:21] <vila> mindlace: if you used to use push/pull and didn't change your setup, bzr won't magically push/pull
[14:22] <vila> if the doc changed to describe a lightweight checkout instead of a branch, then, yes you won't need push/pull anymore but the change is that your branch was local and is now remote. but even then, you'll need to update your remote working tree, so I still fail to understand :D
[14:24] <mindlace> vila: here we go: http://wiki.bazaar.canonical.com/BazaarForWebDevs
[14:25] <mindlace> I am migrating my devs from svn. I expect push/pull to be a manual operation they take on their branches of the "source" tree.
[14:25] <mindlace> source branch, i guess.
[14:26] <vila> yes they are, why do you say push/pull are not required anymore ?
[14:26] <mindlace> oh, it's not required, there is no remote working tree.
[14:27] <vila> emmajane: hi emmajane ! You couldn't be more timely :-D
[14:27] <mindlace> eh? no i mean this push-and-update plugin
[14:27] <vila> emmajane: mindlace have some questions about http://wiki.bazaar.canonical.com/BazaarForWebDevs
[14:28] <mindlace> is it just merging bzr push and bzr pull into one operation?
[14:28] <vila> so the working tree is where the files you versioned are, doing commit create a revision with one or more parent revisions, a repository is where revisions are storedm a branch is a pointer to the tip revisions
[14:29] <emmajane> vila, I'm just in a meeting...can you email me, or PM me and I'll get back to you?
[14:29] <vila> push and pull affect only the branches (there are exceptions we;ll forget)
[14:29] <vila> emmajane: no worries, I'll explain
[14:29] <mindlace> right but on the server I don't need a working tree… i think?
[14:30] <vila> you don't need a wt on the server where the branches are
[14:30] <mindlace> right
[14:30] <vila> but you need a working tree on your *web* server
[14:30] <mindlace> oh
[14:30] <mindlace> ok
[14:30] <emmajane> (You probably want bzr upload, not that tutorial...)
[14:30] <mindlace> i see. now I get it.
[14:30] <mindlace> no it's fine, I understand bazaar, i just was confused about why I wanted to update the remote working tree
[14:30] <emmajane> (most normal people don't actually do changes directly on the server)
[14:31]  * mindlace <-normal (in this case at least)
[14:31] <vila> there are roughly two solutions: 1) you have bzr on the server and you want to server your web pages from the directory where the branch is also served from, 2) you want to serve from a directory without .bzr or from a server without bzr installed
[14:32] <vila> for case 1) you use push-and-update for case 2) you use bzr-upload
[14:32] <vila> mindlace: does that ^ answer your questions ?
[14:42] <mindlace> yes. it answers my question in the affirmative - I need neither plugin, as I am treating the server "as if" it were subversion
[14:42] <mindlace> server
[14:43] <mindlace> and I'm the only one who deploys anyhow :P
[14:43] <vila> mindlace: lol, ok :)
[14:43] <vila> But how do you deploy ?
[14:44] <mindlace> oh, I can install the plugin *for me* I just didn't want to have to walk my developers through installing a plugin today, as i'm having a hard time getting them to click through the process of branching
[14:45] <vila> ok
[14:50] <KLondenberg> Hi all ..
[14:59] <rubbs> KLondenberg: hello
[15:45] <MvG> Hi there!
[15:45] <MvG> trac-bzr is almost ready for release 0.3.0. I'm currently researching setuptools and its metadata.
[15:47] <MvG> Previous releases did not include any dependency information. I'm now inclined to include install_requires = ['Trac >= 0.10, <0.12', 'bzr >= 2.0']. But as I'm not experienced with python packaging, I fear there might be adverse effects of me doing so, e.g. the package becoming unusable if deps are installed without their egg info or similar. What do you think?
[15:48] <MvG> I also noticed that there is no bzr classifier registered with pypi, despite the large number of bzr-related packages in the catalog. Do you know of anyone applying for a classifier like "Topic :: Software Development :: Version Control :: Bazaar" or similar?
[16:33] <NET||abuse> hmm, i have a project where I ended up loading bout 100 MB of mp4's into a directory(small web videos for the site) that I don't need to bzr push to the remote repo, i bzr remoe --keep 'd the vids from the working copy, but the bzr push is obviously pushing all revisions and copies of those videos when i dont need it to :(
[16:33] <NET||abuse> and at 20KB/s upload ,,, emmm , it sucks
[16:34] <NET||abuse> also,, the upload seems to have hit 5615KB and i'm not seeing it update with any more info....
[16:36] <GaryvdM> NET||abuse: Are there any other revisions commited after the videos commit?
[16:37] <NET||abuse> yeh absolutely.
[16:37] <NET||abuse> i've had the videos there in my working copy/
[16:37] <GaryvdM> I think there is a plugin - I'm taking a look.
[16:37] <NET||abuse> they were being tracked,, then i bzr ignored them and bzr remove --keep 'd them.. and commited at that point
[16:37] <NET||abuse> now i'm pushing to the remote server.
[16:38] <NET||abuse> but the whole repo, as i didn't have a mirror repo up there already.
[16:40] <NET||abuse> ahh, 23648, i guess it's only updating when individual files in the bzr database are uploaded...
[16:40] <NET||abuse> so it's doing the vids right now, and they take a few minutes each file.. ok that makes sense
[16:40] <NET||abuse> so 1/5 way through, it's 130MB for the full repo.
[16:40] <GaryvdM> NET||abuse: Oh  - you are doing upload not push.
[16:41] <NET||abuse> well, i created an empty repo on my remote server, then am pushing into it.
[16:41] <GaryvdM> NET||abuse: did you do bzr push or bzr upload?
[16:41] <NET||abuse> that way i can update on the remote server and get the code there, and i just sync certain of the working copy on the remote server, to the live web directories.
[16:41] <NET||abuse> bzr push
[16:41] <NET||abuse> didn't even know about upload ;)
[16:42] <NET||abuse> bzr help upload   says no help found on upload.
[16:43] <NET||abuse> and bzr upload says unknown command.
[16:43] <NET||abuse> ahh, wait, that was on remote.
[16:43] <GaryvdM> NET||abuse: It is from a plugin
[16:43] <NET||abuse> yeh, i have the plugin on my local...
[16:43] <NET||abuse> wait, that's the thing for ftp'ing and stuff is it?
[16:43] <NET||abuse> or just uploading the latest revision out of the db?
[16:43] <NET||abuse> actually... that's a good idea.
[16:44] <NET||abuse> although, i love having a remote backup of my database of all my projects.
[16:44] <GaryvdM> bzr upload just upload the latest tree to a location. It is ment for people with out ssh access to a server
[16:45] <GaryvdM> NET||abuse: The plugin I was thinking about is remove-revisions, which won't help here.
[16:45] <NET||abuse> I load them into the space on the hosting account ffor any given site, below webroot, it gives a central point for me to pull down copies of projects if i switch computers, or if someone else joins me on a project
[16:46] <NET||abuse> hmm, seems to be moving along, up to 37.4MB uploaded now
[16:46] <NET||abuse> actually i can make a few changes on the WC here while it's busy uploading, i'll be able to push an update again once i checkin a few more changes.
[16:46] <NET||abuse> nice.. other than this hastle of pushing the whole project, loving bzr lately.
[16:47] <NET||abuse> remove-revisions.. hmm, alow you to prune your project db over time.
[16:48] <GaryvdM> NET||abuse: Unfortunatly that only allows you to remove revisions that don't have children
[16:48] <NET||abuse> hmm, i see
[16:48] <NET||abuse> oh, so prune off a branch that neve came to be.
[16:49] <NET||abuse> just to save wasted space sorta thing.
[17:25] <maxb> bzr-svn question, what does: inconsistent details in skipped record: ('svn-v4:72715ce3-35eb-0310-a5ca-db879023b231:mxbot/bot/trunk:364364',) ('25754514 251 0 332', ((('svn-v4:72715ce3-35eb-0310-a5ca-db879023b231:mxbot/bot/trunk:364363',),),)) ('26448822 251 0 332', ([('svn-v4:72715ce3-35eb-0310-a5ca-db879023b231:mxbot/bot/trunk:364363',)],))
[17:25] <maxb>  actually mean?
[18:23] <A4Tech1> hi all
[18:23] <A4Tech1> bzr: ERROR: These branches have diverged. Use the missing command to see how. Use the merge command to reconcile them
[18:31] <maxb> Well, do what it tells you
[18:31] <maxb> Using bzr-svn: Is there much difference in performance between sqlite vs tdb metadata caches?
[18:51] <jelmer> maxb: tdb is faster unless used on top of a slow filesystem (NFS)
[18:52] <jelmer> maxb: and tdb allows concurrency
[18:52] <jelmer> sqlite does not
[18:55] <maxb> jelmer: Thanks!
[18:56]  * maxb sets bzr-svn recaching 360 thousand revisions...
[19:15] <ronny> jelmer: what is tdb?
[19:16]  * rubbs is catching up on all the bzr mailing list emails he hasn't read in the last week. He's a just a little behind.
[19:18] <ronny> oh, seems like a simple concurrent key-value store
[19:28] <maxb> Can anyone elucidate what bzr fast-import means when it says 'bzr: ERROR: The file id "TREE_ROOT" is not present in the tree <bzrlib.inventory.CHKInventory object at 0x1d21710>.
[19:28] <maxb> ?
[20:12] <A4Tech1> ppl
[20:12] <A4Tech1> http://paste.ubuntu.com/343669/
[20:12] <A4Tech1> help please
[20:13] <A4Tech1> I have a 2 o'clock ago everything worked fine. Do not touch anything from the settings
[20:13] <rubbs> can you get to launchpad.net in a browser?
[20:13] <A4Tech1> yes
[20:15] <rubbs> have you been able to push to lp before?
[20:15] <A4Tech1> yes
[20:16] <rubbs> mmm... I"m out of ideas. It's possible that it didn't connect right because lp was having ssh troubles for a sec. Have you tried again since then?
[20:17] <A4Tech1> I noticed this only now
[20:19] <rubbs> if it keeps happening file a bug, but it looks like it was a bad connection from the error message. I'd try again soon and if it doesn't work try again in an hour. After that file a bug
[20:20] <A4Tech1> ok
[20:20] <A4Tech1> thx you
[20:21] <rubbs> no problem.
[20:21] <rubbs> Hopefully it was just a bad connection. Otherwise come back, maybe a dev can help you out
[20:21] <A4Tech1> ok
[20:22] <A4Tech1> I'm going to #launchpad ask :)
[20:23] <rubbs> good luck!
[20:23] <A4Tech1> Maybe they know what the problem
[20:29] <A4Tech1> rubbs:
[20:29] <A4Tech1> rubbs: try bzr pull
[20:29] <rubbs> k just a sec...
[20:29] <A4Tech1> get: bzr: ERROR: These branches have diverged. Use the missing command to see how. Use the merge command to reconcile them.
[20:30] <rubbs> This error is just telling you that there have been changes from both sides of the branch. Your branch has changes at the same time the pull branch has them
[20:30] <rubbs> You need to use a bzr merge to make them come together
[20:31] <rubbs> bzr help merge might help you
[20:31] <A4Tech1> try merge. get^ bzr: ERROR: Working tree "/media/DATA/projects/uITmage/" has uncommitted changes (See bzr status).
[20:32] <A4Tech1> i need to commit?
[20:32] <rubbs> yes, this means that you need to commit your changes
[20:32] <A4Tech1> then push or pull or merge? :)
[20:32] <rubbs> otherwise bzr doesn't know what to do with them.
[20:32] <rubbs> you should merge
[20:33] <rubbs> because the branches have gone in two different directions
[20:33] <rubbs> bzr help diverged-branches can help you to understand a little
[20:34] <A4Tech1> thx you :)
[20:35] <rubbs> no problem
[20:41] <jldupont> help, please, I get the following error: " Error while executing push  RemoteRepository(bzr+ssh://bazaar.launchpad.net/~jldupont/erljld/trunk/.bzr/) is not compatible with CHKInventoryRepository('file:///home/jldupont/workspace/erljld/.bzr/repository/') different rich-root support"
[20:41] <jldupont> whilst doing a "bzr push"
[20:42] <rubbs> jldupont: I'm not 100% sure (as I'm not a dev) but I believe that means your local branch is a different format than that of the remote branch
[20:42] <rubbs> did you by chance run bzr update?
[20:42] <jldupont> no I didn't ... but I remember seeing an update coming from Ubuntu channel through Synaptic.
[20:43] <rubbs> yes, but that is just for bzr it shouldn't have done anything to your local repo or branch
[20:43] <rubbs> by just bzr I mean just bzr the tool.
[20:43] <jldupont> yes, but could it be that Launchpad isn't updated yet??
[20:43] <rubbs> I can't recall how to fix this problem. but maybe someone else can help
[20:44] <rubbs> it isn't that the tools are different, it's the formats on the repositories that causes this problem
[20:44] <rubbs> if you have an older tool than I do, as long as I don't mess with your repo format I can still play with it
[20:44] <jldupont> @rubbs: I see.  What can I do?
[20:45] <rubbs> I'm not sure on the solution myself. I'll try to ping some people who might be able to help
[20:48] <rubbs> jam: ping not sure if your the right one for jldupont's problem, but could you take a look at it
[20:49] <rubbs> I tried to go through my logs to find a similar problem, but I'm having trouble finding it
[20:49] <Peng> jldupont: You probably ran "bzr init-repo" in bzr 2.0 or newer without specifying non-rich-root format.
[20:50] <Peng> jldupont: Your choises are to upgrade lp:~jldupont/erljld/trunk to a rich-root format such as 2a (and everyone else with a copy of the branch will have to upgrade too) or to make a non-rich-root repo and recommit your work.
[20:50] <Peng> Wait wait wait.
[20:50] <jldupont> @Peng: I use the Bazaar plugin under Eclipse with "share project" ... I don't know what that does .
[20:51] <Peng> lp:~jldupont/erljld/trunk *is* 2a. And so is your local repo. So I have no idea what the hell is going on. :D
[20:51] <jldupont> @Peng: how do you check this out??
[20:51] <Peng> jldupont: "bzr info -v" on the LP URL.
[20:51] <jldupont> ok
[20:52] <Peng> jldupont: Plus, the error message said your local repo is a CHKInventoryRepository, which is a rich-root format.
[20:53] <Peng> jldupont: What does "bzr info /home/jldupont/workspace/erljld/" on your client say the format is? Just curious.
[20:53] <Peng> jldupont: Also: what version of bzr?
[20:53]  * Peng is just guessing
[20:53] <jldupont> @Peng: "Standalone tree (format: 2a)
[20:53] <jldupont> Location:
[20:53] <jldupont>   branch root: .
[20:53] <jldupont> Related branches:
[20:53] <jldupont>   push branch: bzr+ssh://bazaar.launchpad.net/~jldupont/erljld/trunk/
[20:53] <jldupont> "
[20:54] <Peng> jldupont: OK. That _should_ be working fine.
[20:54] <lifeless> bzr info nosmart+bzr+ssh://bazaar.launchpad.net/~jldupont/erljld/trunk/ may be useful
[20:55] <jldupont> just tried pushing... "These branches have diverged.  See "bzr help diverged-branches" for more information."
[20:56] <rubbs> jldupont: this means that there are changes in the destination branch that you don't have yet. You have to merge in order to be able to push to that location now
[20:56] <rubbs> run bzr help  diverged-branches to get some info on that
[20:56] <jldupont> @rubbs: I don't want to merge!  my local copy is the correct one!
[20:56] <jldupont> I didn't touch this project for a couple of weeks and now I am coming back to it and it blows in my face!
[20:57] <rubbs> are you the only one with commit access?
[20:57] <jldupont> how can I "override" ?
[20:57] <jldupont> yes I am the only committer
[20:57] <rubbs> bzr push --overwrite
[20:58] <jldupont> @rubbs: let me try this. thanks.
[20:58] <pdragon> I installed bazaar for Windows on another computer in my office. The icon overlays are not showing on his computer, though. The box is checked to show them and I've tried reinstalling but nothing is letting them show up. They work fine on my PC. Any ideas?
[20:58] <rubbs> jldupont: bzr help push will show you everything push can do
[20:58] <jldupont> @rubbs: that seemed to have done the job... THANKS!
[20:58] <rubbs> pdragon: have you restarted since installing?
[20:58] <rubbs> jldupont: good to hear, glad to help
[20:58] <pdragon> yes
[20:59] <pdragon> it's been like this for several versions now. Just upgraded to 2.0 finally and it's still happening
[20:59] <jldupont> @rubbs:  what's your username on SO that I could "upvote" a couple of your questions ;-)
[20:59] <rubbs> pdragon: would the branch be located on a network drive at all?
[21:00] <rubbs> jldupont: my lp username is patrick-regan
[21:00] <jldupont> SO -> http://stackoverflow.com/
[21:00] <pdragon> yes it is. the icon overlays are showing up fine on my PC, though
[21:00] <pdragon> I do have the option checked for network drives
[21:00] <rubbs> er sorry my SO is rubbsdecvik
[21:00] <jldupont> @rubbs: ok then... see you around on SO.
[21:00] <rubbs> er sorry again
[21:00] <rubbs> wrong
[21:00] <rubbs> first one was right
[21:00] <rubbs> patrick-regan
[21:00] <rubbs> haha
[21:02] <jldupont>  Stow, OH ?
[21:02] <rubbs> pdragon: hhmm. I'm stumped so far, but I have access to a network drive on windows. let me try to reproduce your problem
[21:02] <rubbs> jldupont: yep
[21:02] <jldupont> ... one upvote coming up.
[21:02] <pdragon> alright. thanks. it's been baffling me for a while. was waiting to get 2.0 rolled out and see if it fixed things
[21:02] <rubbs> jldupont: thank you
[21:02] <pdragon> that it works on mine and not his is what puzzles me
[21:03] <pdragon> everything else that's part of bzr & tortoise works fine
[21:03] <pdragon> as far as menus
[21:03] <rubbs> pdragon: it is really puzzling almost done with m y check just a sec
[21:03] <jldupont> .... thanks to everybody... until next time... ciao.
[21:04] <rubbs> jldupont: ciao
[21:04] <rubbs> pdragon: they seem to work on mine
[21:04] <rubbs> pdragon: I'm still trying to think of some things.
[21:05] <rubbs> do you have uknown drives checked?
[21:05] <pdragon> hmm... could it be anything in the AppData\bazaar folder in Docs & Settings?
[21:05] <pdragon> i know that persists between reinstalls/upgrades. haven't tried deleting that
[21:06] <rubbs> pdragon: could be you could try editing/deleting the tbzr.conf file
[21:13] <pdragon> rubbs: will try playing around with the AppData folder. Thanks for the help :)
[21:14] <rubbs> pdragon: np, sorry I couldn't help more
[21:15] <poolie> hello all
[21:15] <rubbs> hello poolie
[21:15] <poolie> jam: still around?
[21:16] <rubbs> I haven't seen him talk in a while, but he might be around, just fyi
[21:19] <poolie> thanks
[21:19] <rubbs> np
[21:48] <jam> poolie: yes
[21:49] <jam> Just had my sound off for some reason
[21:54] <jam> rubbs: I think you did fine diagnosing jldupont's issue. He probably did 'bzr init-repo' locally, getting a 2a format repo, branching into that auto-upgraded the format, and pushing back fell over a little bit.
[21:54] <rubbs> jam
[21:54] <rubbs> opps. jam thanks
[21:56] <poolie> hi jam
[22:19] <jam> anyone having trouble connecting to bazaar.launchpad.net?
[22:19] <jam> I can connect to the website just fine
[22:19] <jam> but bzr+ssh fails to connect
[22:20] <jam> even 'sftp bazaar.launchpad.net' is failing for me
[22:20] <jam> ah, mabye it is 04:00 UTC
[22:20] <RAOF> jam: Yes, I am also.  http:// also fails for me.
[22:20] <lifeless> I have a hung push
[22:20] <lifeless> jam: what appens at 0400
[22:21] <jam> lifeless: http://identi.ca/notice/12740973
[22:21] <jam> Wrong day
[22:21] <jam> something very strange about that feed
[22:22] <jam> as it is ... October?
[22:26] <maxb> Neat :-/   My repository has sent bzr-svn into an infinite loop
[22:28] <lifeless> machine down
[22:29] <lifeless> I've escalated and its being looked at
[22:30] <poolie> lifeless: so, twitter it!
[22:30] <poolie> that is part of the process of escalating it
[22:31] <lifeless> poolie: is it?
[22:32] <poolie> it is
[22:32] <poolie> the document may be out of date but i think it's agreed
[22:32] <poolie> and anyhow it just makes sense
[22:32] <poolie> um
[22:32] <poolie> i don't even see anything in #launchpad?
[22:33] <lifeless> #topic there, and it was like that when I got up
[22:33] <poolie> oh so it is
[22:33] <poolie> so it's been known for 80m
[22:33] <poolie> ffs
[22:33] <lifeless> by escalated, I don't mean 'followed a work policy', I mean 'told someone so I can go back to scratching itches'
[22:33] <poolie> ok
[22:33] <poolie> someone else failed then
[22:34] <poolie> who did you tell please?
[22:34] <lifeless> spm
[22:34] <poolie> k
[22:34] <poolie> but he already knew?
[22:34] <lifeless> nope
[22:34] <lifeless> I suspect I interrupted his breakfast :(
[22:35] <lifeless> speaking of which, I vant mine :)
[22:35] <lifeless> I will read up on policy when I get back to work
[22:35] <spm> lifeless: no - just harvesting zombies :-)
[22:39] <lifeless> spm: I don't even want to think about what you mean by that euphism
[22:40] <spm> lifeless: euphemism? no. literal description actually. well. Ghouls, not zombies. but same same. :-D
[22:41] <lifeless> spm: oh, WoW  ?
[22:41] <spm> yarp
[22:41] <lifeless> :>
[22:52] <spm> poolie: lifeless: should be back; if you can confirm from your end?
[22:52] <mwhudson> bounded memory for bzr serve processes pls
[22:52] <poolie> man ulimit
[22:53] <mwhudson> i guess that would be better than the current situation
[22:53] <mwhudson> not very nice for the users that get affected though
[22:53] <poolie> hm
[22:54] <poolie> mwhudson: it would be a bit like lp web app timeouts
[22:54] <poolie> _if_ we turn them into oops-like things and gradually crank down the limit
[22:54] <poolie> then yay
[22:54]  * poolie pats the bot
[22:54] <mwhudson> lol
[22:55] <mwhudson> i wonder if it's possible to tune the oom killer to target lp-serve processes
[22:57] <maxb> I believe you can tweak scores on processes to make the oomkiller more or less inclined to touch them
[22:57] <mwhudson> though by the time the OOM killer is on the loose we've already lost i guess
[22:58] <lifeless> was it memory ?
[22:58] <mwhudson> poolie: i agree we'd need to track how many lp-serve processes that get killed like this
[22:59] <mwhudson> lifeless: i assume so, it usually is it seems, but yes, should check
[23:01] <lifeless> poolie: I don't know how long the outage was, I'd check #launchpad backlog for whoever set the topic
[23:01]  * lifeless goes away
[23:01] <poolie> it hadn't changed in at least that long
[23:02] <jam> mwhudson: wouldn't the OOM killer kill processes that are consuming the most memory? It doesn't seem like 'sshd' would be the problem...
[23:03] <mwhudson> jam: this is a long and sad tale, apparently it's harder than you'd think to do that
[23:04] <mwhudson> it's all james_w's fault this time anyway
[23:04] <poolie> !
[23:04] <mwhudson> well, not really, but
[23:04] <james_w> I think it might be
[23:04] <poolie> james_w: hi
[23:04] <james_w> hi all
[23:04]  * james_w slinks away to work out what happened
[23:05] <mwhudson> james_w: well, we should be more secure against this sort of thing taking the machine out
[23:06] <mwhudson> so "bounded consumption for lp-serve processes" wasn't the correct knee to jerk this time
[23:08] <james_w> hmm, my suspicion is a missing possible_transports parameter
[23:11] <mwhudson> you seemed to be connecting about 30 times a minute
[23:12] <jam> mwhudson: I'm impressed that the ssh handshake resolved that quickly. :)
[23:12] <jam> anyway, I'm done for tonight
[23:12] <jam> see y'all later
[23:12] <mwhudson> jam: :)
[23:12] <mwhudson> i think it's from a machine in the dc
[23:13] <Peng> Someone broke bazaar.lp? Awesome!
[23:13] <mwhudson> and running locally ssh-ing to bazaar.launchpad.dev is actually faster than to the sshd