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