[05:53] <lifeless> mwhudson: fullermd: that delta module is -firmly- deprecated
[08:59] <poolie> jelmer, hello?
[09:39] <gnuoy> vila, could you give me a ping if you've got time to talk about RT#50151: setup pqm to resolve news conflicts for bzr
[09:39] <gnuoy> ?
[09:47] <vila> gnuoy: ping
[09:47] <vila> gnuoy: are you in budapest ?
[09:48] <gnuoy> vila, no, I'm afraid not
[09:48] <vila> k, no worries
[09:48] <vila> :)
[09:48] <gnuoy> I've got 2 relevant files, /srv/pqm.bazaar-vcs.org/pqm-config/pqm.bazaar-vcs.org.conf and /home/pqm/.bazaar/locations.conf
[09:48] <gnuoy> The /home/pqm/.bazaar/locations.conf has very little in it
[09:48] <gnuoy> https://pastebin.canonical.com/57866/
[09:49] <gnuoy> The main config is in /srv/pqm.bazaar-vcs.org/pqm-config/pqm.bazaar-vcs.org.conf...
[09:49] <vila> the former is probably irrelevant (or rather specific to pqm and unknown to bzr)
[09:50] <gnuoy> fwiw, it contains: https://pastebin.canonical.com/57867/
[09:50] <gnuoy> I assumed pqm.bazaar-vcs.org.conf was the relevant file
[09:52] <vila> for pqm yes
[09:52] <gnuoy> given those 2 files does the change need to go into /home/pqm/.bazaar/locations.conf then ?
[09:52] <vila> yup
[09:52] <gnuoy> vila, ok, thats simple then
[09:52] <gnuoy> :)
[09:53] <vila> my bet would be that {workdir} is relevant as the highest section name we want to use
[09:53] <vila> as in: that's probably below this dir that the merges occur
[09:54] <vila> gnuoy: moving to a new room...
[09:55] <gnuoy> vila, the chroot is under /srv/pqm.bazaar-vcs.org/chroot so is this what I need to add ?: https://pastebin.canonical.com/57868/
[09:57] <vila> I'll add home/pqm/pqm-workdir (without a final /)
[09:58] <vila> just to make sure it applies to bzr only (even if bzr is not mentioned there...)
[09:58] <AfC> What's the default branch for ancestor: ?
[10:01] <vila> AfC: ancestor: applies to a branch, I don't get what default you're after O_o
[10:01] <vila> I should be missing your context
[10:01] <AfC> vila: I just did
[10:01] <AfC> $ bzr diff -r ancestor:
[10:01] <AfC> vila: and it did something. I just don't know what branch it did it against.
[10:02] <vila> the current one in the directory you ran bzr diff
[10:02] <vila> bzr info should tell you
[10:02] <AfC> vila: bzr info says the usual useless information, like "parent" and "submit" like I'd know what the difference is
[10:03] <vila> submit_branch is probably relevant
[10:03] <AfC> vila: ie it doesn't mention "ancestor"
[10:03] <gnuoy> vila, so the entry should be https://pastebin.canonical.com/57869/ ?
[10:03] <vila> parent is where you branch from, submit is where you merge from
[10:04] <vila> so 'parent' should be more relevant than 'submit', sorry
[10:04] <AfC> vila: excellent.
[10:04] <AfC> vila: we are, regrettably, no closer to knowing what the definition of ancestor: is.
[10:05] <vila> gnuoy: yup, that sounds good
[10:05] <AfC> vila: [not your fault, just a lack of polish in bzr command line interface]
[10:06] <vila> AfC: I'm using submit: far more than ancestor: myself
[10:06] <AfC> vila: been using ancestor:/path/to/whatever for years.
[10:06] <AfC> vila: no one told me I wasn't supposed to use it.
[10:07] <vila> the subtle distinction between them is... not always clear to me
[10:07] <AfC> heh
[10:07] <vila> in most of the cases I know they give the same results
[10:07] <AfC> er. wait
[10:07] <AfC> vila: ancestor: is a calculation
[10:07] <AfC> vila: submit: is just a tip
[10:07] <AfC> right?
[10:08] <AfC> especially for branches that have far diverged
[10:08] <vila> well, 'ancestor' is where you came from, 'submit' is where you want to go
[10:08] <vila> so the resulting diff is often the same
[10:09] <AfC> ah, interesting
[10:09] <AfC> I thought submit was a location
[10:09] <AfC> in fact, it is something in bazaar.conf
[10:09] <AfC> whereas,
[10:10] <AfC> $ bzr help revisionspec
[10:10] <AfC> ...
[10:10] <AfC> submit:
[10:10] <AfC>         Selects a common ancestor with the submit branch.
[10:10] <AfC> ancestor:
[10:10] <AfC>         Selects a common ancestor with a second branch.
[10:10] <AfC> wtf
[10:10] <AfC> oh, right
[10:10] <vila> true, but as far as diff is concerned, they both provide a revision
[10:10] <AfC> the whacked out
[10:10] <AfC> difference between
[10:10] <AfC> :submit and -r submit:
[10:12] <vila> the former is a location, the later is the tip of this location (i.e. a revision)
[10:16] <vila> gnuoy: should I throw a test at pqm ?
[10:17] <gnuoy> vila, yes pls
[10:18] <vila> gnuoy: done, waiting for result
[10:20] <vila> gnuoy: tests didn't start so probably still failing :-/
[10:20] <vila> gnuoy: can find some log about the latest bzr pqm submission so we can check which dirs/branches were involved ?
[10:20] <vila> s/&/you/ somewhere ;)
[10:21] <blackarchon> hi all
[10:22] <blackarchon> i'm wondering what "qsubprocess --bencode ..." exactly does
[10:23] <gnuoy> vila, the log only seems to contain "Conflicts during merge: Text conflict in doc/en/release-notes/bzr-2.5.txt"
[10:23] <vila> gnuoy: right, that confirms we failed :)
[10:24] <vila> gnuoy: how about the .bzr.log file on the host (not the chroot) ?
[10:25] <gnuoy> vila, nothing in the past hour
[10:25] <vila> O_O
[10:26] <vila> gnuoy: can you paste some of it ?
[10:27] <gnuoy> vila, https://pastebin.canonical.com/57870/
[10:27] <vila> gnuoy: otherwise we have to revise some belief, so may be the merge occurs *in* the chroot ??
[10:29] <gnuoy> vila, I'm not sure how to determine that
[10:29] <vila> gnuoy: bzr version 2.1.4 !!!
[10:29] <gnuoy> vila, the date is old
[10:29] <vila> gnuoy: well, the .bzr.log in the chroot will give plenty of hints about what is done there
[10:30] <vila> gnuoy: or did you mean you don't know where to find this log file ?
[10:30] <gnuoy> vila, I assume its /srv/pqm.bazaar-vcs.org/chroot/home/pqm/.bzr.log
[10:31] <vila> sounds good
[10:32] <gnuoy> vila, https://pastebin.canonical.com/57871/
[10:33] <vila> ok, so only selftest runs there
[10:34] <vila> but your previous log paste is not good, it says 2011-10-10
[10:34] <gnuoy> yes, I saw that
[10:34] <vila> gnuoy: may be you looked in the old pqm host ?
[10:35] <gnuoy> nope
[10:36] <vila> gnuoy: I'm lost, but there should be a .bzr.log file containing more recent events
[10:43] <vila> gnuoy: may be you *could* look in the old pqm host ? ;-)
[10:43] <vila> gnuoy: (never underestimate silly ideas when all the smart ones fail ;)
[10:47] <gnuoy> vila, there is a bzr.log for the pqm user on the old host but I don't think its relevant, https://pastebin.canonical.com/57872/
[10:49] <vila> gnuoy: you're right, doesn't seem relevant for bzr
[10:50] <gnuoy> vila, I don't suppose this entry from the pqm logs is any help? https://pastebin.canonical.com/57873/
[10:52] <vila> gnuoy: hmm, there is a cwd mentioned there... that I never hear about, but that may indeed be the one we're after ?
[10:52] <vila> gnuoy: and it mentions bzr... (well, bazaar at least_
[10:52] <vila> )
[10:53] <vila> gnuoy: so if we can't find the .bzr.log file you may at least try it at the section name and do another test
[10:54] <vila> gnuoy: switching room again (with  a laptop mentioning low battery while being in charge for the last hour :-/)
[11:08] <niemeyer> Hello there!
[11:09] <niemeyer> We were just wondering what's the state of the multiple-branches-per-directory feature
[11:09] <niemeyer> Is that receiving any attention nowadays?
[11:10] <jelmer> niemeyer: hi
[11:10] <niemeyer> jelmer: Yo!
[11:10] <jelmer> niemeyer: yes, we've been working on that for 2.5
[11:10] <niemeyer> jelmer: Sweet!
[11:10] <jelmer> there is an experimental format named 'development-colo' in 2.5 that adds such support
[11:10] <jelmer> the plan is to eventually merge that support back into the 2a format (as it'd be backwards compatible)
[11:10] <niemeyer> jelmer: Is the experimental feature "experimentable" ATM? :-)
[11:11] <niemeyer> jelmer: Our workflows with Go ATM are a bit ugly and boring to deal with.. this would be quite a neat improvement
[11:11] <jelmer> niemeyer: it does work, but the UI isn't completely there yet
[11:12] <niemeyer> jelmer: What important pieces are missing?
[11:12] <jelmer> niemeyer: at the moment you still need to address colocated branches (as they're being named) by their full URL, rather than by short names as in e.g. git or mercurial
[11:12] <niemeyer> jelmer: If it's workable and won't eat our lunch, we can probably be guinea pigs for it
[11:12] <niemeyer> jelmer: Ok, but what about local use?
[11:12] <jelmer> niemeyer: so "bzr log file:,branch=foo" or "bzr log file:///home/jelmer/src/samba,branch=foo" rather than just "bzr log foo" if you're already in /home/jelmer/src/samba
[11:13] <niemeyer> jelmer: Ok, I could live with that
[11:13] <jelmer> niemeyer: I'm very interested to hear about anything else you run into
[11:14] <niemeyer> jelmer: How do I get started on it?
[11:14] <jelmer> niemeyer: the name we're using for it is co-located branches, the existing known bugs are here: https://bugs.launchpad.net/bzr/+bugs?field.tag=colocated
[11:14] <jelmer> niemeyer: upgrade to development-colo ('bzr upgrade --development-colo')
[11:15] <jelmer> niemeyer: you'd probably want to use the bzr daily builds if you do this, I think a fair number of fixes was made after beta 4
[11:15] <niemeyer> jelmer: Sounds good
[11:15] <jelmer> niemeyer: "bzr branches" will list the existing branches
[11:16] <niemeyer> jelmer: Ah, I've seen that one elsewhere ;).. sweet
[11:17] <niemeyer> jelmer: and to create / checkout new branches onto the existing tree?
[11:17] <niemeyer> jelmer: If there's documentation elsewhere, I'd be happy to read rather than pestering you :)
[11:19] <niemeyer> For those following at home, you'll want this: sudo add-apt-repository ppa:bzr/daily
[11:20] <jelmer> niemeyer: I haven't gotten around to writing that yet unfortunately, mostly because there are still a few rough edges in the UI to fix up
[11:20] <jelmer> (you have been warned)
[11:20] <niemeyer> jelmer: :-)
[11:21] <jelmer> niemeyer: creating a new branch should be "bzr init file:,branch=bla" to create a branch named "bla"
[11:21] <jelmer> (eventually that'll be just "bzr init bla")
[11:28] <niemeyer> jelmer: Just so I understand the underlying model, why the file: prefix?
[11:31] <jelmer> niemeyer: mostly because of our internals
[11:31] <jelmer> niemeyer: we do want to support plain colocated branch names
[11:32] <niemeyer> jelmer: Yeah, I guessed that.. was just wondering what file: would cause to the internals so I can infer when to use it
[11:32] <jelmer> niemeyer: we use a , for path segment parameters, but that only works for URLs at the moment, not for local file paths
[11:33] <niemeyer> jelmer: Aha, gotcha, thanks
[11:34] <jelmer> (we didn't want to break people who had branches with comma's in their path)
[11:37] <niemeyer> jelmer: sensible
[11:37] <niemeyer> jelmer:
[11:38] <niemeyer> [niemeyer@gopher ~/a]% bzr branches
[11:38] <niemeyer> * (default)
[11:38] <niemeyer>   foo
[11:38] <niemeyer> jelmer: How to reference to that "default" branch
[11:38] <niemeyer> jelmer: Just trying to understand how to get started with a directory containing branches
[11:38] <jelmer> niemeyer: with no branch argument you'll get the default branch
[11:39] <niemeyer> jelmer: Hmm.. doesn't seem to work in this case..
[11:42] <niemeyer> Hmm.. it's not clear how to check an existing branch out either
[11:42] <niemeyer> If I use "bzr checkout file:,branch=foo", I get a real directory called ",branch=foo" in the current path
[11:44] <niemeyer> jelmer: ^
[11:46] <jelmer> niemeyer: sorry, at the platform rally atm.. was distracted for a bit
[11:46] <niemeyer> jelmer: Maybe we should talk live.. :-)
[11:46] <jelmer> niemeyer: ah, cool - didn't realize you were here too
[11:46] <niemeyer> jelmer: :)
[11:46] <jelmer> niemeyer: yeah, that might be easier
[11:46] <niemeyer> jelmer: The above history is good, though.. I plan to share it
[11:51] <niemeyer> jelmer: Yeah, I don't know how to switch a branch I'm afraid
[11:58] <jelmer> niemeyer: the setup is a bit tricky at the moment, I'll have a look at it later today and get back to you if that's okay
[12:59] <blackarchon> is there a recent manual on how to create a bzr install for windows?
[20:17] <mwhudson> lifeless: not so as you can tell, but ok