[00:03] <lifeless> thumper: ping
[00:03] <lifeless> thumper: did you seem my reply last night ?
[00:13] <maxb> Why would I see a contents conflict on merging, instead of a text conflict, for a file which is ostensibly text, and has common ancestry between the branches being merged?
[00:14] <spiv> maxb: good question.  Not sure!
[00:15] <maxb> oh, oops, it was removed at one point on the merge target branch
[00:31] <abadger1999> Another question for my request to update the EPEL bzr -- what's the API policy and release lifecycle of the 2.x branches?
[00:31] <abadger1999> is it 2.x is compatible but 2.(x+1) can have API breaking changes?
[00:32] <abadger1999> And is it 2.x will be supported for 6 months?  1 year?  Undetermined?
[00:34] <abadger1999> I'm trying to find the best release to put into a repository that's supposed to remain API stable for 4 more years.
[00:36] <james_w> 2.X.Y should be stable across Y
[00:36] <abadger1999> Excellent.
[00:36] <james_w> as for support timeframes, they are longer, but not sure about 4 years

[00:36] <abadger1999> Is there a doc that tells what hte expected timeframe is?
[00:37] <james_w> 2.1.1 is in Ubuntu lucid, which will be around for years
[00:37] <james_w> so 2.1.X might be a good choice
[00:37] <james_w> I don't think so
[00:37] <james_w> Martin started a discussion a couple of weeks ago on the list about what sort of timeframes people would be interested in for the various releases
[00:39] <james_w> maybe you would like to weigh in there
[00:39] <abadger1999> yeah, I saw that in passing... wasn't sure how to ask for a seven year release lifetime, though :-)
[00:39] <james_w> heh
[00:39] <abadger1999> LTS releases are approximately 5 years?
[00:40] <james_w> 3 on the desktop, 5 on the server
[00:40] <james_w> not sure where bzr falls
[00:41] <james_w> night
[00:41] <abadger1999> Night.  And thanks!
[00:42] <lifeless> abadger1999: we don't have any release thats stable for 4 years for bzr itself

[00:43] <lifeless> abadger1999: our policy is to minimise API changes totally on the .Y as james_w says
[00:43] <lifeless> but the bzr community doesn't do bugfixes for 5 years on a given X.Y
[00:43] <lifeless> more like 6-12 months
[00:44] <lifeless> so no API changes on .Z unless its fully compatible or needed for security
[00:44] <lifeless> few changes in .Y's, but they happen
[00:44] <lifeless> and anything goes on X's
[00:44] <lifeless> a new .Y every 6 months
[00:44] <lifeless> a new .Z every month, for the last few .Y's
[00:46] <abadger1999> Okay.  So .Y's are expected to break compatibility but hopefully in little used areas, .Z's are expected to not break anything (barring no other way to fix a security hole)?
[00:47] <abadger1999> Or is it more accurate to say .Y's can break things but porting should be straightforward?
[00:47]  * abadger1999 trying to figure out how best to phrase this in the request to update
[00:49] <thumper> lifeless: yes I did, thanks
[00:49] <lifeless> thumper: cool
[00:49] <lifeless> abadger1999: .Y's *may* break it, if doing so makes things better for bzrlib API's. Not expected, but also not unexpected.
[00:49] <lifeless> so yes, '.Y's can break things but porting should be straightforward?'
[00:50] <abadger1999> lifeless: Thanks!
[00:58] <igc> hi all
[01:15] <abentley> I just got a local delivery failure sending a message to the Bazaar mailing list: http://pastebin.ubuntu.com/411371/
[01:16] <spiv> abentley: ouch.  I guess that's something to ask IS or at least a losa about?
[01:16] <lifeless> #is
[01:16] <lifeless> yeah
[01:17] <abentley> spiv, wanted to make sure it wasn't a known issue.
[01:17] <spiv> abentley: well, not known to me :)
[01:17] <spiv> It wouldn't surprise me to find that #is knows already.
[01:17] <lifeless> there has been no chatter
[02:02] <LaserJock> how can I undo a commit, not revert, just get rid of the log entry, etc.
[02:02] <jelmer> LaserJock: bzr uncommit
[02:05] <LaserJock> jelmer: awesome, is there something like unadd?
[02:06] <LaserJock> oh, maybe rm --keep or something
[02:06] <jelmer> LaserJock: yep, sounds like it
[02:07] <fullermd> If the two are related, it sounds more like you want 'pull' than 'uncommit'...
[02:08] <spiv> Woo, 0 new bugs again.
[02:08] <LaserJock> fullermd: but I have nothing to pull from
[02:09] <fullermd> You have itself.
[02:09] <fullermd> bzr pull --overwrite -r-2 .
[02:09] <LaserJock> hmm, interesting
[02:10] <fullermd> The different between pull [--overwrite] to a prior rev and uncommit is that uncommit leaves your WT in the state it's in right now, with pending edits and adds and rm's and merges equal to the commit you were at.
[02:10] <fullermd> pull goes back to that rev (roughly; mod currently uncommitted changes which get merged)
[02:10] <spiv> "bzr uncommit" followed by "bzr revert" is probably a less confusing way to do that, even if it is two operations.
[02:11] <spiv> pulling from ". -r-2" is a bit subtle.
[02:11] <LaserJock> well, I was trying to unadd mistakenly added files
[02:12] <LaserJock> so i wanted to uncommit, unadd, then recommit
[02:13] <spiv> LaserJock: sounds like the uncommit and rm commands you found were just what you wanted, then :)
[02:14] <fullermd> Well, if you want to be unsubtle, there's always `git reset --kinda-soft-like-a-spring-rain` or whichever variant it is...
[02:16] <lifeless> LaserJock: you can safely revert an added file, btw
[02:16] <lifeless> it will just get unadded
[02:16] <LaserJock> oh
[02:17] <LaserJock> I get mixed up between git revert and bzr revert so I tend to avoid both
[02:18] <LaserJock> the curse of the multiple-DVCS world
[02:18]  * RAOF grumbles at git deliberately using different terminology to everyone else.
[02:18] <lifeless> LaserJock: apt-get install bzr-git; never look back.
[02:19] <RAOF> Well, look back a *little* bit, at least until there's some way to refer to a colocated branch.
[02:19] <lifeless> RAOF: there is
[02:19] <RAOF> WHEN DID THIS HAPPEN?
[02:20] <LaserJock> well, I do like git sometimes, I don't know that I want to get rid of it altogether
[02:20] <lifeless> LaserJock: I wasn't suggesting migrating
[02:20] <LaserJock> but it is annoying that they seem to use different terminology form everybody else
[02:20] <lifeless> LaserJock: just using bzr :)
[02:20] <LaserJock> right, but that's full of FAIL, IMO
[02:20] <RAOF> lifeless: Make my life better.  Point me at docs :)
[02:21] <lifeless> RAOF: https://code.edge.launchpad.net/~jelmer/bzr/colo-urls/+merge/20860
[02:22] <LaserJock> is it easy to push and branch with bzr-git?
[02:22] <LaserJock> the "consumer" end isn't so bad
[02:23] <LaserJock> but if I'm the only bzr user in a team of git-heads I think I'm at a disadvantage using bzr-git
[02:23] <RAOF> Branching just works; to push you need to use “dpush” rather than “push” (unless that's been resolved), but that also works.
[02:24] <LaserJock> then there's that branch-as-a-dir thing that still gets me about bzr even after years of use
[02:24] <LaserJock> I'm getting there though :-)
[02:25] <LaserJock> I just have to force myself to stop blowing away branches
[02:25] <lifeless> why?
[02:25] <lifeless> I delete branches all the time
[02:25] <lifeless> I just deleted 5
[02:25] <LaserJock> because then I don't ever branch
[02:26] <lifeless> ...
[02:26] <LaserJock> I think branching should be a useful thing, but I don't think I'll use them if I just keep deleting them
[02:26] <LaserJock> maybe it's repos I don't like more than branch-as-a-dir
[02:28] <LaserJock> I suppose it's just psychology, I find it somewhat intuitive to mix VCS and non-VCS dirs
[02:28] <LaserJock> *unintuitive
[02:28] <LaserJock> I regularly do that with bzr and I often don't know what's a branch and what isn't
[02:28] <lifeless> LaserJock: so I have one work dir
[02:29] <lifeless> and N branches
[02:29] <LaserJock> I go and blow away a branch thinking it's something else
[02:29] <LaserJock> hmm
[02:30] <LaserJock> so is that like using bzr switch?
[02:30] <LaserJock> I was reading something about being able to do something git-esque by switching working dirs or something
[02:30] <LaserJock> seemed overly complicated
[02:31] <lifeless> spiv: are you around ?
[02:31] <lifeless> LaserJock: bzr switch? 2 extra commands to setup, after that no-brainer
[02:32] <spiv> lifeless: I am
[02:33] <lifeless> I want to talk commands
[02:33] <lifeless> if you're working
[02:34] <spiv> I am working
[02:34] <spiv> Now's as good a time as any, I suppose1
[02:34] <spiv> !
[02:43]  * igc out for a few hours
[02:57] <thumper> lifeless: got a few minutes?
[03:00] <thumper> every time I try to use the bzr command line client I get:
[03:00] <thumper> $ bzr info
[03:00] <thumper> /usr/lib/pymodules/python2.6/lazr/uri/__init__.py:19: UserWarning: Module launchpadlib was already imported from /usr/lib/pymodules/python2.6/launchpadlib/__init__.py, but /usr/lib/pymodules/python2.6 is being added to sys.path
[03:00] <thumper> anyone know what I need to stab to make it go away?
[03:39] <lifeless> thumper: sure
[03:39] <lifeless> thumper: uhm
[03:40] <lifeless> thumper: pkg_resources sucks.
[03:40] <lifeless> thumper: file a bug on lazr
[03:40] <thumper> lifeless: and the short solution to stop bzr complaining at me all the time?
[03:41] <lifeless> apt-get remove python-launchpadlib, I guess
[03:41] <lifeless> thumper: you can make it break - and get a backtrace
[03:42] <lifeless> python -Werror BZR_PDB=1 /usr/bin/bzr info
[03:43] <thumper> didn't stop unfortunately
[03:43] <lifeless> thumper: poke around /usr/lib/pymodules/python2.6
[03:43] <thumper> and BZR_PDB=1 had to go first
[03:45] <lifeless> its a nuts error
[03:46] <lifeless> thumper: do you have python, or setuptools, or soething like that coming from the lp ppa ?
[03:46] <thumper> probably something
[03:46] <thumper> how can I see?
[03:46] <lifeless> apt-cache policy <package>
[03:46] <lifeless> aptitude search ~o
[03:48] <lifeless> its a nuts error because for /usr/lib/pymodules/python2.6/launchpadlib/__init__.py, to have been imported /usr/lib/pymodules/python2.6 has to be on the path already
[03:49] <lifeless> have I mentioned I hate pkg_resources ?
[03:49] <thumper> :)
[03:49] <SamB_XP> lifeless: what IS that ?
[03:49] <lifeless> what is what ?
[03:49] <SamB_XP> that thing you keep saying you hate
[03:50] <lifeless> http://pypi.python.org/pypi/setuptools
[03:50] <SamB_XP> ah, something from the infamous setuptools then ?
[03:50] <lifeless> pep 365 is pkg_resources, but its a pje special
[03:50] <lifeless> note the status - rejected ;)
[03:51] <thumper> pje?
[03:51] <lifeless> phillip J eby
[03:51] <SamB_XP> I'm assuming he's one of the people behind the infamous package mentioned above
[03:51] <lifeless> the guy that brough setuptools and easy_install to life
[03:52] <SamB_XP> exarkun, I believe, is often ranting about setuptools
[03:52] <lifeless> Most Hated Module Ever
[03:53] <lifeless> it has caused more bugs than I want to think about
[03:53] <lifeless> for fun, read /usr/lib/python2.6/dist-packages/pkg_resources.py
[03:53] <SamB_XP> no thanks ;-P
[03:53] <lifeless> note the 15 line vertical whitespace
[03:53] <SamB_XP> woah
[03:53] <lifeless> I mean, thats a trivial thing right. But so unnecessary
[03:54] <SamB_XP> and I thought that one NES emulator was bad!
[03:54] <SamB_XP> it used like up to 5 lines of whitespace in a row for different reasons ...
[03:54] <lifeless> have a look at this:
[03:54] <lifeless> if (modname not in sys.modules or modname in nsp
[03:55] <lifeless>     or modname in _namespace_packages
[03:55] <lifeless> ):
[03:55] <lifeless>     continue
[03:55] <lifeless> for indenting
[03:57] <lifeless> thumper: so the bug is
[03:58] <lifeless> thumper: that pkg_resources has a bug (surprise)
[03:58] <lifeless> thumper: if you add
[03:58] <lifeless> if fn in sys.path:
[03:58] <lifeless>     continue
[03:58] <lifeless> at line 2333 of /usr/lib/python2.6/dist-packages/pkg_resources.py
[03:58] <lifeless> it will probably silence the error
[04:01] <thumper> nope
[04:01] <lifeless> oh
[04:02] <lifeless> well, I'd put pdb in there and inspect
[04:02] <lifeless> I guess there may be an egg magic causnig it to be loaded without the containing dir being on the path.
[04:02] <lifeless> Moar reasons to hate eggs
[04:03]  * SamB_XP wonders if there is such a thing as "build-conflicts"
[04:04] <lifeless> for debian packaging? yes
[04:04] <lifeless> I forget the exact header name
[05:10] <lifeless> spiv: https://code.edge.launchpad.net/~lifeless/bzr/commands/+merge/23068
[05:24] <abentley> lifeless, do commands need to call  ui.ui_factory.clear_term if they might have caused progress messages?
[05:25] <lifeless> abentley: I think thats the current workaround
[05:25] <lifeless> abentley: there is some discussion about makeing self.outf do that if needed, automatically.
[05:27] <abentley> lifeless, I've looked at builtins.py and I only see one command doing that (ls.)  I guess the rest are doing it lower down?
[05:29] <lifeless> let me have a squiz
[05:30] <lifeless> gpg strategy does it
[05:30] <lifeless> abentley: note() does it
[05:30] <lifeless> and so does warning()
[05:31] <lifeless> abentley: so yes, I think that that accurately summarises - the rest are doing it lower down
[05:51] <parthm> lifeless: ping
[05:51] <lifeless> hi
[05:51] <parthm> hi.
[05:51] <parthm> so i am trying to understand rio better. if i get it right, right now its a binary format meant to be written to a file?
[05:53] <parthm> what does rio stand for?
[05:55] <lifeless> see the top of bzrlib/rio.py
[06:00] <parthm> lifeless: thanks. i am just trying out your tags diagnostic patch.
[06:04] <lifeless> parthm: as martin_gzlist says, its not that
[06:06] <parthm> lifeless: yes. just noticed that. so rio is more of an internal binary format (ascii + utf-8) not really meant for stdout. so what would be a good fix for this?
[06:07] <lifeless> parthm: as per the list/bug - change the command to take a filename
[06:07] <lifeless> permit '-' for people to that want to use it
[06:12] <parthm> in 'version-info [location]' with location being optional we probably need a option --output or something. so if the file is open-ed with the correct encoding that should take care of making rio readable?
[06:14] <lifeless> if we are breaking compat
[06:14] <lifeless> change it to version-info filename [location]
[06:14] <lifeless> or
[06:15] <lifeless> change it to version-info filename [-d location]
[06:15] <lifeless> (-d is a common argument we want to support for 'look elsewhere for stuff')
[06:17] <parthm> lifeless: sounds fine to me. so this is probably more of a 2.3 change. i still need to understand rio better will probably spend some more time on that.
[06:17] <lifeless> ok
[06:17] <parthm> i will discuss this on the mailing list in case there are some more suggestions/refinements.
[06:18] <parthm> lifeless: thanks for the help.
[06:18] <lifeless> anytime!
[06:30] <mwhudson> so what are actual good tools for visualizing conflicts?
[06:32] <lifeless> meldd
[06:32] <spiv> mwhudson: http://blogs.mathworks.com/images/steve/2009/windowing_fft_2_03.jpg
[06:33] <lifeless> ow!
[06:33] <lifeless> warn usbefore doing that :P
[06:33] <mwhudson> spiv: thanks
[06:33] <mwhudson> lifeless: hm, bit underwhelmed by meld in this case, how do you invoke it?
[06:33] <lifeless> there is a plugin I believe
[06:35] <mwhudson> oh right 'extmerge'
[06:40] <mwhudson> jelmer: hooray for inconsistent tabs vs spaces in dulwich's _pack.c
[06:40] <mwhudson> at least i assume that's what's going on, not just inconsistent indentation
[09:14] <lifeless> thumper: have you seen https://edge.launchpad.net/codewiki ?
[09:20]  * igc night all
[09:24] <lifeless> gnight
[09:46] <thumper> lifeless: I took a brief look, yes
[10:31] <lifeless> vila: ping
[10:33] <lifeless> mwhudson: do you know, is paste able to run on unix sockets ?
[10:38] <jelmer> lifeless: I ran an evolution git import overnight with profiling: commit_write_group(): 22%, add_inventory_by_delta: 10%, insert_record_stream (overall) 60%
[10:41] <jelmer> anyway, food for thought :-)
[10:41]  * jelmer goes back to soyuzy issues
[10:45] <Kinnison> mmm soyuz
[11:38] <thumper> how do I override create_signatures when calling workingtree.commit() ?
[11:39] <thumper> I want to get the committer from the config
[11:39] <thumper> but not sign
[11:39] <lifeless> pass in your own config object if you want to control that sort of thing
[11:39] <thumper> how do I create a config object?
[11:39] <lifeless> why don't you want the users signing policy to apply though?
[11:40] <thumper> lifeless: because I don't want a box popping up when editing a wiki page
[11:40] <lifeless> thumper: uhm
[11:40] <thumper> and I'm explicitly setting the committer
[11:40] <lifeless> thumper: give me more context, but this sounds like something you shouldn't be bothering with, to me.
[11:41] <lifeless> some folk may want signed wiki changes
[11:41] <lifeless> some folk won't, and bzr lets users choose
[11:42] <thumper> I'm making an executive decision for now
[11:42] <thumper> people can haul me up on it later
[11:42] <thumper> it bugs me
[11:42] <lifeless> thumper: so change your config
[11:42] <thumper> my local commits are always signed
[11:42] <lifeless> the default isn't to sign
[11:43] <lifeless> thumper: are your wikis in a specific subdir ?
[11:43] <thumper> currently it is
[11:43] <thumper> it'll always point to a branch though
[11:44] <lifeless> thumper: so, I suggest you set the signing policy in branch.conf when you create a wiki branch
[11:45] <thumper> ok, you've convinced me to at least make it an option
[11:45] <thumper> but the original question still stands
[11:45] <thumper> how to I override the config
[11:45] <lifeless> bzrlib.config has a number of config objects
[11:46] <thumper> thanks, I'll take a look
[11:46] <lifeless> I still say, don't do it.
[11:46] <lifeless> you're certain to regret it
[11:47] <thumper> I regret many things
[11:47] <thumper> :)
[11:47] <thumper> I already regret some code I wrote three days ago
[11:49] <Kamping_Kaiser> could someone look at this and say if it looks like a bzr bug? i type 'bzr ignoreb' and press tab. result is the paste here http://paste.debian.net/68133/
[11:51] <thumper> lifeless: if it is sign when required, when is it required?
[11:52] <lifeless> thumper: not implemented
[11:55] <james_w> Kamping_Kaiser: you have a conflict in /home/kgoetz/.bazaar/plugins/rewrite/commands.py
[11:56] <Kamping_Kaiser> james_w: thanks. is that a conflict between bzr and rewrite?
[11:56] <james_w> no
[11:57] <james_w> you edited the file at some point or something
[11:57] <james_w> and then did a pull and it put conflict markers in the file
[11:57] <james_w> so it's not valid python
[11:57] <james_w> so bzr crashes trying to load it
[11:57] <james_w> arguably that last bit is a bzr bug
[11:57] <james_w> but you can fix the issue by resolving any conflicts in /home/kgoetz/.bazaar/plugins/rewrite/
[11:59] <Kamping_Kaiser> james_w: i've never edited the file, but i'll make sure my branch is valid
[11:59] <Boobek> hi
[12:00] <Boobek> I have a question before I send a bug request:
[12:00] <Kamping_Kaiser> james_w: loads of conflict markers, reverting them fixes the tab issue. thanks :)
[12:00] <Boobek> can I make a branch from a launcpad project on my localdrive? (for example: bzr branch lp:slip-cover
[12:01] <thumper> Boobek: yes
[12:01] <thumper> that's one of the main points :)
[12:01] <Boobek> :)
[12:02] <Boobek> ok, but in bzr 2.1.1 i get the following output:
[12:02] <Boobek> http://paste.ubuntu.com/411555/
[12:03] <Boobek> it's normal?
[12:04] <thumper> Boobek: looks like you haven't told launchpad your ssh key
[12:04] <thumper> Boobek: but you have done a bzr lp-login
[12:05] <lifeless> gahk
[12:05] <lifeless> hg ships its own bindings to inotify
[12:06]  * thumper is done hacking for a friday night
[12:06] <Boobek> I told it from browser but this command isn't work
[12:07] <Boobek> I have the same output: http://paste.ubuntu.com/411559/
[12:08] <jelmer> thumper: how did the linux import go?
[12:08]  * thumper looks
[12:09] <jelmer> thumper: I don't see how many revs it's already done
[12:09] <thumper> about 65k revs
[12:09] <thumper> look at the most recent log
[12:10] <jelmer> thumper: where do you see that?
[12:10] <thumper> Boobek: ask in #launchpad and someone should help
[12:10] <thumper> http://staging.launchpadlibrarian.net/42124618/mwhudson-linux-trunk.log
[12:10] <thumper> https://code.staging.launchpad.net/~mwhudson/linux/trunk - see the log links
[12:10]  * thumper signs off
[12:10] <jelmer> thumper: That's what I'm looking at :-)
[12:10] <Boobek> thumper, thx
[12:11] <Boobek> join #launchpad
[12:11] <jelmer> Have a nice weekend thumper
[12:11] <thumper> jelmer: it started at around 215k revs, now down to 150k ish
[12:11] <thumper> jelmer: you too
[13:08] <jml> my records aren't good enough to file a proper bug
[13:09] <jml> but the way that bzr handles "conflicts" when deleting directories that contain non-versioned content just cost me quite a lot of time and inconvenience
[13:12] <lifeless> jml: there is a bug. its a real pain.
[13:13] <lifeless> jml: there is a plan too; I believe vila is working on it.
[13:31] <LeoNerd> Mmm... gotta love sshfs. I've double-mounted router -> server -> desktop via sshfs. bzr on my AMD64 2.2GHz desktop is still faster, over all that, than bzr natively on the AMD Geode 266 router.
[13:43] <hersonls> can i ignore all symlinks in a repo with .bzrignore?
[13:44] <bialix> .bzrignore is filenames pattern matching, not file kind pattern matching
[13:44] <lifeless> no, though that might be an interesting extension; some way to say that an ignore rule applies by kind
[13:48] <hersonls> exists another way to do this?
[13:58] <bialix> hersonls: one can write pre_commit hook to blacklist symlinks from commit?
[14:04] <hersonls> bialix, i go see in documentation how do this
[14:04] <hersonls> a pre_commit
[14:24] <SamB_XP> lifeless: so should someone make a ticket requesting that?
[14:26] <LeoNerd> Ugh... Why is Module::Pluggable soooooo slow?
[14:27] <LeoNerd> It takes 7 seconds on my slowtiny AMD Geode 233
[14:32] <LeoNerd> er... wrongchannel ;)
[14:33] <bialix> hersonls: you can look at the checkeol plugin
[14:33] <bialix> it has pre_commit hook check
[16:13] <orattue> Hey I am moving from a backup of an old repository to a new one and have run into a small problem when pushing the revision history.
[16:13] <orattue> http://pastebin.com/vZ8UPDkU
[16:14] <orattue> When I push to my new repo it becomes a working tree but I want to keep this a treeless repository. How could I achieve this?
[16:16] <fullermd> Just use remove-tree to get rid of it?
[16:17] <orattue> fullermd: perfect many thanks
[16:51] <lelit> hi all, is there a command to get rid (if at all possible!) of .bzr/obsolete_packs, after a branch taken out of svn?
[16:53] <MvG> Hi! I just noticed that RegistryOption.from_kwargs adds arguments to the help text in the order kwargs.iteritems() returns them, which seems to be arbitrary and in particular not the one they were given at invocation time. This yields to non-deterministic help texts, which shouldn't be a real problem but feels a bit ugly nevertheless. Opinions?
[16:55] <jelmer> MvG: I agree
[16:55] <jelmer> lelit: not yet afaik, other than rm -rf .bzr/repository/obsolete_packs
[16:55] <MvG> So maybe I should file a bug.
[16:56] <jelmer> MvG: or submit a patch :-)
[16:56] <lelit> jelmer: that's good enough, if its safe :)
[16:56] <MvG> jelmer: I'm not sure enough what the "right" approach would be. Alphabetical order? Or is there a way to get at the argument order of a **kwargs?
[16:56] <lelit> are those effectively garbage-able?
[16:57] <jelmer> lelit: generally, yes
[17:23] <MvG> Is there a proper way to include the help text of the alternatives of a RegistryOption in the generated help? RegistryOption.from_kwargs does that, but when I use a proper registry I don't see a way.
[17:35] <krisives-gearbox> Does bzr support scripts in .bzr/hooks ?
[17:48] <LarstiQ> anyone know where I should ask to have my two bazaar-vcs.org wiki users merged? (openid based and old style)
[17:53] <fullermd> I gave up and hoped to $DEITY I'd never have to change any of my settings.
[18:07] <LarstiQ> fullermd: well, I do :)
[18:21] <MvG> jelmer: For the record: Filed bug 559409, attached a branch and requested a merge.
[18:21] <MvG> I just hope such a trivial fix can do without NEWS item.
[18:40] <bialix> MvG: hi
[18:40] <MvG> bialix: hi!
[18:40] <bialix> I have a question on trac-bzr
[18:41] <bialix> MvG: https://answers.launchpad.net/trac-bzr/+question/106783
[18:41] <bialix> can you comment on that?
[18:42] <MvG> I wonder why I haven't seen a mail for this...
[18:43] <bialix> MvG: maybe because there is no answer contact set?
[18:43] <MvG> Probably.
[18:43] <bialix> I'm not sure how this part of LP supposed to work
[18:44] <MvG> Grrrr! news_merge seems to be causing backtraces.
[18:47] <marcingy> hi - just wondering if there is anyway to prevent a file being committed as part of a bzr commit command. The file is part of the tree but I have a need for a specific local change for testing purposes that doesn't need to be committed to the trunk ever. and I don't want to have to cotinually remember to enter bzr commit .
[18:48] <bialix> MvG: for bzr-explorer we have answer contact set to bzr-explorer-dev group, and therefore we get notifications on the questions and answers
[18:49] <bialix> marcingy: maybe you need to use loom or pipeline plugin to keep your changes in separate place?
[18:49] <MvG> Now that I've reported bug 559436 I can return to that question...
[18:55] <LarstiQ> marcingy: that, or consider commit -x
[18:55] <marcingy> thanks and I'll go and have a look at loom and pipeline
[18:58] <MvG> bialix: answered.
[18:59] <bialix> thx
[18:59] <bialix> heya LarstiQ ! how are you?
[19:02] <LarstiQ> bialix: heya! :) Done well with studies so far, but pressure building up again with several deadlines
[19:03] <bialix> are you planning to attend UDS?
[19:03] <LarstiQ> ah, there is one coming up again I guess
[19:03] <LarstiQ> bialix: no, not so far
[19:04] <bialix> I understand
[19:05]  * LarstiQ has been focusing on studying, little time for anything else
[19:05] <LarstiQ> bialix: ah, and I still have lectures and one exam in that week, so no
[19:05] <LarstiQ> bialix: how about you?
[19:06] <bialix> I'll be there
[19:06] <bialix> first time to meet all legendary bzr hackers
[19:07] <LarstiQ> cool :)
[19:07] <bialix> yeah :-)
[19:08] <fullermd> _all_?  Better hope an asteroid doesn't choose that time and place to fall on...
[19:09] <bialix> fullermd: if there won't be you then of course not all, but many
[19:10] <LarstiQ> or one very big bus
[19:11] <fullermd> Legendary bzr hacker?  Me?  I guess that's true...   my great bzr hacks never really happened, which makes them pretty dang legendary   :p
[19:11] <LarstiQ> bialix: will you be in Brussels the weekend after UDS?
[19:12] <bialix> fullermd: common, I'd like to meet you anyway, you adding the charm to this channel :-)
[19:13] <bialix> LarstiQ: no, fly away at Saturday
[19:13] <fullermd> Well, exactly.  If I went somewhere, what would the channel do while I was gone?   8-}
[19:13] <bialix> LOL
[19:13] <bialix> that's true, silly me!
[19:14] <fullermd> Have a sprint in my backyard, I'll be there.
[19:14] <fullermd> It's beautiful this time of year, and for probably at least another week, or even two.  Then it gets mother-letching hot and miserable.
[19:15] <bialix> what it means "mother-letching"?
[19:17] <LarstiQ> bialix: ok, I'll see if I can maybe be there on Friday evening then
[19:17] <fullermd> It's a content-free emphatic.  A polite euphemism for a more profane way of saying it.
[19:17] <bialix> ok, got it
[19:18] <fullermd> ...  OK, not especially polite, but at least politER.
[20:32] <MvG> Is someone around here empowered to make me either an additional or the sole owner of the LP trac-bzr-team?
[21:07] <lifeless> MvG: its owned by ~bzr
[21:07] <lifeless> MvG: so I could transfer ownership, but why? Perhaps administrator is what you want?
[21:34] <jelmer> MvG: thanks (for filing that bug report about option ordering)
[21:44] <MvG> lifeless: Dunno what the difference between ownership and admin is. I only realized that I couldn't make the team the answer contact, and assume it's due to missing privileges. You could make me admin, see if that helps.
[23:48] <mwhudson> lifeless: i don't know, sorry
[23:56] <dark_soul> how do we change the commiter name? without having to reininstall