[07:55] <vila> hi all
[09:01] <jelmer> hi vila
[09:02] <mgz> morning all
[09:03] <vila> synchronicity :) hey mgz, jelmer
[09:13] <mgz> who's pilot?
[09:13] <mgz> ...jelmer, sayeth the wiki
[09:14] <mgz> ...arkgr
[09:20] <jelmer> ah, hmm
[09:20] <jelmer> vila, mgz: if either of you could do a second review of https://code.launchpad.net/~nmb/bzr/893470-dedupe-list-branches/+merge/83075, that'd be grand
[09:25] <jelmer> hmm, doesn't seem like there is an awful lot to PP on..
[09:26] <vila> jelmer, mgz: on it
[09:27] <mgz> jelmer: there might be a rush later in the week, you never know :)
[09:32] <mgz> jelmer: is bug 55461 fixed now with the splitting of get_transport in two?
[09:32] <jelmer> mgz: yup
[09:33]  * jelmer assigns to himself
[09:33] <jelmer> mgz: thanks
[09:33] <vila> jelmer: reviewed, BB:tweak
[09:34] <jelmer> hmm
[09:34] <jelmer> mgz: bug 390486 also seems to be in progress now..
[09:34] <mgz> heh, just looking at that one as well.
[09:35] <mgz> trying to find a bug for remote push not creating trees, but we don't seem to have anything saying exactly that
[09:35] <vila> because we've never supported it except via push-and-update
[09:36] <jelmer> mgz: bug 325355 ?
[09:36] <mgz> ...that'll do
[09:36] <vila> and the current effort from jelmer is blocked by the chroot
[09:40] <mgz> if it was a real chroot, could just treat the paths as relative to /
[09:40] <mgz> and worry less about accidentally escaping
[09:41] <vila> the issue is that the chroot is a transport and wts want local paths (or be fixed to use the transport API)
[09:45] <vila> does 'safe_decode() called on an already-unicode string' ring a bell ? Recent addition ?
[09:47] <mgz> o_O
[09:47] <vila> seen in an import log file so a trace.mutter probably
[09:47] <mgz> stack? it's not a function we use I think
[09:49] <vila> brz-builddeb ?
[09:50] <vila> yup, in util.py
[09:50] <mgz> ah, b...
[09:50] <mgz> you got there first
[09:51] <vila> testing a local jubany ~clone
[09:51] <mgz> change that to mutter_callsite if you want to see the cause
[09:51] <astraljava> Hi guys. Got a small puzzle here which is probably a cakewalk for you guys. Basically, I did a merge on a branch, which wasn't up-to-date, and now as I try to revert, it does nothing.
[09:52] <astraljava> The branch is lp:~ubuntustudio-dev/ubuntu-seeds/ubuntustudio.precise
[09:58] <mgz> astraljava: did you commit the merge?
[10:00] <astraljava> mgz: Yes. Now I got it reverted, but the earlier commits are still missing.
[10:02] <mgz> reverted as in... `bzr uncommit` or as in `bzr revert -r-2 && bzr commit` or as in `bzr merge -r-1..-2 && bzr commit`?
[10:02] <mgz> likely, all you want is to do `bzr pull`
[10:02] <astraljava> mgz: I did `bzr uncommit` && `bzr update`
[10:02] <mgz> and get the tip from lp again... unless you already pushed to lp
[10:03] <mgz> in which case you want to get the old head from your repo and pull that revid
[10:04] <astraljava> mgz: I didn't push after the uncommit, no.
[10:05] <mgz> so, does pulling from lp get you back up to the latest rev?
[10:06] <astraljava> mgz: No. It is back to the revision that I pushed as the merge.
[10:07] <mgz> okay, so you did push to lp.
[10:07] <astraljava> mgz: I pushed after the merge, yes, but not after the uncommit.
[10:07] <astraljava> Sorry if I was unclear.
[10:09] <astraljava> I was told that bzr doesn't allow this operation (pushing from a non-up-to-date branch) by default, but I don't find --overwrite in my config either.
[10:09] <astraljava> I didn't expect this, cause I use other rcs more, and there this doesn't happen. Is there a config entry I can make so that it won't happen again?
[10:12] <mgz> it is a little suprising it was allowed, suggests you didn't do exactly what you thought
[10:12] <mgz> what changes did you lose from tip? just two?
[10:12] <astraljava> mgz: Perhaps so, I claim not to be an expert by any means.
[10:13] <astraljava> mgz: Two, yes. There were already commits 1278 and 1279, but seems my branch was only at 1277, thus my merge commit becoming the new 1278.
[10:13] <mgz> one from colin and one from steven? in which case, you just reordered the mainline
[10:13] <mgz> which is easy to fix, and there is a config option to prevent accidentally doing it
[10:14] <astraljava> mgz: I believe so, yes. I only noticed 1279 from Colin.
[10:14] <mgz> so, in your local branch, do
[10:14] <mgz> `bzr pull -r 1277.1.2`
[10:16] <mgz> then you can either merge the current tip, or redo the original merge and overwrite the top revision on lp
[10:16] <astraljava> Did the first, now says on revision 1279, which sounds lovely.
[10:17] <astraljava> So it's up-to-date now, and I can merge another branch with that?
[10:17] <mgz> so, if you now do `bzr merge :parent`
[10:18] <mgz> you'll merge in the merge you did already, but without reordering the mainline, and can commit and push that
[10:18] <mgz> which should make the branch on lp look sensible again without having to uncommit there as well.
[10:19] <mgz> or, at your choice, do uncommit lp:... and if anyone has pulled in the mean time they'll need to drop that revision too
[10:21] <mgz> once done playing, can avoid this in future by doing `bzr config append_revisions_only=True -d lp:~ubuntustudio-dev/ubuntu-seeds/ubuntustudio.precise`
[10:24] <astraljava> mgz: Okay, so `bzr status` says there's a pending merge, so I just merge again now? What does `bzr merge :parent` mean?
[10:25] <mgz> ...this is a little hard to explain without drawing trees
[10:26] <astraljava> mgz: Okay, nevermind. :)
[10:26] <mgz> basically, all you did was change the left-hand path
[10:27] <mgz> by merging your previous merge again, but onto the latest revision, you change what counts as the mainline back to what it was
[10:28] <mgz> (:parent just means "from launchpad" in this case, which has the merge you did before)
[10:28] <astraljava> mgz: Gotcha.
[10:28] <mgz> so, committing this merge and pushing it reorders the tree again
[10:29] <mgz> but existing revisions stay as they were
[10:29] <mgz> there are some threads on the bazaar list with pretty pictures
[10:32] <astraljava> mgz: I must have done something wrong, still, cause now it says the branches have diverged.
[10:34] <mgz> do `bzr log -c-1 -n0` in your local branch and pastebin me the output?
[10:35] <astraljava> mgz: http://paste.ubuntu.com/767743/
[10:37] <astraljava> Oh btw. can that config be a global one? I didn't find a global config file.
[10:38] <mgz> it's a per-branch config
[10:38] <astraljava> Okay, thanks.
[10:38] <mgz> ideally it'd be set true by default in many circumstances, as this is confusing and annoying for people
[10:39] <mgz> right... that's not the right revision merged somehow
[10:40] <mgz> but you could push --overwrite that and it would be fine.
[10:41] <astraljava> Ok, so it will be fine for others after the push?
[10:41] <mgz> it would tell them their branches have divered if they've already pulled, but it's likely not fatal here
[10:42] <astraljava> mgz: Okay. Is there then a way to get rid of that message? I could tell people that then, if they visit our channel complaining about that.
[10:42] <mgz> they basically just need to pull --overwrite
[10:43] <astraljava> Ok. Haha! Now it complains about "AppendRevisionsOnlyViolation". :D
[10:43] <mgz> right :)
[10:44] <astraljava> Ok, let's see now whether it worked alright.
[10:44] <astraljava> At least it says it pushed up to revision 1280.
[10:44] <astraljava> YES!
[10:44] <astraljava> mgz: I could kiss you right now.
[10:45] <astraljava> mgz: But I think I better let that be.
[10:45] <astraljava> Thanks so much!
[10:49] <mgz> great!
[11:26] <glen> how do i update current trunk checkout to some named tag?
[11:28] <mgz> `bzr update -rtag:your_tag`
[11:31] <glen> $ bzr up -r tag:release-2.3.1-final
[11:31] <glen> bzr: ERROR: no such option: -r
[11:32] <jelmer> glen: what version of bzr are you using? the -r option is fairly recent.
[11:32] <glen> bzr-0:2.0.3-1.amd64
[11:32] <jelmer> that's quite old
[11:32] <jelmer> more than two years I think
[11:32] <jelmer> glen: you can also use "bzr revert -rtag:your_tag"
[11:32] <glen> not as old as bzr-1.18-1.amd64.rpm :)
[11:33] <vila> Riddell: hey ! How are you ? Hopefully better ?
[11:33] <glen> and how to go back to trunk?
[11:33] <jelmer> glen: "bzr revert"
[11:33] <mgz> he has too many llls now, perhaps he's become welsh?
[11:34] <vila> argh, false alert ?
[11:35] <Riddelll> vila: well better is a relative term, my brain is still a bit slow and I've got an eye blocked off else I see squint
[11:35] <glen> jelmer: seems i can't upgrade bzr. i'm on py2.4. [ERROR] Not a supported Python version. Need 2.6+
[11:35] <vila> :-/
[11:36] <vila> Riddelll: glad to see you here anyway :)
[11:37] <Riddelll> vila: I won't be driving on French roads in the near future :)
[11:37] <vila> Riddelll: caribean drivers (and roads) are... different
[11:38] <vila> Riddelll: what happened ?
[11:39] <vila> Riddelll: I remember getting very very scared the first time I saw a car on the right *lane* one night, stopped and without lights...
[11:39] <vila> Riddelll: since then, I drove far slower...
[11:39] <Riddelll> vila: I don't remember what happened
[11:39] <vila> :-/
[11:39] <vila> Riddelll: you were alone ?
[11:40] <Riddelll> yes
[11:40] <vila> Riddelll: and woke up at the hospital ?
[11:41] <Riddelll> yes
[11:41] <vila> :-(
[11:42] <Riddelll> where the doctors promptly kicked me out and sent me home in a taxi
[11:42] <mgz> Riddell: we love you, even if we can't do much from this side of the ocean :)
[11:43] <Riddelll> I'm back on the same side of ocean now
[11:43] <Riddelll> in presence if not in timezone
[11:44] <mgz> ah, you're returned? in time for the cold and storms?
[11:44] <vila> Riddell: wow, that was rude :-(
[11:45] <vila> Riddell: I hope you still have better souvenirs from Guadeloupe :-}
[11:46] <Riddell> mgz: the storms I'm used to but not the cold
[11:50] <schnoodles> Howdy i merged a branch and pushed it but i was told that its not ready to be merged. How do i revert the git history ?
[12:15] <jelmer> glyph: bzr < 2.4 should still work
[12:15] <jelmer> glyph: bzr 2.3 is a huge improvement over 2.0
[12:15] <jelmer> schnoodles: wrong channel ? :)
[12:17] <mgz> glen: ^
[12:18] <jelmer> oops
[12:18] <jelmer> sorry glyph
[12:18] <jelmer> glyph: I guess you're higher than glen in my irssi <tab> priority list..
[12:24] <jelmer> urgh
[12:25] <jelmer> 1490 'open' calls during a simple "bzr ls" without plugins
[12:26] <jelmer> (my serializer-avoids-xml branch brings that down to ~1290)
[12:26] <jelmer> there is lots of stuff in there that's unnecessary though
[12:26] <vila> jelmer: o_O, open as in python builting open ?
[12:26] <mgz> is that including imp...
[12:26] <vila> s/g//
[12:26] <mgz> what vila asked
[12:27] <jelmer> vila: no, libc open
[12:27] <jelmer> there's ~100 opens related to ubuntu one
[12:27] <vila> what does u1 have to do with 'bzr ls' ???
[12:28] <jelmer> vila: it installs extra .pth files, which means python probes for modules in more locations
[12:28] <mgz> okay, back to what I was asking then, how many of those are python imports?
[12:28]  * jelmer files a bug against u1
[12:28] <vila> argh
[12:31] <jelmer> mgz: all but 2 dozen
[12:31] <jelmer> mgz: those 2 dozen are system libraries and bzr repository opens
[12:33] <jelmer> hmm, more like 3 dozen, actually
[12:34] <jelmer> mgz: 1206 from python, 20 from the system and 19 for bzr
[12:35] <mgz> okay, not quite as bad as it sounds then, we do need to do some more stuff on reducing the total number of modules basic bzr operations want though.
[12:35] <jelmer> vila: bzr actually opens bazaar.conf 6 times :(
[12:35] <mgz> vila's on that! :)
[12:35] <jelmer> mgz: (that's with my xml branch, otherwise there's 200 more from the xml modules)
[12:36] <mgz> reviewing now
[12:36] <vila> jelmer: I know, there is currently no central place where we could avoid re-opening bazaar.conf
[12:37] <mgz> library_state!
[12:42] <vila> mgz: hehe, yes, library_state will be involved but some sort of possible_config_stores is also needed
[12:46] <jelmer> bug 903180
[12:56] <jelmer> vila, mgz: Hmm, I wonder if it makes sense to use "from __future__ import absolute_import" everywhere
[12:58] <vila> jelmer: what does absolute_import ?
[13:00] <mgz> vila: breaks plugins :)
[13:01] <vila> oh, you mean, making relative imports illegal ?
[13:01] <vila> +1 :)
[13:01] <jelmer> mgz: I don't think it will, it's limited to the module in which you add it right?
[13:02] <mgz> I'm joking a little jelmer, 'everywhere' would take some doing.
[13:02] <mgz> but bzrlib shouldn't break... much
[13:03]  * mgz eyes bzrlib.test_suite
[13:03] <mgz> def test_suite(): import tests return tests.test_suite()
[13:03] <vila> pff
[13:04] <mgz> I'd prefer not to add things all over the code base if we could do a lint check instead.
[13:05] <mgz> otherwise seems a fine idea.
[13:08] <jelmer> hmm, actually
[13:09] <jelmer> it's a trivial patch to make lazy_import do absolute imports only by default
[13:09] <mgz> that's worthwhile.
[13:09] <jelmer> now that we're on >= 2.5
[13:12] <mgz> jelmer: do we want mkdir -p to actually not complain if dir exists?
[13:13] <mgz> seems that's the shell behaviour so might be least suprising
[13:14]  * mgz writes some tests and adds try/except
[13:16] <jelmer> mgz: hmm, I guess
[13:17] <jelmer> mgz: it seems we'll need to check before running os.makedirs(). The code that does the versioning already handles it existing.
[13:20] <mgz> well, what I've just written is catching the OSError
[13:20] <mgz> but... seems that builtins doesn't have the errno module imported which is mildly annoying
[13:21] <mgz> okay, lazy import, tests pass
[13:27] <mgz> phone answered, branch pushed
[13:39] <jelmer> mgz: sorry for the noisy comments..
[14:02] <wgz> I approve of noise!
[14:17] <vila> wgz: meh, I missed that while reviewing but it seems get_environ_unicode in win32utils is not used outside of tests ??
[14:27] <wgz> vila: indeed, it's another one of the little pieces branches
[14:28] <vila> ha ok
[14:28] <wgz> next in the stack is bug 832028
[14:30] <vila> wgz: ok, what's the plan ?
[14:30] <vila> requires some encoding and force a wrapper around os.environ ?
[14:31] <wgz> pretty much
[14:31] <wgz> -    base = os.environ.get('BZR_HOME', None)
[14:31] <wgz> +    base = osutils.path_from_environ('BZR_HOME')
[14:32] <wgz> hm, commited that with the wrong whoami last week
[14:33] <wgz> the tricky bit is not breaking nix too much by decoding paths we used to let through as bytestrings
[14:34] <wgz> hence the diversion via bug 794353
[17:38] <wgz> argh, would have been faster to just delete everything and start from scratch, there's no sense to how things are arranged currently
[17:40] <jelmer> wgz: which things?
[17:42] <wgz> all of osutils and win32utils more so, and how they interact
[17:44] <jelmer> ah
[17:44] <wgz> I can't use osutils functions from win32utils (without local imports), and the randomness of how things are split between then is crazy
[17:45] <wgz> there's a bug that was reported, and worked around, just because it wasn't clear there was already an implementation of the right thing in the other file
[17:45] <wgz> and bzr-explorer et all make things worse by duplicating even more :)
[17:52] <jelmer> ahh
[17:54] <wgz> need to stop trying to make things perfect and just... go for better
[18:00] <glyph> wgz: Le mieux est l'ennemi du bien
[18:01] <wgz> should make that my motto really, I get stuck on dumb things like this way too much
[18:09] <glyph> Is there an idiom that bzr users use which I haven't discovered yet, which is (without using colocated branches) similar to 'git fetch'?
[18:09] <glyph> I find myself doing stuff like "(cd ../upstream; bzr pull); bzr pull" quite a lot.
[18:10] <jelmer> glyph: there is "bzr multi-pull"
[18:10] <jelmer> part of bzrtools
[18:10] <glyph> "... and the branches of checkouts"?
[18:10] <glyph> this is going to be a learning adventure :)
[18:10] <jelmer> glyph: branches of checkouts?
[19:23] <Saxy> Anybody here ?
[19:24] <Saxy> Have a question about bazaar !
[19:24] <Saxy> .-(
[19:25] <Saxy> Will try again later !
[19:26] <glyph> jelmer: heh, unfortunately my directory structure (there are SVN checkouts here too) looks quite antagonistic towards multi-pull
[19:26] <glyph> but this will be quite useful in some cases
[19:26] <glyph> jelmer: what's a "branch of a checkout" though?
[19:27] <glyph> My understanding was that a branch was a thing you have a checkout of, not vice versa.
[19:28] <fullermd> Presumably it means "the branch this is a checkout of".
[19:29] <fullermd> i.e., foreach(thing in we_found) { pull(open_branch_of(thing)) }
[19:30] <thomi> Hi - is there a bzr command that lets me know if branch X will cleanly merge into this branch? Currently I do a merge & then a revert, but maybe there's a simpler way?
[19:33] <wgz> thomi: `bzr merge preview > /dev/null && echo 'Will merge cleanly'` maybe?
[19:33] <wgz> *--preview
[19:34] <thomi> oooh
[19:35] <thomi> hmmm, it's be nice to have a --dry-run flag
[19:36] <thomi> because I can't do the above with a bzr alias.
[19:36] <thomi> I guess I could set up a bash alias, but that's not as nice.
[20:28] <wgz> I'm reading the XDG Base Directory spec, and I have no idea where it thinks .bzr.log should go
[20:33] <jelmer> wgz: that's a good question, indeed
[20:39] <spm> jelmer: ta wrt the importd cleanup; just getting rid of the .db and tmp files now.
[20:41] <mgz> okay, enough banging head against this environment/configs stuff, let's discuss it in the standup tomorrow
[20:42] <jelmer> spm: anytime :)
[20:49] <wgz> ha, bug 257895 is funny, the xml inventories don't cope with files containing C0 control codes
[20:51] <wgz> that must be pretty much wontfix by now, it would require layering an escaping scheme on top, or at least rejecting dodgy filenames
[20:52] <jelmer> wgz: you have an... interesting sense of humour
[20:54] <wgz> I was looking the regexps in your code moving earlier today and thinking "hey, that's not actually correct",
[20:54] <wgz> and lo, we have bugs.
[20:57] <jelmer> wgz: introduced by me, or prexisting?
[20:57] <jelmer> *pre-existing
[21:16] <Noldorin> hi folks
[21:17] <Noldorin> lifeless, hey
[21:19] <wgz> jelmer: bugs as old as the original code, not your move today
[21:46] <Noldorin> hi wgz
[21:48] <wgz> I can never tell if you saying hi means you want something Noldorin :)
[21:48] <Noldorin> wgz, who doesn't? :-P
[21:48] <Noldorin> would you prefer i say bugger off ;-)
[21:48] <fullermd> If you're offering, I'd like a bacon cheeseburger.
[21:50] <jelmer> fullermd: I think you have to say hi first
[21:50] <wgz> we're having a burger off?
[21:50] <wgz> I don't think I'm very good at making burgers...
[21:52] <fullermd> You kill a cow, you kill a pig, you put the big on the cow, add fire.  's not that hard   :p
[21:52] <fullermd> (note that I didn't say the fire should be _near_ the cow and the pig, of course.  Who wants burnt meat?)
[21:54] <Noldorin> wgz, fullermd you could have made a slightly less appetising joke but that isn't what i meant either :-P
[22:05] <Noldorin> wgz, bah, you probably aren't even familiar with the English expression :-P
[22:05] <Noldorin> anyway...
[23:35] <BlindWolf8> Hello all. Is there a way that myself or a team member can view the latest changelog without doing an Update/Pull locally?
[23:37] <LeoNerd> bzr log URL
[23:37] <fullermd> Will probably be as fast (or faster) to pull locally though, unless you're a long way behind.
[23:39] <BlindWolf8> I think he just wants to see it to avoid conflicts...I could just get him to update at the start of each day to avoid issues
[23:39] <spiv> "bzr missing URL" might be what they want?
[23:40] <BlindWolf8> that could be...is there a GUI option or is the only option a command line?
[23:40] <BlindWolf8> he can use the comand line no problem, but I figured I'd ask
[23:42] <BlindWolf8> btw, just saw an option for Shelve/Unshelve changes. I'm assuming this is something new? what does it do?
[23:43] <maxb_> It has existed for years :-)
[23:44] <BlindWolf8> hahah
[23:44] <BlindWolf8> I found the docs
[23:44] <maxb_> It means to temporarily remove uncommitted changes from the working tree and hide them inside the .bzr dir for later recall
[23:44] <BlindWolf8> does shelfing a change work on uncommited changes too?
[23:44] <BlindWolf8> I'm assuming so since shelfing a commited change is just like reverting
[23:45] <maxb_> shelving a committed change doesn't really make any sense to me
[23:45] <BlindWolf8> right, just making sure
[23:45] <BlindWolf8> thanks guys!