[00:10:20] --- kaj has become available [00:31:24] --- Russ has left: Disconnected [04:09:49] --- Simon Wilkinson has left [04:41:02] --- Simon Wilkinson has become available [04:58:29] --- Jeffrey Altman has left: Replaced by new connection [06:13:58] --- deason has become available [07:29:41] --- mdionne has become available [07:39:05] --- reuteras has left [08:39:27] --- jaltman has become available [08:57:26] --- stevenjenkins has become available [09:00:21] --- kaj has left [10:01:59] --- mdionne has left [10:03:35] --- Russ has become available [10:18:16] --- kaj has become available [11:12:19] --- mdionne has become available [11:13:19] --- mdionne has left [12:43:22] --- kula has left [12:43:26] --- summatusmentis has left [12:46:21] --- summatusmentis has become available [12:47:36] --- kula has become available [13:16:39] Simon: Don't know if you get the bug mail, but I have access to a sparc64 system. I can't load kernel modules, but I can make sure the build works. [13:24:15] Russ: That's all we need. Basically ioctl32 is only needed for register_ioctl32_conversion, which we shouldn't be doing by that point. [13:36:45] * Russ attempts to rewrite the Debian packaging OpenAFS repository to get rid of all the old tarballs and fix the historic repository structure. I have a working repository, but when I clone it, it thinks many of the tags point to invalid objects. Grumble. [13:38:25] Have you actually deleted objects? [13:40:58] Yeah, I'm using git filter-branch, which does all sorts of nasty things. [13:41:20] Apparently the the problem was that git got very confused by cloning a repository whose current HEAD pointed to a detached commit. [13:41:35] git checkout master in the repo where I did git filter-branch, and now git clone works fine and sees all the tags. [13:41:45] Wierd. [13:42:07] Repository shrunk from 341MB to 81MB, which is still not great but is a substantial improvement. [13:42:30] How many local patches are you carrying for 1.4.x? [13:42:34] I should probably try repacking it with more aggressive options. [13:44:59] Five substantial ones and then some other minor stuff. [13:45:03] It's all merged into 1.5 now. [13:46:18] Did all the stuff that's in 1.5 make the last round of pullups (ie, will it be in 1.4.12) ? [13:46:58] No, some of the changes are fairly substantial, such as the fstrace message catalog fixes. [13:47:10] I think a lot of it is pulled up, though. [13:47:27] Let's see. the Linux kbuild headers stuff is. [13:47:58] The Debian-specific compiler flags work isn't, since I redid that on master to avoid setting CC where unnecessary, and that had some followups and we didn't pull all that up. [13:48:17] The Debian-specific module renaming was done differently on 1.5 and I'm now using that configure flag, but I don't think it's available in 1.4. [13:48:41] The nasty hack in the Debian package to build the PAM modules PIC is handled in master by building _pic.a versions of the libraries. I don't think we pulled that up. [13:49:09] I think I also have a patch to expected bos directory permissions that I decided to just deal with dropping for 1.5 and not in 1.4. [13:49:44] Yeah, can't get the repo below 81MB. [13:51:49] Oh well, the canonical OpenAFS repository is 220MB, so that's not too bad. [13:52:35] And the Debian repo has to carry around 140KB of uncompressable gunk per upstream tarball we used for Debian packaging to store the pristine-tar xdelta, so overall, fairly happy with that. [13:53:07] Oh, the actual repository is only 35MB. The rest of that space is the checkout. [13:53:17] Yeesh, that's a lot of space consumed by the checkout. [13:53:33] So I shrunk the repo by nearly a factor of 10. [13:53:37] Yeah, totally worth it. [13:53:40] That's not bad at all. [14:04:54] Russ: http://gerrit.openafs.org/1040 should fix the sparc64 ioctl32 issue. [14:11:11] Thanks, rsyncing a tree with that patch to the system now. [14:23:21] Hrm. I suppose I ought to do a CellServDB RSN. I sort of want to wait until next week, though. How close are we to 1.4.12 now? [14:23:56] We haven't done rc1 yet. [14:24:32] I'd really like to have time to look at the reported performance regressions, but my test network is currently off due to a cooling failure in our machine rooms, and won't be back on till the new year. [14:28:29] Oh, cooling failures suck. [14:28:56] Though, it seems like there is an abundant source of chilled air this time of year. [14:29:32] In fact, there is considerable condensation all around the window frame in our machine room. [14:30:11] Yeh. The irony is that the cooling failed because the external temperature was too low. [14:30:57] Does your cooling have its own outside compressors, or does your campus have chilled water as a utility like ours does? [14:31:31] We have a bit of both. [14:31:58] We have a central chilled water supply, with local compressors as a backup (as I understand it) [14:32:28] Always such a pain in the ass to set up the Debian kernel headers on a system where I don't have root, particularly when it's missing standard tools like aptitude. [14:32:49] Sorry! [14:32:59] I try to avoid systems where I don't have root [14:33:55] Yeah, me too. [14:34:01] But I don't really want to run my own sparc64 system. :) [14:34:42] The source tree is building now. [14:35:38] Cool. Ta. [14:37:52] Today's favourite git command : describe [14:39:20] Yeah, that's rather neat. [14:39:30] git filter-branch, while scary, rocks pretty hard. [14:44:01] /home/rra/openafs/src/libafs/MODLOAD-2.6.32-trunk-sparc64-SP/osi_ioctl.c:28:32: warning: extra tokens at end of #ifdef directive /home/rra/openafs/src/libafs/MODLOAD-2.6.32-trunk-sparc64-SP/osi_ioctl.c:29:27: error: linux/ioctl32.h: No such file or directory /home/rra/openafs/src/libafs/MODLOAD-2.6.32-trunk-sparc64-SP/osi_ioctl.c:61:8: warning: "AFS_AMD64_LINUX20_ENV" is not defined [14:44:40] Hmmm. [14:44:55] Ah. Did you grab version 1 or version 2 of that patch? [14:45:22] Ah, version 1. Sorry. One second. [14:45:32] Should have warned you, sorry. [14:46:25] There are a few cast to integer from pointer of a different size errors in the module build on sparc64 from 32-bit userspace, btw. [14:46:47] afs_BozonLock and afs_CheckBozonLockBlocking [14:46:51] Can you grab the build output and put it somewhere, and I'll take a look. [14:46:59] Er, warnings, rather. [14:47:00] Sure. [14:47:25] I still get /home/rra/openafs/src/libafs/MODLOAD-2.6.32-trunk-sparc64-SP/osi_ioctl.c:61:8: warning: "AFS_AMD64_LINUX20_ENV" is not defined [14:47:27] But it builds now. [14:47:32] Yeh. That's a different bug. [14:49:14] invalidate_inode_pages is deprecated. [14:49:50] http://gerrit.openafs.org/1041 fixes the not defined warning. [14:50:00] Oh, cool. [14:50:21] I wonder what we should be using instead ... [14:54:16] ... should be invalidate_mapping_pages() which seems to have been available since 1.5.x [14:55:09] (sorry, 2.5.x [14:59:13] I want to say it's not that simple, but I forget why. cg2v would probably remember [14:59:31] Well, someone should tell Linus :) [15:00:09] static inline unsigned long __deprecated invalidate_inode_pages(struct address_space *mapping) { return invalidate_mapping_pages(mapping, 0, ~0UL); } [15:00:22] It's been like that (without the __deprecated) since 2.5.x days. [15:00:45] --- jaltman has left: Replaced by new connection [15:00:46] --- jaltman has become available [15:05:11] Russ: If you're still in kernel building mode - http://gerrit.openafs.org/1042 [15:10:21] Will test as soon as this build finishes. [15:13:42] /afs/ir.stanford.edu/users/r/r/rra/public/dropoff/openafs.log has that complete build log (32-bit sparc with 64-bit kernel headers). [15:18:43] Russ: Is that vanilla 1.5.x? Because rxgen seems to have gained some debug output from somewhere [15:21:18] Found it. My bad. [15:24:46] Okay, I'm confused. Why do we have both AFS_NOBOZO_LOCK and AFS_BOZONLOCK_ENV ? [16:19:37] Probably just to confuse you. :) [16:20:52] Well, I'm thoroughly confused. They aren't direct opposites. Sun5 has both AFS_NOBOZO_LOCK and AFS_BOZONLOCK_ENV defined. [16:20:54] My brain hurts. [16:54:54] Simon: Thank you so much for cleaning up the old bugs. [16:55:32] That's OK. Starting to run out of steam, but I've made it to mid 2009. [16:55:56] There's a fair number of patches rotting in there ... [17:04:04] Yeah. [17:05:54] thanks for the RT effort. [17:06:57] did you review the stalled tickets as well as the open ones? [17:07:12] Well, shortly I will have a list of RT tickets that contain either patches, or ones which have trivial fixes [17:07:30] (where doing the fix is less work than noting it, I've just been making the change and pushing to gerrit) [17:07:38] No, I've just been doing the open ones. [17:08:01] The stalled tickets are likely to be such a zombie graveyard that I'm not sure I want to go there. [17:11:36] I suspect that most of them are issues where we needed more input from the submitter and never received it. [17:14:02] I really want a ticketing system that will: [17:15:03] a) Let me assign milestones to bugs b) Split tickets up by area c) Handle patches and large attachments in a way that doesn't suck [17:15:23] d) Let me flag patches (so I can easily say - this has a patch, or "this is a simple fix") [17:55:59] Oh well, 370 bugs read, 32 closed. [18:08:51] 9%. [18:09:14] you did about as good percentagewise as my RT binges, but showed more patience. [19:10:47] --- jaltman has left: Replaced by new connection [19:10:48] --- jaltman has become available [21:10:47] --- jaltman has left: Disconnected [21:13:04] --- deason has left [22:28:00] --- reuteras has become available [23:09:28] --- kaj has left