| 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:00 |
| 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:06 |
| kwmiebach | spiv, thank you. i think i will do a new local branch, maybe it is possible to specify a revision umber | 00:11 |
| kwmiebach | (I believe "revert" is doing what I want. But how can I proove the outcome?) | 00:12 |
| kwmiebach | spiv, is there also a way to revert to a milestone? | 00:37 |
| bignose | kwmiebach: is the milestone a tag? | 01:26 |
| bignose | (and if not, why not?) | 01:26 |
| 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:27 |
| kwmiebach | bignose, thank you. I am only making local copies of some launchpad repositories. Gonna try to see milestones as tags. | 01:30 |
| 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:31 |
| jimis | kwmiebach: bzr info -v or some other flag possibly? | 01:36 |
| kwmiebach | jimis, witth your help I checked the help for "bzr info" and it said "bzr revno" is what I needed. cool. | 01:39 |
| kwmiebach | the fog is starting to clear now :) | 01:40 |
| 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:44 |
| bignose | kwmiebach: what is a milestone to you? | 01:45 |
| poolie | lifeless, spiv, hi | 01:47 |
| 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:48 |
| 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:52 |
| spiv | kwmiebach: ah, sorry, I forgot to say --overwrite in the 'bzr pull' invocation | 01:54 |
| spiv | kwmiebach: launchpad milestones don't necessarily correspond to any revision | 01:55 |
| 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:56 |
| 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:58 |
| 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? | 01:59 |
| 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:00 |
| spiv | kwmiebach: it might have had uncommitted changes, or unversioned files | 02:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| kwmiebach | is there a windows command line version of bazaar? I am actually using bazaar on cygwin, but I believe it is slow | 02:05 |
| bignose | kwmiebach: there is, and I've used it a few years ago | 02:07 |
| 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 | 02:08 |
| === robbyoconnor is now known as ` | ||
| === ` is now known as r0bby_ | ||
| === r0bby_ is now known as robbyoconnor | ||
| 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:33 |
| thomi | bah - figured it out, was looking at the wrong branch :( | 04:46 |
| jelmer | moinmoin | 06:08 |
| * jelmer heads to a coworkspace, back in 30 min | 06:33 | |
| vila | moin | 06:59 |
| poolie | hi vila | 07:09 |
| vila | hey poolie | 07:10 |
| vila | I see pqm is still going strong :) | 07:26 |
| jelmer | whoa | 07:30 |
| vila | I'm glad we do so many landings :) | 07:33 |
| vila | <cough> | 07:33 |
| 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:35 |
| vila | jelmer: about your unparsed-url mps | 07:36 |
| 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:37 |
| 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:38 |
| vila | I'm not advocating for doing that everywhere either (and may be not *now* either) | 07:39 |
| vila | but we've encountered so many related bugs... | 07:40 |
| jelmer | vila: I wouldn't be opposed to that | 07:40 |
| 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:42 |
| 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:43 |
| vila | yeah, yeah, I certainly don't want to distract you (almost ;) | 07:44 |
| vila | jelmer: oh, and thanks a ton for all the reviews ! | 07:45 |
| jelmer | vila: no problemo, I am after all patch pilot :) | 07:46 |
| 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:52 |
| mthaddon | thx | 07:53 |
| jelmer | vila: is that a blocker for the new PQM? | 07:54 |
| vila | mthaddon: for my own enlightenment, what was the root cause here ? You can really get a chroot without the right users declared ? | 07:55 |
| mthaddon | vila: we copied the chroot wholesale from the existing PQM instance, so the UIDs aren't matching up | 07:56 |
| 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:57 |
| * vila nods | 07:58 | |
| poolie | hi vila, would you like to talk? | 08:25 |
| vila | poolie: sure | 08:26 |
| vila | ! | 08:26 |
| lifeless | vila: so the failing test didn't output its exception ? | 08:26 |
| 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:27 |
| vila | poolie: wfm | 08:28 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| lifeless | vila: or run with -1 | 08:37 |
| vila | lifeless: hmm, running with -1 was abandoned when subunit were used ;) | 08:37 |
| 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:38 |
| 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:39 |
| 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 ;) | 08:40 |
| 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:09 |
| jelmer | ccxCZ: hi | 09:21 |
| 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:22 |
| jelmer | ccxCZ: It should be possible to do that outside of PQM with just a script that watches the branch | 09:24 |
| 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:29 |
| jelmer | ccxCZ: pqm can only really handle merge commands, potentially requiring a testsuite to pass before accepting a merge command | 09:30 |
| ccxCZ | okay, seemed to me that way. But what I described shouldn't be that hard to build, right? | 09:31 |
| ccxCZ | anyway I kinda miss some documentation on how to handle bzr-send messages | 09:33 |
| 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:35 |
| 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:37 |
| ccxCZ | how do I do that? I point it at mbox file instead of uri? | 09:39 |
| jelmer | ccxCZ: "bzr send" attaches a file that you can point it at | 09:40 |
| ccxCZ | I need to exctract the mime part then, right? | 09:41 |
| jelmer | yep | 09:41 |
| ccxCZ | hmm, maybe I'll try to involve buildbot then | 09:46 |
| 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:49 |
| jelmer | ccxCZ: writing what? | 09:52 |
| ccxCZ | nvm for now | 10:00 |
| poolie | hi jelmer, can you have a go at the review queue today? | 10:01 |
| 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:03 |
| jelmer | nevermind, maybe I should switch back to ~bzr/+activereviews, ~bazaar+activereviews is too noisy | 10:04 |
| === medberry is now known as med_out | ||
| thumper | can bzr have a global ignore list? | 10:19 |
| jelmer | thumper, ~/.bazaar/ignore IIRC | 10:20 |
| thumper | jelmer: ta | 10:20 |
| Riddell | wow, PQM is slow | 10:28 |
| vila | Riddell: hehe, welcome to the club :) | 10:34 |
| 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:35 |
| vila | Riddell: in other words: *now* is not the time to use pqm to check that the whole test suite pass ;) | 10:36 |
| vila | Riddell: I may have an offer you can't resist to though... | 10:37 |
| 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:38 |
| 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:39 |
| vila | not fully guaranteed as I've seen cases where pqm were raising different failures, but pretty rare these days | 10:40 |
| 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:41 |
| 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:42 |
| Riddell | logged in | 10:43 |
| vila | Riddell: meet babune: http://babune.ladeuil.net:24842/ | 10:44 |
| vila | babune: meet Riddell | 10:44 |
| === vila is now known as babune | ||
| 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:45 |
| babune | Riddell: you're now part of the testers group | 10:46 |
| 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:47 |
| Riddell | it does | 10:49 |
| babune | Riddell: oh, you run the chroot-natty one ? | 10:49 |
| 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:50 |
| 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 | 10:51 |
| === babune is now known as vila | ||
| vila | What a lovely bot... | 10:52 |
| Riddell | how do I specify a different branch? | 10:53 |
| vila | 3 min 23 sec, eat that pqm ! | 10:53 |
| 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:54 |
| Riddell | ah hah | 10:55 |
| Riddell | lovely | 10:55 |
| vila | jelmer: bad target for your generate-revhistory proposal I suspect | 10:58 |
| vila | Riddell: in other news, your submission just started on pqm ;) | 11:00 |
| Riddell | --MARK-- | 11:01 |
| vila | :) | 11:01 |
| === Mkaysi_ is now known as Mkaysi | ||
| jelmer | vila: any chance you can submit my fix for 2.4 to lp:bzr/2.4 ? | 13:57 |
| vila | jelmer: sure thing | 13:58 |
| fullermd | Aw, man, you want vila to make pqm work _harder_?? | 13:58 |
| vila | work pqm work ! | 13:59 |
| fullermd | Slavedriver :( | 13:59 |
| 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:00 |
| 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:04 |
| jelmer | muhahaha >-) | 14:06 |
| vila | hehe | 14:06 |
| jelmer | (that was actually unintentional...) | 14:06 |
| vila | yeah, they all say that... | 14:08 |
| vila | jelmer: in fact, I'm more interested in merge 2.4 => trunk right now for babune's sake, so all is fine | 14:09 |
| vila | since that means your equality_funcs.clear workaround should turn oneiric blue, finally | 14:11 |
| 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:22 |
| mgz | it doesn't serve much purpose without the main chunk which has yet to land | 14:23 |
| jelmer | I hadn't counted on that either | 14:25 |
| jelmer | Perhaps we should've checked with doko | 14:25 |
| 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:26 |
| 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:32 |
| vila | bzr root ? | 14:36 |
| 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:37 |
| Riddell | mm, actually bzr root might be just what I wanted | 14:38 |
| bignose | Riddell: branch_root=$(bzr root) ; echo ${PWD#${branch_root}/} | 14:39 |
| 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:40 |
| 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:41 |
| fullermd | Doesn't work too well without bash either ;p | 14:42 |
| * bignose ignores systems without Bash :-) | 14:42 | |
| bignose | I'd be happy seeing a 'bzr relative-path [filename]' that does what Riddell is asking | 14:43 |
| 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:44 |
| vila | Well 'Show the tree root directory' doesn't specify if the path is absolute or relative | 14:45 |
| === micahg_ is now known as micahg | ||
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| vila | fullermd: I know ;) | 14:54 |
| vila | but test scripts can be run repeatedly without removing the tmp test dir... | 14:55 |
| 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 | 14:56 |
| vila | nope, M-p | 15:00 |
| vila | And F- doesn't exist, you just made it up ;-P | 15:01 |
| fullermd | What, you don't have Function keys? | 15:03 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| vila | so volumes and eject should be probably be configurable giving f1->f19, you lose ! | 15:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| vila | jelmer: \o/ | 15:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| jelmer | hah, finally some progress on colocated branches | 15:28 |
| vila | some *more* progress you mean ? :-D | 15:28 |
| fullermd | Well, now that we've established at least 16 F keys, we can colocate 4 bits of branches :p | 15:29 |
| vila | jam: I can't find a description of bzr.groupcompress.max_bytes_to_index, can you propose one ? | 15:32 |
| jam | vila: doc/en/release-notes.txt "bzr.groupcompress.max_entries_per_source" it got renamed bytes which is the same value *16 | 15:33 |
| jam | so 'entries_per_source' = 65536 => max_bytes_to_index = 16*65536 = 1M | 15:34 |
| vila | I meant a definition suitable for help | 15:34 |
| vila | ha found it in delta.h | 15:35 |
| gour | is it possible to see in log output whether some revision is gpg-signed? | 15:48 |
| Riddell | gour: only in the latest versions | 15:50 |
| gour | Riddell: 2.4:x? | 15:50 |
| Riddell | gour: yes, since 2.4b5 New option ``--signatures`` for ``bzr log`` | 15:51 |
| gour | Riddell: that's cool and missing in hg | 15:51 |
| 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:52 | |
| 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 | 15:53 |
| gour | bummer...py-pyme port required for 2.4b5 fails to build :-/ | 16:07 |
| 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? | 17:00 |
| hikiko | hello! is there a way to change the last commit log? | 20:15 |
| gour | hikiko: uncommit and re-commit? | 20:17 |
| hikiko | uncommit does change the code? | 20:20 |
| 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:22 |
| hikiko | thank you :) | 20:29 |
| === CardinalFang_ is now known as CardinalFang | ||
| === yofel_ is now known as yofel | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!