[03:23] <kishor> hello
[03:24] <kishor> i have gone through the documentation and considering my inexperience in the version control, i am finding it extremely difficult to understand the manuals.. I want to setup a central repository hosted on our ubuntu server... I am using bazaar-explorer as the team works both in ubuntu/windows ... any leads/links/directions will be highly appreciated
=== Pikkachu is now known as PikkachuAway
=== PikkachuAway is now known as Pikkachu
[07:20] <vila> hi all
[07:20]  * vila upgrades, bbl
[07:51] <vila> doh, one of those *painful* upgrade :-/
[08:39] <mgz> morning
[08:49] <vila> mgz: morning ! Thanks for the installers !
[08:50] <vila> mgz: I'm fighting with the last unity upgrade right now (lost my most used shortcuts :/)
[08:56] <mgz> I did get to go to bed in the end...
[09:19] <jml> hey guys, we have a couple of branches for udd that we'd like to see land soon:
[09:19] <jml> https://code.launchpad.net/udd/+activereviews
[09:20] <jml> (the 'stormify' and 'postgres' ones in particular)
[09:22] <vila> given the backlog we already have on bzr and udd, I'm afraid we won't get to them shortly :-/
[09:30] <jml> vila: we have patches for udd that date from mid-December, can we swap the recent patches with them in the patch queue?
[09:48] <mgz> I looked at the db changes mps and the diffs didn't scare me
[09:49] <mgz> am fine with approving them if you guys deploy it and chase up if things break
[09:56] <mgz> jml: for instance, storm does not seem to be on jubany
[09:58] <jml> mgz: ok. I'll have to talk with the team about that. Taking on responsibility for another service isn't a thing to do lightly.
[09:58] <jml> mgz: although it's not out of the question either.
[10:00] <mgz> I didn't mean for ever, just in response to james_w saying "care should be taken rolling this out"
[10:01] <jml> how is udd trunk controlled? pqm? tarmac? manual test runs?
[10:01] <mgz> the code looks fine to me, just can't commit to spending days debugging deployment issues
[10:02] <mgz> dunno. manually, I belive.
[10:03] <vila> jml: udd trunk is tested by deploying on jubany :-/
[10:03] <jml> vila: heh
[10:03] <jml> vila: you don't have anything that runs the test suite before landing changes to trunk?
[10:04] <vila> oh yes we have ! We call them devs :)
=== frankoid_ is now known as frankoid
[10:07] <jml> vila: ok, thanks.
[10:08] <jml> I'm just wondering whether we should schedule some work so that jubany's udd is run more like other Canonical services.
[10:11] <vila> sounds fair
[10:13] <vila> from the top of my head, we need branches for udd/bzr/bzr-builddeb, packages from -cat, and some settings for apache, start/stop gracefullty the importer itself and.. lp setup (credentials and ssh key)
[10:14] <vila> ha, and the pgimport.conf which would probably be removed from the udd branch or something
[10:16] <vila> ha crap and the crontab of course, anyway part of it is already documented in READE_DEPLOYMENT and the rest would have to be found while changing the deployment process :-}
[10:19] <jml> yeah
[10:19] <jml> we could probably puppetize that pretty easily
[10:19]  * jml touches wood
[10:20] <jml> the fab thing that landed already demonstrates what an automated deployment process could look like.
[10:20] <vila> fab ?
[10:22] <jml> vila: it's yet-another-Make replacement. if you run 'fab deploy-to-ec2' after doing some set up with keys and stuff, you'll get an ec2 instance with udd running on it.
[10:23] <jml> vila: it's quick-and-dirty, but I needed something to test the binary package scan mode before I asked for it to be deployed on hadar.
[10:23] <vila> fabric ?
[10:24] <vila> yeah, fabric
[10:24] <jml> yeah.
[10:27] <jml> I'm looking forward to precise in the DC so we can charm up things like this
=== wgrant_ is now known as wgrant
[12:14] <jml> how can I set up my locations.conf for colo so that I can push branches to lp:~jml/$PROJECT/$BRANCH_NAME automatically
[12:16] <jelmer> jml: for colocated branches or bzr-colo, the plugin?
[12:17] <jml> jelmer: colocated branches
[13:17] <jelmer> jml: afaik we don't have anything for that yet - possibly we should add a special config variable for that
[13:17] <jelmer> (name of the current colocated branch in the current directory)
[13:17] <LarstiQ> {nick}?
[13:18] <jelmer> ah, that's a good point
[13:18] <jelmer> that would usually work, unless you manually set branch nicks
[13:29] <jml> jelmer: I guess append_path might work?
[13:29] <jml> hmm, no, because it's not part of the path
[13:30] <jml> jelmer: I guess if nick is set you would want to push to lp:~USER/PROJECT/NICK anyway
[13:31] <LarstiQ> jml: and nick should default to colocated branch name now afaik
[13:31] <jelmer> jml: yep, that should work though
[13:32] <jml> LarstiQ: as in it does, or as in someone ought to make that the case?
[13:32] <jelmer> jml: nick will default to the colocated branch name if no nick was manually set
[13:32] <jml> nice
[13:32] <LarstiQ> jml: as in let me check if that is in 2.5
[13:32] <jml> LarstiQ: it is, I think.
[13:32] <jml> is nick not available in the config?
[13:33] <LarstiQ> jml: it is available as {nick} I think?
[13:33]  * jml tries
[13:34] <jml> push_location = lp:~jml/pkgme-binary/{nick} doesn't seem to expand.
[13:36] <LarstiQ> jml: feh
[13:36] <jelmer> vila: ^
[13:37] <vila> yeah, nick is one of the few options not migrated yet
[13:38] <vila> but {basename} works otherwise (at least for regular branches)
[13:39] <jml> vila: what's basename?
[13:40] <vila> the last part of the branch path, so ~/src/bzr/integration/trunk -> trunk
[13:40] <vila> ~/src/bzr/trunk -> also trunk
[13:42] <LarstiQ> hmm
[13:44] <LarstiQ> vila: it does not seem to get expanded, but maybe I'm not setting it correctly
[13:44] <vila> supporting {nick} will be nice (there was some pending discussion about changing when nick is updated related to master branches that I lost track about and was seen as a pre-requisite to the migration)
[13:44] <vila> LarstiQ: it's not linked to an option so it can't be expanded
[13:45] <vila> s/not linked//
[13:45] <LarstiQ> vila: `bzr config 'push_location=lp:~/project/{basename}'; bzr push` => bzr: ERROR: Option basename is not defined while expanding..
[13:45] <LarstiQ> vila: aha
[13:46] <vila> LarstiQ: basename is a "magic" option that can only be set in locations.conf
[13:47] <vila> so, correction, s/the last part of the branch/& when used in a locations.conf section/ :-/
[13:49] <LarstiQ> check
[13:49] <vila> it doesn't make a lot of sense to define it in branch.conf where it will always have the same value
[13:50] <vila> and defining push_location in locations.conf is not a super idea either as it means it overrides whatever you put in branch .conf
[13:51] <vila> so, lacking a defaults.conf, I currently defines mypush=lp:~vila/bzr/{basename} in my [/home/vila/src/bzr] section and then
[13:51] <vila> bzr push `bzr config mypush`
=== zyga is now known as zyga-afk
=== yofel_ is now known as yofel
[15:33] <vila> mgz: ping
[15:33] <mgz> poing
[15:51] <luke-jr> Is it possible to get bzr to give me a 3-way diff of conflicts (HEAD, common parent, and merge source)?
[15:54] <mgz> giving --show-base to merge puts in the base revision for content conflicts
[15:54] <mgz> which you or your tools can probably interpret
[15:54] <mgz> for funny things like move/delete conflicts that's no help
[15:56] <mgz> remerging specific files with that flag added should sometimes help
[15:57] <mgz> you can also configure an external merge tool
[15:58] <luke-jr> can I make it default? :D
[16:01] <mgz> yeah. where is that actually documented...
[16:02] <mgz> http://doc.bazaar.canonical.com/beta/en/user-reference/configuration-help.html#bzr-mergetool-name
[16:04] <luke-jr> might close https://bugs.launchpad.net/bzr/+bug/562669 then ;)
[16:04] <ubot5> Ubuntu bug 562669 in Bazaar "merge should show base always, or at least configurably" [Medium,Confirmed]
[16:05] <luke-jr> … but I don't have an external tool :|
[16:05] <luke-jr> I just want --show-base
[16:06] <jelmer> luke-jr: bzr alias merge='merge --show-base'
[16:06] <luke-jr> thx… guess I can deal with the conflicts manually
[16:06] <luke-jr> (cmdline conflicts, mentioned in that bug)
=== deryck is now known as deryck[lunch]
[16:21] <vila> jelmer: ping
[16:25] <jelmer> vila: pong
[16:25] <vila> jelmer: see pm ;)
[16:32] <jelmer> btw, did you see my email about bundling plugins?
[16:54] <mgz> have we got any tests for the bzrlib.transform progress display?
[16:54] <mgz> ...I guess I'll just post a simple fix and worry about pains like that later
[16:55] <vila> jelmer: yes, marked unread-need-to-answer
[16:55] <vila> jelmer: by the way, I've seen the gtk ghost progress bar once this morning
[16:56] <vila> mgz: hmpf, will be fun to add, no I don't think we have any
=== deryck[lunch] is now known as deryck
=== yofel_ is now known as yofel
[19:24] <converge> I wish to get the 6.1 version of this repository, can someone help me ? https://code.launchpad.net/~openerp-commiter/openobject-addons/trunk-extra-addons
[19:41] <LarstiQ> converge: `bzr branch lp:openobject-addons/6.1` will get it
[19:44] <converge> LarstiQ: thanks
[19:45] <LarstiQ> converge: np
[22:07] <poolie> hi all
=== jordan_ is now known as jordan