[03:59] <lifeless> wow quiet day
[04:00] <beuno> we're all coding away before 1.0 closes  ;)
[04:08] <Peng> I'm pinging out. :)
[04:08] <lifeless> ;)
[04:17] <lifeless> Peng: thanks for your patch to the docs; it's been merged I believe.
[04:23] <Peng_> Lagggg.
[04:23] <Peng_> lifeless: :)
[04:23] <Peng_> 34.7s!
[04:24] <lifeless> Peng_: :)
[04:24] <lifeless> Peng_: did you see what I said ?
[04:24] <Peng_> "thanks for your patch ...", yes.
[04:24] <Peng_> Nothing after that.
[04:25] <lifeless> that was all
[04:31] <Peng__> Jesus!
[04:42] <Peng> Sighhh.
[04:43] <lifeless> lagathon?
[09:48] <dato> abentley: yeah, thanks
[11:47] <AfC> How come `bzr gdiff` doesn't work if multiple files are given as arguments?
[11:49] <jelmer> AfC, simply hasn't been implemented yet
[11:49] <AfC> jelmer: k
[11:49] <AfC> jelmer: do you need a bug for that?
[11:50] <jelmer> AfC: please
[11:50] <AfC> Fine.
[11:50] <AfC> I've actually been meaning to try and get into the gdiff code
[11:50] <AfC> I'm not much for pygtk, but there are a couple of behaviours I want to recommend changing
[11:52] <AfC> [*every* single time I run it I a) maximize, then b) drag the Paned divider to give it enough room to show me the file names, then c) move from "combined" to first file.]
[11:52] <AfC> [getting a bit tedious]
[12:03] <jelmer> there has been some talk about what to do with the diff window
[12:03] <jelmer> perhaps we could call out to meld or something like that
[12:03] <AfC> jelmer: (meld?)
[12:04] <jelmer> meld.sf.net
[12:04] <AfC> I came across some neat code in devhelp relating to remembering previous maximized-or-not state and acting accordingly to restore it on new instantiation. It's pretty good when done right.
[12:13] <lifeless> moin
[12:27] <lifeless> moin
[12:31] <mwhudson> allegedly
[13:01] <sverrej> Using bzr-svn, is it possible to commit locally and then push the commits together to subversion later?
[13:02] <sverrej> bzr commit in a bzr-svn branch always commits directly to the svn server.
[13:03] <luks> not if you use 'bzr branch' instead of 'bzr checkout'
[13:03] <luks> you can either unbind the checkout or use commit --local
[13:04] <sverrej> I tried commit local, but it told me "bzr: ERROR: Cannot perform local-only commits on unbound branches."
[13:04] <sverrej> but I can try to unbind
[13:04] <sverrej> or check out again
[13:04] <sverrej> thanks!
[13:05] <lifeless> sverrej: it's a double negative - thats already unbound
[13:05] <mneisen> One question about the new knitpack format: is it possible to automatically delete the obsolete packs in obsolete_packs, or is it even possible to stop bzr putting obsolete packs in there at all?
[13:05] <lifeless> mneisen: they should auto delete; I thought I had merged that
[13:05] <lifeless> I'll check
[13:06] <mneisen> lifeless: I just did a small benchmark with the new format, and i ended up with about 60 megs of files in obsolete_files.
[13:06] <mneisen> lifeless: I use the 0.92rc1 version of bzr.
[13:06] <Enquest> I did a "rm foo.css" how can I bring a file back ... With svn I only needed to do "svn update"
[13:06] <lifeless> mneisen: it's not merged sorry; I have a patch to clean it up though
[13:06] <lifeless> Enquest: bzr revert foo.css
[13:07] <mneisen> lifeless: great news. Hope to see it soon in the released packages ... :-D
[13:07] <lifeless> mneisen: it'll be in 0.93/bzr.dev later today; it's unlikel to be cherry picked into 0.92
[13:07] <mneisen> OK. Thanks anyway ...
[13:08] <mneisen> lifeless: Do you know by any chance when bzr-gtk will be up to speed, i.e. when bzr-gtk can be used with up-to-date bzr packages?
[13:08] <lifeless> you can rm the contents of that dir safely
[13:08] <lifeless> we use it to make operations wit flakey networks safer
[13:08] <mneisen> lifeless:OK, will use rm.
[13:08] <lifeless> just leave the dir itself around
[13:15] <mneisen> lifeless: Anything about bzr-gtk (see above)?
[13:16] <lifeless> it's just been released today
[13:16] <lifeless> so 24 hours probably
[13:19] <mneisen> lifeless: oic, didn't know that it was released today.
[13:19] <mneisen> Thanks!
[15:44] <dato> lifeless: "strict arch limits" (I'm unfamiliar with PAA)
[15:45] <dato> er, PPA (see? :)
[15:45] <siretart> dato: it builds for i386, amd64 and lpia only (well, anything xen supports)
[15:45] <dato> oh, and bazaar-vcs.org has ppc?
[15:47] <lifeless> hope to soon; need to hook it up
[15:47] <siretart> currently amd64 and i386 only
[15:48] <siretart> and I doubt that we'd have a lot of lpia users
[15:48] <lifeless> also I'd like to get rpm's up
[15:48] <siretart> lifeless: aren't there any plans to offer PPAs for debian chroots as well? (no idea about that)
[15:49] <dato> why are debian packages on bazaar-vcs.org anyway?
[15:49] <dato> sid is covered, lenny as usual, and I normally upload backports.
[15:49] <siretart> they used to be undermaintained in the past?
[15:49] <dato> plus lifeless could do any of those uploads if/when necessary.
[15:49] <siretart> oh, I forgot backports. thanks dato!
[15:50] <dato> (and backports is autobuilt these days)
[15:50] <lifeless> dato: debian waits for releases
[15:50] <lifeless> bazaar-vcs.org uploads beta's
[15:50] <dato> lifeless: rc
[15:50] <dato> sid gets rcs
[15:51] <dato> and lenny, they'd migrate if there was time :)
[15:51] <lifeless> It didn't in the past;
[15:51] <dato> yeah, I'm just talking about the present
[15:51] <siretart> lifeless: we do since the pkg-bazaar team got into shape
[15:51] <lifeless> but more importantly, when debian next starts to release it will probably stop taking bzr versions
[15:51] <lifeless> when the UVF kicks in.
[15:51] <lifeless> It's true that this may be next decade :)
[15:52] <siretart> there is backports.org for stable and oldstable
[15:52] <dato> (I'm personally not uploading for oldstable atm)
[15:53] <lifeless> siretart: and it's great the team is in shape - I'm in it too :)
[15:53] <dato> lifeless: anyway, I'm not unhappy in any way, just wondering.
[15:53] <lifeless> the basic thing is that the bazaar-vcs.org is geared around bzr's release cycle; even sid is geared around debians release ccle, so we need something for bzr enthusiasts during debian stabilisation.
[15:54] <lifeless> (this is why we have ubuntu debs too)
[15:54] <lifeless> the ubuntu one is much more visible because its 6 monthly
[15:58] <lifeless> I'd also like to get daily builds up; its on my todo
[15:58] <lifeless> we had them for baz and users lovd them
[16:18] <pattern> i'd like to put keep some of my system configuration files in /etc under revision control... so should i do something like "mkdir /etc/bzr ; cd /etc/bzr ; bzr init ; cd /etc"  ?
[16:19] <pattern> and then, how would i add, say, /etc/make.conf to my new /etc/bzr repository?
[16:19] <pattern> oops
[16:19] <pattern> oh, that's right... i thought i mistyped that question
[16:19] <pattern> but it's typed correctly :)
[16:21] <pattern> or maybe i should just "cd /etc ; bzr init" and then just "bzr add make.conf" from /etc itself ?
[16:31] <lifeless> statik: where are you ?
[16:47] <nevans> pattern: I simply put my entire /etc dir into bzr.
[16:48] <nevans> cd /etc; sudo bzr init; sudo bzr add; sudo bzr commit -m "version controlled /etc"
[16:55] <Le-Chuck_ITA> hi there, I am using bzr-gtk found in ubuntu gutsy
[16:56] <Le-Chuck_ITA> and olive does not seem to correctly recognize bzr branches on my disk
[16:56] <Le-Chuck_ITA> it only shows the directories and not the files, and offers disabled menu entries for handling the branch
[16:58] <Le-Chuck_ITA> how do I open a branch with olive? And how do I bookmark it?
[16:58] <Le-Chuck_ITA> it's such a simple program that you easily exhaust all the possible operations :)
[17:29] <pattern> nevans: nice :)
[17:29] <pattern> the only thing is that with gentoo, there's a lot of automatic messing with files in /etc
[17:29] <pattern> so i don't want to keep having to commit a ton of changes by hand
[17:30] <pattern> there are handful of files that i edit manually, and those are the ones i really want to keep under bzr's version control
[17:30] <pattern> anyway, the stuff that gentoo messes with itself are automatically kept under RCS version control via dispatch.conf
[17:40] <bialix> luks: hi
[17:40] <luks> hi
[17:40] <bialix> I fixed problem with lock and pack repo in my branch
[17:41] <bialix> I just wonder: when you're planning to release QBzr 0.7.0?
[17:42] <luks> hmm, I guess I could do it over the weekend
[17:42] <bialix> it will be great
[17:42] <nevans> pattern: I just do the whole /etc directory because it's easier.  simply "sudo bzr add; sudo bzr commit", and you're done.  I don't mind that I'm versioning a few extra things that I don't care as much about.
[17:44] <pattern> it's going to be a ton of extra things for me
[17:44] <pattern> on the other hand, when i do a "bzr status", it lists a ton of "unknown" files and directories
[17:45] <nevans> yeah, that's the other reason I do the whole thing... then I know when anything in there changes.
[17:45] <bialix> luks: do you still prefer to file wishes to QBzr in bug tracker?
[17:45] <fullermd> pattern: I version just a few files out of /etc (and /usr/local/etc, and similar places).  I just have '*' in .bzrignore, and manually add the bits I care about.
[17:45] <nevans> fullermd: that makes sense... that's what I do in my home directory.
[17:46] <luks> bialix, yes, since otherwise it's very easy to forget them
[17:46] <nevans> err... the home directory itself ignores .*  ...some of the subdirectories ignore *
[17:47] <nevans> (although... my home directory is actually still using svn, not bzr... and ignores behave a little bit differently in svn)
[17:47] <pattern> ahh... ".bzrignore" ... i should look in to that :)
[17:47] <bialix> luks: ok, because I have 2 new items to wishlist: search in qlog and working with tags in qlog window
[17:47] <luks> search in qlog was on my unwritten todo list already
[17:48] <luks> but please add it anyway
[17:48] <luks> it's better to have all ideas on one place
[17:48] <bialix> can we collaborate on search feature sometime?
[17:49] <luks> I haven't touched the code for a while, so I'm not sure when I'll have time and motivation to work on it
[17:49] <bialix> ok
[17:50] <luks> I usually add new features only when something really annoys me or I'm really bored :)
[17:50] <bialix> me usually too
[18:54] <Jamon> is there a way to uncommit a specific commit out of order?
[18:54] <Jamon> perhaps undo changes is a better way of saying it
[18:54] <lifeless> not really; there is a way to merge it out - to reverse it. But it is part of the written history so it can't be removed without rbeaking referntial integrity
[18:55] <lifeless> so - 'bzr merge -r234..233 .'
[18:55] <lifeless> that will remove commit 234 for you
[18:55] <lifeless> (you need to commit after that naturally)
[18:56] <Jamon> i made a commit that changed mysql functions to pgsql, now later on i just want to switch back to mysql... so bzr merge -r will allow me to do that?
[19:03] <lifeless> yes
[19:04] <Jamon> whats the diff between that and revert?
[19:04] <lifeless> revert undoes all changes to the selected paths from the revision forward
[19:05] <lifeless> spiv: reconcile on launchpad is up to 4.5Gb and no progress marker yet
[19:06] <Jamon> so revert is full sequential, and merge is from points out of sequence
[19:07] <lifeless> yes
[21:52] <dodijk> Hello! Does anybody have any experience with using bazaar on a branch on a hfsplus filesystem? I get permission errors (on .bzr/branch-format) when trying to add files. Moving the branch to ext3 fixes this...
[22:04] <dato> dodijk: maybe jam-laptop knows about that, but he doesn't seem to be around right now
[22:06] <dodijk> data: ok, i'll try again some other time
[23:28] <nir> Is there a shortcut to create a new branch WITH the current changes in the tree?
[23:29] <beuno> nir, uncommited ones?
[23:33] <nir> yea
[23:34] <beuno> nir, I don't think you can do that with bzr, no. As far as I can tell, bzr brings in the repository and restores the working tree from it
[23:34] <beuno> rsync would work though
[23:34] <fullermd> branch ; merge --uncommitted
[23:34] <beuno> ah, there you go
[23:35] <beuno> I learn new things here everyday...
[23:35] <nir> great
[23:35] <nir> although branch --uncommitted would be even nicer
[23:37] <beuno> nir, you can file a bug requesting it. Unless fullermd has a good reason why not to have it
[23:38] <nir> its a feature request, not a bug
[23:40] <beuno> nir, right, it would be wishlist, I don't believe there is something specific for feature requests in Launchpad
[23:40] <beuno> blueprints seem like and overkill, and I believe they don't have "states" so you would know when it gets implemented