[00:16:52] --- kaj has become available [00:19:17] --- kaj has left [00:19:20] --- kaj has become available [00:59:14] --- Russ has left: Disconnected [05:54:39] --- Simon Wilkinson has become available [07:15:24] --- deason has become available [07:18:03] --- jaltman has left: Disconnected [07:18:10] --- jaltman has become available [07:22:43] Hudson failure test submitted. src/viced/viced.c should blow up. [07:23:10] http://gerrit.openafs.org/2395 [07:41:57] Hudson claims the failure test was successfully built [07:45:07] we need a build log [07:45:17] if his web server worked i bet we'd have a link [07:45:53] well, we have a link [07:45:55] it just doesn't work [07:46:09] i have a pony. it doesn't work either. stupid pony. [07:49:32] It does mean that we need to be very careful about not assuming that code he has marked verified has been [07:53:51] --- abo has left [07:54:04] --- abo has become available [08:27:58] --- jaltman has left: Disconnected [08:54:35] --- meffie has left [09:04:35] --- meffie has become available [09:12:26] --- kaj has left [09:16:28] apparently the hudson issue is currently success is success and fail is success. (in terms of the actual text of the messages it sends) [09:17:32] --- kaj has become available [09:24:20] --- kaj has left [09:27:35] --- reuteras has left [10:16:22] --- jaltman has become available [10:58:55] --- jaltman has left: Disconnected [11:07:33] --- jaltman has become available [11:15:33] --- Simon Wilkinson has left [11:27:44] fine, i will have a flex fix shortly [11:27:59] Yay [11:30:57] it's ugly. not horribly ugly. just ugly. [11:31:15] ... oh. [11:37:01] 2399. quite chinsy [11:53:30] --- kaj has become available [12:01:32] of course the last several pushes via gerrit haven't shown up in git.openafs.org [12:02:23] --- Simon Wilkinson has become available [12:02:45] Ah, are pushes from gerrit not making it out again? [12:03:03] yeah, seems so. 52fe3b27489f113c0f7488c5b78fd95a18d44831 for example [12:03:33] openafs.stanford.edu is refusing connections on port 22. [12:03:50] oof [12:04:05] It's let me in now. Let me see what is going on. [12:04:51] Too many open files. [12:04:57] ow [12:05:08] so something is leaking open files? [12:05:15] That usual means that one, or other, of the repositories needs packing. [12:05:35] cron. [12:06:10] (Or that gerrit has leaked file handles) [12:06:36] Gerrit going down for a moment ... [12:07:32] --- geekosaur has left [12:07:38] --- abo has left [12:07:57] --- abo has become available [12:12:48] ls -l objects/pack/ | wc 6084 54749 587023 [12:13:00] We're going to need Russ to fix this, I think. I can't open enough files. [12:13:54] grah [12:17:26] I wonder which Hudson plugin Jason is using. Reports on the interweb suggests that there are file handle issues in gerrit which Hudson may trigger [12:17:54] well, we can ask him to stop it for now [12:18:28] Let's restart gerrit. If it breaks again, we should probably think about asking him for more details about how he's polling for changes. [12:19:30] --- geekosaur has become available [12:20:27] There's also a fix that I could make to the init script, but sadly I'm not Russ, so I can't actually edit the file. [12:22:05] Gerrit is back up, it should have pushed out the missing changes [12:25:45] --- geekosaur has left [12:25:58] --- geekosaur has become available [12:30:37] --- meffie has left [12:31:03] I think the problem is probably http://code.google.com/p/gerrit/issues/detail?id=460 [12:31:14] Which will require an upgrade to the init script that starts gerrit. [12:40:25] --- rra has become available [12:40:38] --- meffie has become available [12:41:00] * rra is in if there's something I need to fix. [12:41:46] Could you edit /etc/init.d/gerrit on o.s.e and set the default value for GERRIT_FDS to 1024, rather than 128 ? [12:43:20] Done. [12:43:25] Or rather pushing out now. [12:43:42] Then, we need to run git gc /srv/gerrit/repo/openafs.git/openafs.git - it needs to be done by a user with access to at least 7000 file descriptors, but the ownerships need to stay the same. [12:43:52] (ie gerrit needs to be able to everything that it can write to now) [12:46:09] We should do that periodically from cron, shouldn't we? [12:46:56] We probably should, yes. I keep being told that we shouldn't need to, but that doesn't seem to be the case. [12:47:23] At least the gerrit user should be able to run it from cron, but it can't do so at the moment, because gc wants to open all of the pack files, and that doesn't work out so well. [12:51:40] It's running gc now, just taking absolutely forever. [12:51:48] I'm not sure why it's so slow. [12:52:00] It's doing "counting objects" and taking nearly a second per object. [12:54:15] We've got 14,000 objects. That's not going to end soon. [12:54:34] I'm hoping it will eventually speed up, but otherwise this may take a while. [12:54:43] Here's hoping! [12:58:28] Thankfully, we appear to not be blocking other repo work while this is running. [13:02:18] you're not "supposed" to need to run it from cron (so I hear) because of the commands that automatically do it... but I've always wondered if our repo is sufficiently weird with gerrit and such that that doesn't apply [13:02:48] Well, in general you are only not supposed to have to run git gc with a repo to which you commit directly. [13:03:02] If you only interact with a repo via git push, you do have to run gc periodically because git receive-pack does not gc. [13:03:16] But that's for a regular Git server; the Gerrit thing is weird and different. [13:04:14] my impression was that gerrit interacts with the repo directly through some git bindings or something; so maybe the equivalent of "git $X" that it does doesn't automatically gc --auto [13:05:38] --- meffie has left [13:08:31] Up to 1165 objects so far. [13:10:13] gerrit uses JGit, but that should garbage collect [13:10:31] --- meffie has become available [13:13:31] so, i have a dafs-also binary build change. it doesn't tweak bosserver, docs, or move files around. my belief is that those should all be done separately (well, maybe docs and bosserver in one change). just fwiw. [13:18:08] bosserver? bosserver doesn't touch AFS_DEMAND_ATTACH_FS [13:18:31] dafs bnodes? [13:19:04] the log messages should be corrected. [13:20:03] well, maybe not. but my plan was to say e.g. "DAFS salvager binary" or "dasalvager binary" when that's what it means [13:31:31] Looks like we're missing some dependency libraries when linking libafsauthent. [13:31:33] dpkg-shlibdeps: warning: symbol __dn_expand used by debian/libafsauthent1/usr/lib/libafsauthent.so.1.1 found in none of the libraries. dpkg-shlibdeps: warning: symbol crypt used by debian/libafsauthent1/usr/lib/libafsauthent.so.1.1 found in none of the libraries. dpkg-shlibdeps: warning: symbol __res_search used by debian/libafsauthent1/usr/lib/libafsauthent.so.1.1 found in none of the libraries. [13:32:47] that'd be libresolv [13:32:54] And -lcrypt. [13:32:57] of course, we need it "sometimes". [13:33:10] * rra is trying to figure out what makefile variable those get put into, since we're linking the binaries properly. [13:33:22] XLIBS maybe? [13:33:42] is XLIBS safe to link there? probably [13:33:44] I think we've got something that expands out when we need -lcrypt [13:33:48] LIB_CRYPT, maybe? [13:33:54] Yeah, not XLIBS. [13:34:12] Not seeing that set anywhere.... [13:34:44] Hm. [13:34:50] I'm actually not seeing any Autoconf probes for crypt at all. [13:34:54] Am I missing something? [13:35:02] Maybe that's only in my rxgk patches [13:35:25] Looks like -lresolv is getting put into LIBS. [13:36:01] Gah, so much of our Autoconf code is 1.x vintage stuff that could be so much tighter and smaller. [13:36:28] Ah, no, resolv doesn't get put into LIBS. [13:36:33] LIB_AFSDB apparently. [13:36:50] --- Kevin Sumner has left [13:36:51] I think. [13:36:53] Wow, this is confusing. [13:37:02] --- meffie has left [13:37:16] yeah, LIB_AFSDB. [13:37:23] Okay, so we need to add something for crypt too, it looks like. [13:37:31] I'm sure I have code for this [13:37:36] Simon, do you have a separable patch for that you'd rather submit, or should I roll something? [13:37:45] If you have something, we should go with that rather than creating a future merge conflict. [13:37:53] --- Kevin Sumner has become available [13:38:00] --- meffie has become available [13:38:31] We should use symbol versioning with our shared libraries too, at some point, but that's a problem for another day. [13:39:59] dnl Check to see if crypt lives in a different library AC_CHECK_LIB(crypt, crypt, LIB_crypt="-lcrypt") AC_SUBST(LIB_crypt) [13:40:11] ... is what the rxgk tree is doing [13:40:34] That looks right. [13:40:54] I'd make that LIB_CRYPT, though, to match our other variables. [13:41:09] yeah, it's LIB_crypt, because it's stolen from Heimdal :) [13:41:10] Oh, we're not consistent. [13:41:30] And we have LIB_libintl already. [13:41:46] Do you want to push something to Gerrit for it? [13:41:52] I'm pushing the -lresolv thing now. [13:41:53] I will do ... [13:44:01] --- meffie has left [13:45:57] --- meffie has become available [13:49:51] flex change: yinz should comment [13:50:35] Doesn't look terrible. I do wonder about the autoconf bits - should it use AS_IF(), and I'm not sure that the m4 quoting is correct. Russ would be better placed to comment on that. [13:50:51] Also, should we just test for '-l' rather than using '--version' [13:51:01] > "DAFS salvager binary" but that can be detected by dafs vs fs bnode, yes? [13:51:39] --version seems safer. -l may or may not be what we want [13:51:57] > but that can be detected by dafs vs fs bnode, yes? sure. but i was going to update the strings, is all [13:52:13] not build a daboserver [13:53:22] dafs always is 2403 [13:53:35] going for a walk now. i need my farm share before the pickup spot closes [13:55:44] okay, okay [14:17:31] Up to 5,220 objects counted. [14:20:23] Third of the way, then . Ouch. [14:21:12] We should definitely do this more frequently than once a year. :) [14:21:38] Yeah. [14:23:55] The Gerrit repo is currently 379MB. I'm going to be curious to see how big it is when this is finished. [14:25:59] Yeah, that will be interesting. [14:37:41] --- Simon Wilkinson has left [14:43:11] Hm. [14:43:13] windlord:~/dvl/openafs> git describe --abbrev=4 HEAD openafs-devel-1_5_75-49-geb873 windlord:~/dvl/openafs> build-tools/git-version UNKNOWN [14:43:51] Oh, it takes a mandatory argument. [14:43:53] Duh. [15:13:56] There we go. [15:13:59] Trying 171.67.225.134 (port 7001): AFS version: OpenAFS 1.5.75-1-debian built 2010-07-13 [15:33:15] Why did that libafsauthent patch which Gerrit thinks it cherry-picked not make it into the repository? [15:35:02] Gerrit says: Change has been successfully cherry-picked as 57d727da233252477c16a34cf628f6764534b8bc. [15:35:22] But: openafs:/srv/git/openafs.git> git show 57d727da233252477c16a34cf628f6764534b8bc fatal: bad object 57d727da233252477c16a34cf628f6764534b8bc [15:37:16] 1.5.75-1 packages uploaded to Debian experimental. [15:41:40] --- deason has left [15:44:48] No commit notification was sent for that change that wasn't really merged either. [16:12:44] I could restart Gerrit and see if that causes it to push the pending change. Sometimes that works. [16:12:55] Should probably wait until it finishes gc'ing. [16:29:51] --- phalenor has left [16:39:12] --- phalenor has become available [17:08:37] Up to 15,309. [17:13:11] --- geekosaur has left [17:13:54] --- geekosaur has become available [17:23:40] --- dwbotsch has left [17:24:18] --- dwbotsch has become available [17:36:49] --- phalenor has left [17:46:50] --- phalenor has become available [17:52:58] Ah, good, it finally started speeding up. [17:53:04] Up to nearly 30,000 now. [17:57:36] --- shadow@gmail.com/owl72B95F2A has left [18:08:41] --- dwbotsch has left [18:09:53] --- dwbotsch has become available [18:10:51] openafs:/srv/gerrit/repo/openafs.git# setuidgid gerrit git gc Counting objects: 143129, done. Compressing objects: 100% (37639/37639), done. Writing objects: 100% (143129/143129), done. Total 143129 (delta 115927), reused 131138 (delta 104469) openafs:/srv/gerrit/repo/openafs.git# du -sh . 115M . [18:11:01] Knocked 250MB off the repository size. [18:11:46] git gc now finishes almost immediately. [18:22:37] Okay, I'm going to restart Gerrit to see if that will push the changes that were supposedly merged but weren't. [18:26:39] Okay, that one change just didn't merge, but I submitted it again and then it worked fine. [18:26:47] I don't know if we lost any other changes in that same state. [18:27:37] Ah, no, restarting *did* fix it. I just didn't wait long enough. [18:27:40] Okay, that's a relief. [18:28:04] Unfortunately, we now have two duplicate changes in the repository. :/ Ah well. I should have had more patience. [18:28:17] No harm done other than a confusing double log entry. [18:36:02] --- JSund_ has become available [18:36:02] --- JSund_ is now known as JSund__ [18:36:02] --- JSund has left [18:36:02] --- JSund__ is now known as JSund_ [18:36:02] --- JSund_ is now known as JSund__ [18:36:02] --- JSund__ is now known as JSund [18:38:50] --- JSund is now known as JSund_ [18:38:50] --- JSund_ is now known as JSund__ [18:38:50] --- JSund__ is now known as JSund [18:43:57] --- geekosaur has left [18:44:03] --- geekosaur has become available [18:44:14] --- JSund is now known as JSund__ [18:44:14] --- JSund__ is now known as JSund_ [18:44:14] --- JSund_ is now known as JSund [18:47:48] --- phalenor has left [18:50:25] --- JSund is now known as JSund_ [18:50:25] --- JSund_ is now known as JSund__ [18:50:25] --- JSund__ is now known as JSund [18:50:25] --- JSund has left [18:50:27] --- JSund__ has become available [18:57:49] --- phalenor has become available [19:16:57] --- shadow@gmail.com/owl9DEC967B has become available [19:35:40] make dpkg is still a horrible hack from the perspective of building proper Debian packages, but it generates a bunch of *.deb files eventually that probably vaguely do the right thing. [19:36:11] The whole make dpkg approach is impossible to make work properly since the basic assumptions are just wrong, but it seems to be what people want, so I think what it does now is about as close as it can get. [19:36:55] Although at some point someone could figure out why it seems to run make install about three times (which doesn't happen with the exact same packaging files doing a proper Debian build). [19:37:30] The fact that it builds a native package because there's no orig.tar.gz file available and that it generates a *.tar.gz that includes all the object files from your local dirty tree are probably impossible to fix. [19:38:27] Hm, I could probably change it to just not build the source package, since the source package is the main thing that's going to be broken. [19:38:38] Anyway, home. [19:38:45] --- rra has left: Disconnected [19:39:10] ok [19:57:47] --- Russ has become available [19:58:08] Sorry for having broken it earlier. I hadn't caught the debian/changelog issue. [20:24:36] --- jaltman has left: Disconnected [20:26:31] --- Born Fool has become available [20:46:43] --- jaltman has become available [20:55:36] --- jaltman has left: Disconnected [21:09:50] --- jaltman has become available [21:48:17] shadow: Thank you for all the work you're doing on the remaining release tasks! [21:52:21] we're close [21:54:02] Should I abandon 2321? I don't expect it to be of much use if it's not in a release, though I still don't have a sense for where the opens count is dropping negative. (I guess I haven't really looked at it, recently, though.) [21:54:16] leave it for now. [21:57:46] * Russ laughs at dafileserver. "What file server are you running?" "DA file server." [21:59:06] it's a lousy name, of a number of lousy choices [22:01:16] "Whose fileserver are you?" "Coach Ditka's fileserver." [22:01:48] I like it. I think it's funny. [23:04:46] --- kaj has left [23:22:36] --- reuteras has become available [23:39:55] --- Russ has left: Disconnected