[00:36] <thumper> boo
[00:36] <thumper> I added a command to allow setting append only in a plugin
[00:37] <thumper> I have a locations.conf that automatically sets the push branch
[00:37] <thumper> so used "bzr append-only :push"
[00:37] <thumper> bzr: ERROR: Unsupported protocol for url "lp:~thumper/unity/test"
[00:37] <thumper> $ bzr append-only lp:~thumper/unity/test
[00:37] <thumper> HPSS calls: 54 (30 vfs) SmartSSHClientMedium(bzr+ssh://thumper@bazaar.launchpad.net/)
[00:37] <poolie> hm, strange
[00:37] <thumper> so it just seems that we need another deref thing
[00:38] <poolie> seems like it
[00:38] <poolie> there is another bug like that
[00:39] <thumper> $ bzr revno :push
[00:39] <thumper> bzr: ERROR: Unsupported protocol for url "lp:~thumper/unity/test"
[00:39] <thumper> same issue elsewhere
[00:40] <jelmer> thumper: bzrlib.directory_service.directories.dereference()
[00:40] <thumper> and another problem
[00:40] <thumper> jelmer: revno isn't mine :)
[00:40] <thumper> I was testing my append_only tweak
[00:40] <thumper> pushed branch
[00:40] <thumper> set remote append only
[00:40] <thumper> uncommitted locally, followed by revert
[00:40] <thumper> then pushed
[00:41] <thumper> $ bzr push
[00:41] <thumper> Using saved push location: lp:~thumper/unity/test
[00:41] <thumper> No new revisions or tags to push.
[00:41] <thumper> however the revno of the LP one is one higher than locally
[00:41] <thumper> shouldn't it complain?
[00:41] <jelmer> thumper: it'll only complain if the branches have actually diverged
[00:41] <thumper> hmm...
[00:41] <thumper> ok
[00:42] <jelmer> so if you do a commit locally and then try to push, it should error out
[00:43]  * thumper does an unchnaged commit
[00:43] <thumper> yep got diverged
[00:43] <thumper> but you get that with diverged branches anyway
[00:43]  * thumper tries --overwrite
[00:44] <thumper> $ bzr push --overwrite
[00:44] <thumper> Using saved push location: lp:~thumper/unity/test
[00:44] <thumper> bzr: ERROR: Server sent an unexpected error: ('error', 'RevisionNotPresent', 'Revision {tarmac-20120212192717-9jmrqx6we7yd8bl7} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(CallableToParentsProviderAdapter(<bound method CHKInventoryRepository._get_parent_map_no_fallbacks of CHKInventoryRepository(\'chroot-95047632:///~thumper/unity/test/.bzr/repository/\')>))], []))))".')
[00:44] <thumper> HPSS calls: 18 (0 vfs) SmartSSHClientMedium(bzr+ssh://thumper@bazaar.launchpad.net/)
[00:44] <thumper> oops
[00:44] <thumper> we should have a "you can only append" message right?
[00:44] <jelmer> yes
[00:44] <jelmer> or at the very least, not an error of this kind
[00:45] <jelmer> if you can file a bug about this, perhaps with a way to reproduce it that would be really great
[00:45] <jelmer> I think I've seen this error before, but never in a way that was reproducable
[00:45] <thumper> sure
[00:49] <thumper> jelmer: https://bugs.launchpad.net/bzr/+bug/931209
[07:27] <vila> good morning bazaar
[09:02] <mgz> morning!
[09:02] <vila> mgzorning !
[09:25] <bialix> hi all
[09:25] <bialix> mgz,wgz: I'm going to release current state of bzr-explorer trunk as 1.2.2 this weekend
[09:29] <mgz> bialix: okay.
[09:30] <mgz> will see if I have an evening free to fix a few things before then.
[09:30] <mgz> thanks bialix.
[09:31] <bialix> we have a couple of fixes in trunk already. more fixes will be good, but Ben Finney reminded me that we need a proper release before 2.5 final
[09:33] <mgz> yeah.
[09:39] <bialix> ok
[12:43] <edlinde> how do I get the files in http://igraph.bzr.sourceforge.net/bzr/igraph/0.6-main/files ?
[12:43] <edlinde> do I need to have bzr installed on my machine?
[12:45] <jelmer> edlinde: yes, that's probably the easiest way to do so
[12:57] <LarstiQ> edlinde: though bzr can run from source if installing is difficult (though it will be slower if you can't compile the c extensions)
[14:07] <gnomefreak> what bzr package contains bzr-notify?
[14:17] <mgz> gnomefreak: bzr-gtk though you may want to check recently fixed bugs before filing a new one
[14:19] <gnomefreak> mgz: this is not a new one. i filed a bug on this a while ago. IIRC it was marked a duplicate but dont recall the bug number
[14:19] <gnomefreak> mgz: thanks
[14:21] <gnomefreak> thats odd. i cant find it at all. doesnt matter since it is a bzr PPA
[14:24] <mgz> gnomefreak: bug 903696
[14:24] <ubot5`> Launchpad bug 903696 in bzr-gtk (Ubuntu) "bzr-notify crashed with SIGSEGV in g_return_if_fail_warning()" [Medium,Confirmed] https://launchpad.net/bugs/903696
[14:24] <gnomefreak> that looks like the one
[14:25] <gnomefreak> mgz: ok i commented on it rather than report a new one. thanks
[14:27] <mgz> it looks from the bug that testing with tip bzr-gtk would be useful to confirm the issue is resolved
[14:30] <gnomefreak> version 0.103.0+bzr769-1 it is still broken. I removfed the package a little while ago but i will make a note to reinstall it in a few days maybe eraly next week
[14:33] <jelmer> I guess we'll just need to release and upload 0.104
[14:34] <gypsymauro> hi
[14:35] <gypsymauro> there is a way to convert a project from darcs to bzr?
[14:35] <jelmer> gypsymauro: it should be possible to do so with bzr-fastimport
[14:36] <gypsymauro> any example somewhere jelmer ?
[14:36] <gypsymauro> I'm googling but a lot of false positives :D
[14:37] <jelmer> gypsymauro: I'm not sure, I've never used it myself
[14:37] <jelmer> gypsymauro: 'bzr fast-export-from-darcs' should generate a fastimport stream for you from the darcs repo
[14:37] <jelmer> gypsymauro: you can then use 'bzr fast-import' to create a bzr repository from that
[16:42] <zyga> jml: ping
[16:43] <jml> zyga: yes?
[16:43] <zyga> jml: hi
[16:43] <zyga> jml: I'm an avid user of testtools/testscenarios
[16:43] <jml> \o/
[16:43] <zyga> jml: it seems that the only thing that keeps me back in python2.7 now is testtools/setup.py
[16:44] <jml> zyga: what about it?
[16:44] <zyga> it seems it wants to use bzrlib to figure out the revision and things like that
[16:44] <jml> zyga: only if you're using a checkout.
[16:44] <zyga> jml: so, since I wrote something that resolves this exactl problem once and for all
[16:44] <jml> zyga: shouldn't do that for released versions
[16:44] <zyga> jml: (hmm, I recall seeing similar issues with venv/tox
[16:44] <zyga> jml: anyway, I was wondering if you would consider using versiontools
[16:45] <jml> zyga: I'll take a look.
[16:45] <zyga> jml: it's a tiny library that understnads how to do what you do in setup.py, works with all python versions and most sensible VCS systems (and has plugin support to add more via 3rd party packages)
[16:45] <zyga> jml: I'll push a MP to let you know how it looks like
[16:46] <zyga> jml: if you are curious: versiontools.rtfd.org
[16:46] <zyga> jml: I've got a MP hanging that removes the need to use setup_requires if you are scared of things like that (some people found it allergic)
[16:47] <jml> zyga: thanks.
[16:48] <zyga> jml: is there any reason you are using distutils as opposed to setuptools/distribute
[16:48] <mgz> what I do is just hack the test script to fall back to no version if an ImportError gets thrown from bzr
[16:49] <zyga> mgz: consider using versiontools
[16:49] <mgz> I swear I put up an mp that did this, but now can't see it
[16:49] <mgz> why?
[16:49] <zyga> mgz: it's a bit more clever than that
[16:49] <mgz> it's yet another annoying dependency
[16:49] <zyga> mgz: it's implemented right, unlike most one-off copy/paste solutions
[16:49] <zyga> mgz: works across various vcs'es
[16:49] <zyga> mgz: it is only a build-time dependency if you use it (your users won't have to)
[16:50] <mgz> well, it's still something I'd be commenting out before running setup.py like I do with setuptools
[16:50] <zyga> mgz: it's a dependency but one that is cheerful to work with
[16:50] <zyga> mgz: nope
[16:50] <zyga> mgz: why ?
[16:50] <mgz> build time is what I care about when I'm downloading a branch tip to quickly test
[16:50] <zyga> mgz: then you don't have to comment anything out
[16:50] <mgz> I'm not dealing with prettily packaged branches
[16:51] <mgz> if it's quiet when it's not there then I can live with it
[16:51] <zyga> mgz: it's not only silent but actually works correctly in such cases
[16:51] <mgz> historically the junk people use in setup.py isn't very good at falling back to basics
[16:52] <zyga> mgz: my problem exactly, I had ugly code in each setup.py I wrote
[16:52] <zyga> mgz: then I decided that I can do better and made a project out of that
[17:02] <bdmurray> Is there any chance I could get the lucid-updates branch of update-manager updated?
[17:05] <james_w> bdmurray, something looks broken with one of the update-manager branches unfortunately: http://package-import.ubuntu.com/status/update-manager.html
[17:07] <bdmurray> james_w: okay, so is there anything I can do?
[17:08] <james_w> bdmurray, I don't think we can get the importer past that, so it would be a case of tracking down the bug and fixing it
[17:17] <quicksilver> if I've got a shared report into which I've pulled a toxic revision (accidentally committed large file) is there some way to "garbage collect" the repo and get rid of it, if no actual branch uses it?
[17:17] <quicksilver> s/report/repo/;
[17:17] <mgz> not an easy one.
[17:18] <mgz> with a little scripting, you can just create a new shared repo, then branch everything under the current one into that, then replace the old location with the new one
[17:20]  * quicksilver nods
[18:05] <quicksilver> is there a tool to extract a commit message from a revision?
[18:05] <jelmer> quicksilver: bzr log ?
[18:06] <jelmer> quicksilver: can you perhaps expand a bit on what you're trying to do ?
[18:06] <quicksilver> long story :)
[18:06] <quicksilver> reapply a bunch of commits, preserving commit message
[18:07] <mgz> that's the kind of thing the rebase plugin *should* make easy
[18:07] <quicksilver> I can extract a patch for the commit with bzr diff
[18:07] <mgz> but whether in fact it does may be another issue
[18:07] <quicksilver> I can probably hack something up with bzr log | sed
[18:08] <quicksilver> just wondered if there were tools for "field-by-field" access to parts of revisions
[18:08] <mgz> well, yes, bzrlib.
[18:08] <jelmer> quicksilver: if you have a XML parser ready, 'bzr cat-revision' could be useful
[18:21] <quicksilver> jelmer: aha
[18:21] <quicksilver> mgz: fair enough.
[18:23] <quicksilver> jelmer: doesn't look like XML to me, looks like colon-separated text
[18:25] <jelmer> quicksilver: yeah, it's just the repository-internal data
[18:26] <jelmer> quicksilver: in older versions that was in XML, in newer versions it's bencode
[18:26] <jelmer> another option would be bzr-xmloutput, it has a command that can spit out the data in XML for you
[18:43] <zyga> jml: https://code.launchpad.net/~zkrynicki/testtools/use-versiontools/+register-merge
[19:40] <quicksilver> jelmer: so many possibilities, so many tools to look at. I may stick with perl + sed and a quick hack job :P
[19:41] <jelmer> heh, that works too :)
[20:28] <thomi> Hi - how does 'bzr lp-open' pick which browser to use?
[20:28] <thomi> My default browser is firefox, but ever since I installed chromium it's started using that instead...
[20:50] <LarstiQ> thomi: it uses webbrowser.open
[20:50] <LarstiQ> thomi: http://docs.python.org/library/webbrowser
[20:51] <thomi> LarstiQ: thanks, I'll look there for a solution.