[00:08] <jasonlife> Do I create one repo per project? or one repo for all projects ?
[00:08] <jasonlife> Do I have to
[00:08] <bob2> either
[00:09] <bob2> there's no storage-space benefit to the latter
[00:11] <jasonlife> Is there no right way to maintain repo and project?
[00:12] <jasonlife> If I have just one repo, then it ends up with a lot of projects and their different branches in one place.. so it may be bad..
[00:13] <bob2> who cares?
[00:13] <jasonlife> :P
[00:14] <jasonlife> bzr maintains different directories for different branches of same project.. right?  I'm new to bzr..
[00:15] <bob2> a branch is a directory
[00:15] <jasonlife> in cvs, it maintains only one directory even if I created multiple branches..
[00:15] <jasonlife> that's why I'm wondering..
[00:16] <Peng> The benefit of repo-per-project is if projects use incompatible repo formats, or if you want to delete a really large one or something.
[00:19] <jasonlife> and I can use shared repo feature with different branches of same project I guess.
[00:20] <Peng> Yes. THat is what it is for.
[02:01]  * igc lunch
[02:08] <AfC> lifeless: I'm very intrigued by your commitfromnews plugin
[02:09] <lifeless> AfC: cool
[02:16] <MTecknology> With subversion you can proxy the traffic through apache so you can have pretty fine grained control over who can access what. Is there any easy way to do this with bzr? I was looking at the launchpad code to get an idea but that's pretty hard for me to understand and follow
[02:19] <AfC> lifeless: Since most people can't be bothered (or taught, it seems) to write "good" commit messages, and since commit messages aren't editable in Bazaar, I've been increasingly down on them as a change log for a code base.
[02:19] <AfC> lifeless: but the prospect of people editing ChangeLog files explicitly doesn't appeal much either (since merging branches with {NEWS, ChangeLog} type files is a nightmare)
[02:20] <AfC> lifeless: your plugin makes me think that maybe the two together might be ok (as people could see the ChangeLog and be more likely to follow its patterns; and meanwhile the log|visualize view of history isn't completely useless
[02:21] <AfC> lifeless: I realize full well that your plugin was for a file called NEWS, but it got me thinking.
[02:21] <AfC> [I know, I know, thinking without a licence. Scary, this free market economy]
[02:25] <lifeless> AfC: the plugin could be easily extended to support other file names.
[02:25] <AfC> lifeless: no doubt
[02:25] <lifeless> MTecknology: there is a thing in contrib
[02:25] <lifeless> MTecknology: or unix file permissions
[02:25] <AfC> lifeless: (it's the wisdom of it all that I'm mulling over)
[02:25] <lifeless> MTecknology: or you can hook into it
[02:25] <lifeless> AfC: so I wrote it because I've never liked 'bzr log' as a way toget a human meaninful summary of what has happened in a code base.
[02:26] <lifeless> even if the commit messages are perfect, some changes union
[02:26] <lifeless> e.g.
[02:26] <lifeless> rev N, add feature
[02:26] <lifeless> rev N+M, change feature to be better
[02:26] <lifeless> rev N+M+Z do a release: but we should only mention feature /once/.
[02:27] <AfC> lifeless: yeah
[02:28] <AfC> lifeless: I'm not sure if this is what you're doing, but I'm guessing that in such a NEWS file × your plugin, the diff would show up at each merge up the chain of gatekeepers
[02:28] <lifeless> indeed
[02:28] <lifeless> and when doing a commit myself, I write the one for N
[02:28] <AfC> lifeless: that would be good; one of my beefs is that I spend a lot of time writing the damn mainline merge commit messages; all the other bastards get away with one liners.
[02:28] <lifeless> for N+M, I edit the NEWS entry
[02:28] <lifeless> and the plugin gives me the edit, which I then tweak to say 'improved thing from N'
[02:29] <lifeless> give it a spin
[02:29] <AfC> [not the terms of warmth and affection for the wonderful contributors to the open source project I am the maintainer of]
[02:29] <AfC> s/not/note
[02:29] <AfC> lifeless: in my case, NEWS is hand-crafted public release note, ChangeLog doesn't exist (based on our drooling enthusiasm of the early days of DVCS that we wouldn't need one anymore).
[02:30] <lifeless> sure.
[02:30] <AfC> lifeless: I don't think I need *revision* resolution in a ChangeLog file, but a features, API changes, etc aggregation would be useful indeed
[02:30] <lifeless> would you like a config option to set the filename
[02:30] <lifeless> or just have it grab stuff from both ChangeLog and NEWS ?
[02:30] <AfC> lifeless: anyway, thought I'd give you some surface level first impression feedback
[02:30] <AfC> lifeless: probably both?
[02:30] <lifeless> AfC: I just ordered a new laptop :)
[02:31] <lifeless> i7, 2 cores w/hyperthreading.
[02:31] <lifeless> the bit that I possibly went overboard on, is memory and disk.
[02:31] <AfC> lifeless: (NEWS file only gets tweaked in the final weeks before a release; on the other hand, what's really missing is a «changes» record of "what a branch actually introduces (feature, bugfix, whatever))
[02:31] <lifeless> 8G, and a 128GB SSD
[02:31] <AfC> nice!
[02:32] <lifeless> yeah
[02:32] <lifeless> lenovo have about 35% off at the moment
[02:32]  * AfC is undecided on whether or not an SSD would be a good idea for him or not
[02:33] <AfC> what I'd *really* love is an SSD for the /, /usr type stuff, and a fast spinnning HD for the dynamic and temporary stuff (ie, compiling fallout, web browser cache crap, etc). If I'd bought a 17" monster with 14,000 cores and two drive bays I coulda done it
[02:34] <AfC> but with an itty bitty 12" with one drive bay and a ULV chip, no room for me. Not even a PCMCIA slot :)
[02:35] <lifeless> mine is 12", ulv
[02:35] <RAOF> They do ulv i7s now?
[02:35] <lifeless> yup
[02:35] <lifeless> and i5's (can be better than i7 at the same clock rate), and i3's
[02:36] <lifeless> http://www.notebookreview.com/default.asp?newsID=5546&review=lenovo+thinkpad+x201+x201s+tablet
[02:36] <lifeless> the x201s is what I ordered
[02:36]  * RAOF is a big fan of his x200s
[02:37] <lifeless> RAOF: now they do touchpads, I'm happy ;)
[02:37] <lifeless> AfC: i7-620LM - the L is the low component, m is mobile
[02:37] <RAOF> Oh, it's got a touchpad now?  Hm.
[02:37] <lifeless> AfC: i7-xxxM is mobile - all the voltages have shifted around:P
[02:37] <lifeless> RAOF: optional
[02:38] <lifeless> RAOF: depending on model, the x200t always has it, I believe.
[02:38] <lifeless> sory, 201t
[03:04] <MTecknology> there's a bzr-email package in the repos. how does a person use that?
[03:12] <lifeless> if you install it and type 'bzr help email' it has online docs
[03:13] <MTecknology> lifeless: awesome, thanks :)
[03:59] <poolie> hi all
[04:00] <lifeless> hi
[04:44] <parthm>  /leave
[04:52] <poolie> igc, hi?
[04:52] <igc> hi poolie
[04:53] <poolie> just wondered if you were around
[04:53] <poolie> i'm in the middle of something atm but wanted to chat
[04:53] <poolie> missed you before
[04:53] <igc> np
[04:58] <lifeless> I wish the bash completion knew about the switch sarch path
[05:00] <poolie> igc, how about now?
[05:00] <igc> poolie: sure
[05:00] <poolie> i was thinking about bzr-grep vs your 'product as platform' thing
[05:01] <poolie> i'm a bit ambivalent about whether to merge it into bzr core or make it a platform
[05:02] <igc> poolie: hmm
[05:02] <poolie> the easy answer is to just let the author decide
[05:02] <poolie> there are pros and cons
[05:02] <igc> I haven't been following the discussion to be honest
[05:03] <poolie> so, the details don't particularly matter
[05:03] <lifeless> poolie: btw, if you want bzr-plugin-info in core; please just merge it
[05:03] <lifeless> I don't object, but don't have cycles atm
[05:03] <poolie> but we have some new code that could be either a plugin or builtin
[05:03] <poolie> lifeless: yes it applies to that too, though it's arguably a special case cause it helps with bootstrapping
[05:03] <poolie> maybe i should just post to the lisnt
[05:03] <lifeless> poolie: yes; I'm not proposing that you treat all things the same way ;)
[05:04] <lifeless> poolie: I'm specifically saying not to wait for me.
[05:04] <spiv> poolie: drive by opinion: I think grep would be good to have in core.  I haven't carefully considered, it's just my initial reaction to the idea.  (Although maybe users will have a similar initial reaction?)
[05:04] <igc> poolie: my initial reaction to "grep" is that it probably ought to be in core
[05:04] <spiv> igc: snap!
[05:04] <poolie> :)
[05:05]  * spiv wanders off
[05:05] <igc> hi spiv! :-)
[05:05] <lifeless> w.r.t. grep, as a special request - consider making sure its hookable-enough for bzr-search to kick in when possible.
[05:05] <lifeless> may be a YAGNI.
[05:05] <spiv> igc: hi :)
[05:05] <spiv> lifeless: interesting idea, probably a case of "land it first, refactor as necessary later", though?
[05:06] <igc> poolie: is a 5 min phone call possible?
[05:06] <poolie> eminently posssible
[05:06] <igc> poolie: I'd like a quick chat re the windows installers, ec2, etc.
[05:06] <poolie> call me?
[05:09] <igc> poolie: sure
[05:25] <lifeless> heh - cheap but humorous http://www.makeuseof.com/tech-fun/quick-glance-into-apples-future-pic/
[05:30] <mwhudson> wow, bzr-svn is quite complicated
[05:32] <lifeless> ...
[05:35] <mwhudson> just randomly griping
[05:35] <mwhudson> it wasn't totally obvious to me what a CachingRevisionMetadata was
[05:56] <mwhudson> also the tests take ages and fail with the bzr i have installed
[05:56]  * mwhudson tries bzr.dev
[06:24] <GaryvdM> Hi igc
[06:24] <igc> hi garyvdm!
[06:24] <igc> garyvdm: thanks for the numerous bug fixes to treewidget
[06:25] <GaryvdM> :-)
[06:25] <GaryvdM> igc: I made some big improvements to the treewidget tests last night
[06:26] <igc> GaryvdM: that's great news
[06:26] <igc> GaryvdM: I'm wondering whether the additioal filtering I'm doing in epxlorer is triggering some issues
[06:26] <GaryvdM> igc: Maybe that will make it possible to easily write a test for Bug 529985
[06:27] <igc> hopefully
[06:27] <GaryvdM> igc: Let me have a look at the be code
[06:28] <igc> GaryvdM: lib/wt_browser.py
[06:32] <poolie> lifeless: i have a draft message here about patch pilots vs just helping people
[06:32] <poolie> to emphasize that there's "help people" and then "staff committing to do this as a timeslice"
[06:33] <lifeless> cool
[06:33] <poolie> do you want me to finish/send it
[06:34] <lifeless> I think its worth teasing the issues apart
[06:34] <lifeless> if you think the mail will help with that, then you should send it
[06:34] <poolie> ok
[06:34] <GaryvdM> igc: ha ha
[06:34] <GaryvdM> >                # This locks and unlocks the tree each time.
[06:34] <GaryvdM> >                # I wonder how that impacts performance?
[06:34] <GaryvdM> igc: Badly!
[06:35] <poolie> lol
[06:37] <GaryvdM> igc: The code in _QBrowseFilterProxyModel could be better a taking advantage of TreeFilterProxyModel.
[06:39] <GaryvdM> igc: ie, if you overwrite filter_id rather than filterAcceptsRow, then you don't have to worry recursive loading, caching, and showing parents for children that are shown.
[06:40] <GaryvdM> igc: I'll fix that for you.
[06:41] <igc> GaryvdM: I'm just in the middle of something right now so I can't take a look. Is there any chance you could submit a MP or fire me an email with an explanation of what I need to do?
[06:41] <GaryvdM> Sure
[06:41] <igc> thanks
[06:49] <lifeless> poolie: around?
[06:49] <lifeless> poolie: if so, up for a quick call?
[06:50] <poolie> let me finish this first pls
[06:50] <poolie> 5m
[07:04] <vila> hi all
[07:06] <igc> hi vila
[07:20] <poolie> hello vila
[07:20] <poolie> how are things
[07:20] <vila> fine
[07:21] <vila> slowly making my way in the review queue
[07:22] <vila> I was wondering about https://code.edge.launchpad.net/~parthm/bzr/138600-2.1-mkdir-should-fail-on-invalid-parent/+merge/20199
[07:22] <vila> Should we land it in 2.0 and 2.1 ?
[07:22] <vila> What's your opinioin ?
[07:22] <vila> onion even
[07:22] <vila> bah typos
[07:23] <poolie> my opinion: thanks but no
[07:23] <poolie> not severe enough for 2.1
[07:24] <vila> ha good, just the nudge I was waiting for :) I was 60% / 40% myself (for the same reasons)
[07:26] <vila> my main reason was to minimize the SRU related overall patch size, so the autopack bug from jam was ok but the mkdir should clean wasn't
[07:27] <poolie> k
[07:27] <poolie> explain nicely and i'm sure parthm won't be offended
[07:28] <vila> k
[07:29] <vila> Regarding the grep plugin though, I'm for landing into core (but still as a plugin)
[07:29] <vila> likewise for plugin-info
[07:30] <vila> I don't want to merge *any* plugins, but these two are exceptions :)
[07:30] <parthm> poole: i won't be offended :-)
[07:31] <lifeless> vila: I'm not really fussed on either; I think plugin-info has good reason to be outside [the case for updating preferred-lists without doing new releases of bzr itself]
[07:31] <vila> parthm: Ha great ! :)
[07:31] <poolie> lifeless: actually in that case possibly it's the list itself that should be separately updated
[07:32] <vila> lifeless: hmm, I'm tempted to say you can still install locally to override but...
[07:32] <vila> lifeless: Are you sure it will be updated *that* often (after some initial period) /
[07:32] <vila> ?
[07:34] <vila> lifeless: I think plugin-info is targeted at users who don't know the ecosystem well and as such are unlikely to install it
[07:34] <poolie> that's the thing
[07:35] <vila> may be the preferred-lists can be updated on demand without updating the plugin itself ?
[07:38] <vila> 12GB and thrashing.... wth ?? I can't believe that with 10.5GB active and 1.4G swap used there are enough processes swiping their entire memory space.... :-/
[07:44] <poolie> running what?
[07:44] <poolie> i'd like to help with reviews but it's been an awfully interrupted week and looks set to continue
[07:45] <vila> poolie: my desktop (including babune), no clear culprit to point my finger at, I'mm also running a bunch of emacses and firefox and whatnot
[07:46] <vila> That's fine, I nudge people when needed
[07:47] <vila> it also seems that runinng the test consume more memory that it used too, just a feeling across the various OSes, may just be yet another consequence of the leaking tests
[07:58] <lifeless> vila: poolie: I'm not arguing for or against particulary.
[07:59] <vila> lifeless: ok, I see your point anyway
[08:02] <vila> GaryvdM: ping
[08:02] <GaryvdM> vila:pong
[08:02] <vila> poolie: did you process GaryvdM's key for pqm
[08:02] <vila> GaryvdM: https://code.edge.launchpad.net/~garyvdm/bzr/commit-BoundBranchOutOfDate/+merge/20393 any problem to send that to pqm ?
[08:03] <poolie> vila, GaryvdM, sorry, no
[08:03] <poolie> it's flagged but i haven't done it yet :-(
[08:03] <poolie> vila can you see if there's a typo or something, otherwise ping a sysadmin or send a signed rt
[08:03] <GaryvdM> vila: I would like to do it myself :-) poolie: I'm not in a rush
[08:04] <vila> GaryvdM: to you want me to merge it or do you still want to use it to test pqm ?
[08:04] <vila> poolie: typo where ?
[08:07] <vila> poolie: is there an url to look at pending RT requests ?
[08:12] <poolie> GaryvdM, vila, there is already an rt for this, 35953
[08:12] <poolie> claims to have been done
[08:12] <poolie>  DCA3 ACB2 0CC7 D6D4 6100 18E6 77FD C477 018A 3A1D
[08:12] <GaryvdM> I'll retry then :-)
[08:12] <poolie> is that you?
[08:12] <vila> GaryvdM: give a try and let us know
[08:12] <vila> good
[08:13] <GaryvdM> poolie: how do I check that?
[08:13] <poolie> GaryvdM: remove the trailing slash from the destination url
[08:13] <poolie> nm, it is you
[08:13] <poolie> pqm is bizarrely pedantic
[08:15] <vila> GaryvdM: and use submit_branch = http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev
[08:18] <poolie> i think that's the problem
[08:21] <GaryvdM> vila, poolie: Cool that worked.
[08:22] <GaryvdM> But I got a NEWS conflict
[08:22] <poolie> welcome :)
[08:22] <GaryvdM> :-)
[08:22] <poolie> not sure what's up with that
[08:22] <poolie> better ask spiv tomorrow
[08:22] <poolie> for now, merge trunk and resubmit
[08:23] <vila> GaryvdM: be sure to insert your netry sorted
[08:24] <GaryvdM> ack
[08:47] <GaryvdM> vila: http://pqm.bazaar-vcs.org/ says the test for my patch is stuck on 0%. Is this normal?
[08:48] <vila> GaryvdM: yes. :-/
[08:48] <GaryvdM> ok
[08:48] <vila> It's not stuck, the progress report is bogus
[08:49] <GaryvdM> I see
[08:49] <vila> lifeless: I thought you fixed that ^ recently ?
[08:50] <vila> GaryvdM: the important bit is that it accepted your request, now you'll get a feedback mail titled either 'success' or 'failure'
[08:50] <vila> the later came with a full output
[08:50] <GaryvdM> vila: yes - that is cool. :-)
[08:52] <GaryvdM> Now that I can submit to pqm, I'm going to have to do *mini*-patch-pilot duties. :-)
[08:53] <vila> GaryvdM: Welcome !
[08:57] <lifeless> vila: no, poolie added it.
[08:57] <lifeless> vila: its doing a progress bar
[08:57] <lifeless> vila: once spm: / lamont
[08:57] <lifeless> vila: once spm: / lamont: get the python-subunit package in the bzr chroot on balleny sorted out, we can move forward.
[08:57] <vila> ha, ok
[08:58] <vila> losa: ping, thanks in advance ^ :)
[08:58] <lifeless> vila: there is an rt, its non trivial
[08:58] <vila> yeah,kidding
[08:59]  * vila rejoices that it installed subunit once for all babune slaves :)
[09:07]  * lifeless goes blind
[09:07] <lifeless> python code written in 2007, that doesn't use optparse
[09:07] <lifeless> or getopt
[09:07]  * vila sends some perl to lifeless 
[09:09] <poolie> GaryvdM: your branch merged, yay
[09:14] <vila> GaryvdM: Congrats ! :D
[09:24] <GaryvdM> Yay. Thanks for the help.
[09:24] <GaryvdM> Bye. Need to focus on work
[09:51] <Peng> Eh, optparse is a pain. Every time I use it, I have to find the last script I wrote that uses it and still read the docs. For a quick hack with only one or two options, it's not worth the effort.
[09:52] <Peng> Once it gets more complicated than that, it's definitely worth switching to optparse, but before that? Eh.
[09:53] <Peng> s/find/copy and paste from/
[09:54] <distatica> I'm trying to follow http://doc.bazaar.canonical.com/bzr.2.1/en/tutorials/centralized_workflow.html But I have a problem, when I use checkout and then commit it uploads as expected but clobbers the existing dir with my new group + permissions, making it unaccessible to other members of the group.
[09:55] <distatica> is there a way to stop the permissions from being written? Prefer something that doens't need to be included every commit if possible.
[09:55] <fullermd> On a SysV filesystem, you need g+s on the dir to preserve the group ownership.
[09:55] <distatica> oh, thank you
[09:56] <fullermd> bzr doesn't touch the group, so that's all in the filesystem.
[09:56] <fullermd> The perms (e.g., g+w) bzr does, based on...  uh...  some dir.
[09:56] <fullermd> I just g+w everything under .bzr/
[09:58] <lifeless> Peng: optparse is less code @ 2 options
[09:58] <Peng> lifeless: Yes, but it's code I have to look up first.
[09:58] <lifeless> Peng: even if it wasn't, getopt would be better than a manual parser
[09:58] <lifeless> Peng: you've been spoilt by bzrlib :)
[09:58] <Peng> I've forgotten how to use getopt after spending time with optparse! :(
[09:58] <Peng> So I have to look it up too!
[09:59] <lifeless> check out gtester-report
[09:59] <fullermd> You could just compromise and use Getopt::Std   8-}
[09:59] <lifeless> fullermd: acgggrle
[09:59]  * fullermd sneaks back under his bridge.
[10:11] <Peng> In my most recent manual option parsing abomination, I _was_ using optparse. I was just doing it in a really stupid way and optparse could handle it much more simply.
[10:20] <distatica> thanks again fullermd, g+s fixed it perfectly.
[10:48] <parthm> vila: hi.
[10:48] <vila> parthm: hey
[10:49] <parthm> so i was looking at bzrlib/plugins. whats needed to put a plugin there. seems like just a copy. right?
[10:49] <lifeless> Peng: do you mean to merge to core?
[10:49] <lifeless> bah
[10:49] <lifeless> parthm: ^
[10:49] <lifeless> parthm: or do you mean to install it ?
[10:49] <parthm> yes. i was talking in context of vilas comment on https://code.launchpad.net/~parthm/bzr/503670-grep-builtin/+merge/20420
[10:50] <vila> parthm: well, as a plugin, you need to register (lazily) the command and put your files under bzrlib/plugins yes
[10:50] <parthm> iiuc i need to put the relevant files in trunk/bzrlib/plugins/grep/*
[10:50] <vila> yes
[10:51] <lifeless> oabzr branch lp:bzr-plugin-info
[10:51] <lifeless> parthm: ^
[10:51] <lifeless> copy the setup.py from there
[10:51] <lifeless> change appropriately.
[10:51] <parthm> lifeless: sounds fine.
[10:51] <lifeless> or grab the sample from the developer docs
[10:51] <parthm> one thing which came up was that the advantage of a plugin is that it can be used by 2.0/2.1 users.
[10:52] <lifeless> I like plugins
[10:52] <lifeless> my default is 'plugin' ;)
[10:52] <parthm> does bzr provide a way for someone to checkout just bzrlib/plugins/foo?
[10:52] <parthm> :)
[10:52] <vila> parthm: your call, there is no urgency into merging into core
[10:53] <lifeless> parthm: not really; there is views
[10:53] <lifeless> but plugins in core are generally not maintained with backwards compat in mind.
[10:53] <vila> parthm: I think maturing as a plugin for a couple of months is a good plan (and 2.0 users will love you too :)
[10:53] <parthm> yes
[10:53] <lifeless> there is my branch somewhere to include arbitrary plugins in the tarballs we make
[10:53] <lifeless> but that had a bug and noone fixed it
[10:54] <parthm> vila: :-) ... yes that sounds fine to me too.
[10:54] <vila> parthm: in that case mark your mp as rejected and create a new one when you feel ready
[10:54] <parthm> vila: ok.
[10:56] <parthm> so as suggested i will continue to bzr-grep as a plugin for sometime and improve it based on feedback.
[10:57] <parthm> maybe the bzr packaging (tar or installer) step should have a step to pick specified plugins to package them.
[10:57] <parthm> i think linux users are ok but i suspect windows users may not bother installing plugins manually.
[10:57] <parthm> thats the adv of prepackaged plugin vs external plugins
[10:58] <vila> parthm: file a bug against bzr-windows-installer and osx asking for inclusion
[10:58] <parthm> vila: will do.
[10:58] <parthm> is there a way for including it in the source tarball thats released? or maybe getting it listed in synaptic?
[10:59] <parthm> i typically pick up my plugins from synaptic and don't bother manually installing.
[10:59] <lifeless> parthm: to include it in the source tarball, see the branch I wrote to do just that; its around somewhere.
[10:59] <lifeless> problemis that it doesn't call into setup.py in each plugin.
[11:00] <lifeless> parthm: to list it in synaptic, package the plugin and get someone on the debian plugins team to upload it to debian
[11:00] <lifeless> we can sync it from there to Ubuntu a day layer
[11:00] <lifeless> *later*
[11:01] <parthm> lifeless: ok. i can try to do it after a few weeks when the plugin has had some time to mature.
[11:02] <parthm> in the mean time i will add setup.py. how does bzr-plugin-info work, where does it get the plugin list?
[11:02] <lifeless> parthm: from cached.py' bzr plugin-info --python URL URL URL .... > cached.py is how that is updated.
[11:03] <parthm> lifeless: and URL is lp:bzr-xxx?
[11:03] <lifeless> yes
[11:04] <parthm> vila: maybe good to keep https://code.launchpad.net/~parthm/bzr/503670-grep-builtin/+merge/20420 open for some time. basically i am looking for review inputs. it can be rejected after review.
[11:04] <parthm> lifeless: thats sounds good.
[11:05] <lifeless> parthm: if you want review on the plugin; I suggest:
[11:05] <lifeless> bzr init an empty branch
[11:05] <lifeless> bzr push that to lp:bzr-grep (if vila will accomodate you :))
[11:05] <lifeless> then submimt your branch to lp:bzr-grep as a merge proposal
[11:06] <parthm> lifeless: ah. ok. thats sounds like a better way. i will try that.
[11:06] <vila> lifeless: parthm vreated lp:bzr-grep :)
[11:07] <parthm> vila: :-) in that case we can probably reject the mp. i will raise a review request against lp:bzr-grep.
[11:07] <vila> but adding more devs to it would be good... what the right team ? ~bzr ?
[11:07] <vila> parthm: great
[11:07] <parthm> vila: will do.
[11:11] <parthm> so for lp:bzr-grep, should i just change 'maintainer' to bzr-core and add myself as 'driver'. so apart from bzr-core will i also have commit permissions.
[11:15] <lifeless> not bzr-core
[11:16] <lifeless> bzr
[11:16] <lifeless> and you should be in bzr anyhow
[11:16] <lifeless> bzr-core is actually 'just bzr not plugins'
[11:16] <lifeless> its confusing
[11:16] <parthm> lifeless: ok.
[11:17] <parthm> lifeless, vila: done. 'bazaar developers' are not listed as maintainers for lp:bzr-grep.
[11:17] <lifeless> don't set a driver either
[11:18] <parthm> lifeless: but won't i lose commit rights to lp:bzr-grep that way?
[11:18] <lifeless> join ~bzr
[11:18] <lifeless> driver doesn't do what you might think it does
[11:18] <lifeless> it has no influence on commits
[11:19] <lifeless> the url - lp:~TEAM/bzr-grep/branchmae
[11:19] <lifeless> the TEAM there is what controls commits
[11:20] <parthm> lifeless: ok. looks like i lost the rights to change the driver of lp:bzr-grep maybe you could remove my name from there https://launchpad.net/bzr-grep
[11:22] <parthm> lifeless: so to join team bzr, do i send a message via "contact team's owner"?
[11:22] <lifeless> parthm: I've added it to the 'bazaar' project group
[11:22] <lifeless> parthm: no, you click the join this team link
[11:22] <lifeless> I've also added 'bzr plugin' to the description
[11:23] <lifeless> I hope thats ok
[11:24] <parthm> lifeless: sorry this is taking so long. i can't seem to find the 'join this team' link on https://launchpad.net/~bzr
[11:25] <lifeless> bah
[11:25] <lifeless> its set to restricted
[11:25] <lifeless> I'll talk to poolie about this friday
[11:25] <lifeless> for now
[11:25] <lifeless> whats your lp username
[11:25] <parthm> its parthm.
[11:31] <parthm> lifeless: looks like it worked. thanks for your help.
[11:32] <parthm> vila: the grep mp can probably be rejected, i will raise an empty one against lp:bzr-grep.
[11:33] <vila> parthm: I think you can reject yourself (or something is broken otherwise), let me know if you can't (I'm curious)
[11:36] <parthm> vila: i can't seem to find a way to reject it. should it be listed in the "Review:" dropdown?
[11:37] <vila> parthm: in the status at the top of the page
[11:38] <vila> parthm: found it ? Click the little yellow pencil otherwise
[11:38] <parthm> vila: ok. that worked. thanks.
[11:38] <vila> parthm: great !
[11:39] <vila> haaaa, https://code.edge.launchpad.net/bzr/+activereviews done to 10 mps with 4 ready to land, go bzr devs :D
[11:39] <parthm> vila: cool :-)
[11:40] <parthm> vila, lifeless: thanks for your help. got to go. have a nice day.
[12:55] <davidstrauss> How can I convert from svn to bzr and filter out some files?
[13:08] <igc> night all
[13:30] <jelmer> davidstrauss: convert from svn to bzr first, then use fast-export/fast-import's filter-branch to remove those files
[13:30] <parthm> hello. i am trying to add binary support (ignore binary) to bzr-grep. https://bugs.launchpad.net/bzr-grep/+bug/531336
[13:31] <parthm> my initial thought is to catch UnicodeDecodeError and print a message that its a binary file and move on to the next one.
[13:31] <parthm> i am not too familiar with unicode. does that seem like a reasonable fix?
[13:32] <parthm> it will certainly be faster than looking for \x00 in the first few lines.
[13:32] <davidstrauss> jelmer: thanks :-)
[13:56] <parthm> nevermind. i did the fix using textfile.text_file which is very convenient.
[14:23] <parthm> vila: ping
[14:25] <vila> parthm: pong
[14:25] <parthm> vila: hi. I am going through your comment 'I think we put new features into bzrlib.test.features instead.'  on https://code.launchpad.net/~parthm/bzr/262450/+merge/19483
[14:26] <parthm> does this mean i take the _PosixPermissionsFeature and the following assignment and move it to tests.features?
[14:26] <parthm> there aren't any other classes there so i was a little confused.
[14:27] <vila> parthm: yes. Sorry for that, as often when we change some coding rule we haven't apply that one in the whole code base
[14:27] <parthm> vila: ok. thanks for the clarification. i am closing the review comments now.
[14:30] <parthm> vila: i see lines like 'subunit = tests.ModuleAvailableFeature('subunit')'. does my code just to be moved (and Feature) class imported or do i need to do something more?
[14:30] <vila> just move the code and update the imports so that the tests use 'features.PosixPermissionFeature'
[14:31] <parthm> vila: ok.
[14:34] <davidstrauss> jelmer: How can I specify multiple exclude_paths? It's not anywhere in the documentation>
[14:35] <jelmer> davidstrauss, I'm not myself familiar with bzr-fastimport/bzr-fastexport unfortunately :-?
[14:39] <davidstrauss> How can I get Paramiko to use a custom SSH private key location? (Not the default of .ssh/id_rsa or .ssh/id_dsa)
[14:41] <luks> davidstrauss: does Paramiko even use .ssh/id_rsa/dsa?
[14:41] <luks> I thought it only supports the Putty key agent
[14:41] <davidstrauss> luks: This is on Mac OS X
[14:42] <luks> oh
[14:42] <luks> why not use openssh then?
[14:42] <davidstrauss> luks: I can.
[14:42] <luks> you can set the key in ~/.ssh/config then
[14:44] <luks> (Host example.com\n    IdentityFile /path/to/private/key)
[14:46] <MTecknology> There's bzr-email. I read the help for it 'bzr help email' but I still don't understand how to set the configs it's referring to.
[15:00] <MTecknology> hrm... Can I set those values in $HOME/.bazaar/bazaar.conf on the remote server?
[15:00] <MTecknology> * that I'm pushing the code to
[15:01] <Raim> if you can open a ssh session, yes...
[15:01] <Raim> I mean, a shell :)
[15:02] <MTecknology> Raim: I mean for the bzr-email plugin. I don't know if I need that set local or remote; now that I know what file I need to set those in
[15:03] <MTecknology> I suppose now that I have a clue I can just try it to :P
[15:22] <stani> When i merge branch B into branch A and commit the changes to branch A, all the commits of branch B become one commit in branch A. Is there an easy way to transfer the commits of branch B as individual commits to branch A while merging?
[15:22] <vila> stani: the commits are still there as inidividual commits, try 'bzr log -n0'
[15:23] <vila> or bzr qlog
[15:23] <stani> thanks, can i diff them?
[15:26] <stani> vila: thanks, I think i know how
[15:29] <vila> stani: bzr diff -caaa.b.c should do the trick once you get the revnos from the log (or clicking at the right place in qlog)
[15:35] <bialix> hi all
[15:36] <bialix> I have a question about hooks
[15:36] <bialix> there is open hook
[15:36] <bialix> can I setup new hooks from open hook?
[15:36] <bialix> say, I have config in a branch which tells me about other hooks
[15:37] <bialix> then I would like to setup in runtime required hooks based on this config
[15:37] <bialix> is it possible
[15:37] <bialix> ?
[15:41] <vila> bialix: I don't think that's the expected usage
[15:41] <bialix> hi vila
[15:41] <vila> bialix: you install hooks and then you can tests whether they apply or not instead
[15:41] <bialix> I want to make universal hooks launcher
[15:41] <vila> s/can tests/can test/
[15:42] <bialix> but I don't want to install every possible hook
[15:43] <vila> define universal hooks launcher ?
[15:43] <bialix> I'm put the script into the tree under version control
[15:44] <bialix> and I need the way to laucnh this script on hook
[15:44] <bialix> say I have python module in my tree with hook implementation
[15:44] <bialix> so I need only one plugin to install to launch this hooks
[15:45] <bialix> vila: is it make sense? or sound crazy?
[15:46] <vila> a little bit of both so far :)
[15:46] <bialix> yep :-)
[15:46] <thorike> thorike> hey guys
[15:46] <thorike> * jelmer has quit (Ping timeout: 265 seconds)
 i get bzr launchpad-login thorsten-prante
 bzr: ERROR: Transport error: Server refuses to fulfill the request (403 Forbidden) for https://launchpad.net/~thorsten-prante/%2Bsshkeys
 what can i do
[15:46] <vila> each hook has a different signature at least so I don't see how you will address that to start with
[15:47] <bialix> vila: okay, say I have python module with hook function which conforms signature
[15:47] <bialix> script won't fly, I see
[15:48] <bialix> thorike: lp is upgrading now, no?
[15:48] <vila> thorike: you may get better feedback from #launchpad where you already asked :)
[15:49] <bialix> hmm, it's planned to upgrade today but not yet, according to announce
[15:50] <bialix> vila: how can one define project-specific hooks?
[15:50] <vila> thorike: from the bzr side, I don't remember a 403 for launchpad-login, so I'd suspect a server -side thing
[15:50] <bialix> or better: branch-specific?
[15:50] <vila> bialix: by testing that they are invoked for a given branch
[15:51] <thorike> what abou bzr: ERROR: Invalid http response for http://bazaar.launchpad.net/~docky-core/docky/trunk/.bzr/repository/packs/2ff01fc6c27e6c04d7c95356fe08a608.pack: Missing the Content-Range header in a 206 range response
[15:51] <bialix> vila: e.g.?
[15:51] <thorike> vila, ^
[15:51] <bialix> thorike: are you using proxy?
[15:51] <vila> thorike: urgh, sounds like an intercepting proxy playing tricks at first glance
[15:52] <thorike> yeah
[15:52] <vila> thorike: bzr branch  http://bazaar.launchpad.net/~docky-core/docky/trunk docky WFM
[15:53] <vila> Branched 1165 revision(s).
[15:53] <vila> that adds value to the proxy cause
[15:54] <j^> hi, is there a way to run loggerhead with loggerhead.conf and just auto_publish_folder
[15:54] <j^> the example just sets that for a subfolder
[15:56] <thorike> thanks guys
[15:56] <thorike> had to reboot
[15:57] <thorike> was proxy
[15:57] <bialix> what it means: repacking chk?
[15:58] <bialix> it seems pul from lp:bzr/2.1 triggers full repack of my repo, :/
[15:58] <vila> bialix: rejoice ! You now have a fully repacked repo :)
[15:59] <vila> bialix: how many packs in repository/packs ?
[16:00] <bialix> now there is 2: one 90 big
[16:00] <bialix> 90MB big
[16:00] <bialix> it was it
[16:00] <bialix> so, vila: how can I check in the hook that I'm in the right branch/tree? any examples?
[16:00] <vila> bialix: sounds like a regular autopack to me
[16:02] <vila> bialix: not readily available but depending on the hook you should have some tree/branch/repo handy and from there you can get your hands on the config or xxx.base
[16:02] <bialix> right now I'm interested in MutableTreeHooks.start_commit
[16:03] <vila> AAARGH ! Forgot dentist appointment  !
[16:07] <bialix> wow
[16:07] <vila> grr, next available slot in 2 weeks :-/
[16:07] <bialix> oops
[16:08] <bialix> you have not enough good dentist around it seems
[16:08] <vila> bialix: so MutableTreeHooks.start_commit has the tree as parameter, so you from it you check whether your hook should apply or not
[16:10] <vila> well, once I *go* to the first appointment I'm in the loop and get new ones quicker, that's first time I have to wait so long though
[16:12] <MTecknology> is smtplib build into python?
[16:13] <bialix> MTecknology: yes
[16:13] <bialix> MTecknology: err, no
[16:14] <MTecknology> bialix: I'm still trying to figure out bzr-email; I got side tracked
[16:22]  * mrjazzcat is away: Auto-away after 30 mins idle (gone at 3rd Mar, 09:22:12)
[16:26] <MTecknology> I put this configuration on ~/.bazaar/bazaar.conf on the server that I'm pushing code to http://dpaste.com/167394/. I just pushed a new revision to is but no email was generated.
[16:28] <MTecknology> I just looked in /var/log/mail.* and there's nothing that seems to be trying to get through.
[16:30] <bialix> vila: still here?
[16:57] <bialix> vila: it works
[16:57] <vila> great !
[17:00] <MTecknology> I'm not even finding the docs I need to figure out how to make this work...
[17:39] <cody-somerville> If I have a checkout, what is the location alias for the remote branch? ie. I'm trying to find out the revno so want to do something like: bzr revno :checkout
[17:40] <james_w> does :bound work?
[17:41] <cody-somerville> yes :)
[17:41] <cody-somerville> ty
[17:43] <MTecknology> Any ideas about that email question above?
[17:45] <jasonlife> i'm using NFSv4 and keep getting "bzr: ERROR: [Errno 5] Input/output error" after some bzr command..  Actually the command seems to work tough..
[17:45] <jasonlife> I noticed bzr problem with NFS, but couldn't find fix..
[17:46] <jasonlife> anybody have idea on NFS and bzr issue?
[18:10] <jam> jasonlife: the only 2 problems I've seen are
[18:11] <jam> 1) stuff with bzr-svn/git/hg because of using TDB which doesn't like NFS
[18:11] <jam> 2) We use a OS level file-locking, and sometimes that isn't enabled on NFS
[18:11] <jam> one solution to (2) is to use local working trees with NFS branches and repos
[18:12] <jasonlife> I'm using NFS for my home directory and my local copy is in my home directory
[18:12] <jam> k, so you'll probably need to make sure that NFS locks are properly set up.
[18:12] <jam> But I don't really know how to do that
[18:13] <jasonlife> Are there any side effects of the error?  I have used bzr for one days so far, everything seems working fine even if I got the error
[18:13] <jam> I'd have to see the actual failure to tell you any more
[18:13] <jam> that specific error doesn't quite match what I would think the locking would be
[18:14] <jasonlife> You mean NFS locks in my NFS server for my home directory?
[18:14] <jam> jasonlife: right
[18:14] <vila> morning jam !
[18:14] <vila> jam: quick question before I quit
[18:14] <vila> jam: branchbuilder doesn't support symlinks right ?
[18:14] <jam> hey vila
[18:15] <jam> IIRC, no
[18:15] <jam> we could add it
[18:15] <vila> jam: or rather, it *looks* like it supports adding them but not modi... ok, yeah, I'll do that
[18:15] <jam> though I don't think MemoryTree supports them either
[18:15] <vila> :-(
[18:15] <jam> well, not well
[18:15] <jam> at lesat
[18:15] <jam> least
[18:15] <vila> well, time to add them there too :)
[18:16] <vila> ok, I'll look into it tomorrow...
[18:16] <jasonlife> jam: http://pastebin.com/bUMuuehZ
[18:16] <jasonlife> this is the error I got in .bzr.log
[18:17] <jam> so, that does look like it is a locking issue.
[18:17] <jam> Given the location
[18:17] <jam> I would guess it is normally harmless
[18:18] <jam> We keep track of the current sha value for a file, and track it against the mtime. That looks like it is a failure to update that
[18:18] <jam> which means we will re-read the file later
[18:18] <jam> which isn't a problem.
[18:18] <jam> It is *possible* that you could get a failure during 'bzr add'
[18:18] <jam> which would then forget that a new file was added
[18:18] <jam> but most failures are a 'repeat the command' away. I wouldn't expect corruption from it.
[18:18] <jasonlife> I see
[18:29] <gavenkoa> Hi! I have issue on bzr pull. When pull done on emacs source it gets 4 MiB inet traffic! When I search diff and compress it I got only 10 KiB! Why so mach inet traffic used by bzr client?
[18:29] <gavenkoa> http://pastebin.com/i6nXw15n
[18:47] <Kinnison> Presumably because you're not using the smart protocol; so it has to fetch indexes etc to work out what diffs it needs to fetch
[18:53] <gavenkoa> Kinnison: OK, that protocol use?
[18:53] <Kinnison> It would rely on the emacs people having set up the smart server
[18:53] <Kinnison> If they've not published how to use it; then they haven't
[18:53] <gavenkoa> sftp is ok?
[18:53] <Kinnison> sftp is just as bad
[18:53] <Kinnison> bzr+ssh:// is better
[18:54] <gavenkoa> ((
[18:54] <gavenkoa> I post bug https://bugs.launchpad.net/bzr/+bug/252945
[18:59] <Kinnison> Your comment really didn't belong on that bug
[19:00] <Kinnison> Your bug is "When pulling from HTTP, a 10KiB diff transferred 4MiB of data"
[19:00] <Kinnison> Not "When pushing...."
[19:02] <MTecknology> I'm still not getting it... for bzr-mail to work, does it have to be client side instead of server side?
[19:17] <gavenkoa> Kinnison: sorry ((
[19:18] <jasonlife> Is there bzr command to list the files that are not part of bzr project?
[19:18] <gavenkoa> bzr st | grep "^\?"
[19:19] <lifeless> bzr ls --ignored --unknown -R
[19:20] <jasonlife> lifeless: thanks.. it works..
[19:21] <jasonlife> is "*.o" file the "ignored file" ?
[19:22] <lifeless> yes
[19:24] <mtaylor> bzr tags is showing me crap
[19:25] <mtaylor> lifeless: http://pastebin.com/qBxVcwfz
[19:25] <mtaylor> lifeless: the tags with ? listed are from other projects...
[19:26] <lifeless> yes.
[19:26] <lifeless> you merged them into your tree. Don't do that.
[19:29] <jasonlife> I'm wondering how mtaylor merged tags from other projects..
[19:29]  * mtaylor also wonders that
[19:41] <lifeless> mtaylor: the bzr merge command probably ;P
[19:41]  * mtaylor pokes lifeless in the eye
[19:42] <lifeless> its possible that it merges under mistake circumstances; in which case please file a bug
[19:42] <lifeless> mtaylor: I need these eyes... to use my awesome new lappy
[19:42] <mtaylor> lifeless: cool
[19:49] <luke-jr> just found a large history of a project that I imported into Bzr... is it possible to prepend that history to my repository?
[20:00] <ahorden> hey all, what is the max size of file I can store in bazaar?
[20:01] <mtaylor> abentley: pipelines question... is there any way that I'm not finding to do bzr lp-submit on the whole pipeline at once? Also - is there any way do bzr push on each pipe in the pipeline at once ... or do I need to move through the pipeline and do each pipe in turn?
[20:01] <lifeless> ahorden: pragmatically, about 1/3 your physical memory
[20:01] <ahorden> I have a 3.8G database dump I want to keep in revision control, and I keep getting bzr: ERROR: exceptions.OverflowError: signed integer is greater than maximum
[20:02] <ahorden> lifeless, box has 8 gig of memory at the moment
[20:02] <lifeless> code wise we should be 64-bit safe; if not please file a bug
[20:02] <abentley> mtaylor, there isn't currently a way to submit all pipes at once.
[20:02] <lifeless> ahorden: are you running a 64-bit kernel and userspace ?
[20:02] <bialix> ahorden: most likely you have 32-bit version of python?
[20:02] <mtaylor> abentley: cool. at least i'm not just stoopid
[20:02] <lifeless> mtaylor: he didn't say that :P
[20:02]  * mtaylor pokes lifeless in the eye
[20:02] <ahorden> Platform: Linux-2.6.31-19-server-x86_64-with-Ubuntu-9.10-karmic
[20:03] <lifeless> ahorden: please run 'ubuntu-bug bzr' then, and give us a bug report. Let us know the number and I'll promote it to upstream right away
[20:04] <bialix> ahorden: run `python` and check the first line
[20:05] <ahorden> lifeless, I was about to upload this http://dev.biological-hazard.net/~adhorden/bzr-20100303195926-10714.crash its the crash report might help you debug better
[20:05] <MTecknology> lifeless: any chance you could help me with bzr-email? I've been looking. I feel like I'm retarded for not finding information about it beyond 'bzr help email' and where to set the config.
[20:05] <lifeless> MTecknology: what version of bzr-email do you have?
[20:05] <lifeless> MTecknology: and what do you want to do with it?
[20:08] <MTecknology> lifeless: On the server I have a user account with this config [http://dpaste.com/167394/] on that user account. I'd like it to be that if anyone pushes new code to any branch there an email gets sent to the devs.
[20:08] <ahorden> lifeless, I would do a bug report if Launchpad would let me log in!
[20:08] <lifeless> ahorden: #launchpad should be able to help you with that
[20:09] <MTecknology> lifeless: 0.0.1~bzr4
[20:10] <lifeless> MTecknology: that doesn't look like a version I've ever seen packaged
[20:10] <lifeless> rmadison bzr-email
[20:10] <lifeless>  bzr-email | 0.0.1~bzr40-1 | lucid/universe | source, all
[20:10] <lifeless> do you mean that ^ ?
[20:10] <MTecknology> sorry, ya
[20:11] <MTecknology> running on karmic; same version - just had part of it chopped off
[20:13] <lifeless> MTecknology: so, you've read bzr help email ?
[20:13] <ahorden> lifeless, is the crash report any good?
[20:13] <lifeless> ahorden: I don't know, please file it as a bug
[20:14]  * lifeless is already in the middle of prepping breakfast, helping MTecknology, writing an email
[20:15] <MTecknology> lifeless: ya, the config seems easy enough; it took looking aroundto figure out I need to put that in $HOME/.bazaar/bazaar.conf
[20:15] <lifeless> MTecknology: you'll want it in .bzr/branch/branch.conf
[20:15] <lifeless> MTecknology: as different user accounts might not have the config otherwise.
[20:15] <MTecknology> lifeless: OH!
[20:16] <MTecknology> lifeless: can I put that in on the server side or how should I put that in the branch?
[20:16] <ahorden> lifeless, thanks bug will have to wait maintainance tonight on launchpad
[20:16] <lifeless> this is covered (although it could be clearer) in 'bzr help configuration'
[20:16] <lifeless> ahorden: ok
[20:17] <lifeless> MTecknology: the servers copy of the branch, the server can't see the client side branches ;)
[20:19] <MTecknology> lifeless: parent_location is kind of odd to have considering it's where I pushed to it from. What happens when somebody else pushes code to it from a different location?
[20:19] <lifeless> nothing
[20:20] <MTecknology> that just deals with where the branch was created from?
[20:20] <lifeless> its just the default for 'pull' or 'merge' in that branch
[20:20] <lifeless> see bzr help configuration
[20:20] <MTecknology> ok
[20:24] <MTecknology> lifeless: what would you suggest using for sending email? Could I just use sendmail?
[20:24] <lifeless> MTecknology: use whatever you like
[20:29] <MTecknology> time to see if this works now...
[20:30] <jelmer> jam: fwiw we don't require TDB for bzr-hg/svn/git, we can also use sqlite (which might has the disadvantage of only allowing one concurrent writer)
[20:31] <MTecknology> lifeless: I tried that in the file you mentioned; just added it to the end of the file using email = Kalliki Private Devs <dev-private@kalliki.com>
[20:31] <MTecknology> editor = /usr/bin/vim
[20:31] <MTecknology> post_commit_to = dev-private@kalliki.com
[20:31] <MTecknology> post_commit_difflimit = 40000
[20:31] <MTecknology> oopss... sorry
[20:32] <lifeless> did you see the bit 'By default bzr-email only emails when a commit occurs,...'
[20:32] <MTecknology> ya, I made a commit and pushed it to the server
[20:33] <MTecknology> oh... that's for local commit; it only knows I push- doesn't it?
[20:33] <lifeless> right
[20:33] <lifeless> the server can't tell 'commit' from 'push' or 'uncommitt
[20:38] <MTecknology> lifeless: I'm guessing this is working mostly.. It doesn't want to let the user use sendmail - I guess I'll try to allow the user to do that
[20:39] <lifeless> what do you mean
[20:39] <lifeless> I hesitate to ascribe an intentional stance to your server.
[20:39] <MTecknology> I have sendmail installed; I guess by default normal users can't use it
[20:40] <lifeless> uhm
[20:40] <lifeless> most folk use 'mail' not sendmail to queue mail for delivery.
[20:41] <lifeless> queuing and internet transferral are very different things.
[20:41] <MTecknology> what package is that?
[20:41] <lifeless> you may have it already
[20:41] <lifeless> try typing 'mail'
[20:41] <MTecknology> nope
[20:41] <MTecknology> not found
[20:41] <lifeless> well, there are lots of packages
[20:42] <lifeless> most MTAs include a mail program
[20:42] <lifeless> I can't really comment  on sendmail per se
[20:42] <lifeless> you don't need an MTA on the machine though, bzr can use an SMTP server
[20:43] <MTecknology> what would you choose to queue the message?
[20:43] <lifeless> I use the default, which is to run the mail program
[20:45] <MTecknology> mailx; alrighty
[20:46] <mwhudson> jelmer: hey, did you see my bzr-svn merge proposal?
[20:46] <mwhudson> no hurry, just wanted to make sure it didn't fall through the cracks
[20:47] <MTecknology> well - I like this error more - bzr: ERROR: mail is not installed
[20:49] <lifeless> MTecknology: well, whatever you want again. 'mail' is largely a standard, there are options to tweak how bzr-email uses it. My /usr/bin/mail comes from bsd-mailx
[20:52] <MTecknology> lifeless: I just installed bsd-mailx assuming that was the right one; which mail gives me /usr/bin/mail; when I push I get that error
[20:52] <MTecknology> lifeless: but if I'm that user and I run 'mail' I get 'No mail for kalliki'
[20:53] <lifeless> MTecknology: 'mail -s test your-email@gmail.com'
[20:53] <lifeless> type type type
[20:53] <lifeless> ctrl-D
[20:53] <lifeless> or you could use smtp
[20:53] <lifeless> or whatever :P
[20:54] <MTecknology> ok odd, I get "bzr: ERROR: mail is not installed !?" after a push; but the message still winds up in my inbox
[20:55] <lifeless> MTecknology: run with -Derror
[20:57] <MTecknology> lifeless: http://paste.ubuntu.com/387847/
[21:00] <lifeless> we're getting ENOENT
[21:00] <lifeless> on your workstation
[21:00] <lifeless> did you install the plugin locally?
[21:00] <MTecknology> It's both local and remote
[21:00] <lifeless> well, then you'll probably want to install mailx on the workstation
[21:00] <lifeless> or don't install it there.
[21:00] <MTecknology> ok
[21:01] <lifeless> bzr is running the plugin locally and its erroring
[21:01] <MTecknology> oh
[21:02] <MTecknology> lifeless: awesome :D now... is it possible to change the subject of the email?
[21:03] <lifeless> not currently
[21:03] <lifeless> there might be patches unmerged, I'm not sure
[21:04] <MTecknology> awesome
[21:04] <MTecknology> lifeless: thanks for the help :D
[21:04] <MTecknology> awesome plugin :D
[21:04] <lifeless> de nada
[21:14] <drewww> I'm having trouble checking out just part of a tree from a bzr repository on launchpad - can I not do "bzr branch lp:projectname/path/to/file"?
[21:14] <bob2> correct
[21:15] <bob2> the only common vcs to support that is svn, afaik
[21:15] <lifeless> and cvs
[21:15] <drewww> huh
[21:17] <drewww> So how should I work around this? It's making deployment for this web service tricky.
[21:18] <lifeless> you can use views
[21:18] <lifeless> but that doesn't quite do the same thing
[21:18] <drewww> hmm
[21:18] <lifeless> why do you need to deploy?
[21:18] <drewww> It's a web app thing
[21:18] <drewww> I'm using a framework that I Can't distribute
[21:18] <drewww> so I just have the "app" folder in my repository
[21:19] <drewww> and to deploy, need the app folder to be at the same level in the web server's webroot as the framework's files.
[21:19] <lifeless> why not have your repository root /be/ the app folder
[21:19] <drewww> yeahhhhhhh starting to think that would have been the right choice, but I had an installation instructions file at the same level as app
[21:20] <drewww> which was how I used to set stuff up with svn
[21:20] <drewww> old habits die hard
[21:22] <ahorden> lifeless, one bug https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/531612
[21:28] <jelmer> mwhudson: hi
[21:28] <jelmer> mwhudson: yep, I saw it
[21:28] <mwhudson> cool
[21:28] <jelmer> mwhudson: I have some concerns, will reply today
[21:29] <mwhudson> jelmer: ok
[22:18] <mwhudson> jelmer: i see what you meant by bzr-svn's tests being better than bzr-git's being better than bzr-hg's :-)
[22:26] <jelmer> mwhudson: :-)
[22:53] <mwhudson> jelmer: HgWorkingTree.commit() doesn't seem to create a revision that has the current tree tip as a parent
[22:54] <mwhudson> jelmer: is that "yeah, we know", "oh, that's surprising" or "meh" ?
[22:55] <jelmer> mwhudson: yeah, we know :-)
[22:56] <jelmer> mwhudson: the working tree support in bzr-hg is, uhm, experimental
[22:56] <jelmer> if it works, I'm surprised too
[22:56] <mwhudson> jelmer: it's kind of a shame that the pull tests use it to set up the test cases then?
[22:56] <jelmer> mwhudson: it uses commit as well?
[22:57] <jelmer> are you sure it doesn't just use the hg API directly?
[22:57] <mwhudson> jelmer: yeah
[22:57] <mwhudson> jelmer: look at tests/test_pull.py:34 ish
[22:58] <mwhudson> (i was a bit surprised to see this!)
[23:19] <thumper> how do you use bzrlib to add a file, or update a file if there is no working tree?
[23:20] <thumper> actually if a file exists, I want to merge it in if it is text and replace if it is binary
[23:23] <mwhudson> thumper: you can
[23:23] <mwhudson> 't merge or commit or anything without a tree
[23:23] <mwhudson> you can do this stuff in a preview tree though, i guess?
[23:24] <thumper> interesting
[23:30] <distatica> I'm having a problem commiting to lp after a checkout, I get a Invalid url supplied to transporter error: http://paste.pocoo.org/show/185320/ am I missing something obvious?
[23:31] <distatica> wait, that doesn't have me with the issue on commit, just checkout, I had another checked out branch and I tried commiting wtih the same error.
[23:37] <mwhudson> distatica: launchpad code hosting is down for a rollout right now
[23:50] <distatica> oh I see
[23:54] <jelmer> mwhudson: I've merged your patch but changed the way in which limit is used
[23:54] <jelmer> mwhudson: The reason for this is that a pull from an out of date branch should be a no-op unless --overwrite is specified
[23:55] <jelmer> mwhudson: unfortunately I can't push atm, launchpad being down temporarily and all :-)
[23:56] <mwhudson> jelmer: awesome