[00:32] <kyan> Hello again! Why is it that http://bazaar.launchpad.net/~info-futuramerlin/futuramerlin.com-calculator/main0.96/files shows the content of three of my local directories even though I cded to the right one before 'bzr add' 'bzr commit -m' 'bzr push'?
[01:15] <Demosthenes> right. i'm using branches for separation of roles and distribution. (prod/test/dev) merging up from one to the next, i'm running into situations where i'm having simple one-line changes labelled as conflicts, which don't show in the conflict output
[01:15] <Demosthenes> when i'm merging interactively
[01:18] <maxb> poolie: Hi, if you're around, what's your likely timeline for sorting the failed bzr builds in ~bzr/proposed?
[01:22] <poolie> hi maxb
[01:22] <poolie> i'm going to do that pretty much now
[01:22] <maxb> yay
[01:22]  * maxb resumes bashing dulwich into shap
[01:22] <maxb> e
[01:23] <poolie> hi spiv
[01:24] <spiv> Morning.
[01:27] <spiv> Oh good, the socket regression in python2.6 in maverick got fixed.
[01:30] <jelmer> \o/
[01:39] <poolie> hi spiv
[01:39] <poolie> james_w: still around?
[01:39] <james_w> hi poolie
[01:39] <poolie> spiv if your plate is empty i was going to suggest bug 619614,
[01:39] <poolie> unless james_w is already on it
[01:40] <james_w> nope, I just wanted to note the pointer today, I was going to come back to it soon
[01:41] <james_w> getting a small test case should make working out the interaction fairly easy, but unfortunately because of the strategy of building everything up and then applying the transform it can be hard work going from the final state back to the operations that caused it.
[01:44] <spiv> poolie: ok, I'll do that
[02:04] <poolie> maxb, i know what broke the earlier uploads
[02:04] <poolie> hard and jaunty are now ok, and i'll just push rebuilds for karmic..
[02:39] <poolie> maxb should be all ok now
[02:59] <poolie> testing them in chroot snapshots...
[05:29]  * mwhudson had forgotten how slow log -v is with packs
[05:35] <poolie> maxb: hi; so bzr seems ok in the ppa
[05:35] <poolie> bzr-svn needs some love, or a backport?
[06:16] <poolie_> maxb, i'm going to backport bzr-svn now
[06:16] <poolie_> actually, maybe i'll see if jelmer wants to do that
[06:47] <poolie_> maxb, around?
[07:37] <poolie> james_w: should i just s/debian_bundle/debian to fix these deprecation warnings?
[07:42] <vila> hi all !
[07:45] <vila> poolie: I caught up with my mail backlog and noticed I was patch pilot this week, sorry for starting so late :-/
[07:46] <poolie> np, i was a bit slack last week
[07:46] <poolie> i'm updating ppa packaging stuff
[07:46] <poolie> i'd happily swap :/
[07:46] <poolie> it's a bit tedious
[07:46] <poolie> otoh it's good practice for getting into making it better
[07:47] <vila> yeah, learning is always painful :)
[07:52] <vila> mgz: ping
[08:15] <poolie> woo spiv :)
[08:15] <poolie> vila, what's next for you?
[08:16] <vila> poolie: roughly: pp'ing, re-submitting the mps I've put in WIP before my vacations (leaking tests and locking config files)
[08:17] <spiv> vila: incidentally, if you want to be a really amazing PP, talk a look at the full list of WIP MPs for lp:bzr at https://code.edge.launchpad.net/~bzr-pqm/bzr/bzr.dev/+activereviews
[08:17] <vila> then, pursuing config stuff (as we discussed) and/or more conflict resolution and/or UDD bugs
[08:17] <spiv> Just in case the regular list doesn't keep you busy ;)
[08:18] <vila> spiv: hehe, I've already looked at that if only to find my own  MPs ;)
[08:18] <lifeless> spiv: tests needed ;)
[08:23] <vila> poolie: by the way, I was wrong yesterday, we *have* a maverick slave on babune but it's currently failing because it uses python-2.7 to help mgz
[11:04] <GaryvdM> Hi vila.
[11:04] <vila> GaryvdM: hey !
[11:05] <GaryvdM> Should I maybe merge poolie's branch and mine together with mine, and merge together?
[11:05] <GaryvdM> Or land poolies, and them merge dev into mine?
[11:06] <vila> GaryvdM: just land yours :) If a conflict occurs for poolie it will be trivial to fix
[11:07] <GaryvdM> vila: Ok.
[11:11] <Crovax-31> Hi, it's me again, if I have two branches, i want to apply 2 commits (and not all of them) from one to the other
[11:12] <Crovax-31> do I make a patch or it may be applyed directly?
[11:15] <GaryvdM> Crovax-31: You can do a cherry-pick merge:
[11:15] <GaryvdM> bzr merge FROM_BRANCH -r x..y
[11:16] <GaryvdM> Crovax-31: unfortunately, cherry-picks are not yet tracked in the history like other merges.
[11:18] <Crovax-31> GaryvdM:  which man page talk about this feature?
[11:19] <GaryvdM> Crovax-31: bzr help merge
[11:20] <GaryvdM> quote: "When merging a branch, by default the tip will be merged. To pick a different
[11:20] <GaryvdM>   revision, pass --revision. If you specify two values, the first will be used as
[11:20] <GaryvdM>   BASE and the second one as OTHER. Merging individual revisions, or a subset of
[11:20] <GaryvdM>   available revisions, like this is commonly referred to as "cherrypicking"."
[11:21] <Crovax-31> great, thanx for the help
[11:31] <Crovax-31> "bzr merge --revision=4761..4762 ../my_repo/" thanx GaryvdM
[11:39] <fullermd> Note that that's applying 1 commit, not two...
[11:40]  * jelmer waves
[12:45] <LeoNerd> Is there anything I ought to know about running bzr as root? E.g I'm using it to version control my DNS zonefiles in /etc/bind, inplace, so I just run   sudo bzr ...
[12:47] <vila> LeoNerd: you may encounter errors about the log file or some config file in ~/.bazaar owned by root,
[12:47] <vila> but AFAIK we fixed that in recent versions of bzr
[12:48] <LeoNerd> OK.. well.. so far I've not seen any errors or problems at all, in fact.. :) Was just wondering if e.g. there might be any security issues involved in it..?
[12:49] <vila> LeoNerd: well, nothing that I know of, but as usual while running anything as root, be extra careful :D
[12:49] <LeoNerd> Sure. :)
[12:50] <LeoNerd> e.g I was just wondering if $malicioususer could plant some file somewhere that bzr as root would execute.. but then if said user can write to /etc/bind I suppose I have bigger problems
[12:51] <vila> LeoNerd: being paranoid but willing to version control some files that only root can modify, I've setup some scripts to help me *copy* the original files into a versioned controlled tree, but that's just me :) etckeeper requires bzr to be run as root
[12:52] <vila> LeoNerd: I'm pretty sure bzr doesn't rely on any external exceutable by default (except python itself of course)
[12:52] <vila> diff was used in the early days but isn't anymore
[12:53] <LeoNerd> Ya.. was wondering on local plugins and whatnot..
[12:53] <vila> at least not by default (patch were used too long ago)
[12:53] <LeoNerd> E.g. I know vim has had issues in the past with modelines and so on...
[12:53] <LeoNerd> A user could construct a modeline that means vim will execute a command as root, if root even just "view"s the file. :)
[12:53] <vila> LeoNerd: so, even with sudo, the user plugins will be used
[12:55] <vila> LeoNerd: you can avoid them if you don't need them with --no-plugins or with a paranoid use of BZR_PLUGIN_PATH, BZR_DISABLE_PLUGINS and BZR_PLUGINS_AT
[12:56] <LeoNerd> Right.. Well, I think this is good enough
[12:56] <vila> ok
[12:57] <vila> mgz: ping
[13:08] <maxb> I suppose one thing that could be done is for sudo to clear BZR_PLUGIN_PATH and BZR_PLUGINS_AT, much like it clears PYTHONPATH
[13:14] <vila> maxb: meh, that will forbid the trick I mentioned above :)
[13:22] <LeoNerd> maxb: Doesn't sudo by default clear most of env anyway?
[13:22] <maxb> it varies on config
[13:22] <maxb> mine doesn't because it's too damn paranoid
[13:22] <maxb> s/it's/that's/
[13:29] <vila> LeoNerd: you may also consider 'sudo -H' so that ~root is used to better control which plugins are used and avoid the bugs I mentioned above
[13:30] <mgz> hey vila!
[13:30] <vila> mgz: heeey !
[13:30] <LeoNerd> AHyes
[13:30] <mgz> did you have a nice holiday?
[13:31] <vila> mgz: just... lovely :)
[13:32] <vila> mgz: I'm looking at https://code.edge.launchpad.net/~gz/bzr/cleanup_testcases_by_collection_613247/+merge/32711
[13:32] <mgz> there's some log from a few evening ago that might help as well...
[13:32]  * mgz goes to find
[13:32] <vila> and the corresponding one for testtools
[13:33] <mgz> http://irclogs.ubuntu.com/2010/08/15/%23bzr.html#t23:35
[13:33] <mgz> http://irclogs.ubuntu.com/2010/08/16/%23bzr.html
[13:37] <vila> mgz: see my comment on the mp while I read those logs
[13:37] <mgz> great thanks, I'll go read.
[13:38] <vila> mgz: hmm, I just realize the ~4000 uncollected test cases I'm seeing may require your testtools patch...
[13:38] <mgz> ah, yeah, and I needed some feedback on if that'd break --parallel
[13:38] <vila> mgz: there is that too :)
[13:39] <mgz> wasn't clear from the code and I didn't want to fiddle around faking more than one cpu here as there weren't any failing test_selftest tests
[13:40] <vila> mgz: I don't understand how locals can be involved in ref cycles... Aren't they supposed to be freed when leaving a function/method ?
[13:40] <vila> mgz: cough, lack of test for --parallel ? I can believe it :->
[13:40] <vila> grrr, I *can't* believe it
[13:41] <mgz> it works as an expression both ways!
[13:41] <mgz> just needs different tone of voice imagined.
[13:41] <vila> looks like holidays is not a cure for my typos ruining jokes disease :)
[13:42] <mgz> okay, I'll reply to a few points in the mp so they get recorded rather than lost on irc
[13:42] <vila> mgz: all the babune slaves have 2G not 8 :)
[13:42] <vila> mgz: works for me
[13:43] <mgz> I'm unsure, but I think this probably won't help babune,
[13:44] <mgz> unless some of the thread failures are of the "can't start new thread" variety still.
[13:44] <vila> mgz: Just mentioning to mitigate your remark about people with 8G PCs (not that I'm concerned here since I have 12G :-D)
[13:44] <mgz> ehehehe
[13:45] <mgz> most devs do, it's only me and parth who've reported issues running the whole test suite
[13:45] <vila> mgz: also, maverick/py27 is still failing if you want to have a look at it on babune
[13:45] <mgz> great, I will do.
[13:46] <mgz> hopefully I've got bugs filed on everything, but maverick might turn up a few new ones.
[14:03] <GaryvdM> I'm sure I read about tool in bzr to help merge changelog files, but I can't find anything about it now.
[14:04] <GaryvdM> Can anyone advise me where to look?
[14:05] <mgz> do you just mean the news-merge plugin?
[14:05] <vila> GaryvdM: james_w will now for sure but I suspect it's part of builddeb and similar to news-merge
[14:05] <james_w> poolie: no, I prefer to import the new name and catch ImportError to fall back.
[14:05] <mgz> vila: what's the link for maverick/py27 on babune? (posted mp reply)
[14:05] <GaryvdM> mgz: oh - maybe that was what I was thinking about.
[14:06] <vila> mgz: it's just maverick, py27 has been installed for you, I will revert that once you're happy with the results to turn the slave into a "regular" one (revert to py26 until py27 becomes "natuarally" the default for maverick if ever)
[14:07] <james_w> GaryvdM: yeah, there's one for Debian changelogs in bzr-builddeb thanks to jam
[14:08] <vila> mgz:  in case you encounter weird problems related to extensions, pyrex is not available so far for py27 so I ran py26 setup.py build_ext -i
[14:08] <mgz> hm, and I see it ends with:
[14:08] <mgz> ERROR: Failed to archive test reports
[14:08] <mgz> hudson.util.IOException2: remote file operation failed: /home/babune/babune/slaves/maverick64.local/workspace/selftest-maverick at hudson.remoting.Channel@3a777ac9:maverick64.local
[14:08] <mgz> which I presume is not my fault?
[14:08] <vila> mgz: the last one yes, some previous one went a bit further I think
[14:09] <vila> mgz: well, it's nobody's fault :) But I thought you fixed enough stuff to make it pass... I was wrong :)
[14:10] <mgz> yeah, #16 ran the whole suite, but hudson appears to have not managed to record the results
[14:10] <mgz> Ran 20939 tests in 298.961s
[14:10] <mgz> FAILED (failures=53, errors=8, skipped=2184, expected failures=25)
[14:10] <mgz> that's not too bad, and the tail-end ones in the console log all look like things I've got bugs open for
[14:11] <GaryvdM> james_w: Thanks. I think it's maybe not beening used, as the debian dir is the root of the branch. I change that, and see if it works.
[14:11] <GaryvdM> mgz: Is that for py2.7?
[14:11] <mgz> yup.
[14:12] <mgz> odd, bzrlib.tests.per_repository.test_revision.TestRevProps.test_simple_revprops(RepositoryFormat6) has the same traceback five times,
[14:12] <mgz> might mean Robert's cleanup reporting is broken on 2.7 somehow
[14:13] <mgz> ha, yes, each (param) is adding a traceback
[14:19] <vila> mgz: good, I'm more concerned by the [multi part 0 .... ] stuff still looking like leaks from subunit or something
[14:21] <mgz> I'm just getting the full log now. continuing stream leaky problems probably explain the java xml parsing error at the end that's breaking the reporting
[14:22] <mgz> I'll have a look at the subunit code see if I come up with any theories
[14:26] <GaryvdM> vila: is this a bug? : http://pastebin.org/613865
[14:27] <vila> GaryvdM: tree transform is malformed is almost always a bug :-/ bzr.dev ?
[14:28] <GaryvdM> vila: no - 2.2.0
[14:28] <GaryvdM> vila: Let me try with bzr.dev
[14:28] <vila> GaryvdM: no need,
[14:28] <vila> GaryvdM: 2.0 and dev are close enough
[14:29] <vila> GaryvdM: a bug with a reproducing recipe will be highly appreciated (especially if you encountered it for a common use case (which I suspect))
[14:30] <GaryvdM> vila: Ok
[18:19] <nUboon2Age> newbie question: i forgot to add an item in the changelog when i was doing a commit.  is there a way to retroactively alter it to add the item?
[18:23] <LeoNerd> Only by uncommit/commit, but then you've made a brand-new commit, not altered the original one. If it's a private branch nobody else is looking at, then that should be OK, but if it's been pushed or exists somewhere others can see it then its' a rather disruptive operation, as now everyone else will be out of sync.
[18:28] <nUboon2Age> LeoNerd: okay thank you for a clear explanation.  That lays out my options fairly straightforwardly.
[18:30] <nUboon2Age> oh, another related question: i pushed this rev onto LP.  can i somehow delete this branch (so i can do it again correctly?) LeoNerd?
[18:31] <LeoNerd> Ah well, I don't really know LP much...
[18:31] <nUboon2Age> i mean the LP version of the branch, not my local version of the branch...
[18:32] <nUboon2Age> LeoNerd: oh, okay well thank you for your help.  i appreciate it.  anyone else?
[18:34] <nUboon2Age> okay i found a place to delete the branch, so thanks all. ;-)
[18:35] <nUboon2Age> on the branch details page.
[18:35] <rubbs> nUboon2Age: if someone else already branched from that LP branch you could still run into trouble
[18:35] <nUboon2Age> ah good to know rubbs. thank you.
[18:36] <rubbs> np
[18:36] <rubbs> mostly because all their stuff will be referencing that branch. It may be a good idea to just add another commit with your fix.
[18:37] <nUboon2Age> here's just a thought: it'd be nice to have some kind of admin function where mistakes like that could be fixed. ;-)
[18:38] <nUboon2Age> i can imagine it would be complicated, but i can envision it being at least possible.
[18:50] <vila> nUboon2Age: if nobody has yet pull your branch you can do 'push --owerwrite'
[18:50] <nUboon2Age> vila: oh cool.  thanks!
[18:50] <vila> nUboon2Age: well, even if some people have pulled, you still can, they will have to either 'pull --overwrite' or merge if they really need
[18:51] <nUboon2Age> vila: excellante!
[19:25] <hazmat> with bzrlib how do i get from a branch object to the working tree object?
[19:26] <hazmat> i'm trying to programatically check if my local branch/checkout has uncommitted changes
[19:41] <vila> hazmat: you can go from wt to branch (wt.branch) not the other way around, a branch has no idea about which wt is using it and the only the wt can have uncommitted changes
[19:42] <vila> hazmat: wt.has_changes() should address your need
[19:42] <hazmat> vila, ic, thanks
[20:57] <hazmat> using bzrlib.. given a remote branch url like lp:~zebra/foobar/trunk .. how could you open a branch object pointing to it?
[20:58] <hazmat> i tried Branch.open(url) but it seems to want things from the local fs
[21:04] <hazmat> ah.. i need to deference lp and use a transport it looks like
[21:17] <vila> hazmat: b = Branch.open_containing(location)[0]
[21:17] <vila> hazmat: when searching for such tricks, have a look in bzrlib/builtins.py
[21:17]  * vila off to bed :)
[21:18] <hazmat> vila, i'll have a look, i ended up going location = "lp:~/foobar/foobra/ensemble".replace("lp:", "bzr+ssh://bzr.lp.net"); t = get_transport(location); Branch.open_from_transport(t).. doing open_containing with a remote location by default attempted to look at a local directory
[21:19] <hazmat> at least with the lp  alias
[21:20] <lifeless> you can get *a* wt for a branch (not the only one, may not be the one being committed from, may not exist), by doing branch.bzrdir.open_workingtree()