openafs-modules-source fails to build with 2.6.27-2 kernel in intrepid: asm/semaphore.h replaced with linux/semaphore.h

Upstream bug: http://rt.central.org/rt/Ticket/Display.html?id=111634
(Launchpad currently can't perform remote watch on this bug tracker...)

... For some reason, I can't add that tracker in "also affects project", but it automatically does a remote bug watch when I link to it? o.O

I have a patch/debdiff ready for fixing building openafs on 2.6.27. However it is against 1.4.7.dfsg1-5 so I'm waiting for a sync of it before filling a bug with the diff. See bug #264303 for the sync request.

As a side note, the bug you are refering to is not enough to build openafs against 2.6.27 if you are running on 64-bit.

I could just as well upload the debdiff to this bug directly.

As I said, the diff is against 1.4.7.dfsg1-5 which is not yet in the archive, but it will probably work against 1.4.7.dfsg1-3 too, which is in the archive.

/torkel

Actually, at first glance OpenAFS is not using <asm/semaphore.h> at all in kernels >= 2.6.16. For example, "src/rx/LINUX/rx_kmutex.h" has this snippet:

#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,16)
#include <linux/mutex.h>
#else
#include <asm/semaphore.h>
#endif

typedef struct afs_kmutex {
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,16)
    struct mutex mutex;
#else
    struct semaphore sem;
#endif
    int owner;
} afs_kmutex_t;

And in fact, to make the package build and work, one just need to do the same in "src/afs/sysincludes.h" - change

#include <asm/semaphore.h>
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,16)
#include <linux/mutex.h>
#endif

to

#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,16)
#include <linux/mutex.h>
#else
#include <asm/semaphore.h>
#endif

Patch attached.

fwyzard, is that patch from upstream, or have you considered sending that patch upstream to OpenAFS?

From my understanding, Bjorn's debdiff combines (accepted and committed) patches from the upstream bug tracker, so eventually the patch can be removed once upstream makes a release with said code and that release propagates to Debian, and in turn, Ubuntu.

This bug was fixed in the package openafs - 1.4.7.dfsg1-6

---------------
openafs (1.4.7.dfsg1-6) unstable; urgency=low

  * Apply upstream patch to free /proc entries in the correct order.
    Thanks, Marc Dionne. (Closes: #493914)
  * Apply upstream deltas to support 2.6.27 kernels and to stop using
    COMMON_KERN_CFLAGS for all 2.6 kernels uniformly, which fixes
    problems on amd64 with newer kernels. Thanks, Björn Torkelsson.
    (LP: #267504)
  * Translation updates:
    - Swedish, thanks Martin Bagge. (Closes: #493120)

openafs (1.4.7.dfsg1-5) unstable; urgency=low

  * Drop support for hppa. We only have a param file for a 2.4 kernel,
    we were building with UCONTEXT which is stubbed out in glibc for hppa,
    and builds without UCONTEXT fail. The binaries we were building
    before didn't work and no one reported a bug, indicating no one was
    attempting to use OpenAFS on hppa.
  * When building the kernel module, use the setting of the ARCH
    environment or make variable, if present, in preference to uname -m to
    allow cross-compiles. Thanks, Jose Calhariz. (Closes: #492232)
  * Add Jason Edgecomb's copyright and license for man pages to
    debian/copyright.

openafs (1.4.7.dfsg1-4) unstable; urgency=low

  * Undo the move of up.pod to afs-up.pod in debian/rules clean rather
    than just deleting the file and causing the second build to fail.
    Thanks, Dominic Hargreaves. (Closes: #490752)
  * Don't use UCONTEXT on hppa; its glibc doesn't provide those
    functions. It's possible that OpenAFS isn't working properly on hppa
    these days, but as yet there have been no reports.
  * Suggest openafs-krb5 in openafs-client and mention it in the long
    description.

 -- Bj?rn Torkelsson <email address hidden> Wed, 24 Sep 2008 09:33:40 +0100