Russ Allbery <r...@debian.org> writes:
> Dominic Hargreaves <d...@earth.li> writes:
>> Package: openafs-modules-dkms
>> Version: 1.6.1-2
>> Severity: important
>> During an upgrade from squeeze to wheezy, I saw this:
>> Setting up openafs-modules-dkms (1.6.1-2) ...
>> Removing old openafs-1.6.1 DKMS files...
> [...]
>> $ tail /var/lib/dkms/openafs/1.6.1/build/make.log
>> rm -f AFS_component_version_number.c.NEW
>> make[2]: Leaving directory `/var/lib/dkms/openafs/1.6.1/build/src/config'
>> gcc -O2 -I/var/lib/dkms/openafs/1.6.1/build/include -D_LARGEFILE64_SOURCE
>> -I. -c ./config.c
>> In file included from /usr/include/bits/errno.h:25,
>> from /usr/include/errno.h:36,
>> from ./config.c:16:
>> /usr/include/linux/errno.h:4:23: error: asm/errno.h: No such file or
>> directory
>> make[1]: *** [config.o] Error 1
>> make[1]: Leaving directory `/var/lib/dkms/openafs/1.6.1/build/src/config'
>> make: *** [all] Error 2
> I'm very confused, since I've been using openafs-dkms on wheezy for quite
> some time and have never seen any problem like this. It builds fine with
> the current source and the current kernel. I *think* this is something
> specific to your local machine, although I'm not sure what. Could you be
> missing the complete set of linux-header packages, perhaps?
> That file is provided by linux-headers-<version>-common:
Oh, wait, no, I misread that. It's the userspace part that it's building,
and it's missing the normal asm/errno.h in
/usr/include/i386-linux-gnu/asm/errno.h. This is almost certainly
something on your local system; I suspect that compiling a simple program
like:
#include <errno.h>
#include <stdio.h>
int main(void) { printf("hello\n"); return 0 }
would also fail.
Do you have a recent enough compiler to have multiarch support? I wonder
if what happened was that libc6-dev was upgraded but the compiler wasn't,
and dkms ran with a compiler that doesn't understand the multiarch include
paths. There's a Breaks in libc6-dev that tries to prevent this from
happening, but during a dist-upgrade, sometimes orderings get confused.
I'm not sure if dkms ensures that the compiler is fully configured before
kicking off its postinst. At a glance, it *looks* like it should, but
sometimes those dependencies get confusing.
The chain *should* be:
openafs-modules-dkms -> dkms -> gcc -> gcc-4.7
and libc6-dev Breaks old versions of all gcc-* packages earlier than
gcc-4.7 (4.7 always had multiarch support), so that *should* force either
gcc to be upgraded to point to gcc-4.7 or an earlier gcc-* package to be
upgraded to have multiarch support before dkms is considered configured,
and openafs-modules-dkms should not be willing to run its postinst until
dkms is fully configured....
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
