> any progress on the m68k issue? m68k is not currently a release-candidate architecture, and moreover the build failure in question is caused by a broken kernel package on m68k. I think your priority should be to get the package building on hppa, powerpc, and sparc instead.
> On hppa, the package FTBFS due to code errors.
> On ia64 and powerpc, the used buildd are not capable of building
> ${arch}64 because the machine used is only ${arch}32, but the package
> will build fine if a capable machine is used.
All three of these failures (and now sparc) are caused by the per-flavor
modules not being available under the names the build is looking for. It
has nothing to do with 64-bit support: first of all, there is no such
*thing* as a 32-bit ia64 system, the architecture is natively 64-bit, and
second, any of these archs should be able to build modules for 64-bit
kernels just fine regardless of whether the userspace is 32-bit or 64-bit.
(For reference, the Debian sparc port is always a 32-bit userspace, and all
sparc buildds run a 64-bit kernel, and sparc is now showing the same
symptoms as the other failed archs.)
So this is very much not an architecture bug to sort out, this is a bug in
either unionfs or whatever tools it's using for building the modules. Since
other module packages aren't reporting the same problem, it looks like a
unionfs bug to me.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
