Ubuntu

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

Reported by Jonathan Riddell on 2009-05-07
26
This bug affects 3 people
Affects Status Importance Assigned to Milestone
findutils (Ubuntu)
Critical
Colin Watson
Karmic
Critical
Colin Watson
linux (Ubuntu)
Critical
Tim Gardner
Karmic
Critical
Tim Gardner
linux-ports (Ubuntu)
Undecided
Michael Casadevall
Karmic
Undecided
Michael Casadevall

Bug Description

On i386, amd64, and powerpc (via linux-ports), /usr/include/asm has no header files in it. According to the build logs, the header files are apparently installed, but are missing from linux-libc-dev, breaking any package that attempts to use the kernel headers.

Affected Architectures:
i386
amd64
lpia
armel
powerpc

Unaffected Architectures:
ia64
hppa

Unknown:
sparc (kernel currently FTBFSes)

Original bug report:
/usr/include/asm/error.h is missing from linux-libc-dev in linux_2.6.30-3.4

Tim Gardner (timg-tpi) on 2009-05-07
Changed in linux (Ubuntu):
assignee: nobody → Tim Gardner (timg-tpi)
status: New → In Progress
description: updated
summary: - errno.h missing
+ /usr/include/asm/* is not present in linux-libc-dev
Changed in linux-ports (Ubuntu):
importance: Undecided → Critical
milestone: none → karmic-alpha-1
status: New → In Progress
assignee: nobody → Michael Casadevall (mcasadevall)

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'

Changed in linux (Ubuntu):
importance: Undecided → Critical
milestone: none → karmic-alpha-1
Colin Watson (cjwatson) wrote :

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?

Amit Kucheria (amitk) on 2009-05-07
Changed in linux (Ubuntu):
assignee: Tim Gardner (timg-tpi) → Amit Kucheria (amitk)
importance: Critical → Undecided
milestone: karmic-alpha-1 → none
Amit Kucheria (amitk) on 2009-05-07
Changed in linux (Ubuntu):
importance: Undecided → Critical
deleted (to-delete) wrote :

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.

Martin Pitt (pitti) wrote :

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!

Tim Gardner (timg-tpi) wrote :

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.

Tim Gardner (timg-tpi) wrote :

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

Amit Kucheria (amitk) wrote :

That was unintentional.

Changed in linux (Ubuntu):
milestone: none → karmic-alpha-1
Colin Watson (cjwatson) wrote :

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.

Changed in findutils (Ubuntu):
assignee: nobody → Colin Watson (cjwatson)
importance: Undecided → Critical
milestone: none → karmic-alpha-1
status: New → In Progress
Tim Gardner (timg-tpi) wrote :

Not a bug in the kernel build.

Changed in linux (Ubuntu Karmic):
assignee: Amit Kucheria (amitk) → nobody
importance: Critical → Undecided
milestone: karmic-alpha-1 → none
status: In Progress → Invalid
Colin Watson (cjwatson) wrote :

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

Colin Watson (cjwatson) wrote :

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.

Launchpad Janitor (janitor) wrote :

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

Changed in findutils (Ubuntu Karmic):
status: In Progress → Fix Released
Amit Kucheria (amitk) on 2009-05-08
Changed in linux-ports (Ubuntu Karmic):
assignee: Michael Casadevall (mcasadevall) → nobody
importance: Critical → Undecided
status: In Progress → Invalid
Martin Pitt (pitti) wrote :

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.

Changed in linux (Ubuntu Karmic):
assignee: nobody → serc (rtg)
status: Invalid → In Progress
assignee: serc (rtg) → Tim Gardner (timg-tpi)
importance: Undecided → Critical
Changed in linux-ports (Ubuntu Karmic):
assignee: nobody → Michael Casadevall (mcasadevall)
status: Invalid → In Progress
deleted (to-delete) wrote :

@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.

Colin Watson (cjwatson) wrote :

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 ...

Colin Watson (cjwatson) wrote :

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.

Colin Watson (cjwatson) wrote :

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

Launchpad Janitor (janitor) wrote :

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

Changed in linux-ports (Ubuntu Karmic):
status: In Progress → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in linux (Ubuntu Karmic):
status: In Progress → Fix Released
Brad Figg (brad-figg) wrote :

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!

tags: added: verification-needed-lucid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.