[00:21] <dOxxx> lifeless: ah, my bad
[00:22] <poolie> hi dOxxx
[00:22] <dOxxx> hey poolie
[00:22] <dOxxx> I'm kinda stoked the merge tool gui stuff is finally getting into a release :)
[00:22] <poolie> great
[00:23] <poolie> i have to confess i hadn't seen that
[00:23] <poolie> do you mean the upcoming bzr 2.4?
[00:23] <dOxxx> yeah, the corresponding gui changes in qbzr were merged in recently
[00:23] <dOxxx> so they should be in this next beta
[00:24] <dOxxx> if you're packaging trunk of qbzr, that is
[00:30] <dOxxx> ~seen vila
[00:30] <dOxxx> poo, no chanbot
[00:32] <poolie> probably just a bit late for him
[00:32] <poolie> well, 2:30am in france, so pretty late
[00:34] <dOxxx> yeah, I sent him an email
[03:53] <chrisvj> I have a checkout of my code on launchpad. When I try to commit to it, I get http://pastebin.com/mNfaDG5X  can someone help me?
[04:02] <spiv> chrisvj: possibly https://bugs.launchpad.net/bzr/+bug/571064 ?
[04:03] <chrisvj> spiv, im running windows, not ubuntu
[04:03] <chrisvj> afk
[04:04] <spiv> Sure, I don't think that rules out it having essentially the same cause.
[04:04] <spiv> That said, I'm far from sure it's the same bug (but not because of Ubuntu vs. Windows).
[04:05] <spiv> What does 'bzr info' say?  IIRC this might also be due URL aliasing or something like that.
[04:06] <chrisvj> back
[04:06] <spiv> Ugh, still jet lagged a bit.
[04:06]  * spiv makes a coffee
[04:07] <chrisvj> http://pastebin.com/TZzf0Pug
[04:09] <jimis> I work on a lightweight checkout of a branch, and I have some uncommitted change that I want to find next time I work on this. How can I *switch* to another branch, and switch back later to continue my uncommitted changes?
[04:11] <chrisvj> spiv, any breakthroughs?
[04:34] <dmuir> I know this isn't really the place to ask, but I tried over in the mercurial channel, and nobody's responding... anyway, the question is, does hg have a direct equivalent of bzr merge?
[04:34] <spiv> jimis: to switch, just use 'bzr switch'
[04:34] <spiv> jimis: you may want to 'bzr shelve' your uncommitted changes first
[04:37] <spiv> dmuir: I'm hardly an hg expert, but I would've guessed "hg merge".
[04:38] <dmuir> spiv: that's what I would have thought too, but it only works if a pull results in two heads. The problem I have is that pull is doing a fast-forward, so there's only one head.
[04:40] <spiv> dmuir: huh.  I wouldn't have expected that based on my quick reading of the man page.  Unfortunately I have no other guesses for you!
[04:40] <spiv> dmuir: I suppose you could try installing bzr-hg and using 'bzr merge' ;)
[04:41] <dmuir> spiv: haha, yeah, was thinking of doing that too
[04:48] <jimis> spiv: thanks, shelve worked fine
[05:40] <jimis> damn, bzr 2.4 is *many times* faster than 2.3.3 on some operations
[05:41] <jimis> I just built a custom python in my homedir to be able to use it, because 2.3.3 took almost 9min for a "bzr switch"
[05:41] <jimis> and 2.4 is indeed much faster
[05:42] <spiv> jimis: :)
[05:42] <vila> jimis: dropping compatibility with python-2.4/2.5 was a conscious decision based on the assumption that, for RH, getting a python2.5/2.6 was easy enough to not be a blocker
[05:43] <jimis> vila: easy enough only if you have admin :-)
[05:44] <vila> jimis: so the overall plan is to keep 2.3 compatible with 2.4/2.5 but any info about making it easy (or easier) to get python2.6/2.7 (or even .rpm packages) will be very welcome
[05:46] <jimis> vila: if you don't have admin privs you have to build python from source
[05:46] <jimis> vila: tedious, especially since that is the case you will be missing some -dev packages...
[05:47] <jimis> for example, in my case bzip2-dev was missing and I just noticed that python was built without it, so bzr is misbehaving :-)
[05:47] <vila> jimis: that's a trade-off, we have limited resources too.
[05:47] <vila> jimis: file a bug !
[05:48] <jimis> vila: for what? bz2 is necessary isn't it? So it's my fault if I built python without it?
[05:48] <vila> jimis: we're generally pretty good at tracking hard and soft dependencies so that such issues are noticed and fixed
[05:49] <vila> jimis: it could be a soft dependency and gives a nice error message telling you what is missing
[05:51] <jimis> I see. So it's probably a bug since it setup.py didn't warn me that python didn't support bz2
[05:53] <vila> jimis: could be there, could be in bzr itself, but definitely a bug, yes: http://pad.lv/fb/bzr ftw :)
[05:53] <vila> jimis: err, wait a sec, you used setup.py ?
[05:53] <jimis> yeap
[05:54] <jimis> python2.7 setup.py --prefix=$HOME/dist install
[05:54] <vila> jimis: ... as opposed to a bzr .rpm (I know almost nothing about how rpm works, so speak slowly ;)
[05:54] <vila> huh ? You have a python-2.7 ??
[05:54] <jimis> vila: rpms are only for administrators
[05:55] <vila> jimis: you can run from source
[05:55] <jimis> vila: I have compiled python2.7 in my home dir, that's why I explicitly use it with setup.py
[05:55] <vila> great ! So you can use 2.4 on RH !
[05:55] <jimis> I'm having problems, that's what I'm saying :-p
[05:56] <jimis> bz2 module for example
[05:56] <vila> jimis: ... there should a place on the wiki to capture your experiments and bugs...
[05:56] <jimis> :-)
[05:56] <vila> http://wiki.bazaar.canonical.com/DistroDownloads#CentOS/RHEL
[05:57] <vila> jimis: you should be able to edit this page, ask for help here if you can't
[05:59] <jimis> vila: later maybe, I'll try to get it working first :-)
[05:59] <vila> jimis: if I read that right, it indeed requires admin privileges so describing what a *regular* user can do will be useful
[05:59] <vila> jimis: sure, thanks for that !
[06:00] <jimis> but it's getting way too complex
[06:00] <jimis> I should compile custom bzip2 in $HOME, recompile python using that one, and *then* install bzr2.4 using that python
[06:03] <vila> Is there any rpm packager around that could help ?
[06:03] <spiv> vila: it's not an rpm packaging issue
[06:03] <spiv> vila: jimis doesn't have the permissions to install rpms on that system
[06:04] <vila> spiv: I get that. But building packages and being able to use them as a regular user is probably better understood by packagers nevertheless
[06:04] <spiv> jimis: note that as vila says you don't need to install bzr, you can just do 'make build' and run it straight from its source dir just fine
[06:05] <vila> jimis: how is bzr failing with regard to bzip2 ?
[06:05] <vila> jimis: for a specific operation requiring bzip2 or for an unrelated operation ?
[06:06] <spiv> Well, there is 'rpm install --prefix=/home/…' I suppose.  I imagine it's a bit fragile though
[06:06] <jimis> vila: for a "switch -b newbranch"
[06:08] <vila> jimis: right, so this shouldn't require bzip2, definitely a bzr bug
[06:08] <vila> jimis: did you get a traceback or something ?
[06:09] <vila> jimis: we just froze 2.4b5, but there is still  time to fix such issues before 2.4.0
[06:09] <jimis> bzr switch -b df2-vecs
[06:09] <jimis> bzr: ERROR: No module named bz2
[06:09] <jimis> You may need to install this Python library separately.
[06:10] <jimis> vila: In how many points is bzr2.4 incompatible with python2.4? Will you accept patches that fix that?
[06:11] <jimis> If they are a few maybe it's the easiest path :-p
[06:12] <vila> jimis: using 'with' to start with plans to use b'' and things like that
[06:14] <vila> jimis: I don't know if we have an official policy about such patches, but the tendency is to lower the burden of maintaining this compatibility with py2.4 :-}
[06:14] <vila> jimis: so making it easier to use py2.6/2.7 would be preferred ;)
[06:14] <jimis> ah I see now
[06:14] <spiv> There was an extended discussion on the mailing list before we dropped 2.4 support
[06:15] <jimis> I thought it just happened and compatibility was lost :-)
[06:15] <jimis> ok, I'll check it
[06:15] <spiv> It's unlikely we'd revert that; bzr 2.3 is still there for folks that are stuck with Python 2.4
[06:15] <vila> jimis: but file a bug about bzip2 so we support it as a soft depedency
[06:15] <jimis> anyway, I agree that python2.4 misses lots of niceties
[06:16] <jimis> vila: ok
[06:17] <spiv> Yes, it's a bit surprising that bz2 is needed by 'bzr switch', I think we only use it for bundles, export to .tar.bz2, and in the smart server protocol.
[06:18] <spiv> We could probably usefully add an import tariff test about that...
[06:24]  * vila nods @ spiv
[06:25] <vila> hmm, no poolie around ? EODed ?
[06:27] <vila> spiv: ? ^
[06:27] <spiv> He was around this morning, but I wouldn't rule out a surprise jetlag-induced nap.
[06:27] <vila> fair enough, let him nap in peace :D
[06:28] <spiv> Or he might just be away from IRC and thus actually getting some work done ;)
[06:32] <vila> tada !
[06:32] <fullermd> Phew!  Now we don't have to worry about work getting done   :p
[06:32] <dmuir> spiv: hg merge was the right command, but it only works when you're using named branches
 vila: In how many points is bzr2.4 incompatible with python2.4? Will you accept patches that fix that? <- I'd have kept it compatible had that been an option
[07:24] <mgz> there wasn't really time in 2.4 to do anything but break things without using new features so I didn't really see the point, but most people on this list wanted to drop compat
[07:25] <mgz> and semi-related, I wish bzr would deprecate bz2 usage, only the smart server wants it and it's not a great cpu/bandwidth tradeoff in my opinion, just staying with zlib would be better
[07:26] <poolie> hi mgz
[07:27] <mgz> morning poolie!
[07:27] <poolie> it is pretty expensive of cpu for what it gains
[07:27] <lifeless> hi poolie
[07:27] <lifeless> happy friday
[07:30] <poolie> hi there
[07:30] <poolie> mgz, well, we have used some new features
[07:30] <poolie> the big payoff will be if we can get to 3.0 support
[07:30] <mgz> but that's not happening for 2.4
[07:31] <poolie> it would probably be feasible to re-add python 2.4 support now that it's branched off
[07:31] <poolie> that's ture
[07:31] <poolie> *true
[07:31] <mgz> and the cool 2.4 features would be cool regardless of python version
[07:32] <mgz> on the other hand, there aren't many jimises compared to people on the list who didn't want to have to think about backwards compatibility any more.
[07:40] <vila> mgz: yup, that was the trade-off, dropping py2.4 support is a significant step towards 3.0
[07:46] <mgz> I have big doubts about that vila.
[07:47] <mgz> and trying to support py3k will make us all beg for the days of just having to support 2.4 to 2.7
[07:49] <spiv> Ok, one mp submitted, and mysterious test failures irrelevant to the stacking fetch bug I'm working on diagnosed and worked-around.  A good time to EOD and EOW I think.
[08:10] <vila> mgz: well, there have been feedback that maintaining a single code for 2.4 to 3.0 was... ouch, hairy
[08:10] <vila> mgz: but I don't have first hand experience with that
[08:17] <mgz> as far as I can see, the hairy stays even with 2.4 and 2.5 dropped
[08:18] <mgz> most of the hard problems I've run into have been abstractions and interfaces shifting, not spelling changes
[08:27] <vila> mgz: but some hairy can't go without dropping (that's my understanding and belief)
[08:28] <vila> mgz: overall, I expect *more* progress by dropping than by keeping (imbw)
[08:28] <mgz> that's what I have doubts over.
[08:28] <mgz> eg.
[08:28] <mgz> python 3 doesn't support u"" literals
[08:29] <mgz> so, the fact python 2.6 adds b"" literals helps not at all, as you still need to run a source-level rewrite to support both versions
[08:30] <mgz> python 2.6 doesn't solve any of the actual problems with string types you'll run into trying to support python 3, even in the standard library let alone your own code
[08:37] <poolie> Riddell, hi?
[08:38] <Riddell> good morning poolie
[08:38] <poolie> yeah, the py3 stuff may be just too hard
[08:38] <poolie> hi there, how are you?
[08:38] <Riddell> I'm all good thanks
[08:41] <poolie> cool
[08:42] <poolie> i was thinking this morning it would be good to have you do some more stuff that specifically connects bzr to ubuntu
[08:42] <poolie> and vice versa
[08:42] <poolie> one idea i had towards this could be if you were to review the new packaging guide that barry and co are working on
[08:42] <Riddell> sure, I can do that
[08:44] <poolie> that would be cool
[08:44] <poolie> we could get either some improvements to the docs
[08:44] <poolie> or, perhaps identify some things that are clunky to describe and could be reasonably easily technically improved
[09:39] <poolie> jam, hi?
[09:39] <jam> hi poolie
[09:39] <poolie> hey there
[09:39] <jam> just away for a bit, had a "dutch integration interview"
[09:39] <poolie> !
[09:39] <poolie> aka "Let's go Dutch"
[09:39] <jam> Apparently if you live here longer than 3 years you are required to learn Dutch, etc.
[09:39] <poolie> good luck
[09:39] <poolie> could you see if you could help doko with a workaround ofr  https://launchpad.net/bugs/797915
[09:41] <jam> sure, looking at it now
[09:45] <poolie> thanks very much
[09:45] <poolie> doko's in #launchpad
[10:34] <poolie> good night all
[10:51] <AuroraBorealis> hello, i'm still having problems with bzr explorer getting hung up on 'could not acquire lock"
[12:56] <vila> jam: ping
[14:09] <lparry> Hi guys, I'm looking into a  method of versioning CAD files as part of a collaborative engineering project. Would Bazaar be able to cope?