← Back to team overview

linaro-release team mailing list archive

[Bug 750585] Re: [FFe] support for making linux-libc-dev coinstallable under multiarch

 

This bug was fixed in the package linux - 2.6.38-8.42

---------------
linux (2.6.38-8.42) natty; urgency=low

  [ David Henningsson ]

  * SAUCE: (drop after 2.6.38) ALSA: HDA: Fix dock mic for Lenovo
    X220-tablet
    - LP: #751033

  [ Gustavo F. Padovan ]

  * SAUCE: Revert "Bluetooth: Add new PID for Atheros 3011"
    - LP: #720949

  [ Herton Ronaldo Krzesinski ]

  * SAUCE: (drop after 2.6.39) v4l: make sure drivers supply a zeroed
    struct v4l2_subdev
    - LP: #745213

  [ John Johansen ]

  * AppArmor: Fix masking of capabilities in complain mode
    - LP: #748656

  [ Leann Ogasawara ]

  * [Config] Disable CONFIG_RTS_PSTOR for armel, powerpc

  [ Manoj Iyer ]

  * SAUCE: (drop after 2.6.38) add support for Lenovo tablet ID (0xE6)
    - LP: #746652

  [ Steve Langasek ]

  * [Config] Make linux-libc-dev coinstallable under multiarch
    - LP: #750585

  [ Tim Gardner ]

  * [Config] CONFIG_RTS_PSTOR=m
    - LP: #698006

  [ Upstream Kernel Changes ]

  * Revert "tcp: disallow bind() to reuse addr/port"
    - LP: #731878
  * ALSA: HDA: Add dock mic quirk for Lenovo Thinkpad X220
    - LP: #746259
  * ALSA: HDA: New AD1984A model for Dell Precision R5500
    - LP: #741516
  * Input: sparse-keymap - report scancodes with key events
  * Input: sparse-keymap - report KEY_UNKNOWN for unknown scan codes
  * KVM: SVM: Load %gs earlier if CONFIG_X86_32_LAZY_GS=n
    - LP: #729085
  * watchdog: sp5100_tco.c: Check if firmware has set correct value in
    tcobase.
    - LP: #740011
  * staging: add rts_pstor for Realtek PCIE cardreader
    - LP: #698006
  * staging: fix rts_pstor build errors
    - LP: #698006
  * Staging: rts_pstor: fixed some brace code styling issues
    - LP: #698006
  * staging: rts_pstor: potential NULL dereference
    - LP: #698006
  * Staging: rts_pstor: fix read past end of buffer
    - LP: #698006
  * staging: rts_pstor: delete a function
    - LP: #698006
  * staging: rts_pstor: fix sparse warning
    - LP: #698006
  * staging: rts_pstor: fix a bug that a greenhouse sd card can't be
    recognized
    - LP: #698006
  * staging: rts_pstor: optimize kmalloc to kzalloc
    - LP: #698006
  * staging: rts_pstor: MSXC card power class
    - LP: #698006
  * staging: rts_pstor: modify initial card clock
    - LP: #698006
  * staging: rts_pstor: set lun_mode in a different place
    - LP: #698006
  * x86, hibernate: Initialize mmu_cr4_features during boot
    - LP: #752870
 -- Leann Ogasawara <leann.ogasawara@xxxxxxxxxxxxx>   Fri, 08 Apr 2011 09:24:59 -0700

** Changed in: linux (Ubuntu Natty)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Linaro
Release Team, which is a direct subscriber.
https://bugs.launchpad.net/bugs/750585

Title:
  [FFe] support for making linux-libc-dev coinstallable under multiarch

Status in “linux” package in Ubuntu:
  Fix Released
Status in “linux” source package in Natty:
  Fix Released
Status in “linux” source package in Oneiric:
  Fix Committed

Bug description:
  FFe justification: now that multiarch support for runtime libraries in
  the base system is available in the archive, the next step in this
  process is multiarch coinstallability of -dev packages.  Although most
  of the remaining work on multiarch -dev can and will take place in ppa
  for natty given where we are in the release cycle, any -dev package
  tree has at its root linux-libc-dev which is built from the 'linux'
  source package - the package which is updated more frequently than any
  other by SRU.  Rather than trying to keep up with SRUs, or
  artificially inflating the version of a linux-libc-dev-only package
  build in ppa, it would be welcome if a multiarch-ready linux-libc-dev
  could be included in the archive for natty.

  Risks: anything that looks directly in /usr/include/asm for headers
  will have problems with this change; anything that uses the system
  include path from the compiler will not.  My best efforts at examining
  the archive for this issue (see below for details) have turned up only
  four packages in main and universe that are affected: three C library
  implementations, and bash-completion.  Updating these packages in
  concert is manageable (patch for eglibc is ready, patches for the
  others are in preparation), but there's always some risk that the text
  search on package sources has missed something, and there wouldn't be
  room for another full archive rebuild before release to catch other
  breakage.

  
  Details:
  In order to have coinstallable multiarch -dev packages of any sort, linux-libc-dev first needs to be coinstallable since libc-dev depends on it.  This seems to be straightforward to achieve; only the asm directory needs to be moved to the multiarch directory path, all the other header files appear to be (sensibly) architecture-neutral and can be shared between architectures.

  The compiler will find /usr/include/<triplet>/asm for the
  corresponding architecture with no problems; I've done a number of
  test builds that work just fine this way.  The only trouble is with
  software that walks the filesystem looking for asm/<foo>.h includes
  instead of trusting the compiler to resolve them.  It's unlikely that
  software should need to do this since the asm headers should as a rule
  not be directly included from userspace anyway, but the chances are
  not zero. I didn't expect nearly as many packages to break as did by
  the move to /usr/lib/<triplet>, either, so it seems my faith in the
  sanity of upstream build systems is generally misplaced.  And I don't
  think we have time to discover any resulting issues with another
  archive test rebuild and fix the resulting packages before the natty
  release.