[00:59:20] --- jaltman/FrogsLeap has left: Replaced by new connection [00:59:21] --- jaltman/FrogsLeap has become available [01:18:41] --- haba has become available [05:40:29] --- Simon Wilkinson has become available [05:55:12] --- haba has left [05:55:36] --- haba has become available [08:00:57] --- deason/gmail has become available [08:01:10] --- mfelliott has become available [08:21:42] should I expect any problems going to a disk cache on the order of several 10's of GB ? [08:56:38] If you mean running a client with a configured cache of, say, 240GiB then maybe yes. We have a couple of machines here like that and we fairly regularly get bursts of lots of IO-blocked processes (i.e. load avg skyrockets). afs_cachetrim shows up on top of a top during such "outages". [08:57:37] I was thinking more like 20-30GB [08:57:52] I mentioned this to sxw (hi Simon :) at a recent UKUUG workshop. We talked a bit about changing the chunksize but I'm afraid I've never got round to investigating futher :-( [08:58:06] what are you using now? [08:58:14] we usually do 19 or 20 [08:59:12] currently it's whatever might have been "autotuned", i.e. default. [09:18:07] --- rra has become available [09:19:44] oh, yeah, you would def have problems then [09:46:57] are there supposed to be PDFs generated into doc/xml/$whatever_dir ? [09:50:37] pdfs. depends on the platform and availability of tools [09:51:38] The Debian packaging will generate both HTML and PDFs if the tools are installed. [09:54:02] oh, so I'm likely missing the tools then, if they're not being generated [10:19:17] it looks like changes to the command processor on master have broken the default behavior of 'klog ". on 1.6 and earlier is assigned to -principal even though -x is the first command line option. My guess is that cmd_Seek() behavior is broken but I don't have time to look into it. If anyone else does have time, please let me know what you find. [10:23:49] it sounds like the issue fixed by gerrit 4711, if that's from a master a few days old.... if not, yeah, possibly cmd_Seek [10:29:15] the report was from master more than a few days old. I will rebuild and test. thanks [10:43:36] cmd_Seek()'s behaviour shouldn't have changed. [10:43:51] The flags issue that was fixed by 4711 is a possible suspect. [11:05:48] --- Simon Wilkinson has left [11:05:50] --- Simon Wilkinson has become available [13:58:24] --- Simon Wilkinson has left [13:58:30] --- Simon Wilkinson has become available [14:19:22] --- deason/gmail has left [15:11:08] --- haba has left [16:14:56] hey Russ, when you get a chance, any thoughts or suggestions? [16:15:02] Russ, http://pastebin.com/8YGzcCkZ [16:26:33] The output is basically saying that our shared libraries used to contain afs_snprintf, afsconf_IntGetKeys, and afsconf_SetSecurityFlags, but don't any more. [16:27:04] This means that the SONAMEs on those libraries need to increase and the *.symbols files be updated to reflect that those symbols no longer exist, and to reflect the new SONAME. [16:27:24] Since that's an ABI break. [16:27:40] Either that, or there's some bug that's causing those symbols to not be available. [16:29:07] what's a SONAME? [16:29:31] so, I should be able to remove those from the symbol files? [16:29:54] also, what specifically is required to get the pdfs to properly be generated? [16:31:00] I installed the docbook-xsl-doc-pdf package, but that didn't seem to make them get generated [16:50:39] The build dependencies (see build-depends in debian/control) of the package should be sufficient. [16:51:03] The SONAME is the name of the shared library used by compiled binaries to load it from disk. It's controlled by the Makefile.in files in shlibafsrpc and shlibafsauthent. [16:51:35] You can just remove those lines from *.symbols without changing anything else, but any binaries that actually use those symbols and were built against the old libraries will then crash at runtime if the new libraries are installed. For what you're doing, that may not be a problem. [16:52:43] I just want debian packages of master (plus patches), so I can test fileserver code without needing to fight with setting one up on OS X [16:55:07] is there something I can do about the weird 1~1~1~1~ stuff? it seems to append a 1~ to the version every time I run make dpkg [16:58:08] That I don't know. [17:14:19] --- rra has left: Disconnected [17:49:48] --- Russ has become available [19:51:44] russ: I'm not sure how much you know about the changes in the codebase, but as I fix the *.symbols files, it seems to keep finding more symbols that aren't listed, and removing ones that are [19:52:09] is this expected behavior? or am I making things worse for myself accidentally? [19:52:13] That's really weird. It should have found all the missing ones the first time. [19:52:39] well, it errored out the first time [19:52:50] it's acting like it's getting further, before erroring out? [19:53:07] It should either error out or not, all at once, when it generates the symbols files. [19:53:44] it's most certainly not doing that [19:54:25] now it's showing a lot of rx_* and afs_xdr_* symbols needing to be added, which makes some sense, if I understand the work that's been done recently [19:54:46] Yeah, but added symbols won't break the build. [19:54:52] It should just warn and keep going. [19:54:55] I think. [19:54:59] I don't remember how that goes for sure. [19:55:13] But you're getting other really weird stuff, like that ~1 thing that I don't understand. [19:55:34] it's not clear to me what the error is, beyond something like: dh_makeshlibs: dpkg-gensymbols -plibafsrpc1 -Idebian/libafsrpc1.symbols -Pdebian/libafsrpc1 -edebian/libafsrpc1/usr/lib/libafsrpc.so.1.4 returned exit code 1 [19:56:53] I must admit that I never use make dpkg and have never even run it. It's not how the actual Debian packaging is done (that's done in a separate repository via importing tagged releases). So it's possible that something broke it in some way. [19:57:53] oh, that's less than ideal. it's certainly acting like it'll be a relatively large undertaking to get it to fully work correctly. [19:58:07] and "relatively large" is not something I have time for right now [19:58:31] I would volunteer to fix it except that I'm already way behind on a bunch of other stuff. :/ I feel bad that it's not working, but finding time to act on that is trickier. [19:59:10] You could try merging trunk into the Debian packaging repository and see if that goes any better, but you may just run into all of the same problems, if they're actually "trunk is different" problems rather than "make dpkg rotted" problems. [19:59:37] don't feel bad, I was just hoping it'd be easier than doing all sorts of stuff "manually" [20:00:54] is the debian packaging repo tracking master at all? or is it following an older branch? [20:01:08] It's tracking the 1.6 release branch, I'm afraid. [20:02:21] so not older, but not what I'm lokoing for either, probably [20:03:21] Yeah, although it's not too hard to import trunk. Well, I think. I've only used debian/import-upstream with tags, but in theory it should work with any tree-like object. [20:03:35] Likewise with the get-orig-source target. [20:04:06] hrm [20:04:33] So you could try cloning git://anonscm.debian.org/git/pkg-k5-afs/openafs.git and then read debian/README.source about how to import a new upstream version. [20:04:44] And rather than importing a tag, import the commit hash that represents the top of trunk. [20:04:58] I don't know if this will fix any of your problems, though. [20:05:08] You'd still have to redo the work to add the new shared library packages. [20:05:16] That much is just "trunk is different." [20:06:30] well, I've still got those files, so that's not awful. Hrm, I might go back to manual setup for the time being, just because I need to get this up and running [20:07:08] I'll certainly keep you informed about it if I manage to get it working though, make dpkg is a cool make target, if it works [23:20:52] --- haba has become available