=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-zzz
[07:26] <lifeless> jelmer: why https://code.launchpad.net/~testing-cabal/ubuntu/natty/testrepository/daily-build-packaging
[07:26] <lifeless> rather than bzr+ssh://bazaar.launchpad.net/~testrepository/debian/sid/python-testrepository/sid/
[07:26] <lifeless> in https://code.launchpad.net/~testing-cabal/+recipe/testrepository-daily
[09:13] <kgoetz> hi all. does bzr have an interactive commit (or some way of faking it)? i'm about to merge two branches, and was hoping to avoid conflicts and associated messing around
[09:15] <kgoetz> ah, merge -i might be it
[09:19] <kgoetz> does this look like my terminal corrutping the message, or bzr getting the printing wrong? 'Merge phase 2/3olution pass 1/10 0/19\
[09:22] <kgoetz> ah, worked it out, sorry all
[09:37] <lifeless> that looks like a bug
[09:37] <lifeless> I thought they had all been squashed
[09:37] <kgoetz> probably because i was accidentally piping into vi -, so strangeness probably resulted fro that
[14:27] <jelmer> lifeless: I didn't set up the original packaging branches
=== mz is now known as tsu
[17:02] <mathrick> hiya
[17:02] <mathrick> bzr-svn fails with unicode errors again in the daily ppa: http://launchpadlibrarian.net/65112532/buildlog_ubuntu-maverick-i386.bzr-svn_1.1.0~bzr3558~ppa370~maverick1_FAILEDTOBUILD.txt.gz
[17:47] <maxb> mathrick: Yes. http://wiki.bazaar.canonical.com/DailyPpaStatus
[18:36] <maxb> jelmer / james_w : Can you think of any reason why bzr-builddeb has a split between Build-Depends and Build-Depends-Indep ?
[18:39] <maxb> Oh, gah, figured it out. It's so you don't need the -Indep stuff to build a source package only
[18:41] <ScottK> Things not needed to run clean (part of building the source package) or only used in arch independent pacakges go in build-depends-indep.  See Debian policy for details.
[18:44] <lifeless> jelmer: so no objection to me changing it ?
[18:46] <jelmer> lifeless: no, seems like a good idea to me
[18:51] <lifeless> done
[19:03] <jelmer> mathrick: should be fixed now, there's a new build on the way
[19:32] <maxb> oh nice. though it still failed because of missing ReverseTagDict.keys()
[19:34] <maxb> meanwhile, I think I've got to the bottom of the bzr-builddeb failures
[20:25] <sako> hey all so does bzr push lp:project   do an update both ways?
[20:25] <sako> if there are new changes on the server will it get pulled in?
[20:26] <mathrick> jelmer: nifty, thanks
[20:26] <mathrick> sako: no, push is push
[20:26] <mathrick> you want merge in this ase
[20:27] <mathrick> pehaps rebase if it's applicable
[20:37] <maxb> although, you probably don't want rebase unless you really really know you want rebase
[20:45] <mathrick> I don't think it's _that_ strong a disclaimer, rebase is pretty natural for great many everyday scenarios
[20:45] <caravel> hi folks
[20:45] <mathrick> it basically removes the need for trivial merges, the kind that don't happen in darcs but do in bzr/git/hg
[20:49] <maxb> Yes, but it also screws things up if you've published the old revisions in any way
[20:50] <caravel> I have a couple of quick questions today : we need to setup our workflow (web server, externalized hosting, jailed ssh). Considering the option to push our changes, once we've tested them, to the server also using bzr. We're in the process of asking our provider to extend a little bit our ssh, to get rsync at least. What's the most efficient then: the "smart server" mode, or rspush ?
[20:51] <caravel> and..
[20:52] <caravel> can anyone confirm the requirements of each, on server side ? from the docs, I understood that "smart server" needs a copy of bzr of course in the ssh, while rspush "only" needs rsync. Is this correct ?
[20:56] <caravel> by the way, the high level doc I was asking here, yesterday, is this one http://doc.bazaar.canonical.com/latest/en/admin-guide/simple-setups.html#smart-server
[20:57] <caravel> sorry no
[20:57] <caravel> this one http://wiki.bazaar.canonical.com/Specs/SmartServer :)
[20:58] <maxb> I would describe rspush as a bit of a hack.... sure, it works, but its basically just some safety wrappers around directly rsyncing your local tree somewhere
[20:59] <lifeless> bzr push is generally faster
[21:00] <caravel> thanks maxb, I was guessing so, since it hasn't been integrated in the "product" so far
[21:00] <caravel> hi lifeless :) there you are again. Do you mean bzr+ssh, right ?
[21:02] <caravel> so in our interest (cf. traffic saving), I should ask the hosting guys if we can get bzr installed in our chroot, otherwise rsync, right ?
[21:04] <caravel> in other words, rspush is a hack that was written by/for those of us... who can't get bzr available in their hosting, typically. Right ?
[21:10] <lifeless> yes
[21:11] <lifeless> though you don't need rspush at all if you have e.g. sftp (which openssh servers have by default)
[21:12] <lifeless> the reason rsync is inefficient is the pack files
[21:12] <caravel> lifeless: from my understanding rspush makes use of rsync, hence should be WAY more efficient than sftp. What do you mean ?
[21:12] <lifeless> every time a pack is recompressed, rsync has to copy it again
[21:12] <lifeless> packs are highly compressed - often hundreds : 1 compression ratio
[21:13] <lifeless> bzr+ssh is the ideal
[21:13]  * caravel needs to learn about "packs" : he knows the English word but have no idea what it means in bzr language. Will be back shortly !!
[21:15] <lifeless> the files in .bzr/repository/packs
[21:15] <lifeless> its the binary database that your revision history is stored in
[21:16] <caravel> lifeless: I got that but let me search please, I need you to save your time so you can answer what I can't find elsewhere :)
[21:18] <caravel> (by the way, some of you people might want to share what you are telling me here, in the docs : I feel the are rather legitimate performance and comparison questions, didn't really find a concise list of "advice" to help choosing between protocols. Just some thoughts, might help more users to join ?)
[21:21] <fullermd> AIR, the main push (so to speak) behind rspush was about copying the WT.
[21:22] <caravel> hi fullermd, txs - what do you mean by "WT", working tree I guess right ? (sorry!)
[21:24] <caravel> fullermd: yes, that's my guess too, hence whenever there are really LOTS of augmentations, grown files etc. then building on rsync has to be a good option
[21:26]  * caravel just found *finally* some tips about using SFTP... in Bzr's SysAdmin guide :D (I was looking for this last year cf. FZ server, no luck then... and don't need it anymore!)
[21:28] <caravel> lifeless: (found reading about packs, must go for an hour, chat later if you're still here)
[21:30]  * maxb sobs a bit as fixing another bzr-builddeb test glitch uncovers yet another one