/usr/include/asm/* is not present in linux-libc-dev

I opened a task for this on linux-ports and updated the original bug as its also affected on the powerpc architecture. It strangely does not affect ia64 or hppa.

Debugging this issue with Luke Yelavich has revealed that building the package locally in a karmic chroot results in a functional package, as did building in a devirtualized Jaunty PPA.

Further problem, due to the broken kernel headers, the linux and linux-ports source packages are unbuildable:

make[3]: Nothing to be done for `/tmp/buildd/linux-2.6.30/Makefile'.
  HOSTCC scripts/basic/fixdep
In file included from /usr/include/sys/socket.h:40,
                 from /usr/include/netinet/in.h:25,
                 from /usr/include/arpa/inet.h:23,
                 from /tmp/buildd/linux-2.6.30/scripts/basic/fixdep.c:117:
/usr/include/bits/socket.h:354:24: error: asm/socket.h: No such file or directory
/tmp/buildd/linux-2.6.30/scripts/basic/fixdep.c: In function 'traps':
/tmp/buildd/linux-2.6.30/scripts/basic/fixdep.c:377: warning: dereferencing type-punned pointer will break strict-aliasing rules
/tmp/buildd/linux-2.6.30/scripts/basic/fixdep.c:379: warning: dereferencing type-punned pointer will break strict-aliasing rules
make[5]: *** [scripts/basic/fixdep] Error 1
make[4]: *** [scripts_basic] Error 2
make[3]: *** [sub-make] Error 2
make[2]: *** [silentoldconfig] Error 2
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory `/tmp/buildd/linux-2.6.30'

This appeared with 2.6.30-3.4, although the source changes between 2.6.30-2.3 and -3.4 do not seem obviously connected to this. I wonder if it has something to do with building against -2.3's linux-libc-dev?

A lot of packages now fail to build because they use /usr/linux/sys/*.h from glibc which uses indirectly parts of this package. Many other headers (X11, zlib, syslog, termcap, signal, netinet, glib, dialog, stdc++, ...) use the sys headers from glibc.

I would suggest a complete restart of all failed builds by the build server admins after this one is fixed.

Amit, you removed the alpha-1 milestone. Can we please make sure that it gets fixed in the next days, so that we actually have a chance of building other packages? It seems this breaks the build of like a third of the archive's packages right now :/

Thank you!

I think this is a bug in Karmic 'find' (it works correctly in Jaunty). One of the last steps after the kernel has collated the headers is this:

cd /home/rtg/kern/karmic/kern-64/ubuntu-karmic/debian/tmp-headers/install/include/ && find . -name '.' -o -name '.*' -prune -o -print | cpio -pvd --preserve-modification-time /home/rtg/kern/karmic/kern-64/ubuntu-karmic/debian/linux-libc-dev/usr/include/

If I run just the 'find' part by hand, i.e., 'cd /home/rtg/kern/karmic/kern-64/ubuntu-karmic/debian/tmp-headers/install/include/ && find . -name '.' -o -name '.*' -prune -o -print', it does not show any files in the include/asm directory.

See attached log file.

In fact, if I downgrade my Karmic chroot to findutils_4.4.0-2ubuntu4 then everything works as expected.

That was unintentional.

This is indeed a findutils bug, which I have diagnosed and will take up with upstream.

What's happening is that there's an "..install.cmd" file directly under include/, which matches the .* pattern given to find and therefore triggers the -prune action. Now, normally -prune is a no-op for files. Unfortunately, in this case the stat buffer find is using is undefined (because it uses FTS_NOSTAT as an optimisation) and so happens to contain stat information from the previous thing it touched, which happened to be a directory; it therefore gets confused and thinks ..install.cmd is a directory so sets the "stop_at_current_level" flag. This doesn't get cleared until the next time it exits a directory on its walk, which happens to be when it exits the asm/ directory.

Not a bug in the kernel build.

And yes, we'll definitely be doing a mass give-back of failed builds after this one!

This is specific to -prune; find's parser declares whether each predicate needs stat information or not, but does so incorrectly in the case of -prune. This is a relief since the fix can be quite well-targeted.

This bug was fixed in the package findutils - 4.4.1-1ubuntu2

---------------
findutils (4.4.1-1ubuntu2) karmic; urgency=low

  * 20_prune_stat.dpatch: find -prune now makes sure it has valid stat()
    information (LP: #373214).

 -- Colin Watson <email address hidden> Thu, 07 May 2009 22:19:04 +0100

Reopening. Of course it is a bug in the kernel _build_, just not in the kernel source. Now that findutils is fixed, we need a new upload of linux to build against the new findutils.

@Martin: It cannot be seen as fixed. A tool like findutils indirectly depends on the asm/* files from the linux-libc-dev package. Without these files it isn't possible to successful compile them. So someone from the ftp team must manually revert the version of the linux-libc-dev package (binary install) to have a working copy, compile then findutils and then do a rebuild to get a new linux-libc-dev package.

In case anyone is curious, the original bug was introduced in http://git.savannah.gnu.org/cgit/findutils.git/commit/?id=756b47b1609ecb0890f04302afba4c74779e263f due to https://savannah.gnu.org/bugs/?15531; I believe it was exposed recently due to http://git.savannah.gnu.org/cgit/findutils.git/commit/?id=cecfe3ef8e4db51d97f0cbed864f47893adc354e, which fixed a similar uninitialised stat data bug, but unfortunately the previous buggy code had the effect of catching the exact same property of the uninitialised stat data in question that ended up causing problems here ...

Moshroum: don't worry, we are familiar with the steps required to recover from this kind of bug and it's already in hand; it's just waiting for the relevant sysadmin in the US wakes up.

... or indeed "it's just waiting for the relevant sysadmin in the US to wake up" (now with correct grammar!).

This bug was fixed in the package linux-ports - 2.6.30-1.2

---------------
linux-ports (2.6.30-1.2) karmic; urgency=low

  [ Luke Yelavich ]

  * [Config] enable CC_STACKPROTECTOR=y for i386 as per karmic mainline
  * [Config] disabled CONFIG_EMBEDDED on i386
  * [Config] change CONFIG_MOUSE_PS2=m for sparc
  * add Build-Conflicts: findutils (= 4.4.1-1ubuntu1)
    - LP: #373214

  Rebase on top of karmic mainline 2.6.30-3.4:

  [ Kees Cook ]

  * SAUCE: [x86] implement cs-limit nx-emulation for ia32
    - LP: #369978

  [ Stefan Bader ]

  * SAUCE: input: Blacklist digitizers from joydev.c
    - LP: #300143

  [ Tim Gardner ]

  * [Config] Enabled CC_STACKPROTECTOR=y for all x86en
    - LP: #369152
  * SAUCE: Default to i915_modeset=0 if CONFIG_DRM_I915_KMS=y
  * [Config] CONFIG_DRM_I915_KMS=y
  * [Config] Set CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR to appropriate ARCH
    minimums

  [ Upstream Kernel Changes ]

  * rebased to 2.6.30-rc4

  [ Tim Gardner ]

  * [Config] armel: disable staging drivers, fixes FTBS
  * [Config] armel imx51: Disable CONFIG_MTD_NAND_MXC, fixes FTBS

  [ Upstream Kernel Changes ]

  * mpt2sas: Change reset_type enum to avoid namespace collision.
    Submitted upstream.

 -- Luke Yelavich <email address hidden> Fri, 08 May 2009 18:42:16 +1000

This bug was fixed in the package linux - 2.6.30-4.5

---------------
linux (2.6.30-4.5) karmic; urgency=low

  [ Colin Watson ]

  * Build-Conflict with findutils (= 4.4.1-1ubuntu1), to avoid
    /usr/include/asm/* going missing
    - LP: #373214

 -- Stefan Bader <email address hidden> Fri, 08 May 2009 11:09:08 +0200

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-lucid' to 'verification-done-lucid'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!