=== yofel_ is now known as yofel
=== bigjools-afk is now known as bigjools
=== Peng_ is now known as Peng
[08:10] <mgz> morning
[10:56] <xnox> bzr-cia is broken due to hostname changes. Please review & merge https://code.launchpad.net/~xnox/bzr-cia/fix-hostname/+merge/122490
[10:56] <jelmer> xnox: Thanks, looks good
[10:58] <xnox> jelmer: thanks. Kind-of broke the work flow used by #ubuntu-installer devs
[11:00] <jelmer> xnox: Merged now; I'll also update cia-clients
[11:00] <xnox> cool! =) thanks
[11:00] <jelmer> We should probably file a RC bug about this.
[11:24] <kinkie> Hi all, a question: I need to merge a branch which is stored in a format 2a repo into one which is in format pack-0.92. direct merge will not work, nor will going through a bundle. Is there any way to do it without losing the merged branch history?
[11:24] <kinkie> thanks
[11:25] <jelmer> hi kinkie
[11:25] <jelmer> kinkie: how are things?
[11:25] <kinkie> Hi jelmer
[11:25] <jelmer> kinkie: there is no easy way to do that. Why do you still have a branch in 0.92 format?
[11:25] <kinkie> jelmer: doing fine.. doing some endless refactoring on squid.
[11:26] <kinkie> Some squid developers are running old platforms and are not happy about being forced to upgrade to newer versions of bzr :\
[11:27] <kinkie> apart from that, I'm running marathons - it's fun and relaxing, but it  takes lots of time :)
[11:28] <kinkie> back to the merge: you said that there is no easy way. What is the hard way? :)
[11:29] <jelmer> kinkie: even to bzr 1.16, which was released in June 2009?
[11:29] <kinkie> Guess so.   I hope I'll manage to convince them sooner than later.
[11:30] <jelmer> kinkie: The hard way is to replay the entire branch in the 0.92 format somehow
[11:31] <jelmer> with new revision ids
[11:31] <kinkie> bzr diff -c <revid>,  bzr commit -m "message"?
[11:31] <kinkie> foreach revid to be merged?
[11:32] <jelmer> kinkie, yes, roughly
[11:32] <kinkie> sigh.. there's 100 of them :\
[11:32] <kinkie> okay
[11:32] <kinkie> thanks
[11:32] <jelmer> kinkie: the rich root migration was a bit of a mess :-(
[11:33] <kinkie> Heh. I am sure that if it was a mess, it's because there was no other way
[11:33] <jelmer> kinkie: yup; doesn't make it less of a pain though..
[11:34] <mgz> can't you fast import to older formats?
[11:35] <mgz> manually scripting the replay seems painful and error prone
[11:35] <jelmer> mgz: ah, that's a good point
[11:36] <jelmer> kinkie, that's worth a shot too
[11:36] <kinkie> Sounds interesting. Is there a recipe?
[11:36] <kinkie> I'm branching the fastimport plugin now.
[11:41] <jodh> I'm having trouble getting a packaging recipe to work (http://paste.ubuntu.com/1183378/). The 'nest-part' seems to work, but when I attempt to build using pbuilder, no build actually happens and I end up with a .deb containing only config files. Anyone have any ideas?
[11:43] <jelmer> hi jodh
[11:43] <jelmer> jodh: Does the source package that result from the recipe look okay?
[11:44] <kinkie> hm..:
[11:44] <kinkie> kinkie@metro:~/squid/workspace/sourceformat$ bzr fast-export
[11:44] <kinkie> bzr: ERROR: Unable to import library "fastimport": bzr-fastimport requires the fastimport python module
[11:44] <kinkie> kinkie@metro:~/squid/workspace/sourceformat$ bzr fast-import
[11:44] <kinkie> bzr: ERROR: command 'fast-import' requires argument SOURCE
[11:44] <kinkie> yet the fastimport python module has installed without errors
[11:44] <jelmer> kinkie, note that the fastimport python module is different from the fastimport plugin
[11:45] <mgz> that looks fine to me, the second one
[11:46] <mgz> you want `bzr help fast-import` maybe?
[11:46] <kinkie> isn't it distributed with the fastimport plugin itself?
[11:47] <kinkie> ok: lp:python-fastimport, right?
[11:48] <mgz> it's a dependency, but if you're branching from source, you're expected to be the kind of person who reads INSTALL
[11:48] <mgz> or at least after realising it doesn't work, reads it :)
[11:48] <kinkie> heh. Took me a short while ;)
[11:48] <kinkie> done and installed
[11:49] <kinkie> so the suggestion is fast-export then fast-import to convert the 2a branch to pack and then merge?
[11:50] <jelmer> kinkie, yep
[11:50] <kinkie> or can I fast-export the bundle directly? It'd just work ont he merge directive, right?
[11:50] <jelmer> kinkie: I'm pretty sure that wouldn't work
[11:50] <mgz> it probably expects a branch, but you can convert a bundle to a branch reasonably simply
[11:51] <kinkie> nah, I'll just go the branch way
[11:52] <kinkie> I'll be damned, it IS fast - 3k commits/minute
[11:52] <kinkie> neat
[12:04] <sil2100> Hello uys
[12:04]  * sil2100 has keyboard problems
[12:05] <mgz> do we need to think of words with lots of gs in to try to get you to type?
[12:05] <jodh> jelmer: thanks for the pointer. I don't understand why yet, but the usual ubuntu packaging seems to automagically add a couple of gobs of black magic to the packaging. And that doesn't seem to happen in the recipe scenario. However, I now have a lead to follow...
[12:05] <jelmer> kinkie: you shouldn't export the entire branch, just the new revisions - otherwise you'll have trouble merging later
[12:05] <jelmer> jodh: recipes are just a way of creating a source package
[12:05] <sil2100> Anyway, I need help, since I think I broke by accident the unity merger
[12:06] <jelmer> hi sil2100
[12:06] <sil2100> Hi jelmer!
[12:06] <jelmer> sil2100: what can we help with?
[12:06] <jelmer> jodh: so after you've built the recipe, the usual ubuntu packaging comes into play
[12:06] <mgz> sil2100: which branch? the quantal packaging one?
[12:06] <sil2100> jelmer: ok, so... we had a wrongly placed tag in bamf trunk, so I wanted to move it to the right place - so I did a bzr tag --delete, bzr tag and push, but now it seems that whoever wants to do a bzr pull gets a tag conflict
[12:07] <sil2100> mgz: no, bamf source branch
[12:07] <jelmer> sil2100: the easiest workaround is for them to remove their local tag by that name and then pull
[12:07] <mgz> sil2100: okay, so everyone could do that same operation on their local branches (annoying)
[12:07] <mgz> or you could delete the tag from the master and just let it revert
[12:08] <jelmer> sil2100: tags aren't versioned, so there is no easy way to replicate changes to existing tags
[12:08] <sil2100> jelmer, mgz: the problem is, the mergers do a bzr pull without any -overrides
[12:08] <sil2100> jelmer: if I re-add the tag in the same place as it was, will it be the 'same' tag and not make any conflicts?
[12:08] <jelmer> sil2100: also, newer versions of bzr have 'bzr pull --overwrite-tags'
[12:08] <jelmer> sil2100: yes
[12:08] <mgz> basically, one side or the other needs to have the tag deleted before pull
[12:08] <mgz> no overwrite needed.
[12:09] <jodh> jelmer: well, something is going awry as the rules file for Ubuntu seemingly is behaving differently under pbuilder with upstream source than with the ubuntu source. I'm having to force a dh_autoreconf for the upstream case.
[12:09] <sil2100> jelmer, mgz: thanks!
[12:09] <jelmer> jodh: the ubuntu source probably comes with a prebuilt version of configure, whereas the upstream source doesn't have one
[12:09] <jelmer> jodh: in other words, the contents of the tarball and the upstream branch are different (does the tarball perhaps have an autogen.sh that's run?)
[12:12] <jodh> jelmer: you're right - the ubuntu branch has configure under vc whereas upstream doesn't. There is no autogen.sh in either branch.
[12:15] <sil2100> jelmer: just one more question - is there a nice way of moving a tag from one commit to another without breaking bzr pull's of others?
[12:30] <jelmer> sil2100: only if they didn't have the old version of the tag (since tags are not versioned)
[12:37] <sil2100> jelmer: awww, too bad... thanks
[15:11] <kinkie> jelmer, mgz: I tried and failed to do as you suggested :( Maybe I need a step-by-step recipe :\ Can we talk about this tomorrow maybe?
[15:11] <kinkie> Thanks
[15:11] <kinkie> (now I must go)
[15:14] <jelmer> kinkie: Sure, we'll be around tomorrow
[15:14] <jelmer> kinkie: Have a nice evening
[15:17] <SamB_MacG5> vila: Hmm, how do I uninstall the Qt packages installed by the mac installer? They aren't showing up in pkgutil(1)'s output...
[15:19] <vila> SamB_MacG5: pfew, isn't there an uninstaller with the isntaller (it's been a looong time since I looked at an OSX install)
[15:20] <vila> SamB_MacG5: if I were to try doing that myself, I'll search the recipe that every install leave in some dir below... /Library ? /System/Library ?
[15:22] <SamB_MacG5> vila: I got your name from the source paths compiled into the Python extensions from the most recent powerpc/i386 universal installer I could find
[15:22]  * vila blushes
[15:23] <vila> SamB_MacG5: yeah, I did build some installers for some time *after* I was really hacking on OSX, but really, just execute the scripts and smoke test them
[15:24] <SamB_MacG5> ah
[15:24] <vila> SamB_MacG5: so I have some background but the mac I used is... not at my desk anymore
[15:25] <mgz> I'd think macs were best used as desks. anything not a computer, for that matter. door stop, frisbee...
[15:25] <vila> SamB_MacG5: but I don't remember ever building powerpc stuff unless the compiler was a cross-compiling one being my back ;)
[15:25] <SamB_MacG5> Can't you, like, install Amiga OS 4 on powermacs or something ?
[15:26] <vila> dunno, I install Ubuntu on the macs that are on my desk
[15:27] <fullermd> Unbutu?  Is that like Amiga OS 5 or something?
[15:27] <vila> yeah
[15:27] <mgz> it's like freebsod
[15:27] <mgz> but with different colours
[15:27] <fullermd> freelsd comes with every color.  And then some.
[15:29] <SamB_MacG5> vila: that would explain why the Qt, SIP, and PyQt included in the installer in question are all intel-only ;-P
[15:30] <vila> SamB_MacG5: hehe, yes :) Are you really trying to install on a powermac ?
[15:30] <SamB_MacG5> oh, I installed it on a power mac ages ago
[15:31] <fullermd> (which is when pretty much anything done on a power mac was done  ;p)
[15:31] <SamB_MacG5> by which I mean some months
[15:32] <vila> but with which version of OSX ? Due to lack of resources I think only osx 10.5 and 10.6 have installers built for them (at best)
[15:33] <vila> on the other hand, building your own is pretty easy (but will probably take some time to compile qt...)
[15:33] <SamB_MacG5> now I'm just trying to fix the bzr 2.3 mac installer build scripts and accompanying README so that the resulting installer will be fully universal when built on 10.5
[15:34] <mgz> SamB_MacG5: have you found lp:bzr-mac-installers?
[15:34] <SamB_MacG5> (distutils-based extension builds are automatically powerpc/i386 universal when built on 10.5)
[15:36] <SamB_MacG5> mgz: yes, I have, thanks to someone (you?) adding a link there to that one wiki page in response to my reporting a bug about there not being any mention of the build scripts there
[15:36] <mgz> I think credit goes to gordon (also the maintainer of the current mac installers)
[15:37]  * SamB_MacG5 couldn't remember who did it
[16:31] <Trmandy> Hi guys, I have a bzr branch in which I wish to "squash" all revisions up to 100 into a single commit, and retain revisions 101 and above. How can I go about doing this? I can't quite wrap my head around what is necessary to make this happen.
[16:34] <mgz> Trmandy: try playing with the export and import commands from bzr-fastimport
[16:34] <mgz> note this is rewriting history, so isn't a good thing for a public branch
[16:35] <Trmandy> yep, understood. This is a private branch
=== yofel_ is now known as yofel
=== marienz_ is now known as marienz