>I've had a couple of really frustrating moments lately relating to >different versions of aklog and their differing capabilities (the one >included with 1.4.1rc10 is optimal, however). > >Is it too late for me to submit a patch that would add a "-version" >(or "--version", or "-v") flag to the bundled aklog for 1.4.1? I know >it's in the only-the-critical-fixes stage, but I think I can make a >pretty good argument that it wouldn't get near anything that could >cause a bug.
Derrick has pretty much said that it's too late, and that's his call. But I'm scratching my head here ... aklog has AFAICT not changed it's capabilities since it was imported (well, okay, there was a window between when it was imported and before rxkad2b support was added, but before that point it didn't even compile, so I don't think that really counts). So, from where I'm sitting, the aklog that OpenAFS has shipped in a working state hasn't changed really at all. (If you're talking about a certain few binary distributions which I won't name here, well, you'll have to take that up with the people who package those distributions). As a side note ... you can run "ident" on the aklog binary to get out the RCS strings, and that might be useful. --Ken _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
