© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
67d34a1
(Get the code!)
Well, Sam doesn't have anything to do with fixing this bug. Sam, like myself, is one of the maintainers of the Debian package. I don't use Ubuntu, have no upload access to Ubuntu, and know nothing about its release cycle. So far as I know, the same is true of Sam. Insofar as Launchpad implies that Sam has anything to do with what ends up in Ubuntu, it's not being particularly accurate.
I could only speculate on why the fix wasn't backported to Edgy, and since I'm not involved in Ubuntu (only in OpenAFS), I don't want to do that.
Looking at the config.log that you attached (thank you!), here's the actual problem:
/lib/modules/
/lib/modules/
So basically, the kernel headers as included by the OpenAFS configure script don't compile. This is very typical of the error message that you're seeing. Notice in the configure log that every test related to the Linux kernel returns "no", and then the resulting source won't build.
Almost every time we see an error like this, what it means is that the Linux kernel maintainers have changed the headers and now certain other headers have to be included before the ones that OpenAFS is including. The kernel maintainers do this all the time and without warning and believe that it's the responsibility of modules to try to keep up, and OpenAFS then tries to adapt in the next version. I expect that in this case this is one of the many Linux kernel build issues that was fixed in 1.4.2, which is why the current Debian packages work.
It's probably possible to come up with a backport fix for just this problem by inspecting the configure script in 1.4.2 and seeing what additional headers it includes when doing kernel probes, although that may be made more complicated by the fact that I think 1.4.2 does kernel probes in general in a better (but different) way. Coming up with that sort of backport is fairly tedious, though.