=== yofel_ is now known as yofel | ||
=== bigjools-afk is now known as bigjools | ||
=== Peng_ is now known as Peng | ||
mgz | morning | 08:10 |
---|---|---|
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:56 |
xnox | jelmer: thanks. Kind-of broke the work flow used by #ubuntu-installer devs | 10:58 |
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:00 |
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:24 |
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:25 |
kinkie | Some squid developers are running old platforms and are not happy about being forced to upgrade to newer versions of bzr :\ | 11:26 |
kinkie | apart from that, I'm running marathons - it's fun and relaxing, but it takes lots of time :) | 11:27 |
kinkie | back to the merge: you said that there is no easy way. What is the hard way? :) | 11:28 |
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:29 |
jelmer | kinkie: The hard way is to replay the entire branch in the 0.92 format somehow | 11:30 |
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:31 |
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:32 |
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:33 |
mgz | can't you fast import to older formats? | 11:34 |
mgz | manually scripting the replay seems painful and error prone | 11:35 |
jelmer | mgz: ah, that's a good point | 11:35 |
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:36 |
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:41 |
jelmer | hi jodh | 11:43 |
jelmer | jodh: Does the source package that result from the recipe look okay? | 11:43 |
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:44 |
mgz | that looks fine to me, the second one | 11:45 |
mgz | you want `bzr help fast-import` maybe? | 11:46 |
kinkie | isn't it distributed with the fastimport plugin itself? | 11:46 |
kinkie | ok: lp:python-fastimport, right? | 11:47 |
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:48 |
kinkie | so the suggestion is fast-export then fast-import to convert the 2a branch to pack and then merge? | 11:49 |
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:50 |
kinkie | nah, I'll just go the branch way | 11:51 |
kinkie | I'll be damned, it IS fast - 3k commits/minute | 11:52 |
kinkie | neat | 11:52 |
sil2100 | Hello uys | 12:04 |
* sil2100 has keyboard problems | 12:04 | |
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:05 |
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:06 |
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:07 |
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:08 |
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:09 |
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:12 |
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:15 |
jelmer | sil2100: only if they didn't have the old version of the tag (since tags are not versioned) | 12:30 |
sil2100 | jelmer: awww, too bad... thanks | 12:37 |
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:11 |
jelmer | kinkie: Sure, we'll be around tomorrow | 15:14 |
jelmer | kinkie: Have a nice evening | 15:14 |
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:17 |
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:19 |
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:20 |
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:22 | |
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:23 |
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:24 |
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:25 |
vila | dunno, I install Ubuntu on the macs that are on my desk | 15:26 |
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:27 |
SamB_MacG5 | vila: that would explain why the Qt, SIP, and PyQt included in the installer in question are all intel-only ;-P | 15:29 |
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:30 |
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:31 |
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:32 |
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:33 |
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:34 |
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:36 |
* SamB_MacG5 couldn't remember who did it | 15:37 | |
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:31 |
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:34 |
Trmandy | yep, understood. This is a private branch | 16:35 |
=== yofel_ is now known as yofel | ||
=== marienz_ is now known as marienz |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!