[03:42] <cpuchip> hello, I'm new to compiling from source, but I've been interested since I've stuck on ubuntu 9.04 on arm. I've been successfull at building bzr 2.50 from source, but I'd like to make it a deb package so I can distribute it to my friend who has the same setup. I don't see where the debian/control or changelog files can be found to make this possible, will have have to create them from scratch?
[03:44] <spiv> cpuchip: why not grab them from the (current) ubuntu package sources?
[03:45] <lifeless> cpuchip: add the bzr ppa, then do apt-get source bzr
[03:46] <cpuchip> oh? the launchpad.net/bzr/+download? or is this a different location for the source?
[03:48] <cpuchip> looking at https://launchpad.net/~bzr/+archive/ppa I don't see jaunty on the list. but I guess I can pull from those packages. anyway.
[04:28] <cpuchip> lifeless, spiv: I think I found what I needed here: http://ppa.launchpad.net/bzr/ppa/ubuntu/pool/main/b/bzr/ but I'll have to backport from lucid to jaunty.
[04:30] <lifeless> I'm pretty sure jaunty is entirely unsupported now ;)
[04:31] <cpuchip> lifeless it is. but motorola decided to move forward with it on their Motorola Atrix phone for webtop (ubuntu 9.04) so I've been dealing with that, fortunately their later phone sport ubuntu 10.10, unfortunately I'm stuck with the atrix.
[04:32] <cpuchip> I was able to compile from source bzr 2.5.0 orig and it work's just fine, I just didn't want to install it from source bypassing the package manager (apt-get)
[05:01] <cpuchip> I might as well install from source on this one.. I'd have to migrade debhelper from 7.0.7 to 7.4.15 and that's proving to be no fun. thanks guys, I might try again tomorrow for fun again.
[09:20] <Merwin_> Hi vila, could you give me some advices on how to handle upgrades and bug fixes in branches ? If you have time ;)
[09:22] <vila> Merwin_: remind me about your setup ? Centralized branch and lightweight checkouts /
[09:22] <vila> ?
[09:22] <vila> or just regular branches and a public shared branch ?
[09:22] <Merwin_> We have a dev branch we all branched/checkout from
[09:23] <Merwin_> Developpers regulary push on it (either from their checkout or from a branch)
[09:23] <vila> so, they merged their changes locally and then push ?
[09:23] <Merwin_> We also have a "production" branch which is synchronised from the dev branch regulary
[09:23] <Merwin_> Yes vila
[09:23] <vila> ok, good
[09:24] <vila> In this case, they are already working with so-called feature branches where the real work happen
[09:24] <Merwin_> Sometimes my boss comes to me and tell me "Update all what X did today please, but not what Y and Z pushed a few moment ago"
[09:24] <vila> ouch
[09:24] <vila> so 'push --overwrite' ?
[09:24] <Merwin_> update = merge into the production branch
[09:25] <Merwin_> They, currently, I have to check the log, and take commits one by one, merging them with -c number of -rxxx..yyy if they follow.
[09:25] <Merwin_> Then*
[09:26] <vila> right, cherry-pick
[09:26] <vila> that means that when you later try to merge th dev branch you may encounter conflicts
[09:26] <Merwin_> But that's a nightmare to maintain, I have to commit after each merge (I can't do a commit after all commits I want have been merged)
[09:27] <Merwin_> There is no other way to do this
[09:27] <Merwin_> ?
[09:27] <bob2> topic branches
[09:27] <vila> well, you can use 'merge --force' but the commits at least give you a point you can revert to
[09:28] <vila> and provide *some* readability for your production branch...
[09:28] <vila> it
[09:28] <Merwin_> Yeah, 15 commits named "Commit after merge" is not what I call readability lol :P
[09:29] <vila> it's really a workflow issue you have here, all of you validated their additions to dev, cherry-picking them means you have to validate unknown mixes of changes
[09:29] <vila> you can use better commit messages :) "cherry-pick feature A"
[09:30] <Merwin_> vila, but the feature is dipatched in more than one commit :p
[09:30] <Merwin_> vila, what workflow should I use then ? We are ready to change if it's for the better
[09:30] <Merwin_> best*
[09:30] <LarstiQ> Merwin_: develop the feature in its own topic branch as bob2 suggested
[09:31] <vila> well, if you land intermixed changes on dev, you can't properly cherry-pick them :)
[09:31] <bob2> note that it's at best a part-solution
[09:31] <bob2> the real solution is to not write bugs!
[09:31] <vila> so as bob2 said: use feature/topic branches and make sure they are complete *before* merging them to dev
[09:31] <Merwin_> LarstiQ, bob2 : and merge from the branch regulary ?
[09:31] <bob2> Merwin_, no
[09:32] <vila> Merwin_: no, when you're ready to land on the dev branch,
[09:32] <vila> get an up-to-date dev branch, merge your feature branch, make sure it works, commit, push
[09:33] <vila> the gate-keeper model does that in an automated way relying on a test suite to "gate" changes
[09:33] <Merwin_> And then on the production server I just have one commit to merge
[09:33] <bob2> you don't do merges on production servers
[09:33] <vila> I agree with bob2 :)
[09:33] <Merwin_> bob2, ah ?
[09:34] <vila> you validate the dev branch so that the production branch you can always pull from dev ;)
[09:34] <Merwin_> Hum
[09:34] <vila> s/branch you/branch/
[09:34] <Merwin_> And if there are some bugs (because they always have)
[09:34] <vila> the tool is not a magic bullet
[09:35] <vila> it can help you organize your workflow though
[09:35] <bob2> +1
[09:35] <vila> in this case, you fix the bug in the feature branch and then your merge it again
[09:36] <vila> It's a bit hard to explain without pictures, do some tests and look at the result with 'bzr qlog'
[09:36] <vila> you can look at lp:bzr which use the gate-keeper workflow,
[09:36] <Merwin_> You're welcome in France to show me how it works with pictures :)
[09:37] <Merwin_> I'll take a look, thanks
[09:37] <vila> Merwin_: you're welcome in Strasbourg to look :)
[09:38] <vila> Merwin_: each commit on lp:bzr mainline is a merge
[09:38] <vila> the merged branch can have one or several commits
[09:38] <bob2> except for the first few dozen ;p
[09:38] <vila> bob2: hehe, yeah, merge was implemented a bit later ;)
[09:39] <Merwin_> hum ok
[09:39] <vila> but pqm (our gate keeper) has been used for more than a couple of years now ;)
[09:39] <Merwin_> Wand when you backport a bugfix into an old version, how do you do ?
[09:39] <vila> Merwin_: in some cases, the same feature branch is merged repeatedly and qlog will show you that
[09:39] <vila> ha, backport...
[09:40] <vila> http://wiki.monotone.ca/DaggyFixes/
[09:40] <vila> ideally you start fixing in the oldest version so you can merge 'up' into the newer ones
[09:40] <bob2> hahaha
[09:40] <vila> :)
[09:41] <vila> hey, we're talking ideal workflows or not ? :)
[09:41] <vila> the point is that daggy fixes are the easiest and give the cleanest history
[09:41] <vila> backports now...
[09:41] <Merwin_> Ok, that's the best way nobody uses ? :D
[09:41] <vila> there are two main cases
[09:41] <vila> no no no, I do daggy fixes as much as I can
[09:42] <vila> 1) you can just cherry-pick the exact change and be done
[09:42] <vila> you just have to merge up until dev where small conflicts (generally trivial) can occur
[09:43] <vila> 2) you cannot cherry-pick because the fix is not compatible with the old version
[09:43] <fullermd> The advantage of daggy fixes is that you never have to cherry-pick anything; the history is all fully connected.  The downside is that (a) you have to plan to do it, and (b) you can setup a lot of work if the LCA is a long ways back.
[09:43] <vila> in that case you can sort-of start with the actual fix and make it work
[09:43] <bob2> man, i haven't heard anyone say least-common-ancestor in forever
[09:44] <vila> :)
[09:44] <fullermd> Obviously, you don't hang out here enough  ;p
[09:44] <Merwin_> ok, it's clearer thank you.
[09:45] <vila> Merwin_: overall, keeping the shared history clean pays off big times
[09:46] <fullermd> vila: Funnily enough, I accidentally looked at babune last week and have been meaning to corner you about those sphinx messages   ;p
[09:46] <Merwin_> My bosses don't want to do branches. They all uses checkout because "it's simpler" : They don't need to commit nor merge.
[09:47] <Merwin_> The thing is that it's not them who cherry-pick 20 commits because of "Put this in production now"
[09:47] <fullermd> So, they want to create everything mashed together, and then for you to separate it all out later.  Luckily, they pay bonuses to you for doing it.
[09:48] <Merwin_> fullermd, "luckily" :)
[09:48] <vila> or said otherwise: sh** always go down, if you have to handle it, do so sooner rather than later
[09:48] <fullermd> You should cook them a nice dinner to thank them.  Flank steak, mashed potatos, asparagus, minestrone.  Pumpkin pie for desert, say.
[09:49] <fullermd> Of course, you'll make it by putting all the ingredients in one pot at the beginning, then subjecting the whole thing to each step of the preparation.
[09:49] <fullermd> They can just separate out the bits themselves if they want to.
[09:49] <vila> Merwin_: yes ;)
[09:49] <Merwin_> hahaha nice idea :)
[09:49] <Merwin_> vila, do you do training on bzr ? :D
[09:51] <vila> Merwin_: canonical (my employer) does (I may be involved ;)
[09:52] <Merwin_> Do you have a link or something to get an idea about prices, etc ?
[09:53] <vila> http://www.ubuntu.com/contact-us
[09:57] <fullermd> vila: So, you have an idea what's up with that TestTCPServer failure?  It seems consistent on the handful of runs I looked at, and passes every time for me (though occasionally dumping a thread warning)
[09:58] <vila> fullermd: <shudder> don't start me on this topic
[09:59] <vila> let say it's a known transient failure
[09:59] <fullermd> Haha.  That's silly.  Surely there's no such thing.
[09:59] <vila> haha
[10:00] <vila> oh, and I have a fix for the sphinx failures, approved already, I should land it
[10:00] <fullermd> Yah, I saw the MP.
[10:04] <vila> oh, and I'm migrating away from vbox to kvm so expect hiccups on babune too ;)
[10:05] <fullermd> Oooh, I see your strategy.  babune works -> fullermd looks at it -> fullermd bugs vila.  If we break the chain one place, we're safe everywhere   :p
[10:05] <Merwin_> why do you migrate  to kvm?
[10:05] <vila> . o O (rats, uncovered)
[10:06] <fullermd> Obviously, so that the one slave I bother to look at stops working   :p
[10:06] <vila> well, the slave is causing problems is... the windows one
[10:06] <vila> I still have to address some networking issues but freebsd runs fine under kvm
[10:07] <fullermd> Hey, if you know a fix for _that_, quit your job right now.  You can become a billionaire overnight.
[10:07] <vila> Merwin_: in a nutshell, better support
[10:08] <vila> fullermd: oh, there are a *ton* of different fixes ;)
[10:08] <fullermd> And one of them starts and ends with 'u', right?   ;p
[10:08] <vila> hehe
[10:09] <vila> in fact, the first slave I tried migrating was freebsd, no idea why I chose this one first ;)
[10:11] <fullermd> I'm kinda impressed.  I was under the impression that getting it running under KVM was a herculean task, and the result didn't work too well when you got it.
[10:11] <fullermd> That might be from $YEARS ago though.
[10:13] <vila> nah, I migrated the vbox disk with qemu-img and it just worked
[10:14] <vila> the issue is it's nated in kvm and I was using the bridged mode in vbox, it looks like I should do the same with kvm even if this doesn't seem strictly required
[11:44] <vivekimsit> Hii friends!
[11:44] <vivekimsit> I have one problem!
[11:45] <vivekimsit> I have co a branch from launchpad
[11:45] <vivekimsit> now the branch at launchpad is at rev39 and I am at rev36!
[11:45] <vivekimsit> Now how to sync the two branches?
[11:54] <jelmer> vivekimsit: bzr up
[11:54] <vivekimsit> thanks
[11:54] <vivekimsit> :)
[14:33] <hannie> Can anyone tell me how I start Qbzr (gui front end for Bazaar)?
[14:34] <hannie> I have it installed, but when I type qbzr in the Dash (ubuntu 11.10) nothing happens
[14:36] <jelmer> hannie: qbzr isn't a single application, it just provides extra GUI subcommands for bzr
[14:36] <jelmer> hannie: e.g. "bzr qlog"
[14:37] <hannie> ok, so instead of commit I use qcommit in the terminal
[14:38] <hannie> I also tried Ground Control, but that does not work
[14:40] <hannie> thanks jelmer I just tried qpull and it works :)
[14:40] <jelmer> great
=== deryck is now known as deryck[lunch]
[17:45] <santagada> bzr: ERROR: Cannot lock LockDir(chroot-83045520:///%2Bbranch/openerp-web/6.1/.bzr/branch/lock): Transport operation not possible: readonly transport
[17:46] <santagada> when doing a bzr pull
[17:54] <santagada> anyone know why?
[18:11] <cpuchip> santagada, it looks like it's a readonly drive or something from the last two words, check your permissions on that file. is my only guess
[18:16] <santagada> cpuchip: its my hard drive, and I set chmod santagada -R * on it
[18:18] <cpuchip> did you add +w for user on it?
[18:19] <santagada> cpuchip: no, will try it
[18:19] <cpuchip> santagada, good luck I hope that helps, I'm not a veterine here,
[18:21] <santagada> cpuchip: didn't work either
[18:22] <cpuchip> so you do have read/write access to branch/openerp-web/6.1/.bzr/branch/lock?
[18:22] <cpuchip> I'm not familiar with the chroot protocal. I'm familiar with chroot as a command.
[18:26] <santagada> neither am I
[18:26] <santagada> I'm not manually using chroot
[18:26] <santagada> I'm using bzr+ssh
[18:27] <santagada> somehow I think bzr is trying to lock the other side
[18:27] <cpuchip> right that looks familiar
[18:27] <santagada> why it is trying to do that I don't know
[18:27] <cpuchip> that's okay if it's pushing, I'm not familiar with locking remote on a pull but it might.
=== deryck[lunch] is now known as deryck
[20:11] <peteris> Hi people, what best to use for SSH support in Windows with bzr?
[20:17] <cpuchip> putty/plink I believe
[20:19] <peteris> cpuchip, I cant find any reference how to do this properly
[20:19] <cpuchip> did you install tortoisebzr ? I thought that included plink for ssh.
[20:20] <cpuchip> but it might not. I'm on linux and haven't had to install on windows in a while.
[20:22] <cpuchip> peteris, let me look up our internal docs to see how we setup our windows dev machines
[20:23] <cpuchip> peteris we install the standalone version: http://wiki.bazaar.canonical.com/WindowsDownloads
[20:25] <cpuchip> peteris, then get putty from: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html download the windows installer that includes everything but puttyel
[20:26] <cpuchip> I assume you'll want to setup ssh keys (it's less typing your password...) but after that you'll need to add a global environmental variable called BZR_SSH=plink
[20:27] <cpuchip> make sure putty bin dir is in your path
[20:27] <cpuchip> you'll then need to create a dir (assuming windows 7) to tell bzr what usrname to use:
[20:28] <cpuchip> c:\Users\<username>\AppData\Roaming\bazaar\2.0\authentication.conf in it place the next two lines
[20:28] <cpuchip> [DEFAULT]
[20:28] <cpuchip> user=your.user.name
[20:29] <cpuchip> though I think that's configurable in tortiosebzr's menu, we just found it easier to explane it that way.
[20:29] <cpuchip> your.user.name is your ssh user name
[20:29] <cpuchip> then bzr+ssh://path/to/your/repo/branch should work
[20:30] <cpuchip> on a checkout/clone
[20:31] <peteris> ok, will try that :)
[20:31] <peteris> thanks
[20:31] <cpuchip> peteris, good luck!
[21:04] <peteris> cpuchip, it worked, thanks