[00:00]  * mwhudson attempts to figure out how releases on launchpad work these days
[00:01] <jelmer> Tak: it's sometimes mentioned in the NEWS file
[00:01] <jelmer> Tak: I'm not seeing anything on Lucid
[00:03] <Tak> I thought maybe there was a change in the embedding api, or that I've been Doing It Wrong in a way that just didn't break before (md-bzr), but then a google search is gives hits for similar issues with a fair number of python apps
[00:03] <Tak> (not that I couldn't still be doing it wrong)
[00:04] <Tak> cool, so the api change was 2.1.0b1 - thanks
[00:04] <defn> hi everyone.  I am new to bzr and I have a question...  Basically I have this external "branch" which hooks into a larger repository externally -- i would like to do development on my branch locally and then "commit" only to my branch on the remote shell
[00:04] <defn> how does one go about "committing" to a branch
[00:04] <defn> if you have any suggestions for doing local development and then getting those changes under version control please let me know
[00:10] <jelmer> defn: I'm not sure I understand what you're trying to do
[00:11] <defn> jelmer: me either! :)
[00:11] <Tak> jelmer: btw, I'm seeing the filehandle leak on both sid and osx 10.6
[00:11] <jelmer> defn: you'd like to do a partial checkout of a remote repository basically?
[00:11] <jelmer> Tak: I'm not claiming it doesn't exist on lucid, just saying I haven't seen it yet :-)
[00:11] <jelmer> s/seen/noticed/
[00:11] <jelmer> 'morning Ian!
[00:11] <igc_> hi jelmer
[00:13]  * Tak nod
[00:23] <defn> jelmer: hmm, im just sort of confused on how my repo was setup initally -- let me do some digging for how it was created and then let me rephrase :)
[01:17] <poolie> hi
[01:17] <jelmer> moin poolie
[01:18] <poolie> hi there
[01:27] <igc_> hi poolie
[01:28] <poolie> hi
[01:33] <igc_> poolie: Windows installers built and uploaded for 2.0.5 and 2.1.1 over the weekend
[01:33] <poolie> yay
[01:34] <poolie> how hard/easy would it be to do a 64-bit windows build?
[01:34] <poolie> people have asked a few times
[01:35] <poolie> jelmer, igc_: i think my mail about plugin compatibility was too braindumpy; nobody replied yet
[01:36] <lifeless> poolie: I haven't seen it
[01:36] <poolie> but what would you two think about 1- having a blacklist in bzrlib to make it more symmetric
[01:36] <lifeless> but it sounds like something I'd have an opinion on
[01:36] <poolie> heh, it does, doesn't it :)
[01:36] <poolie> 2- making the failure less noisy
[01:37] <fullermd> I fear that sort of blacklist.  It's got a neon sign above it saying "Ask Me About Being Out Of Date"
[01:38] <lifeless> fullermd: depends how its phrased and populated
[01:38] <lifeless> fullermd: if it was 'plugin X < Ver-Y is bust' then its not stale daya
[01:38] <lifeless> < very-Y will stay bust
[01:38] <lifeless> s/day/data
[01:38] <poolie> right
[01:39] <poolie> it may be that we add the faciliity and don't make use of it
[01:39]  * fullermd confiscates lifeless's 'y' key for rampant misuse.
[01:39] <lifeless> poolie: I don't know how quiet you want to go. I think a broken plugin should be listed on every invocation of bzr.
[01:39] <poolie> we could put it only in 'bzr plugins'
[01:39] <lifeless> even though its noisy, its an aberrant situation.
[01:39] <lifeless> and crucially its not easily discoverable
[01:39] <poolie> we may just substitute wonders about why something broke though
[01:39] <poolie> right
[01:40] <poolie> so i think the main thing is to only be giving warnings if the plugin actually would not work
[01:40] <lifeless> hmm
[01:40] <lifeless> we could
[01:40] <poolie> ie eliminate both type I and II errors
[01:40] <lifeless> if exiting with non-zero (e.g. NotBranchError, NoSuchCommand etc)
[01:40] <lifeless> also show broken plugins
[01:40] <fullermd> That could get irritating in the case where the user can't do much about it though.
[01:41] <poolie> mm
[01:41] <lifeless> 'svn:///host/path is not a branch\nWarning: plugin bzr-svn failed to load. See ~/bzr.log for details.'
[01:41] <fullermd> They can wind up with nothing to do but set whatever that env var is to disable a plugin, which then becomes an eternally-encysted part of the env.
[01:41] <lifeless> fullermd: so, if they are running a non-installed bzr, they can set BZR_PLUGINS_PATH to control the plugins, without disabling just-one
[01:42] <fullermd> I was thinking more the case of running an _installed_ bzr, with installed b0rked plugins.
[01:42] <lifeless> fullermd: so, a sysadmin fail ?
[01:43] <fullermd> In a hard or soft sense, yes.
[01:43] <fullermd> I tried fixing such things, but I ran out of bullets   :)
[01:43] <lifeless> poolie: anyhow, I think both your 1 and 2 could be good
[01:43] <lifeless> though I haven't [yet] read the mail to know the context.
[01:44] <lifeless> fullermd's concern about staleness of data would be something to cater for in the blacklist design.
[01:56] <igc_> poolie: I'm yet to read it sorry
[01:57] <igc_> poolie: I scanned it and it had good ideas IIRC
[02:15] <igc_> poolie: no opinion on 64-bits builds currently
[02:28] <GungaDin> how can I merge just a couple of directories into a branch?
[02:29] <bob2> with difficulty
[02:30] <bob2> (assuming the changes are in changesets that altered other files)
[02:30] <bob2> you can merge + revert the bits you don't want (but then the other bits will never be merged)
[02:31] <lifeless> huh
[02:31] <lifeless> easy
[02:31] <lifeless> bzr emrge branch/dir1
[02:31] <lifeless> bzr merge --force branch/dir2
[02:31] <lifeless> bzr commit
[02:31] <lifeless> note though, that like *all* partial merges, it won't be recorded as a merge.
[02:34] <mbohun> what is the proper way to rename/move A.c to B.c and B.c to A.c ?
[02:35] <Peng> "bzr rename"?
[02:35] <fullermd> Use an intermediate name and 3-step it.
[02:35] <fullermd> Or use the `bzr xor` trick...    ;>
[02:35] <Peng> Oh. You can't do it in one step?
[02:36] <fullermd> How would you?
[02:36] <Peng> Err, sorry.
[02:36] <Peng> I was thinking, like, commit wise. Some VCSes don't let you do something like that in one revision.
[02:37] <mbohun> that's what i m wondering, though my example was a bit retarded in fact i have to version of the same html page: index.html and index2.html (index.html being the default) - now i want to swap them so index2.html is going to be the default index.html
[02:37] <fullermd> bzr mv index.html tmp ; bzr mv index2.html index.html ; bzr mv tmp index2.html
[02:38] <lifeless> Peng: one commit is fine.
[02:38] <fullermd> You can do it all in one rev, sure.  I've...  well, I've never done that, but I've moved a file and then created a new file with the old name a lot.
[02:38] <mbohun> fullermd: thanks
[02:39] <Guest87486> Hiya  an a Sunday nite! If I 'bzr branch aRepo', then 'bzr mv aRepo/someDir aRepo/newDir', does 'bzr merge aRepo' automagically put changes under version control in the original source's aRepo/someDir in the *renamed* aRepo/newDir?
[02:40] <lifeless> Guest87486: I don't know quite what you're asking.
[02:40] <lifeless> Guest87486: but I want to know that you can't branch a repo. Youc an only branch a branch.
[02:43] <Guest87486> lifeless: I'm just trying to understand if bzr is smart enuf to put changes originally meant for "aRepo/someDir" into the directory I renamed it as "aRepo/newDir".
[02:44] <lifeless> Guest87486: yes
[02:46]  * igc_ out for a few hours
[02:47] <lifeless> Guest87486: (yes, bzr is smart enough)
[02:48] <Guest87486> lifeless: I just started with version control in general, and bzr in particular.  pretrry amazing once you start to get the hang of it!  Thanks.
[02:58] <tommytb> hi, what is the submit branch shown in branch.conf?
[02:59] <fullermd> It's the default location used for certain operations (send and merge at least, I think)
[03:00] <tommytb> any way to move it back to trunk?  (i messed up my repository when trying out my first branching operation)
[03:01] <fullermd> Using something like `merge --remember` would reset it.  You could manually edit it in the branch.conf.
[03:03] <tommytb> branch.conf also has some of my commit messages in it
[03:03] <tommytb> what does merge --remember do?  i don't want to mess things up more
[03:03] <fullermd> It shouldn't....    oh, maybe qbzr's uncommit hook stashes them there.
[03:04] <fullermd> `merge --remember xyz` does pretty much the same thing as `merge xyz`, except that it stores xyz as the remembered location.
[03:04] <fullermd> Without --remember, it will only save it if there isn't already a saved one.
[03:10] <tommytb> the submit branch is set to a branch I manually deleted, which is causing me some errors.  I have nothing to merge
[03:10] <fullermd> What errors is it causing you?
[03:11] <fullermd> The stored location is just used as a default location for certain commands when you don't specify one explicitly.  Aside from that, it's pretty much cosmetic; it doesn't imply any lower-level link between the branches.
[03:11] <tommytb> when i open my trunk it says in bzr explorer "Not a branch: ~/project/trunk/branch1
[03:12] <fullermd> Mmm.  Explorer is off my turf.  That's igc_'s baliwick, but he's away right now.
[03:12] <fullermd> You could just manually delete the line wholesale from the branch.conf.
[03:13] <lifeless> right
[03:13] <lifeless> also please file a bug on bzr-explorer at bugs.launchpad.net/bzr-explorer
[03:15] <tommytb> deleting the submit branch=...  line from branch.conf seemed to work
[03:15] <tommytb> should i also delete the line below it that just says [commit data]?
[03:16] <tommytb> i have a question on launchpad bzr-explorer already
[03:16] <lifeless> about this?
[03:16] <tommytb> ya
[03:16] <fullermd> Probably not...   I assume those are saved uncommit messages or something.  Might as well leave 'em alone without a good reason to fiddle.
[03:32] <tommytb> ok, thx, i think its fixed
[03:33] <tommytb> does anyone know what the colored circles indicate in bzr explorer when viewing your log history? One of my branches is colored pink and one is colored sky blue.
[03:36] <fullermd> I think it uses some heuristic to guess which branch different revs came from, and colors them based on that.  I'm not sure it has any deeper meaning.
[05:01] <GungaDin> can bzr apply patches?
[05:02] <mwhudson> GungaDin: yes, bzr help patch i think
[05:02] <mwhudson> hm
[05:02] <GungaDin> thx
[05:02] <Peng> If you just have a plain diff, you can use the usual 'patch' command...
[05:02] <mwhudson> maybe that's from some plugin actually...
[07:27] <parthm> I am trying to run 'bzr log' with bzr from trunk. but thats failing with api not compatible error. version and st work and pull says there is nothing to pull http://pastebin.com/Hbgt3KRM
[07:28] <parthm> am i missing something?
[07:28] <vila> hi all ! (new DST here for those who care :)
[07:28] <vila> parthm: upgrade or disable your plugins until they update their checks against bzrlib API
[07:30] <parthm> vila: ah ok. so a plugin probably updated the log command. it works fine with --no-plugins. thanks.
[07:31] <vila> parthm: just loading the plugins (even without modifying log) can trigger that
[07:31] <parthm> vila: i should have thought of that earlier :)
[07:33] <davidstrauss> How can I change the path to Python that Bazaar uses?
[07:33] <lifeless> davidstrauss: an installed bzr ?
[07:33] <lifeless> davidstrauss: or running from source?
[07:34] <davidstrauss> lifeless: Either, preferably installed
[07:34] <davidstrauss> lifeless: I need to run Bazaar under Python 2.6 for bzr-svn support for one use.
[07:34] <davidstrauss> user*
[07:34] <lifeless> well
[07:35] <lifeless> you'll need to installed it under python 2.6
[07:35] <lifeless> unless you're using packages, which should have instaleld it under all versions
[07:35] <lifeless> the #! line at the top of /usr/bin/bzr controls the interpreter used to run bzr
[07:35] <lifeless> but you can also do 'python2.6 /usr/bin/bzr ....'
[07:38] <davidstrauss> lifeless: Running the "python2.6 /usr/bin/bzr" complains about not having bzrlib in the PYTHONPATH
[07:39] <lifeless> davidstrauss: then its not installed for python2.6
[07:40] <lifeless> davidstrauss: is it ubuntu packages that you've installed it with ?
[07:40] <lifeless> or something else?
[07:40] <davidstrauss> lifeless: This is with the Four Kitchens Yum repo packages for RHEL/CentOS
[07:41]  * Peng declares dealing with plugin API compatibility the most annoying thing ever.
[07:44]  * fullermd waves at vila.
[07:45] <davidstrauss> lifeless: I think I figured it out.
[07:45]  * vila waves back !
[07:47] <lifeless> davidstrauss: I don't know anything about CentOS python package sorry
[08:06] <poolie> lifeless: teddybear about apport
[08:06] <poolie> with my current fix for bug 528114 we can get ubuntu-bug sending the crash files to lp again
[08:06] <poolie> but there are two drawbacks
[08:07] <poolie> firstly they are filed against the ubuntu package when they're probably upstream bugs
[08:07] <poolie> secondly they are private by default, pending retracing
[08:07] <poolie> and there seems to be a long delay there
[08:08] <igc1> back
[08:08] <igc1> with a running system this time :-)
[08:14] <lifeless> poolie: hi
[08:14] <lifeless> poolie: uhm, some apport is better than no apport
[08:14] <poolie> yeah that was basically the question
[08:14] <lifeless> poolie: what caused the issue? Have you corresponded with pitti ?
[08:14] <poolie> previously; not today
[08:14] <poolie> i think i just need to fix a larger bug
[08:15] <lifeless> well yes, I know previously :)
[08:15] <lifeless> pitti is up , I saw him in another channel; might make sense to have a hallway chat with him about this now.
[09:56]  * igc1 dinner
[10:27] <writer> Hi everyone
[10:27] <writer> Is it okay to use bzr on a low-bandwidth connection ?
[10:28]  * writer is on a 512 Kbps connection, and getting 'bzr: ERROR: Connection error: while sending GET /ikarus.dev/.bzr/repository/indices/a2ff5c6db2537db1740e0e9ba5216e52.six: [Errno 4] Interrupted system call' with bzr 2.1.0-2 on Arch GNU/Linux
[10:29] <lifeless> thats not going to be your connection per se
[10:29] <lifeless> perhaps there is an intercepting proxy at your ISP or something
[10:30] <lifeless> bzr is usable with lower speed connections than yours
[10:30] <writer> lifeless: there is not any, AFAIK, and I'm getting download speeeds like 2KB/s, 1KB/s and then also get spikes like 67KB/s, 22KB/s
[10:40] <Peng> Wait a minute. "Interrupted system call"? As in EINTR?
[12:01] <Altreus> Hey, I accidentally forgot to specify files to commit. Can I un-commit?
[12:01] <Altreus> oh
[12:01] <Altreus> uncommit heh
[12:02] <Altreus> I didn't expect that to be there :o
[14:46] <igc1> night all
[16:40] <ronj> Hello. It's impossible for me to to even a simple bzr branch, I always get http://pastebin.com/mrm62Bd1 . However, 1. my public key is in ~/.ssh/launchpad_id_rsa.pub, 2. It matches what LP outputs when I click on  "SSH keys: ronj@launchpad.blob", and 3. I tried removing it from LP and reimporting it. Help!
[16:41] <ronj> Using Ubuntu 9.10 x86 with bzr 2.0.2
[16:42] <ronj> And I forgot to mention: it used to work. I don't know what caused it no now fail
[16:59] <davertron> hi guys, i currently have a bzr branch that's pack-0.92 that i want to convert to rich-root-pack so i can pull; how can I do this?
[17:00] <jelmer> davertron: bzr upgrade --rich-root-pack
[17:00] <jelmer> davertron: or, alternatively -- 'bzr upgrade --2a' if you're on bzr >= 2.0
[17:00] <davertron> jelmer: is that a pretty safe avenue?
[17:00] <davertron> jelmer: should i worry about the possibility of a corrupted branch or anything like that?
[17:00] <jelmer> davertron: yeah, though I'd really recommend using 2a if you can - it's much faster
[17:01] <davertron> jelmer: looks like i'm using 1.13.1
[18:19] <bendj> For remote access, I know I can use bzr+ssh or sftp.  What's the _difference_ between the two?  When should I use which?  Does it matter?
[18:20] <LeoNerd> sftp uses a dumb filesystem on the other end; namely the SFTP server
[18:20] <LeoNerd> bzr+ssh shells in to the remote server, runs bzr, and uses it as a smart agent
[18:20] <bendj> LeoNerd: so bzr+ssh is a better opt, it seems
[18:20] <LeoNerd> bzr+ssh costs more in terms of resources on the server, but the smart agent can help reduce network usage or roundtrips
[18:21] <LeoNerd> Can be. Depends on your setup
[18:21] <LeoNerd> between my desktop and my server I use sftp, because my server is a celeron 333 with 784MiB of RAM accessible over a 100Mbit LAN with <1msec of latency.
[18:21] <LeoNerd> sftp is finished well before that celery has even fork()+exec()'ed a python process.
[18:24] <bendj> LeoNerd: Thanks for the explain!
[18:34] <IslandUsurper> does anybody know if horizontal scrolling with the mouse wheel doesn't work in qbzr because of qbzr or Qt itself?
[18:37] <IslandUsurper> I'm using a touchpad, but I know that's not the problem because Chrome and Firefox scroll horizontally when I use it
[18:43] <luks> IslandUsurper: where in qbzr?
[18:43] <luks> it works for me in qdiff
[18:43] <luks> (using a touchpad)
[18:44] <luks> also works in qlog
[18:49] <IslandUsurper> luks, well, I was looking at qdiff
[18:49] <IslandUsurper> However, I'm using Windows
[18:55] <luks> ah, can't test on windows right now
[18:56] <IslandUsurper> when I get home, I guess I can test it on Linux
[19:09] <maxb> Hi, I've just found a crash in qbzr owing to lazy-importing bzrlib.revision.NULL_REVISION. Is lazy-importing a constant ever the right thing to do?
[19:19] <salgado> vila, around?  can you have a peek at https://answers.edge.launchpad.net/launchpad/+question/105604?
[19:19] <salgado> (I just ran 'bzr get lp:vm' and it worked just fine)
[20:28] <mwhudson> jam: does that loggerhead merge proposal have any particular bzr version requirements?
[20:34] <GaLiLe0> we are looking for a version control system for our developers to install on their machines. Some dev work is done directly on a web server though. can Bazaar integrate directly to keep a backup of files on a remote web server?
[20:45] <beuno> GaLiLe0, you have a plugin called "bzr-upload" which will just upload the working tree
[20:47] <GaryvdM> Hi all.
[20:47] <jelmer> hey Gary
[20:47]  * GaryvdM came to find bailix
[20:47] <GaryvdM> Hi Jelmer
[20:48] <GaryvdM> \o/ Built qbzr inno installer under wine :-)
[20:49] <GaryvdM> Bye - rebooting to test in windows....
[21:04] <beuno> jam, ping
[21:08] <thumper> jelmer: we have some fun problems with bzr-git
[21:08] <thumper> jelmer: in particular the size of the cache for the incremental kernel import
[21:13] <jam> hi beuno
[21:13] <jam> mwhudson: I'm sure it does, I don't know it offhand, probably bzr 2.1?
[21:13] <jam> maxb: it would be reasonable to lazy-import the module
[21:14] <beuno> jam, 1) You rock! Thank you for the loggerhead branch.  2) Is it compatible with previous bzr'z?
[21:14] <jam> but yeah, the constant is bad
[21:14] <jam> beuno: prob bzr 2.1
[21:14] <beuno> ah, mwhudson already asked that  :)
[21:14] <jam> beuno: actually, I see "KnownGraph" in one of my bzr 2.0 branches, let me look closer
[21:15] <jam> KnownGraph was introduced in bzr 1.18
[21:15] <mwhudson> sounds ok to me then
[21:15] <beuno> me too
[21:15] <mwhudson> ps: does someone want to maintain loggerhead instead of me?
[21:15] <jam> however, KnownGraph.get_parent_keys is in 2.1, but not 2.0
[21:16] <mwhudson> i don't feel like i've been doing a very good job lately
[21:16] <mwhudson> jam: ah
[21:17] <beuno> I vote for Peng
[21:17] <jam> let me see if there is a way to work around it in an obvious manner
[21:18] <jam> mwhudson: both the C and python versions expose self._nodes which is the internal graph
[21:18] <GaryvdM> jam: I've bumped qbzr min required bzrlib version due to that.
[21:19] <jam> however, the objects in there aren't identical wrt the C vs python versions
[21:19] <jam> so it isn't great to grab that
[21:19] <jam> I could certainly write (ugly) code that would work under all versions
[21:19] <jam> if 2.0 compatibility is important
[21:20] <jam> (pure python stores a reference-by-key , Pyrex stores a reference-to-the-node)
[21:21] <beuno> jam, I think we can just say that the next release of LH only works with 2.1
[21:21] <beuno> and it's twice as fast  :)
[21:22] <jam> well, this isn't the history cache loading, just the generation without-cache step
[21:22] <jam> I'm toying with ideas about how to handle a graph data store that isn't "1 rev-at-time" while also not being "all revs, all the time"
[21:22] <jam> I plan on writing something up for the list
[21:23] <beuno> I think the first hit is usually what gives people the impression it's slow
[21:23] <jam> though honestly, the loggerhead code doesn't really need to be calling "self._load_whole_history_data()" all the time
[21:23] <jam> which could help a lot
[21:23] <jam> The main page doesn't seem like it uses most of that data
[21:23] <mwhudson> jam: i think hazmat has been working on that
[21:24] <jam> mwhudson: assuming that is the same Kapil that was posting to canonical-tech, that is actually what inspired me to look into this code
[21:25] <hazmat> jam, mwhudson i just removed it from a views that where obvious, i'm not  going to be actively pushing it, my knowledge of bzr internals is pretty rudimentary
[21:25] <jam> however, his discussion was "use chameleon, disable all the stuff that seems to be O(history)"
[21:25] <hazmat> jam, thanks for having a look at that
[21:25] <jam> vs, how keep the info, without having to load the *entire* history
[21:25] <hazmat> i checked out your branch, it does seem to better on the cache computation
[21:26] <hazmat> but yeah.. that's an accurate summary :-)
[21:26] <jam> mwhudson: so, other than pushing data into production, and letting people bang on it, what sort of testing does loggerhead have?
[21:26] <jam> specifically, if I just started hacking in 'history.py' to make it not load the whole graph
[21:26] <mwhudson> jam: yeah, that's about it
[21:26] <jam> how would I find out where the gotchas are
[21:26] <mwhudson> jam: i don't know
[21:27] <jam> code-inspection it is, I guess
[21:27] <mwhudson> the code makes me very sad in general
[21:27] <jam> btw, there is one other part of my patch I didn't mention, which is the "try: import loggerhead.app.branch" stuff
[21:27] <mwhudson> there's not actually that much code at least
[21:27] <jam> for some reason on my machine, "try: import loggerhead" succeeds
[21:27] <jam> but "try: import loggerhead.apps.branch" fails
[21:27] <mwhudson> oh yes
[21:27] <mwhudson> that end of things is all screwed up too :/
[21:28] <jelmer> thumper: Hi
[21:28] <thumper> jelmer: on a call right now, with you shortly
[21:29] <jam> anyway, with that patch "bzr serve --http" works for me, so I'm happy enough with it :)
[21:29] <jelmer> thumper: If it's a stand-up, mwhudson knows about it :-)
[21:30] <jam> mwhudson: what is "cache_key", it seems to be BranchWSGIApp.friendly_name, but that still doesn't help much
[21:30] <jam> is it ~ the path on disk?
[21:32] <jam> and, IIRC, the mapping in the sql data structure is "branch_tip_revision => revision_graph_of_whole_ancestry" right?
[21:32] <jam> (so the data currently stored cannot be parsed in anything less than all history)
[21:34] <mwhudson> jam: it's supposed to identify the branch
[21:34] <jam> mwhudson: in theory this could also be applied to your valid concern about the branch => ancestry table
[21:34] <jam> since that is O(branches*ancestry)
[21:36] <poolie> jam, hi?
[21:36] <jam> hi poolie
[21:36] <poolie> shall we talk?
[21:36] <jam> are you off DST yet?
[21:36] <poolie> not yet, next weekend
[21:36] <poolie> so it's 7:30 here
[21:36] <jam> poolie: I have nothing to say to you :)
[21:36] <jam> sure
[21:37] <jam> poolie: how about skype?
[21:37] <poolie> sure
[21:37] <thumper> vila: thanks for jumping in on that question
[21:38] <vila> thumper: I'm ill, so don't hope too much either :-/ I just woke up after falling alseep instead of dining (to give you some idea ;-)
[21:39] <jam> poolie: I logged in, but I don't see you on skype yet
[21:39] <poolie> likewise
[21:39] <thumper> vila: sorry you're feeling crap, get well soon
[21:41] <vila> thumper: no worries, I'm rarely ill and it rarely last long :) (crossing fingers, killing some chicken, etc)
[21:47] <maxb> I love qbzr. Not only is it an amazing tool, but I'm repeatedly astonished by how fast bugs are turned around. <4 hours filed->fixed in this case :-)
[21:52] <GaryvdM> maxb: I was doing the release, and it was a easy thing to fix.
[21:53] <GaryvdM> maxb: Thanks for the bug report.
[21:54] <maxb> You deserve the praise - this isn't the first time I've had a bug turnaround measured in hours :-)
[21:54] <GaryvdM> maxb: However, we do have our share of old bugs, and open bug seems to grow all the time :-~
[21:55] <maxb> So do all projects, I fear
[21:55] <lifeless> moin
[21:56] <GaryvdM> moin lifeless
[22:12] <poolie> can someone review my apport mp?
[22:17] <GaryvdM> jelmer: If I want to add an entry to debian/changelog, but I am not going to be uploading, should I just exclude the -- Gary... line?
[22:24] <jelmer> GaryvdM: Just include it - whoever will actually do the upload will change it to their name
[22:25] <GaryvdM> jelmer: Ok thanks
[23:07] <Boingo> Hello everyone.  I am still a bit new to bzr and trying to get my head wrapped around how I should best use it.  In my case, I have a distributed team work on a base project (PHP website).  Most of the work goes into the base product.  But, from time to time, we need to branch and create specific version for a client.  Most of the changes are cosmetic, CSS, images, etc.  Some are code changes.  Either way, we would like to be able to track the changes in th
[23:11] <timClicks> is there an equivalent to bazaar explorer for Gtk+?
[23:13] <GaryvdM> timClicks: olive, which is a part of bzr-gtk
[23:13] <timClicks> GaryvdM: ty
[23:15] <GaryvdM> timClicks: You can also configure bzr explorer to use the bzr-gtk dialogs, but it will still require that you have qt installed (which i guess is what you don't want)
[23:16] <timClicks> well, I'm fine mixing and matching but used a Windows machine for checking out some code yesterday
[23:16] <timClicks> and was really impressed by Bazaar Explorer
[23:16] <timClicks> and wanted to have something that easy for my Ubuntu machine
[23:17] <GaryvdM> timClicks: bzr explorer/qbzr will honner your gnome styles, if thats whats important
[23:18] <GaryvdM> timClicks: see http://doc.bazaar.canonical.com/explorer/en/visual-tour-gnome.html
[23:24]  * timClicks didn't realise that bazaar explorer was available for GNOME
[23:30] <GaryvdM> timClicks: bzr explorer is built with qt. (qt!=kde)
[23:30]  * timClicks nods
[23:30] <timClicks> understood
[23:31] <timClicks>  I actually thought it was a native MS Windows app
[23:31] <GaryvdM> Oh
[23:31] <timClicks> things make much more sense now
[23:38] <jrib> Hi, how does one start bazaar explorer in OS X?  I installed the desktop bundle and qt libraries (things like bzr qinit work ok from a terminal)
[23:39] <GaryvdM> jrib: run bzr explorer
[23:40] <GaryvdM> jrib: there is allready a bug for adding a application shortcut
[23:41] <jrib> GaryvdM: hmm, I'm getting "bzr: ERROR: unkown command "explorer"".  I installed 2.0.1 + desktop bundle
[23:43] <GaryvdM> jrib: thats odd. Do you see explorer under bzr plugins ?
[23:43] <jrib> GaryvdM: bzr plugins | grep -i explore    returns nothing
[23:45] <jrib> GaryvdM: it is possible that I installed bzr some other way and now installed the bundle on top of it (I don't use OS X and am just trying to get some simple instructions down for a colleague).  bzr currently points to /usr/local/bin/bzr
[23:45] <GaryvdM> jrib: sorry - I don't own a mac. Not sure
[23:46] <jrib> GaryvdM: ok, thank you.  In any case, it's clear now that if I did have explorer installed it should be listed under bzr plugins, right?
[23:46] <GaryvdM> jrib: yes
[23:47] <GaryvdM> jrib: If you have pyqt installed, then you should be able to just put bzr-explorer in the plugins dir
[23:47] <GaryvdM> Not sure where that would be though
[23:52] <jrib> GaryvdM: thanks, copying it to the plugins folder was sufficient.  Now I have to redo it without using a terminal to explain it to my friend :)
[23:53] <GaryvdM> jrib: Not sure why + desktop bundle did not work for you.
[23:54] <GaryvdM> I ran it on a family members mac once, an it worked for me