[01:05:04] --- cclausen has become available [01:09:50] --- dev-zero@jabber.org has become available [01:09:53] --- dev-zero@jabber.org has left: offline [01:12:14] --- Russ has left: Disconnected [03:26:10] --- cclausen has left [03:52:37] 28 deltas span tags, 1 deltas cross branch points. [04:13:35] --- cclausen has become available [05:27:23] --- Jeffrey Altman has left: Replaced by new connection [06:49:11] > rxk5: linux kernel crytpo.... More newlines, please. Also, the lkml people will claim that a shim which makes GPL_ONLY interfaces available to non-GPL modules somehow violates the license. They _might_ not make that claim about a module that provides 3961 interfaces in terms of GPL_ONLY crypto interfaces. But you'd have to maintain it outside the kernel, because if you can get it accepted into the kernel you run the risk of someone coming along and deciding to redesign the interface from scratch, change what it does, and label the whole thing GPL_ONLY. [06:51:18] --- reuteras has left [06:52:15] IBM's GPFS relies upon such a shim (not for crypto, but for file system operations) [06:58:53] --- Jeffrey Altman has become available [07:52:38] --- dev-zero@jabber.org has become available [07:52:41] --- dev-zero@jabber.org has left: offline [10:38:55] This evenings pet hatred is partially tagged trees - take a bow BP-openafs-rxkad-krb5-lha [11:01:24] --- matt has become available [11:02:20] lkml: GPL_ONLY. What the hey does GPL purity buy you against IPL code? [11:08:10] In general, you don't get to make that argument. [11:09:14] Except in the special case where someone is using GPL_ONLY to mean "in-tree only", in which case you get to argue that GPL_ONLY is neither necessary nor sufficient ro restrict a symbol to use by in-tree code. [11:10:26] I didn't think lkcrypto was gpl only, but I guess it could have or in future become so. I think all the code constituting rxk5 and k5ssl is licenseable as BSD, though we might have not paid attention. That would let us use it in kafs, if that's realistic. [11:10:31] But you don't get to argue that GPL_ONLY doesn't buy anything, because "because I want to" is considered a valid reason for marking something GPL_ONLY. [11:10:56] You also don't get to put BSD code into the kernel. [11:11:16] No, but such code may be relicensed, right? [11:11:26] If it goes into the kernel it becomes GPL, and forks. You can't take changes that are made by Linux kernel folk, and use them in your non-GPL'd project. [11:11:38] Not necessarily. That depends on which license form you used, and whether you own the copyright on it. [11:11:41] Yeah, unhelpful. [11:12:03] The whole thing is unhelpful. [11:12:03] Err, I was replying to "may be relicensed", not to Simon [11:13:00] The issue with the IPL is that it's pretty taint happy. Whether rkx5 is tainted or not would seem to depend on whether you can claim that it's a standalone module or not. [11:13:06] jhutz: right, and there is some institutional copyright, iirc, but the license grant is u of m special 'do as thou wild, an it not harm us' [11:13:30] I suppose we wouldn't be in this mess if IBM had GPL'd the thing. But I don't think I'd want that; over the past decade or so I've become quite dissatisfied with the GPL. [11:14:58] The IPL's standalone-code thing appears to be intended along the same lines as the GPL's "mere aggregation" clause, allowing the OpenAFS distribution to include things like NTP that are really and truly not part of AFS. [11:15:24] I'm pretty sure we can. k5ssl in particular--I think it pre-existed rxk5 altogether, for the most part. and the rxk5 bits know only about interfaces available under nonrestrictive license. [11:15:41] I don't think it would apply to rxk5. OTOH, one _might_ reasonably argue that rxk5 is an extension to Rx, not AFS, and Rx was and continues to be distributed under more liberal license terms than the rest of AFS. [11:16:05] I'm not sure what "k5ssl" is, or how it's relevant to AFS. [11:16:24] But only if it's a derivative work of that version of Rx. I suspect that it's actually a derivative work of the version of Rx that's in OpenAFS, and so would come under the IPL> [11:16:25] it's just the crypto and krb5 stuff that is internal to rxk5 in kernel [11:16:41] it can work standalone in userland too, actually [11:21:45] Oh, right; they actually did change the copyright on the Rx in OpenAFS. [11:22:02] Though actually, that may have been Derrick's and my screwup. [11:23:11] Yeah, it looks that way. Look at the copyright message on rx.c in OpenAFS 1.0 [11:24:23] Hmmm. Yes. That's dull. [11:25:18] Pretty much the first thing we did after importing IBM's 1.0 release was to update copyright and license information, because the license they shipped it under didn't actually allow us to distribute something in the form in which they provided it. [11:26:06] I guess we could take the rx libraries back to that old copyright, if we could get everyone who's contributed since to agree to relicense. [11:26:29] yeah, that would actually be worthwhile, too [11:27:23] That might be useful, but rxk5 couldn't be derivative of all of rx. Rx was a known entity and in particular before openafs existed, and there is a nonrestrictively licensed rx. [11:28:06] My understanding, in the UK at least, that it's a derivative work of _whatever you derived it from_. [11:30:06] Perhaps, but it gets messy when it's really derivative of an interface, and not of the implementation of that interface. [11:30:20] It's mostly derived from knowledge of the rx protocol behavior, and of kerberos 5. It knows rx interfaces. [11:30:53] That's still only a small part of rxk5, though it would be an annoyance to re-implement it, that too could be done. [12:19:23] Okay. So now I've found a pretty much atomic delta (ie, something that even cvsps thinks is a patch set) that has a tag in the middle of it. (for those that care: openafs-stable-1_1_0, and move-readmes-one-level-up-20010716 ) [12:39:59] Yes, it's a known problem that there are cases where someone did two non-consecutive commits with the same delta name [12:40:33] Oh. I know. [12:40:38] that isn't necessarily in and of itself a problem [12:40:46] But that isn't a non-consecutive commit. That's a collision. [12:41:08] Basically, the files get removed one side of the tag, and added in their new location on the other side. [12:41:10] *that* is a problem [12:42:06] I'm just making git history reflect CVS - so that the git tags reflect what the CVS tags say. Teaching cvsps how to split patchsets when tags don't work out is _fun_! [12:43:01] Actually, I should probably define these publicly.... My testing criteria for the git repository is ... [12:43:13] a) That all of the branch tips match [12:43:19] b) That all of the tags match [12:43:42] c) That all of the reconstructed deltas match (within a fuzz threshold) [12:43:53] In that order of importance. Anyone think that's wrong? [12:44:04] that was basically what i was trying to do [12:51:48] --- Russ has become available [13:26:39] What does (b) mean? that if I check out the same tag from both repositories, I get identical files? [13:27:29] For that matter, how are you testing (c)? [13:31:11] i assume yes to b, and for c is probably "best effort" [13:31:50] > for c is probably "best effort" That's not an answer to my question. [13:34:01] well, the answer isn't simple. it depends what order you apply the changesets in. i assume the simple way to test is "does applying the delta from wdelta to the before point of the changeset result in the after point" [13:34:15] but there's no succinct answer to c [13:35:24] The question I was asking is about Simon's methodology. [13:35:33] i'm sure it is. [13:35:38] and i bet you get no better answer [13:36:15] The thing is, if you're going to do it the way you describe, then you might as well start with an empty repository, apply all of the deltas you can get from wdelta, in order, tagging along the way, and then verify (a) and (b) after the fact. [13:37:51] I assume Simon will be able to tell me exactly how he's testing (c), unless he's not doing any such testing yet. [13:39:44] that doesn't work. i already tried that [13:39:47] We already know that applying the wdeltas in order to an empty repository will violate (b), because of the split tags. [13:40:07] it also doesn't work because they don't all apply. [13:40:29] i gave him my hand-massaged tree of "made them apply", and that was only for the head [13:40:55] it's academic since hs's idle [13:53:36] Oh, yes; you'd have to fix split tags first. But that can trivially be discovered from the deltas file. [13:54:02] How can it be that they don't all apply? [13:56:20] very easy. deltas with split commits. [14:07:21] Even split deltas should apply if they don't touch the same file. Ones that do touch the same file will of course have to be handled specially, but that appears to already be the case. In any case, I wasn't actually suggesting that the converstion be handled in that way. Rather, I was suggesting that testing (c) as you describe would be as much work as handling the conversion that way. [14:17:26] split tags have nothing to do with delta ordering [14:18:07] but anyway, yes, fine. we'll see what simon plans [14:40:40] --- cclausen has left [14:53:15] --- dlc has left [15:08:40] --- RedBear has left [15:09:35] --- dwbotsch has become available [15:23:47] Back ... [15:24:23] I'm testing a and b by checking out the same things from git and cvs, and diffing between the two trees. [15:25:29] c) is being tested by taking the delta, and the set of equivalent git commits, and using interdiff plus some glue to compare them. Where they don't match (which is often) they're being flagged for manual inspection. [15:30:29] To be honest, once I've got (a) and (b), I care about (c) less. The original plan of this conversion was that it was going to be fast, easy, and imperfect. If the existing tools give me a tree that satisified (a) and (b) I would have given up on (c) already ... [15:39:32] My experience is that interdiff is pretty fragile, and shadow’s plan for testing (c) might leave you with manual checking afterwards. [15:56:12] What do you mean by 'shadow's plan'? [15:57:57] > i assume the simple way to test is "does applying the delta from > wdelta to the before point of the changeset result in the after point" [15:58:43] Something like `git reset -q before-changeset; git apply --cached < wdelta; git diff --cached after-changeset` would let you do this without having to wait for a checkout of the tree. [15:59:08] Hmmm. Yes. [15:59:47] But actually, I'm beginning to feel more and more that if we want git, we may have to decide to care a lot less about deltas. [15:59:59] Or have a timemachine and a large, gatekeeper-thrashing-stick. [16:00:59] --- shadow@gmail.com/owlEBA7042D has left [16:01:28] * Russ is in favor of the time machine plan. [16:01:42] Although where will we find a dress shop that keeps the same mannikin in the window for 60 years? [16:02:48] Russ is in favor of the plan because he believes he has never made that particular error. I also support it, being not a gatekeeper. [16:04:00] I think we can choose to not care too much about (c), at least for the "weird" deltas that would be fixed by the time-machine plan. [16:05:13] It's not just deltas at present, it's the fact that our tree has some very wierd artifacts in it (I think grand's clock has run backwards upon occasion), which upset all of the cvs->patchset tools that I can find. [16:05:29] * Russ has created weird deltas. Particularly early on when I had no idea what I was doing or how this whole delta thing worked. [16:06:11] But it is now in the realms of an interesting problem. Which probably means I'll work on it to the exclusion of everything else. So if I don't make the workshop, you'll know why! [16:06:39] make the workshop. how else will we get you drunk? [16:06:50] --- abo has left [16:07:15] Well, I'll make the workshop, because that doesn't require much effort at this point. But finished slides, that's another matter entirely :) [16:07:33] --- abo has become available [16:07:44] Part of the difficulty may be that you are pretty much forced to work with tools that use heursitics to determine what is a patchset, rather than simply being given a list of all the patchsets there are. That's kind of unfortunate, since in this case you more or less have such a list [16:08:14] We do, and I can use them too. The problem is that the information in those tools is differently deficient. [16:09:43] If you haven’t seen it yet, the newer version of cvsps maintained at http://repo.or.cz/w/cvsps-yd.git has some patches that could be of interest. [16:10:06] There's also a beta release from the original author that handles branch points better... [16:10:39] And Derrick has a patched version where he taught cvsps about deltas. [16:13:06] Oh interesting, I hadn’t noticed the cvsps 2.2b1 release. [16:13:39] It won't work with anything that parses cvsps output because it gets rid of "Ancestor" and does something else (more correct) entirely. [16:14:50] Indeed. Has anyone patched git-cvsimport for that, or are you doing something else entirely? [16:15:36] I am using git-cvsimport, but I'm driving it with the old format of cvsps output. I haven't (yet) found any issues which are due to branch point positioning. [16:16:34] Okay. I kept having issues with openafs-stable-1_4_9 being on top of openafs-stable-1_4_10, but I didn’t investigate very much. [16:17:04] That sounds more like a tagging issue than a branch point one. [16:17:30] Well, it picked the wrong point to start openafs-stable-1_4_9-branch. [16:17:55] Ah, okay. [16:18:05] And I noticed a similar problem with rxk5-devel-1_5_57. [16:18:10] I haven't got that far into the future in any detail yet :) [16:18:40] This was in the wake of the > to >= change that shadow manually hacked into the CVS history. [16:18:59] Yeh. I suspect that may make me sad when I get there. [16:29:06] > openafs-stable-1_4_9 being on top of openafs-stable-1_4_10, Presumably because openafs-stable-1_4_10 was branched first. [16:30:47] --- shadow@gmail.com/owl52607589 has become available [16:39:38] --- cclausen has become available [16:52:00] --- Rrrrred has left [17:20:13] --- matt has left [18:51:21] --- dwbotsch has left [18:51:44] --- RedBear has become available [18:55:32] --- dwbotsch has become available [22:01:04] --- Jeffrey Altman has left [22:29:58] --- Jeffrey Altman has become available [23:08:06] --- kula has left