[00:00] <kwmiebach> 'bzr pull -r 425 .'  resulted in 'No revisions to pull'. But rev 425 is in the log. Strange.
[00:00] <kwmiebach> I come from git - it is so different
[00:06] <kwmiebach> I think bzr revert changed something. But how can I find out if I am at the earlier reveision now? 'bzr log' still shows the latest revision as the first entry
[00:11] <kwmiebach> spiv, thank you. i think i will do a new local branch, maybe it is possible to specify a revision umber
[00:12] <kwmiebach> (I believe "revert" is doing what I want. But how can I proove the outcome?)
[00:37] <kwmiebach> spiv, is there also a way to revert to a milestone?
[01:26] <bignose> kwmiebach: is the milestone a tag?
[01:26] <bignose> (and if not, why not?)
[01:27] <bignose> kwmiebach: if so, ‘revert’ takes the ‘--revision’ option with all the usual revspec values
[01:27] <bignose> so ‘bzr revert --revision tag:foomilestonetag’
[01:30] <kwmiebach> bignose, thank you. I am only making local copies of some launchpad repositories. Gonna try to see milestones as tags.
[01:31] <kwmiebach> what if I tomorrow forget which revision I reverted to yesterday? is there a way to find out at which revision I am?
[01:36] <jimis> kwmiebach: bzr info -v or some other flag possibly?
[01:39] <kwmiebach> jimis, witth your help I checked the help for "bzr info" and it said "bzr revno" is what I needed. cool.
[01:40] <kwmiebach> the fog is starting to clear now :)
[01:44] <bignose> kwmiebach: what I meant was, if you have a milestone and you want to refer to it by name, that's what a tag is for.
[01:45] <bignose> kwmiebach: what is a milestone to you?
[01:47] <poolie> lifeless, spiv, hi
[01:48] <lifeless> hiya
[01:48] <poolie> can we chat briefly?
[01:48] <kwmiebach> bignose, I find "milestones" on launchpad projects.
[01:48] <lifeless> poolie: of course
[01:52] <kwmiebach> bignose, for example the "do" project: https://launchpad.net/do there is a chart of "series and milestone" approx in the middle column (trunk, 0.8, 0.7, 0.6)
[01:54] <spiv> kwmiebach: ah, sorry, I forgot to say --overwrite in the 'bzr pull' invocation
[01:55] <spiv> kwmiebach: launchpad milestones don't necessarily correspond to any revision
[01:56] <spiv> kwmiebach: (e.g. its common to have milestones for releases that aren't ready yet, and the milestone is used as a tool to track what's left to be done)
[01:56] <spiv> kwmiebach: but it's common practice that people will add bzr tags when they make releases
[01:58] <spiv> kwmiebach: e.g. 'bzr tags -d lp:do' reports tags like 0.8.0 and 0.8.5, so you can use e.g. '-r tag:0.8.5' to refer to those tagged revisions
[01:59] <kwmiebach> spiv, I tried "bzr pull --overwrite -r 1234 ." now. It seems to work on the one hand I get a correct "bzr log" afterwards. But the "bzr pull ..." told  me many conflicts were intrioduced. Is that a normal thing?
[01:59] <kwmiebach> How can pulling a different revision introduce a conflict?
[02:00] <spiv> (It occurs to me it might be a nice feature if the launchpad page for a milestone linked to a revision tagged with the milestone name in the corresponding series branch, if that tag exists)
[02:00] <spiv> kwmiebach: because the tree you were pulling in wasn't a pristine copy of the other revision
[02:01] <spiv> kwmiebach: it might have had uncommitted changes, or unversioned files
[02:02] <kwmiebach> spiv, what i did before was some "revert" commands
[02:02] <kwmiebach> so i throw it away and create a clean local "bzr branch" again
[02:02] <spiv> Right, if you revert to some revision other than the current revision for that tree, then you have uncommitted changes
[02:03] <spiv> (as will be clear if you check the output of 'bzr st')
[02:03] <spiv> kwmiebach: note that you can specify -r with 'bzr branch' too
[02:03] <kwmiebach> cool
[02:04] <spiv> kwmiebach: so you can just branch the revision you want directly, rather than branching the current tip then pulling the one you actually wanted.
[02:05] <kwmiebach> is there a windows command line version of bazaar? I am actually using bazaar on cygwin, but I believe it is slow
[02:07] <bignose> kwmiebach: there is, and I've used it a few years ago
[02:08] <bignose> but it was painful. not Bazaar's fault, but Windows's.
[02:08] <bignose> (might be better with a decent command shell, but that's what Cygwin is for.)
[02:08] <kwmiebach> bignose, i undersstand. maybe i stay with cygwin-bazaar
=== robbyoconnor is now known as `
=== ` is now known as r0bby_
=== r0bby_ is now known as robbyoconnor
[04:33] <thomi> Does anyone know why __enter__ and __exit__ were removed from bzrlib.transform.TransformPreview with rev 5967?
[04:33] <thomi> the commit message just says "Cleanups and fixes for merging into null tree. (Aaron Bentley)"
[04:46] <thomi> bah - figured it out, was looking at the wrong branch :(
[06:08] <jelmer> moinmoin
[06:33]  * jelmer heads to a coworkspace, back in 30 min
[06:59] <vila> moin
[07:09] <poolie> hi vila
[07:10] <vila> hey poolie
[07:26] <vila> I see pqm is still going strong :)
[07:30] <jelmer> whoa
[07:33] <vila> I'm glad we do so many landings :)
[07:33] <vila> <cough>
[07:35] <vila> poolie: if the datasync stuff is involved in the pqm increased times, it doesn't show up on babune 'build time trends'
[07:35] <vila> --parallel shouldn't be an explanation but using tmpfs for /tmp on the slaves may (I'm still not fully convinced though)
[07:36] <vila> jelmer: about your unparsed-url mps
[07:37] <vila> I'm wondering if we shouldn't take the opportunity to use URL objects as parameters instead of strings and keep the various representations available for the URL life cycle
[07:37] <poolie> hi vila, jelmer
[07:38] <vila> instead of converting back and forth between paths/urls/unicode/url-encoded and having these conversions occur everywhere
[07:38] <jelmer> 'morning poolie
[07:39] <vila> I'm not advocating for doing that everywhere either (and may be not *now* either)
[07:40] <vila> but we've encountered so many related bugs...
[07:40] <jelmer> vila: I wouldn't be opposed to that
[07:42] <vila> this will also help clarify which parts of the API use which form of URLs (unicode is *not* 42 ;)
[07:42] <jelmer> yeah, that's indeed a bit undefined at the moment
[07:42] <jelmer> where some things are unicode paths, some things are utf8 paths, some things are urlencoded utf8 paths, ..
[07:43] <vila> yeah, and dealing with strings means you lose the original form you may need at some later point
[07:43] <jelmer> vila: for the moment, I'd like to focus on just getting colocated branch support finished
[07:43] <vila> so the main idea would be that URL objects are immutable but can provide the various forms
[07:43] <vila> jelmer: np
[07:44] <vila> yeah, yeah, I certainly don't want to distract you (almost ;)
[07:45] <vila> jelmer: oh, and thanks a ton for all the reviews !
[07:46] <jelmer> vila: no problemo, I am after all patch pilot :)
[07:52] <vila> mthaddon: I filed bug #825027 about the issue you encountered yesterday
[07:52] <ubot5> Launchpad bug 825027 in Bazaar "create_safety_net is brittle" [Medium,Confirmed] https://launchpad.net/bugs/825027
[07:53] <mthaddon> thx
[07:54] <jelmer> vila: is that a blocker for the new PQM?
[07:55] <vila> mthaddon: for my own enlightenment, what was the root cause here ? You can really get a chroot without the right users declared ?
[07:56] <mthaddon> vila: we copied the chroot wholesale from the existing PQM instance, so the UIDs aren't matching up
[07:57] <vila> jelmer: from the bzr pov, no, we can try working around the issue or at least provide a better feedback but given the pqm workflow, I'm not entirely sure we could have give mthaddon a timely and useful feedback :-/
[07:57] <vila> mthaddon: wow, I see
[07:57] <vila> automated deployments ftw ;)
[07:57] <mthaddon> should be fixable on this end, of course :)
[07:58]  * vila nods
[08:25] <poolie> hi vila, would you like to talk?
[08:26] <vila> poolie: sure
[08:26] <vila> !
[08:26] <lifeless> vila: so the failing test didn't output its exception ?
[08:27] <poolie> actually i might put some dinner on, then can i call you at home?
[08:27] <vila> lifeless: all failing tests did output their exceptions
[08:27] <vila> lifeless: the issue is that they were hidden in a redirected file making it harder to understand what was going on
[08:28] <vila> poolie: wfm
[08:32] <lifeless> vila: why was the file redirected ?
[08:32] <vila> lifeless: so it can be post-processed with subunit-stats, man, it's the bzr 'make check' remember ? ;)
[08:33] <lifeless> vila: its been a bit :>
[08:33] <lifeless> vila: why didn't pqm send the original stream out in its error mail? it normally does that ? [and extracts the failures itself]
[08:34] <vila> lifeless: ctrl-alt-del
[08:34] <lifeless> vila: ?!
[08:34] <lifeless> sorry
[08:34] <vila> lifeless: the context was mthaddon debugging the new pqm server, not the usual workflow
[08:34] <lifeless> ⸘
[08:34] <lifeless> vila: so, I would close that bug invalid :>
[08:35] <vila> lifeless: well, the subject says 'create_safety_net' is brittle, I use a 'medium' importance
[08:35] <lifeless> sorry, I should be clearer
[08:35] <lifeless> the 'hard to debug' aspect of it is unrelated to the way that test fails
[08:35] <lifeless> it was due to how the test suite was run
[08:36] <vila> I don't disagree :)
[08:36] <lifeless> as I read the bug, the hard to diagnose part was the greater part of the problem :)
[08:36] <vila> On the other hand, a failure at this point could have just *stopped* the test suite, there is no point in failing gracefully there
[08:37] <lifeless> vila: or run with -1
[08:37] <vila> lifeless: hmm, running with -1 was abandoned when subunit were used ;)
[08:38] <lifeless> right, but as you said: this wasn't normal
[08:38] <lifeless> this was debugging a new server
[08:38] <vila> lifeless: then -1 is not available for 'make check', I indeed thought about defining a new make target for such cases though
[08:39] <lifeless> vila: when would it be used?
[08:39] <vila> but mainly, I agree with you, it has little to do for bzr itself
[08:39] <vila> lifeless: when validating the selftest environment
[08:39] <lifeless> vila: which is why if I was still active in bzr I would probably just close the bug invalid :)
[08:39] <lifeless> vila: I would run ./bzr selftest -1 if I wanted to validate the environment :)
[08:40] <lifeless> anyhow
[08:40] <vila> lifeless: yup, I recommended something like that
[08:40] <lifeless> it was just a cmment, if you want it open, its up to you :)
[08:40] <lifeless> (IMO)
[08:40] <vila> lifeless: thanks, I will add such a comment ;)
[09:09] <ccxCZ> has anyone tried to integrate PQM with issue tracker? I'm currently looking at roundup and how it could handle 'bzr send' messages
[09:21] <jelmer> ccxCZ: hi
[09:22] <ccxCZ> hello :-)
[09:22] <jelmer> ccxCZ, Integrate it in what way, automatically closing bug reports when the fix for that bug lands?
[09:22] <ccxCZ> or close merge request when it's approved
[09:24] <jelmer> ccxCZ: It should be possible to do that outside of PQM with just a script that watches the branch
[09:29] <ccxCZ> I thought about workflow like this: someone bzr-sends me a patch, it goes into roundup as open issue and is forwarded to pqm, which replies with "all tests passed". I then reply via pgp-signed mail or via web interface and say "merge", which closes the issue and merges the branch
[09:30] <jelmer> ccxCZ: pqm can only really handle merge commands, potentially requiring a testsuite to pass before accepting a merge command
[09:31] <ccxCZ> okay, seemed to me that way. But what I described shouldn't be that hard to build, right?
[09:33] <ccxCZ> anyway I kinda miss some documentation on how to handle bzr-send messages
[09:35] <jelmer> ccxCZ: pqm doesn't handle messages sent with bzr send
[09:35] <jelmer> ccxCZ, you seem to want a feedback step between having pqm run the tests and actually doing the merge, I don't think that's very easy with PQM at the moment
[09:37] <ccxCZ> what does handle bzr-send messages? how can I inspect them / assign them to correct repo etc.
[09:37] <jelmer> ccxCZ, "bzr pull" and "bzr merge" can handle the bundle files that "bzr send" attaches
[09:39] <ccxCZ> how do I do that? I point it at mbox file instead of uri?
[09:40] <jelmer> ccxCZ: "bzr send" attaches a file that you can point it at
[09:41] <ccxCZ> I need to exctract the mime part then, right?
[09:41] <jelmer> yep
[09:46] <ccxCZ> hmm, maybe I'll try to involve buildbot then
[09:49] <ccxCZ> or rather I'll write down usecases for such system first, would you mind writing me what you about it when I do?
[09:52] <jelmer> ccxCZ: writing what?
[10:00] <ccxCZ> nvm for now
[10:01] <poolie> hi jelmer, can you have a go at the review queue today?
[10:03] <jelmer> hi poolie
[10:03] <jelmer> poolie: there doesn't seem to be much that needs review at the moment -  is there anything specific I should look at it?
[10:04] <jelmer> nevermind, maybe I should switch back to ~bzr/+activereviews, ~bazaar+activereviews is too noisy
=== medberry is now known as med_out
[10:19] <thumper> can bzr have a global ignore list?
[10:20] <jelmer> thumper, ~/.bazaar/ignore IIRC
[10:20] <thumper> jelmer: ta
[10:28] <Riddell> wow, PQM is slow
[10:34] <vila> Riddell: hehe, welcome to the club :)
[10:35] <vila> Riddell: so, yeah, very slow since ??? but a new server is in the works so the consensus is to wait for it and see if it's still slow and *then* investigate
[10:36] <vila> Riddell: in other words: *now* is not the time to use pqm to check that the whole test suite pass ;)
[10:37] <vila> Riddell: I may have an offer you can't resist to though...
[10:38] <Riddell> vila: qu'est ce c'est?
[10:38] <vila> Riddell: if you connect to babune once, I can add you to the testers group there so you get more rights to run the test suite on various platforms ;)
[10:39] <vila> Riddell: for arbitrary branches that is
[10:39] <Riddell> and then it wouldn't risk failing in PQM and taking another day to pass?
[10:39] <vila> yup, that's the idea
[10:39] <Riddell> how do I connect?
[10:40] <vila> not fully guaranteed as I've seen cases where pqm were raising different failures, but pretty rare these days
[10:41] <vila> Riddell: click the login button top right
[10:41] <Riddell> top right of what?
[10:41] <vila> Riddell: http://babune.ladeuil.net:24842/
[10:41] <vila> Riddell: omg, you don't know where babune leave on the internet ? :D
[10:42] <vila> lives
[10:42] <vila> ruining joke tyops are baclk ;)
[10:42] <vila> abck !
[10:42] <vila> back !
[10:42] <Riddell> me and babune have never been introduced
[10:43] <Riddell> logged in
[10:44] <vila> Riddell: meet babune: http://babune.ladeuil.net:24842/
[10:44] <vila> babune: meet Riddell
=== vila is now known as babune
[10:45] <Riddell> bonjour babune
[10:45] <babune> I'm a bot running the test suite for bzr on various platforms
[10:45] <babune> You can look at the 'debug' tab to see various jobs which accept various parameters (including a branch) to run various subsets of the test suite
[10:46] <babune> Riddell: you're now part of the testers group
[10:47] <Riddell> thanks babune
[10:47] <Riddell> so how do I test things?
[10:47] <babune> Riddell: refreshing the page should reveal additional buttons including a clock with a green button to run a given job
[10:47] <babune> s/button/arrow/
[10:49] <Riddell> it does
[10:49] <babune> Riddell: oh, you run the chroot-natty one ?
[10:50] <babune> So, the 'Critical' and 'High' tabs are the "official" jobs and under normal circumstances are triggered automatically
[10:50] <babune> Riddell: did you specify a different branch than lp:bzr ?
[10:51] <Riddell> babune: yes I clicked on the chroot-natty clock icon
[10:51] <babune> no, good, ho harm done then, perfect
[10:51] <babune> Riddell: for your own branches, better look at the jobs in the 'debug' tab and yell or file bugs if they don't suit your needs
=== babune is now known as vila
[10:52] <vila> What a lovely bot...
[10:53] <Riddell> how do I specify a different branch?
[10:53] <vila> 3 min 23 sec, eat that pqm !
[10:54] <vila> oooh, the 'Critical' jobs have no parameters, I see, try http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-natty/build?delay=0sec
[10:54] <vila> you'll get a page with the accepted parameters
[10:55] <Riddell> ah hah
[10:55] <Riddell> lovely
[10:58] <vila> jelmer: bad target for your generate-revhistory proposal I suspect
[11:00] <vila> Riddell: in other news, your submission just started on pqm ;)
[11:01] <Riddell> --MARK--
[11:01] <vila> :)
=== Mkaysi_ is now known as Mkaysi
[13:57] <jelmer> vila: any chance you can submit my fix for 2.4 to lp:bzr/2.4 ?
[13:58] <vila> jelmer: sure thing
[13:58] <fullermd> Aw, man, you want vila to make pqm work _harder_??
[13:59] <vila> work pqm work !
[13:59] <fullermd> Slavedriver   :(
[14:00] <vila> That reminds me of lucid-emacs's whip sound :)
[14:00] <vila> Yeah, I confess I've used lucid-emacs (later called xemacs) before seeing the true light of using GNU emacs
[14:00] <vila> But RMS said it's ok now
[14:04] <vila> ggggh
[14:04] <vila> well done jelmer :)
[14:04] <jelmer> vila: what did I do ? :)
[14:04] <vila> tricked me into submitting your proposal before realizing two of mine have failed for conflicts :D
[14:06] <jelmer> muhahaha >-)
[14:06] <vila> hehe
[14:06] <jelmer> (that was actually unintentional...)
[14:08] <vila> yeah, they all say that...
[14:09] <vila> jelmer: in fact, I'm more interested in merge 2.4 => trunk right now for babune's sake, so all is fine
[14:11] <vila> since that means your equality_funcs.clear workaround should turn oneiric blue, finally
[14:22] <mgz> hm, had I realised oneiric was really going to ship a non-release python version from a random hg checkpoint, I'd have proposed a branch just removing that code entirely
[14:23] <mgz> it doesn't serve much purpose without the main chunk which has yet to land
[14:25] <jelmer> I hadn't counted on that either
[14:25] <jelmer> Perhaps we should've checked with doko
[14:26] <vila> mgz, jelmer: yeah, worth checking, it would be surprising that python is not upgraded until oneiric is released
[14:26] <vila> mgz: fixing the bug upstream was the right thing to do anyway, thanks again for that !
[14:32] <Riddell> is there a bzr equivalent of "git rev-parse --show-prefix"? i.e. finding out where the current directory is relative to the top of the .bzr branch from the command line?
[14:36] <vila> bzr root ?
[14:37] <vila> ha no, you want the relpath from that... hmm, worth adding an option to the command...
[14:37] <vila> Riddell: care to file a bug ?
[14:38] <Riddell> mm, actually bzr root might be just what I wanted
[14:39] <bignose> Riddell: branch_root=$(bzr root) ; echo ${PWD#${branch_root}/}
[14:40] <Riddell> bash is such a messy language :)
[14:40] <bignose> even better: echo ${PWD#$(bzr root)/}
[14:40] <vila> why not just: 'bzr root' ?
[14:40] <bignose> vila: because it's not what is being requested
[14:40] <bignose> vila: see the difference between 'bzr root' and the shell code I gave
[14:41] <vila> that's why I'm asking, trying both gives the same result here
[14:41] <bignose> it should not.
[14:41] <vila> ha right, different result when I'm not at the root
[14:41] <bignose> ah okay, it would iff you are already at the root. hmm.
[14:42] <fullermd> Doesn't work too well without bash either   ;p
[14:42]  * bignose ignores systems without Bash :-)
[14:43] <bignose> I'd be happy seeing a 'bzr relative-path [filename]' that does what Riddell is asking
[14:44] <vila> yeah, that's why I ask RIddell to file a bug. Adding a --relpath to 'bzr root' would have my preference over a new command though
[14:44] <fullermd> We almost have it, in bzr ls --from-root.  Except it refuses to take a path arg at the same time.
[14:44] <bignose> I don't think it belongs on the 'bzr root' command, which has a different purpose.
[14:45] <vila> Well 'Show the tree root directory' doesn't specify if the path is absolute or relative
=== micahg_ is now known as micahg
[14:45] <fullermd> But he doesn't want the tree root dir.  He wants to know where he is _relative_ to the tree root.
[14:45] <bignose> vila: showing the *current* directory is not "show the root"
[14:46] <fullermd> (of course, it has more to do with showing the root than with parsing a rev, but who expects sanity from git commands?  :p)
[14:46] <vila> bigjools: ouch, you're right, sorry
[14:46] <bignose> fullermd: exactly
[14:46] <bigjools> vila: I am.  What was the question? :)
[14:46] <vila> bigjools: I meant, sorry for the bad auto-completion ;)
[14:46] <bignose> we don't have to make the same bad UI decisions as Git
[14:47] <vila> bignose: ouch, you're right, sorry
[14:47] <fullermd> Quite.  We're perfectly capable of inventing our own all-new bad UI decisions!
[14:47] <bignose> :-)
[14:48] <bignose> fullermd: I think Riddell's request is best met by an optional path argument to 'bzr ls --from-root'
[14:48] <bignose> (since it already does the special case of "current directory" without any changes)
[14:48] <bignose> and that's me out. g'night, all.
[14:49] <fullermd> bzr ls already takes a path; it just refuses to take a path AND from-root.  Kinda squirrely-looking.  It also recurses when I specify '.' as the path, even without recursion, but that's another nit...
[14:49] <fullermd> (though actually, I wish --from-root means to do the _ls_ from root, not show full paths...)
[14:49] <vila> fullermd: you know you can add test scripts to your bug reports in a syntax very close to a shell script ;)
[14:50] <fullermd> I write shell scripts to narrow down and reproduce the bug; they just get attached to the reports as a bonus because I've already written 'em  ;p
[14:54] <vila> fullermd: I know ;)
[14:55] <vila> but test scripts can be run repeatedly without removing the tmp test dir...
[14:56] <fullermd> Oh, I just keep up-arrowing to "rm -rf foo ; ./whatever" when I'm working 'em up.
[14:56] <vila> hehe
[14:56] <fullermd> I guess that would be "C-x M-9 H-q C-é F-17 M-r" for you?   :p
[15:00] <vila> nope, M-p
[15:01] <vila> And F- doesn't exist, you just made it up ;-P
[15:03] <fullermd> What, you don't have Function keys?
[15:06] <mgz> seventeen of them? :)
[15:06] <fullermd> Well, if you're gonna use Emacs...
[15:06] <mgz> I thought that just required four flavours of meta...
[15:07] <vila> function keys are f1 f2 etc, capital has a meaning in shortcuts ;)
[15:07] <vila> Escape Meta Alternate Control Shift, really that's not *that* hard to remember :D
[15:07] <fullermd> You've never seen a keyboard with a Function key, that you chord with a number to put in Fwhatever?
[15:07] <vila> foot keyboard ?
[15:08] <fullermd> No, there are regular keyboards that have it.
[15:08] <fullermd> As I recall, for one example, my PCjr had one.
[15:08] <fullermd> (yeah, OK, get your laughing out of the way...)
[15:08] <vila> ohhh, that reminds me of very old vt100 keyboards maybe
[15:09] <fullermd> Hm.
[15:09]  * fullermd goes to check in the closet.
[15:09] <vila> rats, I can't do that
[15:09] <vila> I mean, I have a closet of course but no keyboard old enough there ;)
[15:10] <fullermd> The VT102 doesn't have any Function just, just PF 1-4.
[15:10] <vila> the oldest may be one with those... DIN plugs ? (Round with 5 pins inside)
[15:10] <fullermd> I've got a Liberty terminal that has F1-F16.
[15:11] <fullermd> VT102 is 1/4" TRS.  Lot older than a DIN   :p
[15:11] <vila> I've amac keyboard with f1->f15 volume-up/down/mute and eject !
[15:11] <fullermd> That sounds like an AT-style.
[15:11] <vila> yeah AT-style
[15:11] <fullermd> Got a handful of those around.
[15:12] <vila> so volumes and eject should be probably be configurable giving f1->f19, you lose !
[15:13] <fullermd> Configurable?!  I thought you said "mac"   :p
[15:13] <vila> plugged into an ubuntu system ;-D
[15:13] <fullermd> Out of the frying pain, into the fire...
[15:14] <vila> And wait ! The othe one has f1->f13 plus volumes and eject ! f1-f20 !!! mwhahahahaha
[15:14] <vila> meh
[15:14] <vila> f1->f*16*
[15:14] <fullermd> IBM made some keyboards that went up to f24, I think.  Probably 80's.
[15:15] <vila> did they run FreeBSD ?
[15:15] <vila> :-D
[15:15] <gour> is anyone familiar with both bzr-2.4 & hg-1.9 to tell how do they compare today?
[15:16] <fullermd> Doubt it.  That would be pre-386, so pre-MMU, so any *nix just points and laughs.  Could probably hook the keyboard up to something current of course.
[15:16] <vila> pre-MMU... painful memories
[15:16] <jelmer> hah
[15:17] <jelmer> pre-MMU! Finally somebody brings something up I remember :)
[15:17] <fullermd> Long time ago.  So long you'd have to chase a far pointer to...
[15:20] <vila> jelmer: \o/
[15:21] <vila> fullermd: FAR pointer ? You *did* code on windows ???
[15:21] <vila> or DOS for this era
[15:21] <fullermd> Oh, no, you had to deal with memory models in DOS too...
[15:22] <jelmer> Turbo C++, good memories :)
[15:22] <fullermd> (though I'm sure there were SOME other platforms that were dumb enough to deal in segmented memory too)
[15:22] <vila> never see any other...
[15:23] <vila> I've dealt with really small processors and memory were you add to switch memory banks to do anything useful, but hey, that's what bare metal is about ;)
[15:28] <jelmer> hah, finally some progress on colocated branches
[15:28] <vila> some *more* progress you mean ? :-D
[15:29] <fullermd> Well, now that we've established at least 16 F keys, we can colocate 4 bits of branches   :p
[15:32] <vila> jam: I can't find a description of bzr.groupcompress.max_bytes_to_index, can you propose one ?
[15:33] <jam> vila: doc/en/release-notes.txt "bzr.groupcompress.max_entries_per_source" it got renamed bytes which is the same value *16
[15:34] <jam> so 'entries_per_source' = 65536 => max_bytes_to_index = 16*65536 = 1M
[15:34] <vila> I meant a definition suitable for help
[15:35] <vila> ha found it in delta.h
[15:48] <gour> is it possible to see in log output whether some revision is gpg-signed?
[15:50] <Riddell> gour: only in the latest versions
[15:50] <gour> Riddell: 2.4:x?
[15:51] <Riddell> gour: yes, since 2.4b5 New option ``--signatures`` for ``bzr log``
[15:51] <gour> Riddell: that's cool and missing in hg
[15:52] <Riddell> go me :)
[15:52] <Riddell> also bazaar kde integration http://blogs.kde.org/node/4467
[15:52] <gour> when is 2.4 scheduled?
[15:52]  * gour is using xfce
[15:53] <vila> 2.4.0 has been frozen, installers and packages are currently built
[15:53] <gour> thumbs up
[15:53] <gour> what would be the best way to mimic hg's 'named branches' concept which i like due to its simplicity? fossil has similar stuff
[16:07] <gour> bummer...py-pyme port required for 2.4b5 fails to build :-/
[17:00] <jonathanj> if i've got an existing branch (with history) but now i want to put that branch into another branch (one that encompasses a bigger project) how do i do that without losing my history?
[20:15] <hikiko> hello! is there a way to change the last commit log?
[20:17] <gour> hikiko: uncommit and re-commit?
[20:20] <hikiko> uncommit does change the code?
[20:22] <gour> hikiko: "Unlike revert, uncommit leaves the content of your working tree exactly as it is. That’s really handy if you make a commit and accidently provide the wrong error message. "
[20:29] <hikiko> thank you :)
=== CardinalFang_ is now known as CardinalFang
=== yofel_ is now known as yofel