 Sorry oom
[17:25] <Kilos> np man
[17:25] <Kilos> this is a heavy winter
[17:26] <Kilos> i see danie and gadget guy one person
[17:27] <inetpro> last night I put a hot water bottle by my feet, helped a lot to keep warm
[17:27] <Kilos> hahaha i do that all day
[17:28] <inetpro> Kilos: yes, GadgeteerZA likes changing his nick around :-)
[17:28] <Kilos> this house is very cold. does not see much sun with all the trees
[17:29] <inetpro> Kilos: you might wamt to join him at #gadgeteerza
[17:29] <Kilos> too much to read aeady
[17:29] <Kilos> already
[17:30] <Kilos> i hardly ever go to twitter anymore
[17:31]  * inetpro has the same challenges, just can't keep up with it
[17:31] <Kilos> yip too much
[17:32] <Kilos> came out of hospital to 700 emails
[17:33] <Kilos> brb
[17:39] <GadgeteerZA> Kilos one person technically but each is one half of my brain...
[17:42] <Kilos> hahahaha
[17:46]  * inetpro wbb
[17:47] <Kilos> ok
[18:30] <inetpro> wb pavlushka
[18:31] <pavlushka> inetpro: ty
[19:00] <melodie> hi Kilos !
[19:00] <melodie> I'll be afk for a few hours, perhaps back later
[19:06] <pavlushka> night night
[19:30] <inetpro> good night


[13:21] <mathrick> jelmer: poke?
[13:22] <mathrick> mathrick@megumi: $ bzr branch git+ssh://git@github.com/mathrick/multiple-cursors.el.git,branch=master
[13:22] <mathrick> bzr: ERROR: The repository you are fetching from contains submodules, which are not yet supported.
[13:22] <mathrick> but git doesn't seem to see any submodules anywhere
[13:26] <mathrick> oh, okay, so it had submodules earlier
[13:26] <mathrick> git is a complete trainwreck, btw, there's no way known to #git to check that other than grepping the log for .gitmodules
[13:53] <mathrick> jelmer: is there a way to promise bzr I won't use submodules, just check it out already?
[14:08] <jelmer> mathrick: hi
[14:08] <jelmer> mathrick: you're already using submodules :-)
[14:09] <mathrick> howso?
[14:09] <jelmer> mathrick: they're in the history - bzr-git requires that it can roundtrip *all* data that is in git into bzr and back out
[14:10] <mathrick> jelmer: but isn't "git submodules support" the same as saying "here's a .gitmodule file"? I mean on git's side
[14:10] <jelmer> mathrick: no, there's more to it than that - the place where the submodule lives has a magic file with special file modes
[14:11] <mathrick> then as long as I'm prepared not to be informed of things (which git submodule already doesn't do anyway), it wouldn't be a lot of a loss
[14:11] <mathrick> oh
[14:11] <jelmer> mathrick: bzr-git supports converting this into a bzr nested tree and back into a git submodule, but bzr itself doesn't support nested trees properly yet
[14:11] <mathrick> that's a shame
[14:11] <mathrick> nested trees are probably the oldest planned feature that still doesn't work properly
[14:12] <mathrick> jelmer: how are they different from bzr join / split anyway?
[14:12] <mathrick> I was never entirely clear on that
[14:12] <mathrick> oh, right, nested trees stay independent?
[14:14] <quicksilver> vila: ping?
[14:14] <jelmer> mathrick: yeah, they're a different branch/repository
[14:14] <jelmer> mathrick: a nested tree or submodule is just a reference
[14:15] <jelmer> the terminology Aaron used was that join/split are "by-value nested trees" and that submodules are "by-reference nested trees"
[14:15] <mathrick> any idea how far away they are from working properly? I really remember seeing them planned back in 0.5 days
[14:15] <mathrick> that makes sense
[14:16] <jelmer> mathrick: I don't think they are going to appear anytime soon, considering bzr's current level of activity and the fact nobody is working on them.
[14:17] <vila> quicksilver: pong
[14:17] <mathrick> jelmer: oh, sorry, I meant more of "how much work would it require to get them fully working", disregarding the fact nobody's doing it atm
[14:17] <quicksilver> vila: dvc-log (C-x V L) always seems to do "bzr log <thisfile>", is there a way do just do a plain "bzr log" ?
[14:17] <quicksilver> (also it seems to be slow when lots of changes)
[14:18] <vila> quicksilver: sorry no idea, I never use that. Have you tried from a line without a file ?
[14:18] <jelmer> mathrick: Quite a lot. I have some thoughts on the best way to approach them, but it's at least a couple of months worth of work.
[14:18] <quicksilver> vila: how would you bring up a diff between two versions?
[14:19] <mathrick> jelmer: oh, ow
[14:20] <vila> quicksilver: from dvc ? for a given file ? I have a couple of shortcuts defined for 'bzr diff', 'bzr diff -rsubmit:' and 'bzr diff -r $whatever' and that's all I use
[14:21] <vila> quicksilver: in other words http://paste.ubuntu.com/6044322/
[14:22] <mathrick> quicksilver: fwiw, I just use the plain old terminal (Guake, so it's easy to access) or if doing more, just open bzr explorer and use that.  I think what I was missing is any way to call bzr-dvc-diff with useful arguments.
[14:24] <quicksilver> vila: (I meant, any built-in keybinding to call with useful arguments)
[14:24] <mathrick> vila: diff mode is very nice in many cases, but a lot of the time, I prefer the qdiff view
[14:24] <quicksilver> mathrick: I prefer diff-mode to qdiff generally
[14:24] <quicksilver> better integration with the rest of the emacs workflow
[14:24] <vila> mathrick: yeah, I can read the qdiff view (and often do so while exploring from qlog)
[14:25]  * vila nods at quicksilver
[14:25] <quicksilver> I occasionally use the qbzr stuff to explore things like who committed certain merge subrevisions
[14:25] <vila> mathrick: but otherwise, full agreement with quicksilver
[14:25] <quicksilver> often starting from qblame
[14:25] <mathrick> speaking of integration, I should bind "bzr qdiff" to something and avoid calling it by hand from terminal
[14:25] <quicksilver> M-& bzr qdiff
[14:26] <vila> same here, qblame (which is shorter than qpraise and qannotate sadly ;)
[14:26] <mathrick> that's just terminal in disguise
[14:26]  * vila blinks
[14:26] <vila> quicksilver: holy cow, why did I never thought of binding qblame and qlog in the dvc buffer...
[14:27] <vila> mathrick: you mean M-x shell ? ;)
[14:27] <vila> truth is shell-mode lacks a lot of terminal goodness, there is a lot to be said about completion for example
[14:28] <vila> (yeah I know it's more bash than the terminal itself)
[14:28] <mathrick> either way, now that I've cleaned up my emacs config, I can actually look at binding bzr sensibly into my workflow
[14:29] <vila> mathrick: seriously, you managed to really clean it up or was it more like "reasonably clean up" ? ;)
[14:29]  * fullermd . o O ( <--- has an rm if you need to clean emacs up... )
[14:29]  * vila manages to remove stuff at each upgrade but some pieces are there for decades (literally ;)
[14:30] <quicksilver> mathrick: it is and it isn't.
[14:30] <mathrick> vila: https://github.com/mathrick/emacs-config vs. https://github.com/mathrick/emacs-config/tree/16fe55f48771768ae448b826f1ef3fc99da5841a :)
[14:30] <quicksilver> mathrick: it saves you switching window and it has a separate command history.
[14:30] <vila> fullermd: vade retro satanas , we all know your number is VIVIVI
[14:30] <mathrick> vila: tell me about it, I removed some 15 yo junk from tit
[14:30] <vila> mathrick: :-D
[14:30] <mathrick> protip: (setq foo 42) is not the proper way of making function-local variables...
[14:31]  * mathrick smacks younger mathrick up the head
[14:31] <mathrick> in my defence, it was my first contact with both emacs and lisp of any sort
[14:32] <mathrick> vila: I've been putting off the cleanup itself for years, and I basically reached the point where I couldn't really install a package because there was no way to stuff it into the pile of mess my config was without doing some sort of cleanup, so I did
[14:33] <mathrick> technically I've been "using" grail.el for a few years, but that was really little more than just mv .emacs ~/elisp/user.el plus some load-path magic
[14:33] <vila> hehe, that's a good reason ;)
[14:33] <mathrick> vila: if you want, take a look at the readme, I've actually documented it and made sure to make it bootstrappable
[14:33] <mathrick> I have verified that I can bring up my config on a vanilla emacs with a single command, including emacs23 :)
[14:34] <vila> I haven't installed a emacs package yet
[14:34] <mathrick> oh, man, ELPA is glorious, especially if you pair it with Cask/Pallet
[14:34] <mathrick> I needed to hack them to stop assuming ~/.emacs.d/, but they work and I have no junk at all in there
[14:35] <mathrick> vila: https://github.com/mathrick/emacs-config/blob/master/Cask <-- this is how I store my deps in bzr
[14:35] <vila> wow, single command, nice, my setup have been following me from sunos to solaris, osx, freebsd, gentoo, ubuntu, all with minimal tweaks but I also relies on bzr to keep them all under control
[14:35] <mathrick> no checking in external libs \o/
[14:36] <vila> wow, nice
[14:36] <mathrick> vila: yeah, I've done some work on win32, which made the config all that more horrible, and it'd take me a day to get it to work on whatever zany version I managed to get to run
[14:37] <vila> ha yeah, win32 too but only slightly
[14:37] <mathrick> one problem I haven't solved properly yet is how to track non-ELPA packages
[14:37] <mathrick> it will require some legwork to integrate VCS checkouts as much as at all possible with Grail
[14:37] <vila> yeah, I don't try, I manage to keep all dependencies optional
[14:37] <mathrick> "be as smart as possible but not smarter"
[14:38] <mathrick> vila: yeah, that too, will do it simultaneously I guess
[14:38] <vila> I've been using 3 small packages for which I keep the source
[14:38] <mathrick> right now I just assume all of ELPA will install
[14:39] <mathrick> actual win32 testing presumably will teach me to know better than that :)
[14:41] <mathrick> vila: if you want, I can ping you when I'm done with that, I actually plan to make a skeleton branch which is that except with all my config removed and only the support bits left in
[14:42] <vila> mathrick: I'd love too, but I keep the little free time I can gather here and there to bzr :-/
[14:42] <mathrick> aye
[14:43] <mathrick> vila: I decided to do it now, because I've been honestly avoiding doing actual coding work out of fear of dealing with the packages I'd need to install onto my old mess
[14:43] <mathrick> and that's just not good
[14:44] <mathrick> oh, right, one thing you WANT to check out: http://emacsrocks.com/e13.html https://github.com/magnars/multiple-cursors.el
[14:44] <mathrick> it's absolutely fantastic, and managed to supplant CUA-rectangle which I've been madly in love with for years
[14:45] <mathrick> quicksilver: ^ you too, if you don't know it yet
[14:45] <mathrick> works best when paired with https://github.com/magnars/expand-region.el
[14:49] <vila> mathrick: hmpf, I'm not even sure I will be able to use that O_O granted it looks nice (multiple cursors that is)
[14:49] <mathrick> oh, you will
[14:49] <mathrick> it's instantly useful everywhere the moment you have it available
[14:49] <vila> mathrick: note that I'm still quite new to CUA-rectangle
[14:50] <mathrick> vila: think of it as better CUA-rectangle, which is already pretty damn great. All kinds of refactoring is possible, and it serves a fantastic replacement of macros and regexes in many cases
[14:51] <fullermd> Sheesh.  Why would you want to replace a regex with anything but a more complicated regex?
[14:54] <mathrick> vila: for example, https://github.com/magnars/multiple-cursors.el/issues/76#issuecomment-23531660 <-- I wrote it writing all key sequences like [C-u C-x n n]
[14:54] <mathrick> then replacing them with the fantastically readable C-uC-xnn, then selected all such instances and converted them to
[14:54] <mathrick> er
[14:55] <mathrick> aside from the fact my xchat buffer got messed up
[14:55]  * quicksilver doesn't even use CUA-rectangle
[14:55] <quicksilver> I use builtin rectange commands every day though
[14:56] <mathrick> quicksilver: MC is that on steroids. You'd use either built-in rectangles or CUA-rectangle, but MC is strictly better than both
[14:56] <mathrick> because it doesn't require you to have consecutive, aligned lines
[14:58] <quicksilver> intersting.
[14:58] <mathrick> quicksilver: watch that screencast, it explains perfectly what it's useful for
[14:59] <vila> yeah, sounds interesting, I wonder though if that won't make myself a bit lazier for refactorings...
[14:59] <mathrick> well, shows, which is even better
[14:59] <mathrick> vila: what do you mean?
[14:59] <quicksilver> why do the best emacs tips always come as off-topic conversiations in other channels?
[14:59] <mathrick> because Emacs is too big to be a single topic!
[14:59] <vila> if there are multiple lines where I need to apply the same modifications, shouldn't that be abstracted ?
[15:00] <quicksilver> mathrick: the more powerful your editor, the more likely you are to put up with ugly boilerplate / repated code
[15:00] <quicksilver> just look at Java ;)
[15:00] <mathrick> serendipity, thy name is Emacs :)
[15:00] <mathrick> quicksilver: yeah, I know
[15:00] <mathrick> but it also makes it really easy to refactor things
[15:00] <vila> but the example where he handles the i18n is different, there, it *helps* the refactoring hugely
[15:01] <fullermd> Well, because most localities have banned door-to-door emacs proselytization, so the pushers have gone online to tempt children into the ways of sin...
[15:01] <mathrick> so "meh, I don't feel like fixing it in 5 places, I will paste it once more" is no longer an excuse
[15:01] <jelmer> mathrick: I think the simpelst thing to do if you can is to fastexport/fastimport the git repo to remove the submodules, and then redo the bzr-git command.
[15:01] <mathrick> jelmer: doesn't really work for pull requests though :\
[15:02] <jelmer> mathrick: ah, yeah..
[15:03] <mathrick> jelmer: oh, speaking of that, how can I replay a fi stream on top of a repo? I have a repo which starts out with a file structure identical to a git repo I want to graft onto, but the history is different and includes other junk. I wanted to filter out all but the files I care about, but replays don't work, they simply replace everything rather than adding to the history
[15:04] <mathrick> specifically, https://github.com/codermattie/Grail and https://github.com/mathrick/emacs-config/tree/16fe55f48771768ae448b826f1ef3fc99da5841a
[15:04] <mathrick> my repo starts with grail files textually identical (they were downloaded as blobs from github), but the history is interleaved with everything that happened to my repo
[15:05] <quicksilver> mathrick: OK, I watched the screencast. I do stuff like that all the time but I have to use a cmobination of rectangle commands, align-regexp, and regexp replace. Neat.
[15:05] <mathrick> I want to isolate just the things I did with grail*.el and graft that on top of a Grail checkout
[15:05] <mathrick> quicksilver: yep, it removes a lot of drudge regexp hackery from my day
[15:06] <mathrick> and trying to divine why align-regexp doesn't work and is it still saving time if I debug it?
[15:06] <jelmer> mathrick: sorry, not sure about that.
[15:18] <mathrick> jelmer: hmm, any idea who knows about bzr fast-import?
[15:23] <jelmer> mathrick: I think Ian and myself are the main people who have worked on it
[15:23] <jelmer> I swapped that stuff out a long time ago :)
[15:23] <jelmer> perhaps try the list?
[15:24] <mathrick> will do
[15:24] <mathrick> thanks
[21:07] <mgrandi> hey, I was wondering if a plugin existed, to kind of, 'pin' a file. I have a file that is dynamically generated and the contents differ occasionally on a rebuild, and i don't want to commit it each time as its derived from something else, but i don't want to ignore the file either cause then it wont get checked out if someone branches the repo
[21:54] <jelmer> mgrandi: no, there isn't anything like that. generally what happens is that people check in foo.in, and then have a build script that copies foo.in to foo and makes local modifications to it
[21:55] <jelmer> (and then add 'foo' to the ignore list)
[21:59] <spiv> I suppose locally you could have a pre-commit that drops that file from the list of changes to commit.
[22:00] <spiv> But that won't help casual developers avoid committing it unecessarily.
[22:23] <mgrandi> yeah
[22:24] <mgrandi> i might do that, thanks jelmer


[08:01] <tjaalton> should the installer recognize win8 and offer to resize the partitions?
[08:01] <tjaalton> I have a machine where it doesn't work, and I wonder how hard it would be to fix
[09:14] <cjwatson> tjaalton: in principle ntfsresize is meant to work, yes
[10:28] <tjaalton> cjwatson: right, I see ntfsresize output on the syslog, it has recognized the partitions
[10:32] <tjaalton> but the partitioner doesn't recognize that win is installed
[10:33] <tjaalton> *win8
[10:37] <cjwatson> Maybe ubiquity.misc.windows_startup_folder is wrong or something
[10:38]  * cjwatson guesses wildly
[10:43] <tjaalton> ah, checking
[10:43] <tjaalton> googling showed that this is a common issue
[10:43] <tjaalton> there's probably a bug about it too
[10:50] <tjaalton> bug 1079056
[10:50] <ubot2> Launchpad bug 1079056 in os-prober (Ubuntu) "ubiquity does not detect Windows 8(UEFI)" [Undecided,Confirmed] https://launchpad.net/bugs/1079056
[10:51] <cjwatson> Ah, well, that's pending merge
[10:51] <tjaalton> oh, cool
[10:51] <cjwatson> xnox: ^- you're touched-it-last on os-prober and I think there's a branch awaiting sponsorship, possibly
[10:51] <cjwatson> Wait, that landed 23 hours ago
[10:51] <tjaalton> heh
[10:52] <tjaalton> ok I'll try todays image
[10:52] <cjwatson> Yeah, please do, would be good to know if that's fixed
[10:52] <tjaalton> sounds sru material?
[10:52] <tjaalton> perhaps for 12.04.3
[10:53] <cjwatson> Probably
[10:53] <cjwatson> There's a grub2 fix that goes along with it
[10:53] <cjwatson> But I'd like to know that it all works as a unit in saucy first
[10:53] <tjaalton> right
[10:53] <tjaalton> I'll know in 20min :)
[11:40] <tjaalton> cjwatson: doesn't work with the current image, os-prober update is included
[11:41] <cjwatson> any legwork you can do to debug this would be appreciated; tends to be horrific to debug remotely ...
[11:41]  * cjwatson is currently trying to reproduce GrueMaster's oem-config bug from yesterday
[11:42] <tjaalton> yeah I'll have a look at os-prober..
[11:43] <cjwatson> First check whether os-prober detects Windows at all, I suppose; could be a multi-part bug and now ubiquity needs to be fixed
[11:44] <tjaalton> I get a grub-probe error for the usb-stick, that's it
[11:44] <cjwatson> OK, well os-prober itself is not too complicated to debug
[11:49] <tjaalton> hmm how to enable the debug output?
[11:51] <cjwatson> You'll find it in syslog
[11:54] <tjaalton> eh, 05efi skips ntfs partitions
[11:54] <tjaalton> os-probes/mounte/05efi that is
[11:55] <cjwatson> The EFI System Partition isn't normally allowed to be NTFS
[11:55] <tjaalton> ah, well here it is
[11:55] <cjwatson> Note EFI System Partition != Windows /, usually ...
[11:56] <tjaalton> ok, that wasn't it :)
[11:56] <cjwatson> But, OK, does it work if you add an ntfs condition there?
[11:56] <tjaalton> no
[11:57] <tjaalton> "$partition is not a ESP partition: exiting"
[11:57] <cjwatson> So - what makes you think that this partition is an EFI System Partition?
[11:59] <tjaalton> was looking at the wrong partition
[12:00] <tjaalton> it has five, sda1 ntfs, sda2 efi, sda3 unused, sda4 ntfs, sda5 ntfs
[12:01] <tjaalton> "sda2 is fat partition, exiting"
[12:01] <tjaalton> there
[12:01] <cjwatson> Ah, maybe this is a grub-mount thing
[12:01] <cjwatson> compare:
[12:01] <cjwatson> ./os-probes/mounted/x86/20microsoft:21: fat) debug "$1 is a FAT partition (mounted by GRUB)" ;;
[12:01] <tjaalton> adding fat to 05efi fixed it
[12:02] <cjwatson> I'll fix that upstream, then, thanks
[12:02] <tjaalton> cool, thanks
[12:06] <tjaalton> restarting ubiquity didn't go as planned :)
[12:07] <cjwatson> Requires fairly considerable care
[12:07] <cjwatson> Probably best to reboot though
[12:08] <tjaalton> I'll lose the os-prober hack then :)
[12:08] <cjwatson> Not if you reboot to a live session and reapply it first
[12:08] <tjaalton> ah
[12:08] <cjwatson> (Restarting can work if you make sure to kill all relevant processes and rm -rf /var/lib/partman)
[12:09] <tjaalton> oh well, rebooted already
[12:14] <tjaalton> hm, ubiquity still doesn't play along
[12:16] <cjwatson> Could be looking in the wrong partition - os-prober would be telling it about the ESP but that doesn't have the Windows startup folder on it
[12:16] <cjwatson> I forget how that gets matched up normally ...
[12:17] <cjwatson> ev might remember
[12:17] <cjwatson> Or xnox
[12:17] <cjwatson> infinity: I pushed our outstanding mklibs changes upstream - 0.1.37 will be syncable once it's available
[12:18] <tjaalton> ok so it's missing something else
[12:18] <tjaalton> since os-prober just lists the efi partition now
[12:20] <tjaalton> "skipping legacy bootloaders on uefi system"
[12:20] <cjwatson> Right, what I mean is that os-prober is indeed only going to list the ESP (correctly), but ubiquity needs to know how to figure out where the Windows root partition is from that
[12:20] <tjaalton> oh
[12:20] <cjwatson> os-prober is only supposed to list the things that it's actually sensible to boot
[12:20] <tjaalton> gotcha
[13:26] <cjwatson> GrueMaster: Ah, I may have a lead
[13:26]  * cjwatson tests
[13:34] <cjwatson> Bingo
[14:09] <cjwatson> GrueMaster: https://bazaar.launchpad.net/~ubuntu-installer/ubiquity/precise-proposed/revision/5433
[14:10] <cjwatson> (tested, works for me, etc.)
[14:11] <cjwatson> and heading into the unapproved SRU queue now
[15:24] <GrueMaster> cjwatson: Awesome!  I'll apply the patch and test here.
[16:29] <GrueMaster> Tested in both VM and raw hardware with 12.04 (amd64).  This fixes the issue.  Thanks.
[16:30] <GrueMaster> I'll keep a local .deb with the fix until it gets into the pool.  Deployment can't wait for SRU process, but it will make our work a LOT easier (and gets Ubuntu Server out more on preinstalled systems).
[16:38] <cjwatson> Great.
[19:05] <infinity> cjwatson: Hah, d'oh.  I was considering backing some of my mklibs changes out, since we no longer have linkers that live in deep paths, but I guess there's no harm in keeping that path handling safer either.
[19:21] <cjwatson> Well, you can back it out in Debian if you like; but as you say ...
[20:29] <infinity> cjwatson: IIRC, didn't it require a coordinated change mirrored to something else at the same time?  rootskel or something?
[20:29] <infinity> cjwatson: (Which was why we didn't push it during the d-i freezes)
[20:29] <infinity> rootskel (1.101ubuntu1) raring; urgency=low
[20:29] <infinity>   * Resynchronise with Debian.  Remaining changes:
[20:29] <infinity>     - Remove the lib64 -> lib symlinks, no longer necessary with the new
[20:29] <infinity>       mklibs.
[20:29] <infinity> ^-- That change.
[20:34] <cjwatson> Was that actually necessary?
[20:34] <cjwatson> Or just expedient?
[20:35] <infinity> I don't remember if it blows up without that change or if it was just the right thing to do.


[01:01] <akgraner> holstein, you're now the team contact in LD
[01:02] <akgraner> I'll add all the event information soon
[01:02] <akgraner> Bill I am sending you a box tomorrow - lanyards and a few mouse pads
[01:03] <akgraner> internalkernel, and holstein we'll have some swag too on Saturday - it's still the old design but I think people will like having them
[02:38] <internalkernel> akgraner: sounds good, let me know what else I can do... just getting past a little cold.... see ya soon!
[14:30] <akgraner> holstein, what are the times for Saturday - I am just now gettng around to adding stuff to the Loco directory
[14:30] <akgraner> I'll blog about all this today as well
[14:36] <akgraner> holstein, just sent the team contact change to the loco contacts list and to the loco team mailing list
[14:37] <holstein> akgraner: noon is the LUG
[14:37] <holstein> thats our official time
[14:37] <mhall119> holstein: congrats
[14:38] <holstein> and i have to play laugh or leaf or whatever that day
[14:38] <holstein> so i have to leave around 1 prolly
[14:38] <holstein> mhall119: :)
[14:38] <mhall119> I read the email as "Amber voluntold Mike to be contact"
[14:38] <holstein> lol
[14:40] <holstein> akgraner: is there a place where i go to request the CD's and all that?
[14:40] <holstein> for the LoCo?
[14:44] <akgraner> holstein, yep - but it;s not time yet
[14:44] <akgraner> I'll poke you when it is
[14:44] <holstein> i was hoping it was something you just 'set-and-forget'
[15:02] <internalkernel> voluntold... lol... I'm going to use that one... :p
[17:32] <akgraner> billf, are you a member of the loco team in LP?
[17:32] <akgraner> I can't seem to find you to add you as the contact for your global Jam event
[17:33] <akgraner> for now I'll add my name until I can add yours
[17:45] <billf> akgraner: hmm, not sure, let me check
[17:46] <akgraner> thanks b/c I can't add you as contact if you aren't there
[17:48] <akgraner> http://akgraner.com/?p=1011
[17:48] <akgraner> billf,  and holstein  take a look at the blog post
[17:48] <akgraner> I'll add that to LD in just a second
[17:50] <billf> akgraner: I am listed on our loco Natty release party event page
[17:50] <akgraner> in Lanuchpad
[17:50] <akgraner> hmmm I'm not finding your name in the LoCo Directory
[17:50] <akgraner> grrrrrr
[17:51] <akgraner> let me see if I can get you added
[17:52] <billf> OK I have joined
[17:55] <akgraner> cool now I just need to let the Loco directory refresh then I'll add you
[17:55] <akgraner> but for now I added me so I could save the event
[17:59] <billf> great, I have no idea why I forgot about adding the event :-)
[18:06] <akgraner> I've got the events added to the LoCo Directory
[18:07] <akgraner> as soon as I can see your name I'll edit it and point it to you as contact
[19:13] <billf> akgraner: I have updated the event details.  thanks for setting it up
[19:14] <akgraner> no worries - were you able to add yourself as contact now
[19:14] <billf> yes
[19:14] <akgraner> it usually takes about an hour to update
[19:14] <akgraner> oh good
[20:57] <akgraner> check out I'm quoted in the same article with Linus and Jono  - http://www.datamation.com/open-source/linus-torvalds-and-others-on-community-burnout-1.html
[20:58] <akgraner> internalkernel, ^^^^^
[22:16] <internalkernel> akgraner: oml
[22:17] <internalkernel> I had to invent an acronym for that... it's beyond omg... it's Oh My Laawwwd.
[22:17] <akgraner> hahaha
[22:17] <akgraner> luv it
[22:17] <internalkernel> oml... and congrats. :D
[22:17] <akgraner> I thought you'd like that article


[01:57] <mup> Issue operator#963 closed: Type of ExecProcess.stdout isn't iterable <small item> <type hints> <Created by benhoyt> <Closed by tonyandrewmeyer> <https://github.com/canonical/operator/issues/963>
[02:19] <mup> PR operator#1022 opened: test: add type hints to test_charm <Created by tonyandrewmeyer> <https://github.com/canonical/operator/pull/1022>
[02:51] <mup> PR operator#1023 opened: test: add type hints for test_storage <Created by tonyandrewmeyer> <https://github.com/canonical/operator/pull/1023>
[20:22] <mup> PR operator#1022 closed: test: add type hints to test_charm <Created by tonyandrewmeyer> <Merged by benhoyt> <https://github.com/canonical/operator/pull/1022>
[20:27] <mup> PR operator#1024 opened: fix: push_path and pull_path include empty directories <bug> <Created by tonyandrewmeyer> <https://github.com/canonical/operator/pull/1024>
[22:04] <mup> PR operator#1023 closed: test: add type hints for test_storage <Created by tonyandrewmeyer> <Merged by benhoyt> <https://github.com/canonical/operator/pull/1023>
[22:05] <mup> PR operator#1025 opened: test: add type hints to test_framework <type hints> <Created by tonyandrewmeyer> <https://github.com/canonical/operator/pull/1025>
[22:40] <mup> Issue operator#1026 opened: Add new Pebble types for log forwarding <feature> <small item> <Created by benhoyt> <https://github.com/canonical/operator/issues/1026>
[23:40] <mup> PR operator#1027 opened: Bump urllib3 from 2.0.2 to 2.0.6 in /docs <dependencies> <Created by dependabot[bot]> <https://github.com/canonical/operator/pull/1027>


[00:14] <lifeless> spiv: so, I'm nearly human again
[00:15] <lifeless> spiv: want to pop over?
[00:16] <spiv> lifeless: to Epping?  Sure.
[00:16] <lifeless> cool
[00:16] <spiv> I'll finish humanising myself and head over.  I'll let you know my eta.
[00:16] <lifeless> kk
[00:33] <lifeless> Odd_Bloke: if you're looking at bzr send
[00:33] <lifeless> Odd_Bloke: apparently we should us xdg-email
[00:33] <lifeless> *use*
[00:36] <Odd_Bloke> lifeless: My next few cycles are going to be spent looking at shelf.
[00:36] <Odd_Bloke> s/shelf/shelves/
[00:36] <r0bby> yeh if only i initialized the String :x
[00:36] <r0bby> that wouldn't have made it less wrong
[00:37] <Odd_Bloke> r0bby: Wrong channel? :)
[00:37] <Odd_Bloke> What's brisbane-core?  I keep seeing references to it, but missed the kicking off point.
[00:41] <lifeless> Odd_Bloke: next gen format
[00:42] <ronny> is there any schema on how the database of the in bzr works?
[00:42] <ronny> (and if there are ways to extend it)
[00:42] <lifeless> ronny: you can't really extend the core (though you can use it to do different things for you)
[00:43] <lifeless> ronny: in terms of docs, there are the Classes stuff on the wiki, and docstrings in the code - pydoctor gives quite good results on that I believe
[00:44] <ronny> hmm, any listing ? i missed the stuff in the wiki
[00:47] <lifeless> http://bazaar-vcs.org/Classes
[00:56] <spiv> lifeless: eta 1220
[00:57] <lifeless> roger wilco
[00:58] <ronny> lifeless: at what part of the src should i look?
[01:00] <lifeless> ronny: well, what are you interested in? If you're interested in the 'db' implementation, btree_index, knit.py (the pack mapped index and access objets), and repofmt/pack_repo.py's RepositoryPackCollection class)
[01:01] <ronny> lifeless: mainly the db stuff
[01:01] <lifeless> if you're more interested in the model, I don't think there is a single good reference
[01:01] <ronny> the model is important for me, too
[01:01] <ronny> just researching the different stuff
[01:01] <lifeless> I'd cast an eye over doc/developers/
[01:02] <ronny> so far git's model seems the most reasonable
[01:02] <ronny> just the rest of git isnt
[01:03] <lifeless> :P
[01:05] <ronny> any reason why bzr did choose uuid's over content hashes other than the rehashing (aka switch hash algo) issue?
[01:12]  * ronny waves for attention
[01:13] <mwhudson> well, bzr-svn includes more information in the uuid
[01:13]  * RAOF is by no means a bzr hacker, but IIRC it allows better tracking of file moves.
[01:14] <ronny> RAOF: nope, not at all
[01:14] <ronny> mwhudson: like what?
[01:15] <mwhudson> ronny: uuid of the repository + revno of the import
[01:15] <ronny> ok, also nothing that would reqire a uuid
[01:17] <mwhudson> i think it's more a matter of style of approach than requirement
[01:17] <mwhudson> but way way before my time
[01:18] <ronny> RAOF: git's bad move tracking is derived in the fact that trees dont have parents, thus the parent/child relation is only in commits
[01:26] <ronny> so any comments?
[01:31] <Odd_Bloke> ronny: I'm not sure the IRC channel is the most appropriate place to look for this kind of discussion.  The mailing list might be better...
[01:32] <ronny> hmk
[01:33] <ronny> i mostly just want to know the reason tho, not discuss it over again
[01:33] <Odd_Bloke> ronny: I still think a post to the ML is most likely to get a useful response.
[01:34] <Odd_Bloke> Anyway, I intended to go to bed half an hour ago.
[01:34] <Odd_Bloke> So, good night #bzr.
[01:34] <lifeless> ronny: we chose uuids for revisions for a couple of reasons; not wanting to redo everything when sha1 is broken, and supporting imports from arbitrary systems is the other (and its been very susccessfuly)
[01:34] <lifeless> ronny: for file ids, we use uuids as a memo, but equally could use just history pointers
[01:36] <ronny> hmm, why does import from others require uuid's?
[01:41] <lifeless> ronny: transitive history is not always available
[01:43] <ronny> i dont see how that makes uuid's an requirement
[01:44] <ronny> i need to sleep
[01:44] <mwhudson> oh that's right, ghosts
[01:45] <mwhudson> i always forget that one...
[01:49] <jelmer> not just that
[01:50] <jelmer> having to calculate the contents in the native format for all contents in the ancestry of a revision is expensive
[01:52] <jelmer> never mind, just read up on what transitive means :-)
[01:57] <mlh> ronny's design questions remind's me that poolie's design notes used to be available somewhere
[02:00] <mlh> like old.bazaar-vcs.org or bazaar-vcs.org/old (I've checked there)
[02:01] <spiv> mlh: http://doc.bazaar-vcs.org/obsolete-docs/ ?
[02:02] <mlh> thanks spiv
[02:02] <mlh> that's an excellent historical document.  I remember meaning to give that link to ESR when he was going to (threatening to ? :-) write a history of (D)VCSs
[02:20]  * igc lunch
[02:21] <lifeless> jml: we need to spend a few hours on 'how to represent skip etc for .unittest
[02:21] <lifeless> '
[02:22] <jml> lifeless: yes.
[02:22] <jml> lifeless: in fact, a mini-sprint on pyunit-friends stuff would probably be a Good Thing
[02:22] <jml> lifeless: let's go to Perth and visit jamesh :)
[02:33] <lifeless> jml: :P
[02:34] <jamesh> lifeless: that reminds me.  I uploaded a testresources branch implementing the make/reset/clean API I suggested.
[02:34] <lifeless> yes, its in my aroundtuit pile :(
[02:35] <jamesh> you said my original description was a bit hard to understand, so maybe some code will make it clearer :)
[02:35] <lifeless> thank you
[02:39] <jamesh> and I don't know whether you'd want to come to Perth at this time of year.  It may be a bit dryer, but it is also a lot hotter
[02:47] <lifeless> jamesh: yeesh, don't need more heat
[02:47] <lifeless> jml: I was thinking dinner, wine, laptops
[03:19] <jml> lifeless: sounds delightful
[03:58] <lamalex> Can I version a single file only? For example I want to keep my .emacs file in sync across a few computers, is there a simple way to do this?
[03:59] <lifeless> lamalex: bzr init ~/my-emacs
[03:59] <lifeless> mv ~/.emacs ~/my-emacs
[03:59] <lamalex> lifeless: so "no"
[03:59] <lifeless> ln -s ...
[03:59] <lifeless> lamalex: yeah, sorry
[03:59] <lamalex> no problem
[03:59] <lamalex> it's not the point of bzr
[04:00] <lamalex> that will probably be cleaner anyway, I'll just make a dir of my misc files, then link to them
[04:00] <bob2> sure, cd ~/ ; bzr init ; bzr add .emacs ; bzr ignore ".*" ; bzr ignore "*" ; bzr commit
[04:39] <lamalex> can someone help me set up a shared repo? I can't get it to not do working trees in the repo
[04:39] <bob2> bzr init-repo --no-trees
[04:39] <bob2> you can alias init-repo to 'init-repo --no-trees' if you like
[04:42] <lamalex> :P as soon as I asked i got it
[04:42] <lamalex> thanks
[04:53] <lifeless> vila: your --load-list is quite nice, thank you
[04:53]  * jml <3 branch-todo
[04:54] <lifeless> jml: ?
[04:54] <jml> lifeless: I'll explain later :)
[04:56] <lifeless> jml: I have a feedback loop going with tests
[04:57] <lifeless> jml: bzr selftest --load-list=foo.list, where foo.list is from selftest --subunit | subunit-filter | tail -n +2 > foo.list
[04:57] <lifeless> jml: 'run only failing tests'
[04:58] <jml> lifeless: *nod* that'd be very handy to have for lp
[04:59] <lifeless> I'll do some more on it this evening I hope
[04:59] <lifeless> would likst to get foo.list by $() rather than a file on disk, or something like that
[05:09] <lifeless> jml: so, see my most recent post to bazaar@, it has the glue needed for a pyunitish runner
[05:10] <jml> lifeless: cool
[06:37] <ronny> moin
[06:38]  * ronny still fails to see how transitive history needs uuid's
[06:53] <ronny> mlh: thanks
[06:59] <lifeless> jml: what are you doing tomorrow evening?
[07:03] <vila> hi all
[07:03] <vila> lifeless: glad you like it :-)
[07:41] <dholbach> hiya
[07:42] <dholbach> pushing a branch to LP with bzr 1.11-1 I get "Permission denied (publickey)" although my pub key is exactly the same as the one I have on LP
[07:42] <dholbach> is there any known issue?
[07:44] <mthaddon> dholbach: sure you're connecting as the right username?
[07:45] <dholbach> mthaddon: I don't think I changed anything
[07:45] <dholbach> email = Daniel Holbach<EMAIL_ADDRESS>[07:45] <dholbach> launchpad_username = dholbach
[07:45] <mthaddon> dholbach: ok, just checking - not sure if it's a known issue, haven't used bzr 1.11-1 myself
[07:46] <dholbach> it's in jaunty now
[07:46] <mthaddon> brave soul - still on intrepid here
[07:47] <dholbach> where do I use "-Dhpss"?
[07:47] <dholbach> it tells me to use it
[07:48] <dholbach> argh, now it worked
[07:48] <dholbach> ok... whatever
[07:48] <dholbach> I'll let you know when I run into it again
[07:49] <mthaddon> I won't be much use - not an expert in any way, just happened to be idling here...
[07:49] <mthaddon> but I'm sure someone else will
[07:52] <jml> lifeless: travelling to Hobart
[07:58] <vila> poolie: ping
[09:16] <spiv> lifeless: you'll be happy to know I have a working right arrow key again.
[09:21] <lifeless> spiv: cool
[09:21] <lifeless> spiv: you hit it harder?
[09:21] <lifeless> jml: well then, upon your return
[09:21] <fullermd> Obviously, it started acting right   :p
[09:25] <spiv> lifeless: if by "hit" you mean "took the cap off and removed a pile of impacted crud", then I guess so...
[09:26] <spiv> It doesn't quite like new, but it basically works...
[09:27] <mbp__> hello spiv, lifeless
[09:29] <mbp__> lifeless: thanks for the post this morning about gc
[09:30] <fullermd> I've managed to not have to do a significant keyboard cleaning on this one yet.  Next month is its 18th birthday, too.
[09:30] <mbp__> kiko, i'm writing up http://bazaar-vcs.org/Roadmap/BrisbaneCore
[09:30]  * fullermd should throw a party.
[09:30] <mbp__> wow
[09:31] <mbp__> fullermd: it must even predate PS/2 connectors?
[09:31] <fullermd> Wikipedia says PS/2 was 1987.
[09:32] <fullermd> But the cable is detachable, so it could have come with an AT connector originally I guess.
[09:34] <mbp__> kiko ^^
[09:34] <kiko> I don't know a lot about PS/2 but brisbane sounds like just the place for summer
[09:37]  * fullermd recalls laughing his head off at http://ars.userfriendly.org/cartoons/?id=20010211
[09:57] <kiko> mbp__, can you tablify that? tables beat lists
[09:57] <kiko> well maybe.. hmm
[09:57] <mbp__> for the tasks?
[09:57] <mbp__> working on it
[09:57] <kiko> maybe
[09:57] <mbp__> at least a table is better if we have estimates
[09:58] <kiko> indeed, indeed
[09:58] <mbp__> at the moment i'm adding more descripiton of the changes and digging up some numbers
[09:59] <mbp__> yay numbers
[09:59] <mbp__> the infallible indicator of objective truth :)
[10:04] <fullermd> Except 8.  I don't trust him.  Shifty eyes and all that.
[10:05] <Toksyuryel> and 13
[10:05] <Toksyuryel> unlucky n' such
[10:05] <fullermd> Yeah, but it's reliably unlucky.  So it's infallible in a way   :p
[10:07] <awilkins> Yegods, this "Python DVCS comparison" thread is long
[10:08] <awilkins> I think the attitude that "We want all the benefits of a DVCS without changing how we work" attitude is rather blinkered though
[10:09] <fullermd> If only that were the most blinkering I ran across in a day...
[10:09] <AfC> But it's worse than that - many people have already fought the learning curve to learn git, and now we seem both cumbersome and slow as a result.
[10:10] <Odd_Bloke> awilkins: I dunno, we claim to be flexible, but are we actually?
[10:10] <Odd_Bloke> (I think so, but maybe we could be more flexible)
[10:11] <fullermd> Considering that the complaints all seem to boil down to "TOO flexible", how would that help?   :p
[10:11] <Toksyuryel> that's a silly thing to complain about though
[10:11] <Toksyuryel> if you don't want to use the flexibility, don't
[10:11] <fullermd> It's a silly world.
[10:11] <AfC> I suspect a global [per user, anyway] revision cache would help enormously.
[10:11] <AfC> bit late now, though
[10:11] <Toksyuryel> it's not foisted on you
[10:11] <fullermd> I don't see it, personally.
[10:12] <fullermd> To be much use, it would have to be several times the size of a "large" project.  Otherwise anything you want would be cycled out by the time you'd profit from it.
[10:12] <fullermd> And that's *BIG*.
[10:13] <AfC> fullermd: (if you're talking to me) no, I'm not talking about in-memory, I'm talking about never ever forcing someone to network transfer the same revision twice in from a remote location. I imagine `bzr init-repo ~` would do it.
[10:13] <fullermd> Of course, the solution to the direct problem is "If you want to work just like svn, just use co --lightweight".  Then we can move on to "zomfg that's slow" and make forward progress on letting them keep marching toward the cliff.
[10:14] <fullermd> I don't mean in-memory, I mean wherever; it would have to be a couple gig at least to get a high enough hit rate to be worth it.  I don't have a could gig to spare.
[10:14] <AfC> fullermd: but since that isn't what the Bazaar hackers expect you to do, it's not a good idea to suggest.
[10:15] <fullermd> And "Use bzr, it'll keep anything you ever pass to it around forever cluttering your hard drive" isn't the best advertising either  :p
[10:15] <AfC> fullermd: assume for a minute you don't know about a) shared repos and b) creating local mirrrors of remote branches. Then do bzr log on a large remote branch a few times and you'll start appreciating how awful Bazaar appears to people.
[10:16] <AfC> That is, in essence, the critique that the Python crew have levelled, and it has as a result disqualified us.
[10:16] <fullermd> Did I say something that gave the impression that I fail to appreciate how awful performance is in many cases?
[10:16] <Odd_Bloke> AfC: 'bzr init-repo ~' has a couple of problems.  Firstly, it's not a cache (you can't delete ~/.bzr safely), and secondly, as noted on the mailing list, it assumes people work underneath a single directory.
[10:17] <AfC> Odd_Bloke: sure. Admittedly, though, most people work under ~ :)
[10:17]  * fullermd branches into /tmp with some regularity.
[10:17] <Odd_Bloke> AfC: Windows users don't.
[10:17] <AfC> fullermd: I don't really think any of us in this channel qualify as normal users in so far as Bazaar (or any DVCS) is concerned
[10:18] <AfC> Odd_Bloke: that's fine. They can `bzr init-repo c:`. Suckers.
[10:18] <AfC> ENOSYMPATHY
[10:18] <AfC> :)
[10:18] <fullermd> Anyway, the solution to logging large remote is to use a dumb server.
[10:18] <fullermd> log --limit 10 bzr.dev.   sftp: 7 seconds.   bzr+ssh: 40 seconds.
[10:19] <fullermd> Doesn't help when they branch into d: now does it?   :p
[10:19] <AfC> fullermd: it doesn't matter that there is a "solution". The problem is that out of the box the way that most people try to use Bazaar turns out not to be wise.   I was being ironic...
[10:20]  * AfC has, in essence, given up advocating Bazaar. I'm tired of shouting at the rain. It's too bad we picked bzr because we really appear to be zealots out in left field for using it.
[10:20] <fullermd> You seem to keep getting this impression that I'm defending the status quo and mocking the poor silly users who just don't Get why it's so vital to use the DUMB SERVER to get good performance...
[10:20] <AfC> Such a shame, because I'm very happy with it.
[10:21] <AfC> fullermd: I would advise against sarcasm in discussions like this. Most people won't get it.
[10:21] <AfC> fullermd: especially when we're exploring the question of whether it's too late for this project.
[10:22] <fullermd> But back to the thread in question, the activity of hg would be exactly the same; a fresh clone would still pull everything across the network.  The activity of git would be example the same; a fresh clone would still pull everything across the network.
[10:22] <AfC> fullermd: right, but in the Git case, the *second* transaction would NOT pull everything - or anything - across the network.
[10:22] <fullermd> The difference is only when you pull another branch into an existing repo.  That brings us back to metabranches.
[10:22] <AfC> fullermd: since we support NOT forcing a full mirror since we support anonymous remote operations, we look bad for doing 100s of MB of transfer just to do a log only to force another 100 MB of transfer to run the same command again.
[10:23] <AfC> Like I said, too late now.
[10:24] <fullermd> Again, what are you trying to convince me of?   Relax. I'm talking about the tool that you and I both have stuck our necks out for. The tool permits that behaviour, and so people think that's what they're supposed to do, and so they do, and then the tool looks horrible.
[10:25]  * fullermd shrugs.
[10:25] <fullermd> I've lost much ability to care about those people.  The train has long since pulled out of the station, and it doesn't matter anymore.
[10:26] <AfC> fullermd: you're lucky, then. I work in a community where virtually every other project has adopted Git, or will. So I'm odd man out, and suffering for it.
[10:26] <AfC> it sucks.
[10:26] <fullermd> Projects will use bzr because political forces dictate (like emacs) or somebody with enough clout likes bzr and decides to impose it (like I did).  Anybody else will look at it and say "slower than other choices", and game over.
[10:26] <AfC> yup
[10:26] <awilkins> I use Bazaar because I had a project that needed really good merge support, it's being used by neophytes, on Windows     ; hg can't handle the tree because it's too deep for it on Windows, git is too scary
[10:27] <awilkins> The performance leaps of bzr between 0.9 and 1.6 on win32 were really gratifying
[10:27] <fullermd> On the day when bzr reaches performance parity, it still won't gain much, because then it'll be "the program that's no longer as slow as it used to be"
[10:27] <AfC> fullermd: shit, I've been trying that line for over a year now.
[10:27] <awilkins> It started off just "ooh, much faster than SVN" and became "wow, that's nice and fast"
[10:27] <AfC> fullermd: and indeed, it didn't help
[10:27] <AfC> Whatever. It's nice and fast for me.
[10:29] <awilkins> The fact that it's written in a langauge I grokked easily enough to pick up was a real plus ; several windows bugs have been fixed that way
[10:29] <fullermd> Obviously, the real trick is to slow everybody else down.
[10:29] <fullermd> Look how well that strategy has worked for web browsers.
[10:29] <awilkins> I'd like to see a 4-way DVCS/SVN benchmark on Windows
[10:29] <fullermd> Remember when you refused to move to Netscape 4, because it was a stupidly slow unbelievably bloated pile of crap?
[10:29] <awilkins> I'm not sure git would be such a clear winner on Win32
[10:30]  * fullermd laughs in his past self's face.
[10:30] <fullermd> The flaming death for bzr is network.  The platform won't affect network that much.
[10:31] <fullermd> I'm left with the assumption that, for whatever reason, bzr didn't grab enough mindshare early on, and the manpower deficiency has left it permanently in the hole.
[10:32] <Lo-lan-do> I think bzr can still prevail within the "enterprise".
[10:33] <Lo-lan-do> It is, after all, easy to use, and seeing how much effort is required to get people to switch from CVS to SVN, getting them to switch to git is going to be *ugh*.
[10:33] <Lo-lan-do> Remember not all paid developers are uber-elite geeks :-)
[10:33] <awilkins> Linux format had a "bluffers guide to git" this month
[10:33] <Lo-lan-do> (And not every VCS user is a developer, either)
[10:33] <fullermd> Paid developers do whatever the paymaster says.
[10:33] <ronny> hmm
[10:33] <fullermd> Heck, we just covered "bzr is way more flexible than everything else".  Flexible is kinda the opposite of what enterprise aims for  ;p
[10:34] <ronny> i came to the conclusion that all dvcs's suck
[10:34] <awilkins> What DVCS really needs for use in the enterprise is gui tools with a good visual metaphor for the distributed-ness
[10:34] <Odd_Bloke> fullermd: I think Lo-lan-do's point is that it'll be easier to convince the paymaster than the paid developers.
[10:34] <ronny> awilkins: i will probably do such a gui tool that manages git/hg/bzr
[10:35] <Lo-lan-do> My point was that it took me *years* to get people to use CVS at a previous job, and I left before managing to get them to switch to SVN even though the syntax/UI is identical.
[10:35] <fullermd> I dunno if that's true.  Really, the business case is pretty much like the open source case.
[10:35] <fullermd> You'll never convince the bulk of the project to move to foo.
[10:35] <awilkins> I always do think that Tortoise[DVCS] should just be one codebase with backend plugins
[10:35] <fullermd> Some group of sufficiently interested and clouted parties will make the decision, and drag everybody else along.
[10:35] <ronny> awilkins: im working on such a thing ^^
[10:36] <ronny> the catch is i dont yet have history/sync support implemented ^^
[10:36] <fullermd> bzr's advantages in flexibility and workflow just aren't obvious unless you (a) think carefully about it, or (b)(1) use it for a while without (2) trying to make it act like $OTHER_VCS.
[10:36] <fullermd> Performance, however, is trivially easy to test and very easy to natter on about to convince people.
[10:36] <ronny> and the comclusion is - all dvcs's suck and are awfull (just less bad than the centralized ones)
[10:37] <ronny> -m+n
[10:38] <fullermd> So really, there are 3 types of people who end up with bzr.
[10:38] <fullermd> (1) the people who are already there
[10:38] <fullermd> (2) the people who are drug there by someone with enough persuasive power
[10:38] <AfC> fullermd: re your original "flexibility and workflow just aren't obvious unless you (a) think carefully about it, or (b)(1) use it for a while without (2) trying to make it act like $OTHER_VCS", hear, hear
[10:38] <fullermd> (3) the people who like VCS's in particular or tools in general enough to spend a lot of time playing and fiddling with the options, and have usecases where the performance is "good enough".
[10:39] <ronny> fullermd: i just recently moved some bzr managed projects i inherited to hg cause bzr wont let me do my workflow
[10:39] <fullermd> Me, I'm used to using totally superior solutions that most people bypass for mostly ill-thought-out reasons.  I run FreeBSD.
[10:40] <Lo-lan-do> Is FreeBSD still totally superior?
[10:40] <Lo-lan-do> (Genuine question -- it's been years since I last tried it)
[10:41] <fullermd> Of course.      "Well, bzr lets you grind wheat..."
[11:29] <bob2> ronny: ok!
[11:33] <ronny> anyway, on the conceptual level i dislike all common dvcs's
[11:34] <Odd_Bloke> ronny: How would you do it differently?
[11:36] <awilkins> Whoa, python just ate 101% of CPU time doing a bzr-fast-export
[11:36] <ronny> Odd_Bloke: collated branches for bzr will mostly solve it
[11:36] <awilkins> Is that a known bug in `top` ?
[11:36] <Odd_Bloke> awilkins: How many CPUs do you have?
[11:36] <awilkins> This is a 1 CPU boxy (with HT)
[11:37] <Odd_Bloke> That might do it.
[11:37] <Odd_Bloke> I don't really know.
[11:38] <ronny> Odd_Bloke: oh, you mean how i would do dvcs different?
[11:38] <fullermd> Rounding errors like that are hardly unknown in top   :p
[11:38] <Odd_Bloke> ronny: Yeah.
[11:38] <fullermd> (rather, in stats reporting like that in general)
[11:39] <fullermd> Race conditions and observer skew and yada yada yada.
[11:41] <Toksyuryel> this has me curious too
[11:41] <ronny> Odd_Bloke: gits model is nice, but it needs more metadata
[11:41] <ronny> and of course no git around it ;P
[11:41] <Toksyuryel> I bet you could write a bzr plugin to do it
[11:42] <ronny> no
[11:42] <ronny> bzw wont get content addressing
[11:42] <awilkins> More like a git porcelain that looks like bzr
[11:42] <awilkins> I dunno, people rate about gitk but I just fast-exported my big branch here and it looks a right mess in gtik
[11:43] <awilkins> Maybe I'm not giving it enough hints
[11:43] <ronny> duno, git only tracks snapshoots of trees
[11:44] <ronny> makes it very messy for tracking history
[12:05] <awilkins> Damn.... git _is_ fast
[12:06] <awilkins> Just did git reset --hard on my fresh imported repo with no tree - p'chow!
[12:16] <Mez> any of the devvies around ?
[12:19] <Odd_Bloke> Mez: Don't ask to ask, etc. :)
[12:19] <Mez> Odd_Bloke: I asked earlier :D noone responded :D
[12:21] <Odd_Bloke> In re: nested branches?
[12:21] <Odd_Bloke> I think the short answer is 'no'.
[12:22] <Mez> :(
[12:22] <Mez> long answer?
[12:22] <Odd_Bloke> Real Soon Now. :)
[12:24]  * Mez headwalls
[12:27] <Odd_Bloke> I believe LarstiQ is working on it.
[12:27] <beuno> Mez, there are very strong rumors that someone will be working on it full time-ish soon
[12:27] <beuno> so maybe we'll get that in a few months
[14:40] <mrevell> vila: ping
[14:41] <vila> mrevell: pong
[14:56] <LarstiQ> Odd_Bloke, beuno: http://bazaar-vcs.org/NestedTreeProgress should be the focal point of nt progress
[14:58] <Odd_Bloke> Mez: ^
[14:59] <Odd_Bloke> LarstiQ: Thanks. :)
[14:59] <LarstiQ> now, I'm down to a couple of conflicts in merge.py and transform.py, so updating that page is next
[15:00] <LarstiQ> we're going to visit my girlfriend's brother now, so ciao :)
[15:04] <Odd_Bloke> LarstiQ: Have fun. :)
[15:10]  * vila doesn't quite follow how the nested boyfriend comes into play...
[16:46] <jam> morning vila
[16:47] <vila> hi jam, stop loonking above my shoulder I am *already* reviewing your patch !
[16:47] <jam> :), I was just saying good morning
[16:47] <vila> :)
[16:48] <beuno> healthy paranoia
[16:48] <jam> well.. paranoia, we can discuss the "healthy" part
[16:49] <jam> 8)
[16:49] <vila> On my right screen I was looking into bbc tests, I think the first failing ones are for you, but obviously your plate is already pretty full today
[16:49] <vila> I say for you because they seem to be related to some '\n' splitting
[16:49] <vila> ./bzr selftest -s bzrlib.tests.per_repository_chk.test_supported.TestCHKSupport.test_pack_preserves_chk_bytes_store
[16:49] <vila> should include them all
[16:50] <vila> -s rocks :-)
[16:51] <Goundy> guys I want your advices on organizing my project repository
[16:51] <Goundy> I'm writing a server/client gaming suite (for poker atm)
[16:52] <Goundy> So I have the client + the server + the project website
[16:52] <awilkins> Is it a problem to just have it all in the same tree :-)
[16:52] <Goundy> Atm I've two branches: One branch mainline which contains two directotries (client and server)
[16:52] <Goundy> and another one for the website
[16:52] <awilkins> Why separate client/server branches?
[16:52] <Goundy> someone think i can do better ?
[16:52] <Goundy> awilkins they're not seperated
[16:53] <awilkins> Ah, sorry,
[16:53] <awilkins> Misread
[16:53] <beuno> Goundy, is the client open source?
[16:53] <Goundy> it's the same branche and it contains the sources in different dirs :)
[16:53] <beuno> (is the server?)
[16:53] <Goundy> beuno all's open source :)
[16:53] <Goundy> I'm hosted on launchpad :)
[16:53] <beuno> Goundy, then I'd think the separation is good
[16:53] <Odd_Bloke> Heh, 'in before'.
[16:53] <beuno> client + server on one side, and webpage on the other
[16:53] <Odd_Bloke> Goundy: Sounds good to me.
[16:53] <Goundy> beuno well I thought the same thing also but guess what a serie can only have one branche :/
[16:53] <Goundy> beuno client and server in the same branch ?
[16:53] <Odd_Bloke> Goundy: It does depend how closely linked they all are.
[16:54] <Goundy> That's what you're saying ?
[16:54] <beuno> Goundy, a LP series you mean?
[16:54] <Goundy> beuno yes
[16:54] <Odd_Bloke> If the website is going to heavily depend on code from the other branch, maybe you want it in the same branch...
[16:54] <Goundy> Odd_Bloke well the link is the networking heh client <> server :è)
[16:54] <Goundy> well the website is totaly in xhtml atm
[16:54] <Goundy> the server is in C and the client in Java :è)
[16:55] <Goundy> The server and the client aren't linked at a source level
[16:55] <Goundy> and the website isn't linked to these sources.
[16:55] <Goundy> ( https://code.launchpad.net/~auresdev )
[16:55] <Goundy> Here's my current organization
[16:59] <Goundy> So you think I'm good keeping it that way guys ?
[19:23] <jam> vila: yeah, that failing test is because we changed the serialization format, and didn't change it there
[19:23] <jam> it isn't really about '\n', just about having another line of data
[19:28] <jam> vila: fixed in brisbane-core
[19:30] <funkychicken818> hey
[19:31] <funkychicken818> i have a merge a repository and it want me to run bzr update but i do not want to run the merge i want to simply remove it cause it screws up my files
[19:31] <funkychicken818> and when i try to run a push from another repository i says that nothing has changed
[19:33] <funkychicken818> hello?
[19:39] <Demosthenes> regarding nesting, isn't there some support for nesting in bazaar?
[19:40] <Demosthenes> i'm trying to model several users with a copy of their own data, centralized into on place for reporting, by pulling from the user branches....
[19:55] <bialix> fullermd: what do you mean by: "(b)(1) use it for a while without"
[19:58] <bialix> fullermd: you talk about: "flexibility and workflow just aren't obvious unless you..."
[20:27] <lifeless> Mez: its not finished, and I don't know anyone currently developing it
[20:59] <Mez> lifeless: apparently LarstiQ is...
[20:59] <Mez> though, by-value should suffice for my needs
[21:11] <lifeless> Mez: 'actively' :P
[21:11] <lifeless> jam: ping, test_sprout_uses_bzrdir_branch_format
[21:12] <jam> lifeless: pong
[21:13] <lifeless> vila: "is used as an id by several tests" -> does this load them all, or fail to laod ?
[21:13] <lifeless> jam: hi, I replied to the mail
[21:14] <lifeless> jam: like to get this bedded down today so I can put the branch (which contains a lot more fixes :P) up
[21:14] <jelmer> if somebody could have a quick look at my InterBranch patch, that would help me a lot
[21:14] <jam> so what are you trying to change that would cause this test to break?
[21:15] <jam> I can sort-of agree that RemoteBranchFormat doesn't contain a lot of info
[21:15] <jam> but I don't see why the test would specifically break because of it
[21:15] <lifeless> jam: the direct cause is that branch_implementations was testing RemoteBranch using the real branch object
[21:15] <lifeless> due to round about things
[21:16] <jam> and so it was passing by accident?
[21:16] <lifeless> oh yes
[21:16] <lifeless> and when I looked at it
[21:17] <lifeless> I could see it actually ends up asserting that the proxy object is a proxy object, which while it meets the letter, doesn't meet the spirit
[21:17] <jam> so what we want to assert is "source.sprout()" creates a target branch in the type that was initialized by the bzrdir object.
[21:17] <jam> I don't know that it matters for Remote
[21:18] <lifeless> well sure, because if I sprout into a remote url, I want to copy across still
[21:18] <jam> If you push into a remote url, you want to preserve the source format, yes. But that isn't what this is testing.
[21:18] <jam> If you push "--stacked" into a remote url
[21:19] <jam> you want a stackable format on the target
[21:19] <lifeless> what you specifically test though is, 'branch.sprout(a_bzrdir) uses a_bzrdir's branch format'
[21:19] <jam> lifeless: right
[21:19] <jam> as that is how "branch --stacked" support is implemented
[21:20] <lifeless> spiv and I were nearly quoting zork looking through this yesterday :)
[21:20] <lifeless> so
[21:21] <lifeless> if I change
[21:21] <lifeless> self.assertIs(self.branch_format.__class__, target._format.__class__)
[21:21] <lifeless> to
[21:21] <lifeless> self.assertIs(target_bzrdir.branch_format.__class__, target._format.__class__)
[21:22] <lifeless> would that still be correct? It seems more obviously so to me, because its testing the direct behaviour
[21:22] <lifeless> rather than relying on the assumption that self.branch_format == target_bzrdir.branch_format
[21:23] <jam> umm... if "self.make_bzrdir('target').branch_format != self.branch_format" we have a serious problem with the test permutations code
[21:23] <jam> as it means we aren't actually testing the permutations we think we are testing.
[21:23] <lifeless> jam: one is backed by a real bzr dir object
[21:23] <lifeless> one is completely fictional
[21:23] <poolie> hello
[21:23] <jam> lifeless: but it is important to be testing the "fictional" apis
[21:23] <jam> hi poolie
[21:24] <jam> We *need* to be testing that  RemoteBranch conforms to the api that the rest of Branch does
[21:24] <jam> I could accept that _format members may not be identical, etc.
[21:25] <jam> So if you have a case that "X._format != self.branch_format" I can accept that
[21:25] <lifeless> jam: get_cloning_metadir gets a real branch format, not a RemoteBranchFormat
[21:25] <lifeless> jam: *because* of the way stacking is addressed
[21:25] <jam> As long as isinstance(X, ?) is still correct
[21:25] <lifeless> jam: so we need to test the apis that are used, not the fictional ones
[21:26] <lifeless> jam: self.branch_format is a RemoteBranchFormat; target_bzrdir is a RemoteBzrDir; target_bzrdir.branch_format is a BranchFormat5/BranchFormat6/BranchFormat7
[21:26] <lifeless> hi poolie
[21:27] <poolie> hi
[21:27] <jam> lifeless: I'm willing to give in to someone who is focused on that portion of the code right now.
[21:27] <jam> But if target_bzrdir is a RemoteBzrdir then it seems that target_bzrdir.branch_format *should* be RemoteBranchFormat
[21:28] <jam> I need to go pick up my son to be back in time for the standup.
[21:28] <jam> I don't want to block you
[21:28] <jam> and I'll admit to not having a perfect understanding of what the code should be
[21:29] <jam> get_cloning_metadir() probably needs real objects
[21:29] <lifeless> jam: I would have thought so to, but then I looked :)
[21:29] <lifeless> and cloning_metadir() on remote delegates to _real_bzrdir
[21:29] <lifeless> so yes, we end up with real objects being initialized on a remote branch
[21:29] <lifeless> one side effect of that is that we initialize via VFS calls
[21:29] <lifeless> 100 or so in fact
[21:30] <jam> lifeless: which seems incorrect
[21:30] <lifeless> andrew and I would like to fix this
[21:30] <jam> anyway, I do need to go, bbiab
[21:30] <lifeless> ciao
[21:43]  * lifeless is fooding
[21:44] <bialix> a while ago I've read the article about dagger fixes. I can't find it anymore with google. Anybody has the link or the saved article text?
[21:44] <lifeless> 'dagger fixes?'
[21:44] <jelmer> s/dagger/dag ?
[21:44] <mwhudson> poolie: can you explain to me the relationship between progresstask and progress bars?
[21:44] <lifeless> bialix: oh, 'daggy fixes'
[21:45] <bialix> daggy? mmm, perhaps
[21:45] <jelmer> bialix: a dagger is a kind of knife IIRC
[21:45] <bialix> it sound similar, is not?
[21:45] <lifeless> http://monotone.ca/wiki/DaggyFixes/
[21:45] <lifeless> bialix: yes, its a false friend
[21:46] <bialix> yes, it's what I need
[21:46] <poolie> it is kind of similar, being a pointy bit
[21:46] <poolie> mwhudson: um
[21:47] <bialix> "daggy" -- queer word
[21:47] <mwhudson> poolie: bzrlib.ui.ui_factory.nested_progress_bar returns a task it seems
[21:48] <poolie> mwhudson: we used to have just one ProgressBar class
[21:48] <bialix> lifeless: thanks
[21:48] <poolie> i'm now doing a model:view separation
[21:48] <mwhudson> ah right
[21:48] <poolie> the model object is a ProgressTask
[21:48] <poolie> however some of the apis have not been renamed yet
[21:49] <poolie> does that help?
[21:50] <mwhudson> yes
[21:50] <mwhudson> what launchpad wants to do is intercept all progress reports
[21:51] <mwhudson> i just don't quite see how to impose my own progressbar class any more
[21:51] <mwhudson> (or indeed, if attacking this at the view level is the right place)
[21:52] <mwhudson> it seems like i could do this by overriding _progress_updated in my uifactory, but um
[21:53] <poolie> you should provide your own ui
[21:53] <poolie> modulo bugs, that should be able to completely replace any concept that progress bars are being drawn on a tty
[21:53] <mwhudson> right
[21:53] <mwhudson> i'm just not completely sure what this ui should do :)
[21:54] <mwhudson> maybe it should override _progress_updated
[21:55] <poolie> nested_progress_bar should not be overridden
[21:55] <poolie> yes
[21:55] <poolie> progress_updated is the main one you should care about
[21:55] <mwhudson> the _ scared me off
[21:55] <poolie> do you just care about "it's still alive"?
[21:55] <mwhudson> yep
[21:55] <mwhudson> the process gets killed after 15 mins of inactivity or something
[21:55] <poolie> calls to that indicate that it is
[21:55] <poolie> um
[21:56] <poolie> possibly we should give the ui a chance to return an object upon which progress_updated will be called
[21:56] <poolie> ie the view object
[21:56] <poolie> but i didn't do that yet
[21:56] <poolie> then it would make sense for the model just to be directly constructed
[22:01] <mwhudson> you mean get rid of nested_progess_bar?
[22:02] <mwhudson> anyway, i'm at least moderately happy as i can delete some code now :)
[22:02] <igc> morning
[22:03] <jam> poolie: I just missed it, ring again
[22:03] <mwhudson> though overriding a _method means that i'll get to do this again in a month
[22:04] <poolie> sorry
[22:04] <poolie> it is the intended method
[22:04] <mwhudson> cool
[22:05] <mwhudson> it's hard to distinguish between "don't call this unless you know what you are doing" and "this may go away"
[22:05] <lifeless> mwhudson: 'method' is for 'clients of bzrlib use/fully public/fully supported'
[22:06] <lifeless> mwhudson: '_method' is for 'for subclassing/private do not use/unsupported use but be ready to update'/
[22:06] <poolie> mwhudson: also and "this is public for subclassing" and "for calling"
[22:06] <lifeless> mwhudson: too many bits, not enough space
[22:06] <poolie> wot he said
[22:06] <lifeless> mwhudson: so ready the docstring, we try to be clear there :)
[22:07] <mwhudson> yeah, this says "Should be specialized to draw the progress."
[22:07] <mwhudson> so woot
[22:09] <poolie> mwhudson: i'd like to come back and clean it up more
[22:09] <poolie> will ping you when i do
[22:09] <mwhudson> poolie: thanks
[22:14] <Odd_Bloke> lifeless: I think LarstiQ has been doing some nested tree stuff recently.
[22:15] <vila> lifeless: they are loaded, that's how I detect that several ones have the same id (which may be a problem or not, it seems wrong to me in general, but I don't know that it can cause a problem except when one fails and you try to understand which one)
[22:15] <Odd_Bloke> He and jelmer were pairing on it at FOSDEM, possibly...
[22:15] <lifeless> vila: cool, we should fix them, but not-right-now
[22:15] <vila> jam: thks for the fix
[22:15] <lifeless> vila: did you see my two patches yesterday (in bzr.dev now)
[22:16] <vila> lifeless: if you found same, mail them to me, I'll record them in my TODO list
[22:16] <lifeless> vila: the second one has a plugin for bzr/subunit, which you will probably like :P
[22:16] <lifeless> vila: '"bzrlib.tests.tree_implementations.test_walkdirs.TestWalkdirs.test_walkdir_versioned_kind(DirStateRevisionTree)" is used as an id by several tests
[22:16] <lifeless> '
[22:16] <vila> lifeless: I would like to look at the one around the command, but didn't find th etime yet
[22:16] <lifeless> vila: you can just drop the code in the second one into ~/.bazaar/plugins/subunit
[22:17] <lifeless> vila: as long as you have subunit installed :P
[22:17] <jelmer> subunit \o/
[22:17] <lifeless> jelmer: yeah, I got around to my long threatened 'I should be able to use this with bzr'
[22:18] <jam> vila: which fix would that be?
[22:18] <vila> subunit appeared on my radar quite strongly today especially the 'reports to the parent as tests begin and end' since I'm currently thinking about parallelizing the test suite...
[22:19] <vila> jam: hehe, the bbc one :)
[22:19] <jam> ah, yeah no prob
[22:19] <jam> are the tests close to all passing now?
[22:19] <jam> (did you get poolie's work?)
[22:20] <vila> I didn't work much on them I wanted to review igc patch about log multiple files and directory
[22:20] <vila> I've seen poolie's work yet
[22:21] <vila> In fact, I'm not there, I'm in bed and I sleep :)
[22:22] <vila> I've *NOT* seen poolie's work yet
[22:22] <vila> grr
[22:22] <vila> sleeping indeed :)
[22:22] <lifeless> spiv: can I delete FakeRemoteTransport? used in one, disabled, test
[22:22] <spiv> lifeless: sounds good
[22:23] <poolie> vila, i'll send today i promise
[22:24] <vila> poolie: I asked nothing ! I don't even know what you're talking about :-) But I'm curious now... will I be able to sleep ? :)
[22:25] <jam> lifeless: I'd like to chat quickly about '\n' delimited chk records
[22:25] <jam> vila: poolie did some work on making the test suite pass
[22:26] <jam> he claims he made progress
[22:26] <jam> nobody else has seen the results :)
[22:26] <jam> I think he is secretly planning on actually doing the work
[22:26] <jam> and then sending it
[22:26] <lifeless> jam: sure thing
[22:27] <jam> lifeless: so... I think it is a good decision to use '\n', as it means we don't have to try quite as hard to make a compressor that is not line based
[22:27] <jam> my main concern is "compatibility"
[22:27] <lifeless> with?
[22:27] <jam> I introduced the hash prefix stuff
[22:27] <jam> in such a way that we can read -dev4 or hash based ones
[22:27] <jam> should I try to do the same for this
[22:27] <lifeless> so the hash thing I think thats worth doing, because we're still comparing IMO
[22:28] <lifeless> however this \n is trivial its not a strategic decision, if you like
[22:28] <lifeless> its should have little to no long term impact
[22:28] <lifeless> so JFDI imo
[22:28] <jam> k
[22:28] <lifeless> twiddle a bit in the dev3 and dev4 disk format labels to stop confusion
[22:28] <jam> it makes *my* life a lot easier :)
[22:29] <jam> doing it means fixing a lot of serialization dependent tests, so getting the answer up-front is important
[22:29] <jam> I sent my hash prefix stuff to the list just now
[22:30] <jam> igc: I think I know why you couldn't reproduce bug #328135
[22:30] <jam> I would guess you had a plugin that did "import bzrlib.workingtree"
[22:30] <jam> which was happening *before* the initialize() code was doing it
[22:31] <jam> I'm not sure why I *don't* have a plugin which does that
[22:31] <jam> though I did spend a bit of time to make a couple of my installed plugins a bit more "lazy"
[22:36] <igc> jam: interesting. Thank you *so* much for tracking this down
[22:36] <jam> igc: you can test yourself with "python -c 'import bzrlib.workingtree_4'"
[22:36] <jam> that should break
[22:36] <jam> (even with my fix)
[22:36] <jam> but at least it isn't user-visible for now
[22:37] <igc> jam: yep, that breaks for me
[22:37] <jam> lifeless: do you think we need to keep -dev3 around?
[22:38] <jam> igc: now, in theory, this would pass "python -c 'import bzrlib.plugin; bzrlib.plugins.load_plugins(); import bzrlib.workingtree_4'"
[22:38] <lifeless> jam: I think its clearly substandard, so no
[22:38] <jam> lifeless: that was my feeling
[22:38] <jam> if I was going to change the format string, I may as well get rid of it
[22:38] <lifeless> jam: sure
[22:40] <igc> jam: yes, that works
[22:40] <jam> igc: there you go :), I assume "bzr init --development-wt5 --no-plugins" would also fail for you
[22:42] <igc> jam: yes
[22:42] <jam> I believe that should work on the bzr.1.12 branch
[22:42] <igc> lifeless: so groupcompress has a minor bug - it needs to import repo_registry before the 'if chk' test
[22:43] <igc> lifeless, jam: also, so we please start using WorkingTreeFormat5 in the new dev formats
[22:43] <igc> s/so/can/
[22:43] <igc> that will increase testing
[22:44] <jam> igc: not by a lot, but sure
[22:45] <jam> I'll go ahead and bump everything to v5
[22:45] <jam> just to make it obvious
[22:45] <lifeless> jam: have you looked at performance with mmap?
[22:46] <jam> lifeless: I have a branch which changes LocalTransport.readv() to use mmap to return the strings
[22:46] <jam> My initial tests showed no real difference
[22:46] <jam> But I didn't test thoroughlty
[22:46] <lifeless> jam: I'd like to try minimising the open() calls
[22:46] <jam> lifeless: yeah, it cached the mmap
[22:46] <jam> and then trapped for rename(), tec.
[22:46] <lifeless> ok call
[22:46] <lifeless> ok cool
[22:47] <jam> lp:~jameinel/+junk/bzr-mmap-readv
[22:47] <igc> jam: were you going to send the development-wt5 to bzr.dev or wait for poolie to merge the 1.12 changes across?
[22:47] <jam> It does a "trace.note()" when used
[22:47] <jam> just to be sure
[22:47] <jam> igc: I was just waiting for 1.12
[22:47] <jam> since it is ~today
[22:48] <igc> jam: np. I'll update the bug report to say as much
[22:49] <lifeless> do teams have +junk?
[22:52] <lifeless> spiv: so, the disabled test turns out to be one that would have trapped the double get_stacked_on verb call :)
[22:52] <Demosthenes> regarding nesting, isn't there some support for nesting in bazaar?
[22:52] <Demosthenes> i'm trying to model several users with a copy of their own data, centralized into on place for reporting, by pulling from the user branches....
[22:54] <Demosthenes> the master doesn't seem to like committed when subdirs are branches.
[22:54] <Demosthenes> er, committing
[22:55] <lifeless> Demosthenes: there isn't user-ready code, no.
[22:55] <lifeless> LarstiQ: you need a bot to pipe up here
[22:55] <lifeless> spiv: bzr: ERROR: [Errno 2] No such file or directory: '/tmp/testbzrG-RDn6.log'
[22:55] <lifeless> spiv: I think there is a bug actually, in the log related test code, cause I'm getting that and I'm not working on write groups ;P
[22:56] <lifeless> spiv: something like a gc event causing it
[22:59] <Demosthenes> lifeless: so i'm better off symlinking or putting the "child" branches in sibling directories then.
[23:00] <lifeless> Demosthenes: or merging them into subdirs - see the merge_into plugin
[23:00] <spiv> lifeless: chatting to thumper atm
[23:01] <lifeless> spiv: when you can, I have a nontrivial issue in this branch
[23:01] <mwhudson> poolie: this is the ui factory code i have now, does it look vaguely sane? http://pastebin.ubuntu.com/117472/
[23:14] <garyvdm> poolie,luks:  Alex is not around so I'm asking you guys. We have a regression in qbzr 0.9.7 - bug 327395 - we allready have a fix - should we do another release with just a cherrypick of that fix - to be included in bzr 1.12 finial?
[23:15] <poolie> hey
[23:15] <poolie> mwhudson: yes that looks good
[23:15] <poolie> i'd also like to factor out the various types of questions we ask the user into abstracted methods
[23:15] <poolie> so you don't need the icky string compare
[23:16] <mwhudson> poolie: yes, that would be nice :)
[23:16] <mwhudson> poolie: thanks for the sanity check
[23:23] <poolie> garyvdm: so where would this change have to be included?
[23:23] <lifeless> woo nearly there
[23:23] <poolie> in the bzr branch, or just in the windows installers?
[23:23] <lifeless> poolie: windows / macosx installers from the look of it
[23:24] <lifeless> garyvdm: doing a release makes it clearer to folk, I'd say do one
[23:24] <garyvdm> Ok -
[23:24] <garyvdm> Should I call it 0.9.8 or 0.9.7-rc2 or ...?
[23:25] <poolie> what was your previous release, rc1?
[23:25] <garyvdm> Just 0.9.7
[23:25] <poolie> if you're just changing that i'd just call it final
[23:27] <garyvdm> I guess that because we did not specify rc1 on the prev release - we have to call it 0.9.8
[23:28] <lifeless> spiv: ok, that fail list all passes now.
[23:28] <lifeless> whew
[23:28] <lifeless> spiv: so I'm running all tests again, see if there are any new fails
[23:34] <spiv> lifeless: woo
[23:35] <spiv> lifeless: yeah, I'm pretty sure from yesterday that the test infrastructure's handling of the log file is busted, because I kept hitting it
[23:35] <spiv> something to do with raising an exception during a cleanup func perhaps?
[23:35] <spiv> So long as my tests weren't erroring it was fine ;)
[23:54] <mthaddon> anyone able to comment on https://bugs.launchpad.net/pqm/+bug/191393/comments/3 - I'm assuming this is a bug in bzrlib rather than PQM, but just checking
[23:55] <lifeless> mthaddon: its likely a case where pqm needs to setup a handler or some such
[23:56] <mthaddon> lifeless: but how come I can reproduce it in such a simple test? doesn't that suggest bzrlib.branch should be doing something different?
[23:58] <lifeless> mthaddon: maybe :P
[23:58] <mthaddon> who'd be best to comment on that?
[23:58] <lifeless> mthaddon: its coming from the pytohn logging stuff
[23:58] <jelmer> would somebody perhaps have time to have a look at my InterBranch patch?
[23:58] <lifeless> bzr uses that to output progress data to  ~/.bzr.log
[23:59] <lifeless> we kindof want that facility to work
[23:59] <lifeless> possibly a better thing to do would be to check if there are no handlers, and if not setup either our normal ones, or null handler
[23:59] <jelmer> It's blocking my bzr-git work a bit atm, as it's required to do bzr pull from remote git branches
[23:59] <lifeless> jelmer: I'll try