[00:21] lifeless: ah, my bad [00:22] hi dOxxx [00:22] hey poolie [00:22] I'm kinda stoked the merge tool gui stuff is finally getting into a release :) [00:22] great [00:23] i have to confess i hadn't seen that [00:23] do you mean the upcoming bzr 2.4? [00:23] yeah, the corresponding gui changes in qbzr were merged in recently [00:23] so they should be in this next beta [00:24] if you're packaging trunk of qbzr, that is [00:30] ~seen vila [00:30] poo, no chanbot [00:32] probably just a bit late for him [00:32] well, 2:30am in france, so pretty late [00:34] yeah, I sent him an email === medberry is now known as med_out [03:53] 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] chrisvj: possibly https://bugs.launchpad.net/bzr/+bug/571064 ? [04:02] Ubuntu bug 571064 in Bazaar "TooManyConcurrentRequests when trying to commit to a network repo with no network connection" [High,Confirmed] [04:03] spiv, im running windows, not ubuntu [04:03] afk [04:04] Sure, I don't think that rules out it having essentially the same cause. [04:04] That said, I'm far from sure it's the same bug (but not because of Ubuntu vs. Windows). [04:05] What does 'bzr info' say? IIRC this might also be due URL aliasing or something like that. [04:06] back [04:06] Ugh, still jet lagged a bit. [04:06] * spiv makes a coffee [04:07] http://pastebin.com/TZzf0Pug [04:09] 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] spiv, any breakthroughs? [04:34] 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] jimis: to switch, just use 'bzr switch' [04:34] jimis: you may want to 'bzr shelve' your uncommitted changes first [04:37] dmuir: I'm hardly an hg expert, but I would've guessed "hg merge". [04:38] 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] 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] dmuir: I suppose you could try installing bzr-hg and using 'bzr merge' ;) [04:41] spiv: haha, yeah, was thinking of doing that too [04:48] spiv: thanks, shelve worked fine [05:40] damn, bzr 2.4 is *many times* faster than 2.3.3 on some operations [05:41] 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] and 2.4 is indeed much faster [05:42] jimis: :) [05:42] 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] vila: easy enough only if you have admin :-) [05:44] 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] vila: if you don't have admin privs you have to build python from source [05:46] vila: tedious, especially since that is the case you will be missing some -dev packages... [05:47] 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] jimis: that's a trade-off, we have limited resources too. [05:47] jimis: file a bug ! [05:48] vila: for what? bz2 is necessary isn't it? So it's my fault if I built python without it? [05:48] jimis: we're generally pretty good at tracking hard and soft dependencies so that such issues are noticed and fixed [05:49] jimis: it could be a soft dependency and gives a nice error message telling you what is missing [05:51] I see. So it's probably a bug since it setup.py didn't warn me that python didn't support bz2 [05:53] jimis: could be there, could be in bzr itself, but definitely a bug, yes: http://pad.lv/fb/bzr ftw :) [05:53] jimis: err, wait a sec, you used setup.py ? [05:53] yeap [05:54] python2.7 setup.py --prefix=$HOME/dist install [05:54] jimis: ... as opposed to a bzr .rpm (I know almost nothing about how rpm works, so speak slowly ;) [05:54] huh ? You have a python-2.7 ?? [05:54] vila: rpms are only for administrators [05:55] jimis: you can run from source [05:55] vila: I have compiled python2.7 in my home dir, that's why I explicitly use it with setup.py [05:55] great ! So you can use 2.4 on RH ! [05:55] I'm having problems, that's what I'm saying :-p [05:56] bz2 module for example [05:56] jimis: ... there should a place on the wiki to capture your experiments and bugs... [05:56] :-) [05:56] http://wiki.bazaar.canonical.com/DistroDownloads#CentOS/RHEL [05:57] jimis: you should be able to edit this page, ask for help here if you can't [05:59] vila: later maybe, I'll try to get it working first :-) [05:59] jimis: if I read that right, it indeed requires admin privileges so describing what a *regular* user can do will be useful [05:59] jimis: sure, thanks for that ! [06:00] but it's getting way too complex [06:00] I should compile custom bzip2 in $HOME, recompile python using that one, and *then* install bzr2.4 using that python [06:03] Is there any rpm packager around that could help ? [06:03] vila: it's not an rpm packaging issue [06:03] vila: jimis doesn't have the permissions to install rpms on that system [06:04] 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] 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] jimis: how is bzr failing with regard to bzip2 ? [06:05] jimis: for a specific operation requiring bzip2 or for an unrelated operation ? [06:06] Well, there is 'rpm install --prefix=/home/…' I suppose. I imagine it's a bit fragile though [06:06] vila: for a "switch -b newbranch" [06:08] jimis: right, so this shouldn't require bzip2, definitely a bzr bug [06:08] jimis: did you get a traceback or something ? [06:09] jimis: we just froze 2.4b5, but there is still time to fix such issues before 2.4.0 [06:09] bzr switch -b df2-vecs [06:09] bzr: ERROR: No module named bz2 [06:09] You may need to install this Python library separately. [06:10] vila: In how many points is bzr2.4 incompatible with python2.4? Will you accept patches that fix that? [06:11] If they are a few maybe it's the easiest path :-p [06:12] jimis: using 'with' to start with plans to use b'' and things like that [06:14] 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] jimis: so making it easier to use py2.6/2.7 would be preferred ;) [06:14] ah I see now [06:14] There was an extended discussion on the mailing list before we dropped 2.4 support [06:15] I thought it just happened and compatibility was lost :-) [06:15] ok, I'll check it [06:15] It's unlikely we'd revert that; bzr 2.3 is still there for folks that are stuck with Python 2.4 [06:15] jimis: but file a bug about bzip2 so we support it as a soft depedency [06:15] anyway, I agree that python2.4 misses lots of niceties [06:16] vila: ok [06:17] 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] We could probably usefully add an import tariff test about that... [06:24] * vila nods @ spiv [06:25] hmm, no poolie around ? EODed ? [06:27] spiv: ? ^ [06:27] He was around this morning, but I wouldn't rule out a surprise jetlag-induced nap. [06:27] fair enough, let him nap in peace :D [06:28] Or he might just be away from IRC and thus actually getting some work done ;) [06:32] tada ! [06:32] Phew! Now we don't have to worry about work getting done :p [06:32] spiv: hg merge was the right command, but it only works when you're using named branches [07:23] 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] 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] 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] hi mgz [07:27] morning poolie! [07:27] it is pretty expensive of cpu for what it gains [07:27] hi poolie [07:27] happy friday [07:30] hi there [07:30] mgz, well, we have used some new features [07:30] the big payoff will be if we can get to 3.0 support [07:30] but that's not happening for 2.4 [07:31] it would probably be feasible to re-add python 2.4 support now that it's branched off [07:31] that's ture [07:31] *true [07:31] and the cool 2.4 features would be cool regardless of python version [07:32] 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] mgz: yup, that was the trade-off, dropping py2.4 support is a significant step towards 3.0 [07:46] I have big doubts about that vila. [07:47] 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] 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. === mrevell-lunch is now known as mrevell [08:10] mgz: well, there have been feedback that maintaining a single code for 2.4 to 3.0 was... ouch, hairy [08:10] mgz: but I don't have first hand experience with that [08:17] as far as I can see, the hairy stays even with 2.4 and 2.5 dropped [08:18] most of the hard problems I've run into have been abstractions and interfaces shifting, not spelling changes === hunger_ is now known as hunger [08:27] mgz: but some hairy can't go without dropping (that's my understanding and belief) [08:28] mgz: overall, I expect *more* progress by dropping than by keeping (imbw) [08:28] that's what I have doubts over. [08:28] eg. [08:28] python 3 doesn't support u"" literals [08:29] 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] 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] Riddell, hi? [08:38] good morning poolie [08:38] yeah, the py3 stuff may be just too hard [08:38] hi there, how are you? [08:38] I'm all good thanks [08:41] cool [08:42] i was thinking this morning it would be good to have you do some more stuff that specifically connects bzr to ubuntu [08:42] and vice versa [08:42] 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] sure, I can do that [08:44] that would be cool [08:44] we could get either some improvements to the docs [08:44] or, perhaps identify some things that are clunky to describe and could be reasonably easily technically improved [09:39] jam, hi? [09:39] hi poolie [09:39] hey there [09:39] just away for a bit, had a "dutch integration interview" [09:39] ! [09:39] aka "Let's go Dutch" [09:39] Apparently if you live here longer than 3 years you are required to learn Dutch, etc. [09:39] good luck [09:39] could you see if you could help doko with a workaround ofr https://launchpad.net/bugs/797915 [09:40] Ubuntu bug 797915 in Launchpad itself "large bzr-svn imports failing" [Critical,In progress] [09:41] sure, looking at it now [09:45] thanks very much [09:45] doko's in #launchpad [10:34] good night all [10:51] hello, i'm still having problems with bzr explorer getting hung up on 'could not acquire lock" [12:56] jam: ping === med_out is now known as medberry2 [14:09] 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? === medberry2 is now known as medberry === beuno is now known as beuno-lunch === beuno-lunch is now known as beuno === yofel_ is now known as yofel === medberry is now known as med_out