[00:56] <mgrandi> it seems bzr explorer does not like huge trees
[00:58] <mgrandi> http://bpaste.net/show/24322/
[01:17] <poolie> hi
[01:17] <poolie> yes it's a known bug
[01:17] <poolie> i thought bialix was going to turn file watchers off by default
[01:18] <poolie> it is too risky to be on til it's more stable
[01:18] <mgrandi> it was going to be turned off on windows by default
[01:18] <mgrandi> cause of its wonderful practice of one thing locking a file and then nothing else can use it
[01:18] <mgrandi> i'm on a mac atm
[01:20] <poolie> ah, maybe it should be off everywhere
[01:21] <mgrandi> well
[01:21] <mgrandi> this is a pretty extreme case, i'm just running a script (thats in a bzr directory) and by default it outputs stuff to the same dir the script is in
[01:21] <mgrandi> and it has 6,721 items totaling 800 mb sooo =P
[01:34] <mgrandi> be back on later~
[03:22] <AfC> bzr 2.5 is released, right? Does that mean in will be in ppa:bzr/ppa soon?
[03:42] <poolie> afc, right, quite soon
[04:09] <AfC> poolie: cheers (just hit a github repo that I'm trying to branch that gave me an error to do with nested trees; I'm hoping that 2.5 will parse it)
[05:45] <mgrandi> so, does bzr-git support pushing to github?
[06:10] <mgrandi> dont want to push to test it cause i dont wnat to mess up the branch >.>
[06:40] <LarstiQ> mgrandi: afaik it does
[06:40] <mgrandi> well
[06:40] <mgrandi> one way to find out
[06:40] <mgrandi> haha
[06:45] <mgrandi> and aww yeah thats sexy.
[06:51] <mgrandi> requires a dpush but it works perfectly.
[06:59] <mgrandi> anyway, bedtime~
[07:28] <Milky> Hello all
[07:28] <Milky> I am going to host a private bazaar for an internal team development
[07:28] <Milky> but can't come across a descent doc/manual that goes through this...
[07:29] <Milky> especially users administration
[07:30] <Milky> I still have no idea how this works, assigning branches to specific users, setting read-only one a mainstream branch for all users but one for example... etc
[07:30] <Milky> could anyone point me to the right direction?
[07:30] <Milky> Thanjs in advance
[07:50] <Milky> ...
[08:02] <mgz> morning
[08:17] <jelmer> hi mgz
[08:18] <mgz> hi!
[10:17] <poolie> o/ jelmer, mgz
[10:17] <mgz> hey poolie
[10:18] <jelmer> hey poolie
[10:19] <poolie> hi there, sorry i missed you before
[12:32] <stefanct> i am trying to setup a daily build recipe for a svn import, but i obviously have problems with the the deb-version string (or to be more precise with fulfillment of its prerequisites).
[12:33] <stefanct> i have included a nest-part statement for the debian part of the ubuntu package
[12:33] <stefanct> the first line of the recipe is bzr-builder format 0.4 deb-version {debupstream-base}-0~r{svn-revno}
[12:35] <stefanct> http://paste.ubuntu.com/860449/ is the complete recipe + bzr dailydeb output
[13:04] <jelmer> stefanct: hi
[13:04] <stefanct> hi jelmer
[13:04] <jelmer> stefanct: I think the 0.4 recipe format still has issues on launchpad
[13:05] <jelmer> stefanct: you might want to try 0.3 (though that unfortunately doesn't support some of the variables you're using
[13:05] <stefanct> agreed@0.4 but i am testing locally. shouldnt it work there?
[13:05] <jelmer> stefanct: it should work locally indeed
[13:06] <jelmer> stefanct: there isn't any packaging in lp:flashrom I guess?
[13:06] <jelmer> in that case you want {debupstream-base:packaging}
[13:07] <stefanct> a "packaging" directory?
[13:07] <jelmer> stefanct: packaging refers to the branch you're nesting
[13:08] <jelmer> stefanct: your deb-version has {debupstream-base} which would take the version string from the 'debian/changelog' file in the root branch (lp:flasrom)
[13:08] <jelmer> except there is no such file in the root branch
[13:08] <jelmer> {debupstream-base:packaging} makes it look at the branch nested under the 'packaging' name
[13:09] <stefanct> ah!
[13:09] <stefanct> are there any good docs about that? this is all missing from the help.launchpad.net pages :/
[13:10] <stefanct> well.. i should recheck that first before blaming.. :)
[13:10] <stefanct> "Here fix-build is a unique short name that we'll use to refer to this branch throughout the recipe." my bad.
[13:13] <jelmer> stefanct: see also 'bzr help builder'
[13:14] <stefanct> ah. i was looking at the man page...
[13:17] <stefanct> jelmer: thanks a lot! --no-build completes now successfully locally and i think i know enough to solve the ppa build on my own
[13:19] <jelmer> cool
[13:25] <stefanct> but it explodes ofc on launchpad due to https://bugs.launchpad.net/launchpad-buildd/+bug/915505 :)
[13:27] <jelmer> stefanct: yep, that's the bug I had in mind earlier
[13:29] <stefanct> last question hopefully: is it possible to have comments in recipes? # obviously is not ignored :) i would like to add a 0.4 template for later when that bug is solved
[13:30] <jelmer> stefanct: yes, you can have comments but they have to start at the beginning of a line
[13:30] <jelmer> I'm not sure if launchpad preserves them
[13:38] <stefanct> it does not
[13:43] <jelmer> stefanct: I guess you can put it in the recipe description
[13:44] <stefanct> good idea, but i dont trust launchpad... ill save it locally too :)
[18:17] <wilx> Hi.
[18:18] <wilx> Is it possible to sync-pipeline and then work with the pipeline in the other location?
[18:19] <wilx> I have done this: 1) created a pipeline and done some changes. 2) bzr sync-pipepile /my/usb/flash/memory. 3) bzr sync-pipeline /home/wilx/mysharedrepo.
[18:19] <wilx> Now, it has created two branches in the shared repor with the names of the pipes in the pipeline.
[18:19] <wilx> But the branches are not the pipeline it seems.
[18:20] <wilx> I cannot bzr swp in them.
[18:21] <wilx> While bzr pipes still shows the pipeline pipes in each of the branches.
[18:21] <wilx> Ideas?
[18:34] <stefanct> jelmer: first binary package just built successfully by the recipe, thanks again and bye :)
[19:11] <jelmer> wilx: hi
[19:11] <jelmer> wilx: no idea, you might want to talk to abentley
[19:13] <abentley> wilx: you ought to be able to, but I haven't tested it recently.
[19:23] <wilx> http://codepad.org/AUt0awX5
[19:24] <wilx> Here is a log of what I have done. The bottom shows the problem.
[19:35] <abentley> wilx: Right, you need to create a lightweight checkout of branch1 or pipe2.
[19:37] <wilx> Would that be bzr co --lightweight in the branch1 dir?
[19:38] <abentley> wilx: co --lightweight $PATH_TO_BRANCH1 anywhere except the branch1 dir.
[19:39] <wilx> Ah.
[19:42] <wilx> I see. It works that way.
[19:42] <wilx> However it makes layout different from the inital pipeline which is surprising.
[19:44] <abentley> wilx: I mostly use sync-pipeline for pushing to Launchpad, and producing that sort of layout wouldn't work.  Launchpad needs the branches to be separate.
[19:46] <wilx> I see.
[19:46] <wilx> Maybe there should be a switch to allow the original repo layout for other destinations/transports.
[19:48] <abentley> wilx: probably the easiest way to reproduce that layout manually is to colo-init, and then sync-pipeline into colo/.bzr/branches
[19:55] <abentley> wilx: btw, until recently, the layout produced by reconfigure-pipeline is one I never used.  I would do "bzr init-repo --no-trees branches; bzr init branches/branch1; bzr checkout --lightweight branches/branch1/"
[19:56] <wilx> I see.
[20:00] <abentley> wilx: if you're using reconfigure-pipeline, init-repo isn't strictly necessary.  reconfigure-pipeline creates a shared repository.
[20:05] <jono> hey all
[20:05] <jelmer> hey jono
[20:05] <jono> hey jelmer!
[20:06] <jono> if I have a branch that I want to merge into another one, and the branch I want to merge in has much of the same code structure, but re-factored, is bzr smart enough to find the right code fragment and merge the branch?
[20:07] <jelmer> jono: the branches aren't related in any other way?
[20:07] <jono> jelmer, so this is what is happening:
[20:07] <jono> I have a branch and someone is re-factoring the code
[20:07] <jono> but moving the code around, changing some of the method names etc
[20:07] <jono> much of the original code logic is the same
[20:08] <jono> but I want to write some changes and I am not sure if I should hold off
[20:08] <wilx> Are your changes conflicting his changes?
[20:08] <wilx> Then hold off. Otherwise proceed.
[20:09] <jono> wilx, this is the thing, I don't know - I suspect they won't because he is just moving some code around - the code itself doesnt change
[20:09] <jono> but as an example if I patch my_func() and the file my_func() is in changes, would the patch still apply?
[20:09] <jelmer> jono: if you're going to be changing the same code that he is moving around then I would wait
[20:09] <jono> thanks jelmer
[21:21] <lifeless> jono: best way to tell: just try merging :)
[21:21] <lifeless> jono: you can always do your changes on top of his branch, rather than in trunk
[21:21] <lifeless> jono: or you can do yours in trunk and let him(or her) merge from you before they submit
[21:31] <thomi> jelmer: I just saw your bug on indicator-jenkins - I didn't think anyone knew about that yet
[21:32] <thomi> jelmer: the bug's been fixed in trunk, and there's a package building - should be done in 1 hour
[21:33]  * jelmer hugs thomi 
[21:33] <jelmer> I don't remember where I learned about indicator-jenkins, but it seemed like a nice thing to try
[21:33] <thomi> let me know if you have any more problems with it. I'll get it working well then send an email out to the canonical QA lists...
[21:37] <wilx> jelmer: Hey, thanks for the quick patch for the bzr:// URI mirroring.
[21:59] <jono> thanks lifeless
[22:29] <poolie> hi all
[22:34] <wgz> hey poolie
[22:44] <jelmer> hi poolie, wgz