[00:21]  * jaimef hunts for the bzr fetch/update
[00:22] <jaimef> ahh pull
[08:14] <mgz> morning
[08:15] <jam> morning mgz, any luck on the ppa stuff?
[10:04] <jml> why you no build daily for quantal?
[10:05] <mgz> there was some discussion on list about what value we were getting from dailies
[10:05] <mgz> but the short answer is because no one has set it up
[10:05] <jml> ah right
[10:06] <jml> well, basically, I want to patch core a couple of times for better colo branch support
[10:06] <jml> but I'm not really interested unless I get to use the patches
[10:06] <jml> I guess I could just add ~/src/bzr to my PATH or something
[10:07] <mgz> I tend to use setup.py install --user
[10:07] <mgz> but a daily for quantal is probably reasonable.
[10:08] <mgz> it's only really the dailies on older (non-lts) releases that were really questioned
[10:11] <mgz> so... I could go around adding precise in the recipes everywhere and see what breaks, then go crying to maxb
[10:13] <vila> mgz: you meant 'adding *quantal*' ?
[10:14] <mgz> I should mind my p-s and q-s...
[10:19] <jml> heh heh
[10:20] <jml> man, so long since I've hacked on bzr
[10:24] <mgz> hm, dulwich ftbs currently...
[10:25] <mgz> quilt error on:
[10:25] <mgz> Applying patch 01_less_strict_index_tests
[10:25] <mgz> patching file dulwich/tests/test_index.py
[10:26] <mgz> should be safe to just pop that patch
[10:27] <mgz> bah, not paying attention, why is bzr-build(?:er|deb) installing postfix on this vm...
[10:29]  * jml gives up and files a bug instead
[10:52] <maxb> It is probably time that we should be turning on dailys for quantal
[10:53] <maxb> My value argument is mainly against maintaining dailys for more than the current stable and current development release
[10:56] <mgz> maxb: I've flipped a few things on and will try to remember to see if there are any new build failures reported
[12:48] <tbf> ...if the main branch moves forward it happens that feature branches develop merge conflicts. is there a better way to solve such issues, than to create a new branch from the main branch and then merge the conflicting feature branch into the new feature branch?
[12:49] <tbf> ...if this'd be git i'd just rebase... but well.
[12:49] <jam> tbf: that doesn't get rid of merge conflicts, it just moves them into the rebase. If you just merge from trunk you can resolve the conflicts in the feature branch without creating yet-another-one.
[12:50] <tbf> jam: of course: i'll have to resolve the conflicts at some point
[12:50] <tbf> jam: let's try
[14:13] <tbf> how does bzr chose its submit branch?
[14:13] <tbf> looks like "bzr info" is showing me total nonsense
[14:14] <LeoNerd> Surely, whatever is named in .bzr/branch/branch.conf ?
[14:16] <jelmer> LeoNerd, and ~/.bazaar
[14:28] <santagada> how do I fork a branch in launchpad?
[14:28] <santagada> the obvious bzr branch lp:... then bzr push lp:~myuser/branch takes a looong time so it apears to be wrong
[14:29] <santagada> shouldn't this be almost instantaneous? or at least not take a long time on the client?
[14:36] <mgz> santagada: the push is slow?
[14:37] <mgz> you probably aren't pushing back to the right location
[14:38] <mgz> eg, I branch lp:bzr, and push back to lp:~gz/bzr/name_of_my_feature
[15:24] <santagada> mgz: it needs the bzr?
[15:25] <santagada> and where can I find this documentation
[15:54] <SamB_MacG5> Hmm... How come INSTALL and setup.py state different minimum required versions of Python?
[16:03] <mgz> SamB_MacG5: doc bug in INSTALL, please feel free to branch lp:bzr/2.4 fix, and propose
[16:04] <mgz> note cElementTree is in python 2.6 core so that bit is also wrong
[16:16] <SamB_MacG5> mgz: Yes, I could swear I've seen somewhere else that mentioned cElementTree as required by bzr but said something about it being bundled in some versions of Python.  (It might have been referring to a version of bzr that actually supports Python 2.5, though.)
[16:19] <mgz> SamB_MacG5: looks like doc/en/admin-guide/introduction.txt also needs updating
[16:21]  * SamB_MacG5 absently wonders how updates to translations are handled
[16:23] <SamB_MacG5> oh, huh, so 2.5 also includes cElementTree
[16:23] <mgz> I tend to update trivial command name changes and stuff in all of them, but leave wording changes for native speakers
[16:23] <mgz> for the admin-guide, there are no translations to worry about at least.
[16:25] <SamB_MacG5> I was more thinking about the problem of figuring out which bits have changed and (likely) need retranslation
[16:28] <mgz> `bzr log -l1 doc/ja` to get N last rev translated docs were changed, then `bzr diff -rN..-1 doc/en` and update would do
[16:31] <SamB_MacG5> makes that gettext-based thing aptitude uses sound like fun, it does!
[16:32] <mgz> gettext is bad enough in general, using it on whole documents even uglier
[16:33] <mgz> (bzr actually does something like that for command help, splits things up into paragraph looking things and hopes, but it's not a very nice way of working)
[16:34] <SamB_MacG5> what would *you* use to track up-to-date/fuzzy/untranslated paragraphs and such?
[16:36] <mgz> I've never really done any translation. Does not seem to be a solved problem though.
[16:37] <SamB_MacG5> at least with ReST like you're using, it presumably isn't terribly tricky to explain which markup should cause something to be considered on its own...
[16:37] <SamB_MacG5> Unlike with docbook and such
[16:41]  * SamB_MacG5 realizes he doesn't need to google for the software, he has an Emacs window open to his Debian box and can just check the source tree for aptitude...
[16:42] <SamB_MacG5> ah, it's called po4a
[16:42]  * SamB_MacG5 has to go
[16:45] <mgz> bye!
[17:19] <jelmer> SamB_MacG5, the minimum required version should be 2.6
[20:41] <SamB_MacG5> okay, what's the *maximum* supported version of Python for bzr 2.4?
[20:44] <fullermd> 2.7, pretty sure.
[20:52] <SamB_MacG5> Hmm, what should become of the bullet items in http://doc.bazaar.canonical.com/developers/code-style.html#python-versions ?
[20:52] <SamB_MacG5> are those things now good?
[20:52] <SamB_MacG5> or are there other reasons any of them shouldn't be allowed?
[20:55] <fullermd> Well, anything talking about pre-2.6 is certainly OBE.
[20:56] <SamB_MacG5> OBE ?
[20:56] <fullermd> Overtaken By Events
[20:58] <SamB_MacG5> And there's a paragraph in http://doc.bazaar.canonical.com/developers/ui.html#progress-and-activity-indications that hinges on Python 2.4's lack of finally blocks in generators
[21:59]  * SamB_MacG5 wishes bzr's docs were in .rst files and/or that Emacs' dir-locals mechanism was a *bit* more expressive ... for example, supporting filename wildcards instead of just modes to act on ...
[22:00] <fullermd> Hm, that works fine in vim.  Maybe you should upgrade  8-}
[22:00] <SamB_MacG5> ... don't you have little cookies at the ends of the files for vim?
[22:01] <fullermd> Well, you could do that too.  But I have all sorts of glob'd up paths in .vimrc for setting this&that.
[22:01] <SamB_MacG5> I'm sure I could do something in ~/.emacs ...
[22:02] <fullermd> Probably.  If nothing else, you could throw together a quick little filesystem implementation that indirects through the raw disk device...
[22:02] <SamB_MacG5> but it would be nicer if something adequate could be added to the repository (regardless of whether or not it would actually be accepted)
[22:04] <SamB_MacG5> something that says "all the .txt files in this tree should be assumed to be in ReStructuredText format"
[22:05] <SamB_MacG5> I had something that almost worked, but it ended up redirecting `log-edit-mode' to `rst-mode' too, so I that's a bust...
[22:40] <SamB_MacG5> soo ... how come nothing seems to link to http://doc.bazaar.canonical.com/developers/win32_build_setup.html ?