[02:01:25] I think it's 100% certain that there will need to be further 1.4 releases , not least to address forthcoming operating system releases. [02:02:26] We also haven't even started talking about 1.6 features yet - I'd like to see us significantly pare down the number of --enable options before we ship 1.6.0 - the starrt of a series is really the only chance to do so. [02:03:02] If we're serious about 1.6.0 soon, we should probably also cut a branch for fit, and stop taking feature changes on that branch, so we've at least got a chance of stabilising the code. [05:01:50] --- Russ has become available [05:03:02] Yeah, there are at least four or five --enable options that we could just make unconditional, and I've been holding off submitting patches for that since I wasn't sure if we wanted to cut 1.6 before making those changes. [05:03:33] I also wonder if we can strip fast-restart and bitmap-later out. [05:05:04] Yeah, if we're shipping demand-attach, those seem pretty pointless. [05:06:31] I'd like to see us do that work before cutting the 1.6 branch, as otherwise we commit ourselves to another 3 years of feature #ifdef madness. [05:07:37] --- abo has left [05:07:38] --- stevenjenkins has left [05:07:55] --- abo has become available [05:11:17] --- stevenjenkins has become available [05:16:00] * Russ would make --enable-supergroups and --enable-bos-new-config always on, remove --disable-afsdb, remove fast-restart and bitmap-later as mentioned, make --enable-unix-sockets always on, and remove --disable-full-vos-listvol-switch. [05:16:22] And can't we, while we're at it, get rid of --enable-bigendian and --enable-littleendian? Those seem rather silly. [05:18:22] I'd like to see --enable-bos-restricted go away in favour of being a per-server runtime option. [05:18:32] Yeah, that would be good too. [05:19:29] And namei fileservers be the default on all platforms (so there's --disable-namei-fileserver for those on Solaris with old UFS) [05:26:17] So, --enable-supergroups changes the semantics of the PRDB, if not its format. If the change is backward-compatible, we can make the option just go away. If the change is _not_ backward-compatible, then I think we need to at least offer a runtime option and a reverse-converstion tool. I don't care what the default is for the runtime option, except that it can't be "on" unless forward-conversion is fully automatic. [05:27:18] > namei fileservers be the default on all platforms I guess I can't argue with this, but I want to. [05:28:11] With supergroups, I believe that the situation is that the prdb is compatible until the first supergroup is created. [05:29:04] --- Russ has left: Replaced by new connection [05:29:04] --- Russ has become available [05:30:58] That's correct. [05:31:04] We don't have a reverse conversion tool, though. [05:33:19] --- Jeffrey Altman has left: Replaced by new connection [05:38:07] In which case, there really ought to be a runtime option, so that operators can upgrade to the new version and be confident that some user won't make a change that makes it impossible to downgrade if something goes wrong. [05:40:02] Yeah, supergroups is the most aggressive of those proposals. [05:48:01] Yes, but I agree turning it on by default and getting rid of the configure option is probably the right thing to do. [05:58:13] Simon, did you not need to cast tv_usec? [05:58:28] My man page says that it is also a long. [05:58:48] Or a suseconds_t in POSIX. [06:02:15] Yeah. [06:02:18] xstat_fs_test.c: In function ‘PrintOpTiming’: xstat_fs_test.c:296: warning: format ‘%06d’ expects type ‘int’, but argument 6 has type ‘__suseconds_t’ [06:02:20] * Russ will comment. [06:10:51] Jeff, I'd rather fix Adam's patch for Windows and submit a new version based on your comments and then approve that so that the atomic change does the right thing from the start, I think. [06:10:56] I can do that now. [06:19:27] --- Jeffrey Altman has become available [06:26:03] src/afs/afs_volume.c:afs_GetVolume() appears to be buggy. Particularly... tv = afs_FindVolume(afid, locktype); if (!tv) { if (afs_IsDynrootFid(afid)) { tv = afs_NewDynrootVolume(afid); } else { bp = afs_cv2string(&tbuf[CVBS], afid->Fid.Volume); tv = afs_NewVolumeByName(bp, afid->Cell, 0, areq, locktype); } } [06:27:33] So, if afid is in the dynamic root volume, but is not the root of that volume, and the call to afs_FindVolume fails, then we will incorrectly call afs_NewVolumeByName("1", afs_dynrootCell, ...) [06:31:56] Hm, it looks like afspag.ko is just disabled all the time for Linux. Am I reading the code wrong? [06:32:17] We seem to be unconditionally defining AFS_NONFSTRANS in all the linux* param files. [06:32:17] I'm not sure what you mean by "disabled all the time" [06:33:25] I'm reviewing 176, and it doesn't suppress the build for me. So I assumed that I was one of the cases mentioned where it's disabled in param.h. [06:33:39] So I went and looked at param.h, and it looks like it's *always* disabled in param.h for all Linux. [06:33:46] So I'm now confused. [06:35:09] I haven't looked at the patch, but I think you're confused. IIRC, NONFSTRANS has to do with the Solaris NFS translator, where we have code that replaces large chunks of the NFS server and produces dependencies on the nfssrv kernel module. I don't think it has anything to do with Linux. And in any case, afspag.ko is not part of the NFS translator. [06:36:15] Take a look at http://gerrit.openafs.org/#change,176 if you have a chance. [06:36:31] That's probaby faster than me trying to explain the situation. [06:36:48] This patch sounds misguided. afspag.ko is intended to be loaded on NFS _clients_; it doesn't need the kernel features that we currently can't have. [06:37:22] We're trying, as I understand it, to address the problem that it currently produces warnings on every build. Maybe we should be going some other direction? [06:38:18] Oh, but apparently someone who didn't actually understand what was going on put #ifndef AFS_NONFSTRANS around all of osi_pag_module.c. Grrr. [06:38:29] Ah, okay, that explains it. [06:38:46] Okay, then it sounds like 176 is wrong, and the real fix is something else. [06:38:57] Yes. We should be going in the direction of FIXING THE WARNINGS instead of just not compiling the code because someone didn't understand what it did and submitted a patch to fear what they didn't understand. [06:39:51] Well, I was leaning towards committing it because I'd thought you said yesterday that it sounded reasonable to you, but I think we all misunderstood each other. :) [06:40:23] Yes. For starters, remove this from src/afs/LINUX/osi_pag_module.c: > #if !defined(AFS_NONFSTRANS) || defined(AFS_AIX_IAUTH_ENV) That's just stupid. The code in question isn't part of the NFS translator, and so shouldn't be conditionalized on AFS_NONFSTRANS, and is in a file that is never compiled on AIX, and so shouldn't be conditionalized on anything AIX-specific [06:40:57] --- abo has left [06:41:00] I'm pretty sure I did not comment on it yesterday. [06:41:26] --- abo has become available [06:41:47] My guess is that then something will fail to compile, but I don't know offhand what. [06:43:07] I think I did comment on the warnings, and suggest that the solution was _not_ to not build the code. My guess is going to be that since the NFS translator code was committed, something evolved in the main module to deal with some change in Linux, and the corresponding change wasn't made in afspag [06:44:20] Ah, I see, yes, you didn't comment and I confused two threads going on at the same time since Jabber has no threads. [06:44:47] Okay, let me try enabling it as you describe above and then see what happens. [06:45:07] Should the AIX conditional stay? [06:45:51] Actually mdionne correctly described the problem on jabber yesterday. If you build afspag.ko, you'll get undefined symbols because code that is common between libafs and afspag depends on things like afs_global_lock, which in afspag is defined in afs_pag_module.c, which is (incorrectly) protected by the conditional I just quoted. [06:46:06] I see no reason for an AIX conditional in a file in src/afs/LINUX [06:46:31] Oh, yeah, good point. [06:46:46] Useful only for that case of running an AIX Linux kernel. :) [06:47:06] His analysis is correct; I just think is solution is wrong. But I'm pretty sure I didn't comment on it then. [06:47:19] Don't give IBM any ideas. [06:54:02] So, I think my problem yesterday was approximately this... After the machine boots, the first major use of AFS is to run depot to pick up any updates since it was cloned. This involves looking at a fairly large number of volumes, all via RO paths below /afs/cs.cmu.edu/. Since the vnodes for /afs and /afs/cs.cmu.edu are stat'd, there is no reference to the dynamic root volume, and it eventually gets pushed out of the volcache. But, there are repeated references to the /afs vnode, so it stays in the vcache. After the depot run completes, the next step is to create user accounts. This involves reading /afs/.cs.cmu.edu/service/etc/autoacct, which is accessed via an RW path to avoid getting an out-of-date copy of the file, which may be edited by someone who doesn't release the volume. So, /afs is in the vcache, and the directory lookup succeeds, but the mount point /afs/.cs.cmu.edu has never been accessed and so is not in the vcache. Fixing that requires that the volume be in the volcache, so we end up calling afs_GetVolume, which does the wrong thing because it's the dynroot volume but not the root of that volume. [06:59:11] When I remove that #ifdef, everything just compiles. [06:59:17] So now I go to figure out why it was added. [07:01:42] ifdef-nfs-translator-20070102, RT 50602 [07:03:14] Because it was hit with a large hammer. [07:03:16] Looks like that change was just too aggressive. jhutz, if you have a moment, could you look at the patch in that ticket? I think the change is correct except for osi_pag_module, but I don't know the code. [07:03:24] That hunk was just wrong. [07:03:42] The other hunks all appear to be NFS translator related, correctly. [07:04:00] yeah [07:04:29] Okay, I'll push this change to Gerrit for further review by others. [07:06:07] Change 179. [07:07:43] --- deason has become available [07:08:07] Oh, cute. My bug was already fixed, but never backported. [07:14:53] Worse, apparently _I_ found and fixed it while working on the NFS translator code, and it got incorporated as part of that patch, but of course the NFS code never made it to 1.4, so neither did this. [07:15:10] * Russ hehs. [07:15:22] Well, I guess I will try to put together a backport for 1.4.x. Is gerrit open for that yet? [07:15:40] I think so, although Simon would be canonical on that. But we pushed a few changes through it. [07:15:54] We have a bunch of pullups that we should do and haven't yet. [07:23:45] --- shadow@gmail.com/owl34D4DBE0 has become available [07:24:34] --- mmeffie has become available [07:25:47] OK; I have a fix, now to compile and test [07:33:23] Argh. How do I get git to show me differences between the head of a branch and its branch point? Or alternately, how do I get to to show me the diff for a particular commit? [07:34:35] git diff (sha1), i think [07:34:39] `git diff BRANCH $(git merge-base BRANCH origin/master)` `git show COMMIT` [07:35:11] the diff for a specific commit you could do with just 'git diff COMMIT^ COMMIT' [07:35:31] git diff COMMIT{^,} is something I type a lot. [07:36:00] Then you'll be happy to note that `git show COMMIT` involves a lot less punctuation. :-) [07:36:21] Yeah, OK; I just found docs for how ^ works. [07:37:48] --- stevenjenkins has left [07:38:17] Ah, yes. I didn't know about git show. [07:38:31] I think I found that in the wiki from Simon's docs and then forgot it again. [07:39:57] --- abo has left [07:40:46] --- abo has become available [07:40:58] --- stevenjenkins has become available [07:47:28] was openafs-stable-1_4_11 never tagged? [07:48:20] Not in Git, it would seem. [07:51:27] Also it’s still doing the Reviewed-on: http://gerrit.openafs.org/http://gerrit.openafs.org/178 thing. [07:52:07] --- deason has left [07:53:01] --- deason has become available [07:54:48] OK; the only changes in CVS are bumping the version number and chaning the RPM specfile to refer to a newer upstream CellServDB [07:56:05] The Reviewed-on thing is a bug and will have to wait until we have a Gerrit upgrade unless Simon backports the fix. [08:01:13] Relocating... [08:17:28] --- reuteras has left [08:45:25] > was openafs-stable-1_4_11 never tagged? given that i used the tarball generator against that tag... [08:47:01] I still don't see the tag for it, and I just pulled and fetched tags. Did you push the tag? [08:48:09] It's ragged in CVS, where 1.4.11 was actually prepared. That tag doesn't seem to have made it into git [08:50:55] the tag isn't pushed yet [08:52:27] how do I tell git.openafs.org to show me a branch other than master? [08:55:08] Go to the summary screen, scroll down to the branches, and click on the branch. [08:56:12] thank you [08:57:38] gitweb is really, really slow on git.openafs.org. [08:57:46] I wonder if running git gc in the repository would fix that. [08:57:59] I wonder if that would do anything weird. [08:58:01] Does its repo have all the deltas? [08:58:04] It may just be the delta refs. [08:58:10] Yeah, since it's the canonical repo. [08:58:34] Maybe it would be worthwhile to run gitweb against a repo copy that doesn't have the deltas? [08:58:48] Well, a clone, I suppose. [08:58:51] Automatically propagating everything to that separate repo is kind of annoying. [08:59:15] Also, it's nice to see the delta names in the gitweb display if we're going to have deltas. [08:59:36] (I'm not sure deltas are really buying anything for us with Git, but I'm also not going to argue for removing them.) [08:59:38] That's true, but mostly we get them anyway because they're the summary line [08:59:46] Only for imported commits. [08:59:48] Not for anything new. [08:59:53] Oh, hm. [09:00:19] What deltas buy us is a canonical human-readable name for each commit [09:00:35] Yeah. [09:00:43] I think that's pretty valuable [09:00:45] This is just the only project that has that and the other stuff I work on doesn't seem to be missing it. [09:01:11] I can definitely see it when that was the *only* name for the commit, but now the only difference is whether it's human-readable, which is less exciting to me personally. [09:01:13] Yes, and the rest of the world doesn't seem to miss instances in IM systems, either. That doesn't mean they're not valuable [09:03:05] But I think the two useful operations are mapping a commit you're looking at to a delta name, and mapping a delta name to the corresponding commit. The former can be achieved by including the name in the commit message, and the latter by using the existing refs. Neither really requires the delta refs to be present in the repositories used by gitweb or gerrit or random developers. [09:04:15] Putting the delta name in the commit either requires that the submitter assign delta names or that we hack Gerrit to understand delta names itself, which is why I believe Simon went the way he did. [09:06:00] I think it would be useful if the gatekeeper pushing a change from gerrit to the real repository had the ability to add additional comments to the commit log. [09:08:05] I don't disagree, but Gerrit currently doesn't have that capability. We'd have to commit --amend and repush each commit before cherry-picking it right now. [09:08:25] The best way to implement that would be to hack it into Gerrit so that it added it like the reviewed-by lines. [09:08:34] But that means custom patches to Gerrit or convincing upstream to take it. [09:16:53] --- cg2v has become available [09:16:53] Sorry been in a meeting all afternoon. Will catchup, then respond ... [09:19:00] On the gerrit front. The only suggestions for new gerrit functionality that I'm interested in are ones that come with an implementation. Otherwise, sorry. [09:19:49] Git is open for 1.4. I had tagged 1.4.11, too, but I guess it didn't get pushed along with the commits for some reason. [09:20:48] Russ: Re tv_usec - I don't need to do so for Darwin, but happy to add that if it makes things easier elsewhere. [09:21:17] Simon, right now, no one is suggesting that you implement anything for gerrit. You've done more than your share of the work already. But I think it's worth discussing possibilities. [09:22:01] Oh, it's definitely worth discussing possibilities. As long as people realise that making them happen require a set of skills that nobody in this community posses at present, to the best of my knowledge. [09:22:40] The advantage of cherry picking changes at submission (rather than merging) is that potentially the whole commit log can be amended - but there's no UI to support that at present. [09:23:18] --- cg2v has left [09:25:32] --- cclausen has become available [09:26:18] Simon: Yeah, casting tv_usec will also fix a bunch of warnings on Linux. I added a review comment. Sorry about not catching that the first time. [09:28:21] I'll respin that fix. [09:28:31] 1.4.11 should now be tagged, too. [09:28:45] Need to find a way of pushing tags that doesn't require manual repository hackery ... [09:30:33] Why? Is there more than one affected tag? Can't someone with bits just apply that tag to the appropriate commit and be done? [09:30:52] Oh, in fact, apparently you did [09:34:12] I think the problem is that we're currently using 'plain' tags which gerrit doesn't seem to handle receiving. I think if we start using annotated tags (which gives us the option of PGP signing tags), then they can be pushed through gerrit. [09:34:50] ... and then we just need to make sure that nobody tags a branch, or a tree with merge commits, or ... [09:35:54] Well, deleting tags is trivial. [09:36:25] Git is much happier to make tags come and go than CVS was. [09:36:32] They're just labels on SHA1s. [09:36:39] (Simon knows this, I know.) [09:36:41] It's only trivial as long as nobody has cloned your tree in the meantime. [09:36:57] Hm, when I've retagged Git trees, git pull just copes and moves the tag. [09:37:34] git-tag(1) has things to say about people who retag public git trees :) [09:38:39] (as well as suggesting that a pull won't move an existing tag. Hmmm) [09:39:49] --- abo has left [09:40:01] * Russ thinks there isn't much reason for Git to be anal about tags, since they're not encoded anywhere in the tree and they're really just arbitrary labels. [09:40:07] I wonder how hard it would be to make the deltas application notice the cherry-picked from line on the commit, and work out what the delta should be called from that. More importantly, I wonder how tricky getting the UI to do so to work. [09:40:09] I have a hard time imagining any problems that could be caused by a moving tag. [09:40:14] --- abo has become available [09:40:42] I think the main problem is if you pull 'openafs-1.4.11', and then I move the tag so everyone else gets a different openafs-1.4.11 [09:41:18] True, but that's not really a technical problem, since you got a different SHA1 and one can tell the trees are different. It can be a social problem, but that depends on your social interaction around the tag. [09:41:45] Indeed. And I'd really like to see us use signed tags, anyway. [09:42:02] Agreed. I sign all the release tags in my personal repositories. [09:42:14] I don't sign all tags only since some of them are automatically generated by git-import-orig. [09:42:32] Yeh. I'm definitely not suggesting signing the delta references. Just release tags. [09:43:16] Their opinion seems to be that if I pull 'openafs-1.4.11', it's Bad(tm) for you to be able to change it by changing the meaning of that tag in the repository I'm pulling from. I argue this is only a problem if I cannot tell the difference between tags from different sources (including those I added locally) and if one source can update tags from another. Otherwise, well, if I have a tag "openafs-1.4.11 from foo", and foo wants to change the meaning of openafs-1.4.11, then my copy _should_ change on the next pull from foo [09:43:55] Signed tags seem like a good idea; that's morally equivalent to signing the release tarball [09:44:30] --- stevenjenkins has left [09:45:16] With pulled up deltas, I assume that the date portion should match that of the original delta? [09:46:31] gerrit.openafs.org seems to have a sucky sshd that only supports CBC-mode ciphers. Can it be reconfigured? [09:46:43] It's the one built into Gerrit. [09:46:47] I suspect it's written in Java. [09:46:51] It's Mina sshd [09:47:21] And we're already giving it the Bouncy Castle crypto provider, which has a better algorithm set than the default JRE crypto. [09:48:17] --- stevenjenkins has become available [09:48:34] --- deason has left [09:49:30] But not so good as to not be vulnerable to a problem that's been known for at least 6 months. Well, I guess in this case I can safely make an exception. But I don't have to like it. [09:49:31] --- deason has become available [09:49:58] I really don't think that the crypto security of our git pushes is the vulnerability in that system. [09:52:27] Well, given that no passwords are sent, that none of the data involved is actually secret, and that the process doesn't actually depend on ssh's integrity protection, yes. [09:53:11] --- haba has left [09:53:50] --- haba has become available [09:55:35] --- deason has left [09:55:56] OK, the afs_GetVolume fix builds and works; it is #180 [09:56:27] --- deason has become available [10:00:01] At some point I'm going to get bored of tracking Shawn's gerrit releases. But given you have to step through each release's schema changes, skipping more than a couple will be a real pain. [10:01:30] annotated tags? [10:01:51] sorry, i'm behind, i had to deal with (my last) kernel panic, because i restarted with a stale afs in place [10:02:04] You mean, you didn't take your own fix? [10:03:21] annotated tags: In particular, I'm talking about tagging releases using git tag -s. Which makes the tag an object in the git repository (rather than just a label), and signs that object with the GPG key of the person making the tag. [10:04:29] > With pulled up deltas, I assume that the date portion should match that's been true in the past [10:05:27] What I'm going to do, is I'm going to get delta/edit to identify pullups, so you don't have to type all of the information in again. Just select the delta you want to tag, leave the rest blank, and it will figure out the name and date from the referenced parent. Or that's the plan. [10:05:35] Oh, cool. [10:05:37] Yes. The date portion is part of the name. [10:06:57] excellent [10:07:13] We've done things in the past that parsed it as a date, including wdelta, but the real purpose is to disambiguate so you don't have to remember or notice that the delta name deal-with-linux-suckage has already been used. [10:07:35] Sorry; I find it difficult to get excited about gatekeeper tools. :-) [10:07:37] or if it's a logical followon you can reuse the name but with a new date [10:08:08] yeah, which is better than reusing the name with the same date :-) [10:08:36] It's now treated as a real date. If you don't specify it when you create the tag, it's auto filled with the commit date of the corresponding change. [10:08:49] Oh, BTW, I called 180 make-getvolume-work-on-non-root-dynroot I suppose there ought to be a convention for proposing delta names [10:08:57] If you reuse the name with the same data, things go boom. [10:09:19] > If you don't specify it when you create the tag Yeah, that sounds like the right behavior [10:09:45] Where did you call it that? [10:09:51] locally [10:10:03] Ah. Right. We don't get to see that at all. [10:10:10] It's the name of my branch, and of the patch file I applied to our 1.4.10-2, and so on [10:10:34] Right, but it would be convenient for me if the official delta name ended up being the same as the one I used, which is why I mentioned it. [10:11:13] 4913817b9a26f5d8c219b3afd9144d4069eb529c doesn't cut it for you then? (Not that it will be called that when it hits the tree, either) [10:11:26] from -c sipb: The Git developers want to hear how people are using the software. http://git.or.cz/gitwiki/GitSurvey2009 [10:11:29] uh, no :-) [10:11:56] don't tell them we're using it. [10:12:12] They'll just start making changes to make our life miserable. [10:12:18] I think that cat's already out of the bag .. [10:12:20] why would they? [10:12:23] they like us [10:12:28] --- deason has left [10:12:33] --- deason has become available [10:12:46] --- abo has left [10:12:48] --- stevenjenkins has left [10:12:54] I should write something for the repo list about our gerrit use. I think we're the first big, non-Android, user of gerrit. [10:12:55] The gerrit developers like us [10:13:00] Shawn is both. [10:13:15] but linux clearly hates us [10:13:17] --- abo has become available [10:13:24] And if we can help them with Git-on-Windows, I think we'll acquire a lot of new friends very quickly. [10:13:54] Actually, I don't think Linux hates us. I just think we're caught in the cross-fire between them and binary kernel modules. [10:14:22] They do hate our code. And having been looking at the performance graphs for the Linux CM, I can't say I blame them. [10:14:28] yes, we lose because of the video card makers, and because we wanted a system call. a few extremists hate us. [10:14:45] Well, and the OSS 4 people and a few others. [10:14:56] It's not just the video card people who have caused lots of problems with out-of-tree modules. [10:15:10] Unfortunately, every time we turn around, those extremists do something to break things for us, even when what they break is something that video card vendors would never use, like being able to export a filesystem. [10:15:18] I seem to recall problems with some of the open source network driver maintainers as well. [10:15:54] The open-source network driver maintainers at least used to be in the same boat as us -- they were trying to maintain cross-platform software. Theirs just wasn't as big as ours. [10:15:54] We're in the situation now where the standard for a new interface is that it is GPL-only. It's only nice people like David who still do all of their stuff non-GPL. [10:15:59] --- stevenjenkins has become available [10:16:23] And things do get fixed. d_alloc_anon's replacement is available, for example, after folk complained. [10:16:35] I suspect David only does that because he knows it's a problem for us and is sympathetic to us. [10:16:55] I bet there are a lot of developers who don't know it's a problem, and a lot more who don't care. [10:17:05] That's probably true. [10:17:23] well, he's probably more sympathetic to us than when we first crossed paths, but he understands now that we are not his enemy nor he ours. [10:18:04] > we are not his enemy nor he ours. That is a recent development. [10:18:30] no more recent than three years ago [10:18:32] not really [10:18:43] --- deason has left [10:18:54] when i had the morgan-brokered concall with him i think he realized that was true. [10:19:02] --- deason has become available [10:19:16] "rx is only hard because you didn't ask. here's the free one. want it?" [10:19:20] --- abo has left [10:19:23] which he then forgot anyway [10:19:33] --- haba has left [10:19:35] Or looked at the code, and ran screaming. [10:20:04] --- abo has become available [10:20:31] --- haba has become available [10:20:43] The RX code has definitely been written by someone with an allergy to functions, or it was some mad crazy challenge - "How can we write an RPC layer using as few functions as possible" [10:21:46] he believed, istr from the call, that reusing was license-verboten [10:22:08] Reusing IPL'd code in Linnux would have been. [10:22:15] RX isn't IPLd. [10:22:18] The OpenAFS code in general is crazy fond of giant functions. [10:23:03] IIRC, that was always a little unclear. Free Rx was a one-time release, and what was in the initial OpenAFS dump was newer than that. [10:23:05] --- stevenjenkins has left [10:23:07] Yeh. I would have believed the stack size argument, but then you look at the amount of large buffers that get allocated slap bang on the stack. Maybe someones '}' key just didn't work too well. [10:23:38] Well, in those days some keyboards didn't have all the characters :-) [10:25:19] --- deason has left [10:25:31] --- stevenjenkins has become available [10:26:06] --- abo has left [10:26:10] --- deason has become available [10:26:33] --- abo has become available [10:26:33] --- haba has left [10:27:25] --- haba has become available [10:38:24] I suspect whoever just tagged the 3 1.4.x stable deltas that were pullups from HEAD has used the wrong date... [10:40:13] i didn't explicitly set a date [10:40:18] (it was me) [10:40:23] oh. duh [10:40:33] Yeh. The magic isn't there yet, so they've all got yesterdays date (the commit date) [10:40:59] I'll remove the tags, and use them as a test case for the forthcoming magic. [10:41:03] ok [10:48:42] Russ: any chance you could give me su access to www-data on o.s.e ? I need to do some delta pruning. [10:49:53] Or, actually chgrp git /srv/git/openafs.git/refs/deltas/{openafs-stable-1_4_x,master} [10:55:32] Ah, yes, I see. [10:56:24] chgrp done and also added the sticky bit to group ownership there. [10:56:40] Thanks. [11:01:53] --- matt has become available [11:08:18] anyone available who can cross check gerrit rsa auth failure? [11:08:47] uh. define? [11:09:35] Yeah, instead of being cryptic, just ask your question. [11:09:49] git push fails with "Permission denied (publickey)"--2 hosts only. [11:11:17] give full git push command line? [11:11:22] i bet it's port 29418 versus 22 [11:11:39] Also would like to know if it's a problem to add more than 1 rsa key, though I don't think that's involved here. [11:11:46] 1. [11:11:49] git push ssh://gerrit.openafs.org/openafs.git HEAD:refs/for/master [11:11:51] 2. [11:12:04] cat ~/.ssh/config Host gerrit.openafs.org IdentityFile /root/work/matt/.ssh/id_rsa Port 29418 [11:12:46] --- haba has left [11:13:02] --- stevenjenkins has left [11:13:03] It's not a problem to add multiple keys [11:13:04] --- abo has left [11:13:07] --- haba has become available [11:13:08] simon: cool [11:13:17] Try ssh -p 29418 gerrit.openafs.org [11:13:19] ok [11:13:36] --- abo has become available [11:13:37] And check that the username you're using to connect matches the one that Gerrit knows you by. [11:13:41] denied [11:13:56] In particular, if you change your preferred email address, then your gerrit username will change. [11:14:04] i just use e.g. git push ssh://shadow@gerrit.openafs.org:29418/openafs.git (whatever):refs/for/master [11:14:06] and that works [11:14:08] The username must be it. [11:14:39] Go to http://gerrit.openafs.org/#settings,ssh-keys and check what's listed for 'SSH Username' at the top of that page [11:14:52] that's it--thanks guys [11:14:56] Cool. [11:15:28] speaking of git, I should be setting up a topic branch for gsoc, right? [11:16:17] Manage your tree however you like. I'd strongly discourage developing directly on master. Whether you have one, or many, topic branches is up to you. [11:16:19] --- stevenjenkins has become available [11:17:31] But you should not spend all summer doing development and then push one giant patch. "One change per patch; one patch per change". [11:18:00] jhutz, I know, that's why I'm trying to get this setup, so I can start pushing changes when they're ready [11:18:04] Yeh, but you could do that with many commits along a single topic branch. [11:18:11] and then push them all [11:18:49] But getting a change a day is much easier to handle than complete silence followed by 100 all at once. [11:19:09] commit changes my local copy, push "pushes" back to the repo, right? [11:19:16] Also, if we don't like the first patch in the series, having to rebase and reupload all of the others will be rather dull. [11:19:21] Yes. That's right. [11:19:33] Right; you could do multiple commits along a single branch, or one branch per change. If your changes are sufficiently independent, I suspect the latter is better, because it will make it easier to make changes in response to comments, but maybe not -- I haven't played with this enough yet. [11:19:40] --- abo has left [11:20:05] --- abo has become available [11:20:08] I should spend more time looking into this [11:21:09] It would be neat if the list of open changes included an indication of how much review each had undergone, so it would be eaiser to pick out things in need of review. [11:21:52] I think there may be an issue in jira about that already. [11:22:43] Up to 115 changes merged through Gerrit. [11:23:02] it was under 100 when i wrote the cartel slides monday [11:23:26] I really should try and find some time to get buildbot going, so we can have automatic verification, too. [11:24:05] The number of changes in gerrit has nearly doubled since a week ago [11:24:45] felix went nuts [11:25:14] some of the changes from felix aren't going to fly, but at least it gets everything out, in small chunks, in a manner easy for anyone to read, review and comment [11:25:21] Yeh. I must find out how he's finding it. I suspect that have to rebase such a big patch set is a little painful. [11:25:39] he did say that it seemed like that was going to happen [11:25:39] It's unfortunate that it's all linearlized, or we would have resolved more of it by now. [11:25:45] yeah [11:25:53] --- haba has left [11:26:09] --- haba has become available [11:26:13] I also wonder if we're going to blow up on some little known system with stack depth issues. [11:26:44] Sadly, now have changes present as reported by "git log -p origin/master..HEAD", but git push returns "ng refs/for/master no new changes" [11:26:57] Well, modern Linux already has a very limited stack size, no? [11:27:05] So if we don't blow up Linux, I suspect we're not in that much trouble. [11:27:31] Yeh. Linux, you only get a page. [11:27:40] --- deason has left [11:27:45] matt: What's your git push command line? [11:27:48] linux is probably about the most limited we have, currently [11:27:49] --- deason has become available [11:27:51] --- stevenjenkins has left [11:27:57] ==rra,shadow,sxw [11:28:02] simon: git push ssh://matt@gerrit.openafs.org/openafs.git HEAD:refs/for/master [11:28:26] And the complete message from that command? [11:28:38] updating 'refs/for/master' using 'refs/remotes/origin/HEAD' from 0000000000000000000000000000000000000000 to 69cf150be870f4b4f9d10b7d0b0aa780054c6958 Generating pack... Done counting 0 objects. Writing 0 objects... Total 0 (delta 0), reused 0 (delta 0) ng refs/for/master no new changes error: failed to push to 'ssh://matt@gerrit.openafs.org/openafs.git' [11:29:01] I'm on a topic branch created on a fresh clone of openafs.git. [11:29:13] Cloned from git.openafs.org ? [11:29:54] git://git.openafs.org/openafs.git [11:30:07] --- abo has left [11:30:25] Branch created as "git checkout -b mybranch origin/master" [11:30:30] --- abo has become available [11:31:45] --- stevenjenkins has become available [11:32:00] git --version ? [11:32:09] what happens if you use a sha1 instead of HEAD? [11:32:10] 1.5.3.4 [11:32:40] dunno--would I use the sha1 hash of the last commit on master? [11:32:55] Use the SHA1 of the commit you're trying to push. [11:33:03] ah, ok [11:33:06] git show will tell you that. [11:33:27] it's eating that [11:33:55] woot [11:33:56] Is your HEAD currently 0{40}, by any chance? [11:34:24] Don't know how to interpret 0{40} [11:34:35] 00000000....0000000 [11:34:38] 40 of them. [11:35:14] Sorry, I've been hiding in git land for too long. What Russ said. [11:35:23] --- deason has left [11:35:28] --- deason has become available [11:35:30] Oh. I find that hard to believe (that's my HEAD). [11:35:41] That's what you get if you somehow checked out something that's not a tree. [11:35:46] Maybe I need the git update. However, checkin delivered. [11:35:47] Er, not a commitable tree. [11:35:50] Such as a remote or a tag. [11:35:53] Oh, he has a disconnected head? [11:36:02] That's what we're trying to figure out. [11:36:04] Sounds worse than it is, I'm sure. [11:36:59] git rev-parse HEAD should tell you [11:37:15] The 0's are definitely reported in the push--I believe the invocations I usd are canonical. [11:37:18] git rev-parse HEAD 9a61f640d19d91d2c227de745a9578c18114c9f4 [11:37:22] > updating 'refs/for/master' using 'refs/remotes/origin/HEAD' Wait, using origin/HEAD? That certainly won’t do anything. [11:37:35] --- abo has left [11:37:50] Matt, your commits don't have a first line following the Git developer guide. Could you git commit --amend and repush with a commit message that has a (short) first line summary that doesn't end in a period, then a blank line, and then the paragraph descriptions? [11:38:02] BTW: If anyone is thinking of trying to work through that libosi patch for review, you might want to wait for gerrit 2.0.17, which lets you track your progress through a patch set. [11:38:11] --- abo has become available [11:38:25] Russ: Sure. It -does- have a first line. I'll make it shorter. [11:38:27] Simon: thanks. [11:38:56] Is there any way that we could get libosi in smaller pieces? Say a framework, and then one logical chunk at a time. [11:39:03] 69cf150 is indeed the head of openafs.git/master [11:39:51] What does `git symbolic-ref HEAD` output? [11:40:04] refs/heads/miniosi [11:40:28] This is probably just a Git bug that would be fixed by upgrading Git. 1.5.3.4 is ancient. What distro do you use? [11:40:29] Hrm. That ought to be right. WTF is it taking 'HEAD' to mean the wrong head? [11:40:39] Well, the last one that you pushed had a line and a bit in the first paragraph with a couple of sentences, just to be clear about what I'm seeing. But I suspect we're on the same page. [11:40:42] I buy git bug. Sorry it's old. [11:40:59] Russ: amending [11:41:09] Danke! [12:18:06] the principal_ntoh misuse is the reverse of the fix in http://gerrit.openafs.org/#change,86 [12:19:25] to preclude slow cloning times for developers, is there something we can do with bundles? [12:20:43] You mean like precomputing packs so the server doesn't have to do so every time someone clones? [12:21:25] jhutz, yes. there's support for doing it. i don't see how yet. if it's useful i will look when i catch up [12:21:26] Is the time to compute a pack really the issue? Surely we're bandwidth limited for most users? [12:21:40] i think the pack can be compressed [12:21:54] I was wondering if we should run git gc on the repo. [12:21:55] like creating bundles of the repo at point releases, and having devs pull after getting it? [12:21:57] like, more optimally than what we already do [12:22:01] is that really much faster? [12:22:08] i have no idea [12:22:25] I'd be pretty surprised if the git:// protocol doesn't take advantage of all of these tricks already. [12:22:33] If you're using http://. then you're probably boned. [12:23:03] What you're supposed to do is run git gc periodically on the repo, which will take all loose objects and roll them into a new pack. [12:23:21] isn't git supposed to automatically do that every once in a while? [12:23:32] Some operations will periodically do it. [12:23:40] I don't think that a bare repo that we're just pushing to will. [12:23:42] I think it is. And gerrit is supposed to do so as well. [12:23:56] But yeh, it might be that srv/git needs packed. [12:24:19] The git gc man page says that you either need to run it by hand or configure it to run automatically, which isn't the default. [12:24:37] Hold on to your hats ... [12:24:49] Ah, no, it says that only some operations run git gc --auto. [12:25:09] --- haba has left [12:25:12] --- abo has left [12:25:17] --- stevenjenkins has left [12:25:23] * Russ runs git gc --aggressive on my own repos, which rebuilds a single pack for everything and hence is more compression, but it breaks http transport. [12:25:29] --- haba has become available [12:25:42] --- abo has become available [12:26:16] Well, I've garbage collected. Anyone notice any difference? [12:27:02] Hmm. Yes. gitweb sucks a lot less. [12:28:47] --- stevenjenkins has become available [12:29:04] --- dev-zero@jabber.org has left [12:41:06] The deltas editing tool now knows how to handle marking pullups [12:42:01] yay! [12:42:40] --- Russ has left: Replaced by new connection [12:42:41] --- Russ has become available [12:42:44] If you're handling a delta that it marks as (PULLUP) just leave the name and date blank and it will do the honours. [12:43:05] I suspected the problem with gitweb was parsing too many objects. [12:43:06] For this to work, you need to always pullup with git cherry-pick -x [12:47:57] Note that git commit -c *does not add the required information* if you're handling a pullup conflict [12:50:43] Hmm. I bet `git commit` wants to support -x too. [12:51:14] --- Russ has left: Replaced by new connection [12:51:15] --- Russ has become available [12:53:22] I suspect that after a git cherry-pick conflict the editor file is populated with the correct message, so you don't need to worry about the -c at all. [12:54:59] Oh, so it is, _if_ you ignore its advice to “use the option '-c 07a2039b' to retain authorship and message.” [12:55:33] Well, not quite. Then you become the author. [12:56:00] Bah. [13:01:28] I'm trying, and failing to parse the text about --author in the git commit manpage. You could read it that you can do --author= to copy attribution information. [13:01:40] This does the right thing for entirely wrong reasons but is useful as a workaround: VISUAL='cp .git/MERGE_MSG' git commit -c 07a2039b [13:02:42] :) [13:03:10] Even if you override --author you’d change the author date. [13:03:31] Yeh. Although I suspect we don't care so much about that. [13:04:34] --- haba has left [13:04:59] --- deason has left [13:05:14] --- deason has become available [13:05:31] --- haba has become available [13:13:53] --- Russ has left: Replaced by new connection [13:13:53] --- Russ has become available [13:36:44] --- Russ has left: Replaced by new connection [13:36:45] --- Russ has become available [13:40:48] --- Russ has left: Replaced by new connection [13:40:48] --- Russ has become available [13:59:12] --- mdionne has become available [14:18:42] --- matt has left [14:20:17] --- deason has left [14:20:43] --- deason has become available [15:39:08] --- mmeffie has left [15:49:32] --- dev-zero@jabber.org has become available [16:55:23] gerrit received some very large submissions today. I don't think we can consider accepting them into the tree until after we decide what is happening with 1.6 [16:56:12] I second the request for mini osi to be broken up into smaller pieces [18:12:31] --- cclausen has left [18:31:16] what did it get, aside from lots of cleanup from felix? I mean, I could go look, but it's easier for you to tell me what's large than for me to look through a hundred patches to see what's large. [18:32:25] Besides Felix submitting a ton of stuff, there are changes to volid allocation and checks on new volids, lots of warning cleanup from Simon and a few from me and from others, OpenBSD stuff from Matt, and two large patches adding new largish libraries, both from Matt. [18:32:30] Some other stuff too... let's see. [18:33:09] MacOS X stuff from Derrick. [18:33:31] A lot of that stuff is still outstanding, not committed yet. [18:33:59] Proposed changes to the return status from rxi_SendPacketList. [18:37:00] why does 59 have no owner? [18:37:19] Adam pushed it without a name in the author, just an e-mail address. [18:37:26] Gerrit apparently doesn't know how to represent that. [18:37:32] He owns it, just not with a name. [18:39:54] I thought we (i.e. Simon) bashed on gitweb to make FIXES be links [18:40:52]