/usr/include/asm/* is not present in linux-libc-dev
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/
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) |
Michael Casadevall (mcasadevall) wrote : | #1 |
Michael Casadevall (mcasadevall) wrote : | #2 |
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/
HOSTCC scripts/
In file included from /usr/include/
/usr/include/
/tmp/buildd/
/tmp/buildd/
/tmp/buildd/
make[5]: *** [scripts/
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/
Changed in linux (Ubuntu): | |
importance: | Undecided → Critical |
milestone: | none → karmic-alpha-1 |
Colin Watson (cjwatson) wrote : | #3 |
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?
Changed in linux (Ubuntu): | |
assignee: | Tim Gardner (timg-tpi) → Amit Kucheria (amitk) |
importance: | Critical → Undecided |
milestone: | karmic-alpha-1 → none |
Changed in linux (Ubuntu): | |
importance: | Undecided → Critical |
deleted (to-delete) wrote : | #4 |
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 : | #5 |
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 : | #6 |
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/
If I run just the 'find' part by hand, i.e., 'cd /home/rtg/
See attached log file.
Tim Gardner (timg-tpi) wrote : | #7 |
In fact, if I downgrade my Karmic chroot to findutils_
Amit Kucheria (amitk) wrote : | #8 |
That was unintentional.
Changed in linux (Ubuntu): | |
milestone: | none → karmic-alpha-1 |
Colin Watson (cjwatson) wrote : | #9 |
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_
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 : | #10 |
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 : | #11 |
And yes, we'll definitely be doing a mass give-back of failed builds after this one!
Colin Watson (cjwatson) wrote : | #12 |
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 : | #13 |
This bug was fixed in the package findutils - 4.4.1-1ubuntu2
---------------
findutils (4.4.1-1ubuntu2) karmic; urgency=low
* 20_prune_
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 |
Changed in linux-ports (Ubuntu Karmic): | |
assignee: | Michael Casadevall (mcasadevall) → nobody |
importance: | Critical → Undecided |
status: | In Progress → Invalid |
Martin Pitt (pitti) wrote : | #14 |
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 : | #15 |
@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 : | #16 |
In case anyone is curious, the original bug was introduced in http://
Colin Watson (cjwatson) wrote : | #17 |
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 : | #18 |
... or indeed "it's just waiting for the relevant sysadmin in the US to wake up" (now with correct grammar!).
Launchpad Janitor (janitor) wrote : | #19 |
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_
* [Config] CONFIG_
* [Config] Set CONFIG_
minimums
[ Upstream Kernel Changes ]
* rebased to 2.6.30-rc4
[ Tim Gardner ]
* [Config] armel: disable staging drivers, fixes FTBS
* [Config] armel imx51: Disable CONFIG_
[ 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 : | #20 |
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/
- 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 : | #21 |
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-
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:/
tags: | added: verification-needed-lucid |
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.