[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Andy Whitcroft]

** Changed in: linux-lts-saucy (Ubuntu Precise)
   Status: Fix Committed => Invalid

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in apt package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux-goldfish package in Ubuntu:
  Fix Released
Status in linux-lowlatency package in Ubuntu:
  Fix Released
Status in linux-lts-saucy package in Ubuntu:
  Invalid
Status in linux-meta package in Ubuntu:
  Fix Released
Status in linux-meta-goldfish package in Ubuntu:
  Fix Released
Status in linux-meta-lowlatency package in Ubuntu:
  Fix Released
Status in linux-meta-ppc package in Ubuntu:
  Fix Released
Status in linux-ppc package in Ubuntu:
  Fix Released
Status in apt source package in Precise:
  Fix Released
Status in linux source package in Precise:
  Fix Released
Status in linux-goldfish source package in Precise:
  Invalid
Status in linux-lowlatency source package in Precise:
  Fix Released
Status in linux-lts-saucy source package in Precise:
  Invalid
Status in linux-meta source package in Precise:
  Invalid
Status in linux-meta-goldfish source package in Precise:
  Invalid
Status in linux-meta-lowlatency source package in Precise:
  Invalid
Status in linux-meta-ppc source package in Precise:
  Invalid
Status in linux-ppc source package in Precise:
  Invalid
Status in apt source package in Saucy:
  Fix Released
Status in linux source package in Saucy:
  Fix Released
Status in linux-goldfish source package in Saucy:
  Fix Released
Status in linux-lowlatency source package in Saucy:
  Fix Released
Status in linux-lts-saucy source package in Saucy:
  Invalid
Status in linux-meta source package in Saucy:
  Fix Released
Status in linux-meta-goldfish source package in Saucy:
  Fix Released
Status in linux-meta-lowlatency source package in Saucy:
  Fix Released
Status in linux-meta-ppc source package in Saucy:
  Fix Released
Status in linux-ppc source package in Saucy:
  Fix Released

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source package.

  Further we would then be able to name the actual binary packages as produced 
by the 
  various source packages to be source package specific.  Thus we would have 
packages as
  below:

  linux-tools- -- coming out of the master branch
  linux-grouper-tools- -- coming out of the grouper branch

  These would be hidden from the user via the previously listed meta packages
  and would not be direct installation candidates.

  There is also an additional linux-tools-common package which represents
  the manual pages and the wrappers.  These would be only generated and
  installed from the master branch and all of the other flavours would
  (at least initially) share this package.

  The actual binaries will be moved over to names similar to below:

  /usr/lib/-tools-/

  with symlinks in as below for each flavour pointing to the above:

  /usr/lib/linux-tools/--

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1205284/+subscriptions

-- 
Ma

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Launchpad Bug Tracker]

This bug was fixed in the package linux-lowlatency - 3.2.0-57.59

---
linux-lowlatency (3.2.0-57.59) precise; urgency=low

  [ Kaj Ailomaa ]

  * rebase to Ubuntu-3.2.0-57.87
  * Release Tracking Bug
- LP: #1251435

  [ Ubuntu: 3.2.0-57.87 ]

  * Release Tracking Bug
- LP: #1250622
  * tools -- upgrade to common generic helper
- LP: #1205284
  * SAUCE: backport ARM seccomp-bpf support
- LP: #1183616
  * SAUCE: ACPI battery: fix compiler warning
- LP: #1247154
  * [Config] updateconfigs: CONFIG_HAVE_AOUT=n for arm
  * Revert "sctp: fix call to SCTP_CMD_PROCESS_SACK in
sctp_cmd_interpreter()"
- LP: #1249089
  * xen/blkback: Check device permissions before allowing OP_DISCARD
- LP: #1091187
- CVE-2013-2140
  * zram: allow request end to coincide with disksize
- LP: #1246664
  * ARM: 7373/1: add support for the generic syscall.h interface
- LP: #1183616
  * ARM: 7577/1: arch/add syscall_get_arch
- LP: #1183616
  * htb: fix sign extension bug
- LP: #1249089
  * net: check net.core.somaxconn sysctl values
- LP: #1249089
  * fib_trie: remove potential out of bound access
- LP: #1249089
  * tcp: cubic: fix overflow error in bictcp_update()
- LP: #1249089
  * tcp: cubic: fix bug in bictcp_acked()
- LP: #1249089
  * ipv6: don't stop backtracking in fib6_lookup_1 if subtree does not
match
- LP: #1249089
  * 8139cp: Add dma_mapping_error checking
- LP: #1249089
  * tun: signedness bug in tun_get_user()
- LP: #1249089
  * ipv6: remove max_addresses check from ipv6_create_tempaddr
- LP: #1249089
  * ipv6: drop packets with multiple fragmentation headers
- LP: #1249089
  * ipv6: Don't depend on per socket memory for neighbour discovery
messages
- LP: #1249089
  * net: bridge: convert MLDv2 Query MRC into msecs_to_jiffies for
max_delay
- LP: #1249089
  * ICMPv6: treat dest unreachable codes 5 and 6 as EACCES, not EPROTO
- LP: #1249089
  * tipc: fix lockdep warning during bearer initialization
- LP: #1249089
  * HID: hidraw: put old deallocation mechanism in place
- LP: #1249089
  * HID: hidraw: correctly deallocate memory on device disconnect
- LP: #1249089
  * xen-gnt: prevent adding duplicate gnt callbacks
- LP: #1249089
  * ath9k: always clear ps filter bit on new assoc
- LP: #1249089
  * libceph: unregister request in __map_request failed and nofail == false
- LP: #1249089
  * usb: config->desc.bLength may not exceed amount of data returned by the
device
- LP: #1249089
  * USB: cdc-wdm: fix race between interrupt handler and tasklet
- LP: #1249089
  * powerpc: Handle unaligned ldbrx/stdbrx
- LP: #1249089
  * intel-iommu: Fix leaks in pagetable freeing
- LP: #1249089
  * ath9k: fix rx descriptor related race condition
- LP: #1249089
  * ath9k: avoid accessing MRC registers on single-chain devices
- LP: #1249089
  * ASoC: wm8960: Fix PLL register writes
- LP: #1249089
  * rculist: list_first_or_null_rcu() should use list_entry_rcu()
- LP: #1249089
  * USB: mos7720: use GFP_ATOMIC under spinlock
- LP: #1249089
  * USB: mos7720: fix big-endian control requests
- LP: #1249089
  * staging: comedi: dt282x: dt282x_ai_insn_read() always fails
- LP: #1249089
  * usb: ehci-mxc: check for pdata before dereferencing
- LP: #1249089
  * mmc: tmio_mmc_dma: fix PIO fallback on SDHI
- LP: #1249089
  * rt2800: fix wrong TX power compensation
- LP: #1249089
  * usb: xhci: Disable runtime PM suspend for quirky controllers
- LP: #1249089
  * USB: OHCI: Allow runtime PM without system sleep
- LP: #1249089
  * ACPI / EC: Add ASUSTEK L4R to quirk list in order to validate ECDT
- LP: #1249089
  * HID: validate HID report id size
- LP: #1249089
- CVE-2013-2888
  * of: Fix missing memory initialization on FDT unflattening
- LP: #1249089
  * USB: fix build error when CONFIG_PM_SLEEP isn't enabled
- LP: #1249089
  * drm/edid: add quirk for Medion MD30217PG
- LP: #1249089
  * drm/radeon: update line buffer allocation for dce4.1/5
- LP: #1249089
  * drm/radeon: fix LCD record parsing
- LP: #1249089
  * drm/radeon: fix resume on some rs4xx boards (v2)
- LP: #1249089
  * drm/radeon: fix handling of variable sized arrays for router objects
- LP: #1249089
  * ALSA: hda - hdmi: Fallback to ALSA allocation when selecting CA
- LP: #1249089
  * fuse: postpone end_page_writeback() in fuse_writepage_locked()
- LP: #1249089
  * fuse: invalidate inode attributes on xattr modification
- LP: #1249089
  * fuse: hotfix truncate_pagecache() issue
- LP: #1249089
  * hdpvr: register the video node at the end of probe
- LP: #1249089
  * hdpvr: fix iteration over uninitialized lists in hdpvr_probe()
- LP: #1249089
  * fuse: readdir: check for slash in names
- LP: #1249089
  * HID: pantherlord: validate output report details
- LP: #1249089
- CVE-2013-2892
  * HID: ntrig: validate feat

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Launchpad Bug Tracker]

This bug was fixed in the package linux-lowlatency - 3.2.0-57.59

---
linux-lowlatency (3.2.0-57.59) precise; urgency=low

  [ Kaj Ailomaa ]

  * rebase to Ubuntu-3.2.0-57.87
  * Release Tracking Bug
- LP: #1251435

  [ Ubuntu: 3.2.0-57.87 ]

  * Release Tracking Bug
- LP: #1250622
  * tools -- upgrade to common generic helper
- LP: #1205284
  * SAUCE: backport ARM seccomp-bpf support
- LP: #1183616
  * SAUCE: ACPI battery: fix compiler warning
- LP: #1247154
  * [Config] updateconfigs: CONFIG_HAVE_AOUT=n for arm
  * Revert "sctp: fix call to SCTP_CMD_PROCESS_SACK in
sctp_cmd_interpreter()"
- LP: #1249089
  * xen/blkback: Check device permissions before allowing OP_DISCARD
- LP: #1091187
- CVE-2013-2140
  * zram: allow request end to coincide with disksize
- LP: #1246664
  * ARM: 7373/1: add support for the generic syscall.h interface
- LP: #1183616
  * ARM: 7577/1: arch/add syscall_get_arch
- LP: #1183616
  * htb: fix sign extension bug
- LP: #1249089
  * net: check net.core.somaxconn sysctl values
- LP: #1249089
  * fib_trie: remove potential out of bound access
- LP: #1249089
  * tcp: cubic: fix overflow error in bictcp_update()
- LP: #1249089
  * tcp: cubic: fix bug in bictcp_acked()
- LP: #1249089
  * ipv6: don't stop backtracking in fib6_lookup_1 if subtree does not
match
- LP: #1249089
  * 8139cp: Add dma_mapping_error checking
- LP: #1249089
  * tun: signedness bug in tun_get_user()
- LP: #1249089
  * ipv6: remove max_addresses check from ipv6_create_tempaddr
- LP: #1249089
  * ipv6: drop packets with multiple fragmentation headers
- LP: #1249089
  * ipv6: Don't depend on per socket memory for neighbour discovery
messages
- LP: #1249089
  * net: bridge: convert MLDv2 Query MRC into msecs_to_jiffies for
max_delay
- LP: #1249089
  * ICMPv6: treat dest unreachable codes 5 and 6 as EACCES, not EPROTO
- LP: #1249089
  * tipc: fix lockdep warning during bearer initialization
- LP: #1249089
  * HID: hidraw: put old deallocation mechanism in place
- LP: #1249089
  * HID: hidraw: correctly deallocate memory on device disconnect
- LP: #1249089
  * xen-gnt: prevent adding duplicate gnt callbacks
- LP: #1249089
  * ath9k: always clear ps filter bit on new assoc
- LP: #1249089
  * libceph: unregister request in __map_request failed and nofail == false
- LP: #1249089
  * usb: config->desc.bLength may not exceed amount of data returned by the
device
- LP: #1249089
  * USB: cdc-wdm: fix race between interrupt handler and tasklet
- LP: #1249089
  * powerpc: Handle unaligned ldbrx/stdbrx
- LP: #1249089
  * intel-iommu: Fix leaks in pagetable freeing
- LP: #1249089
  * ath9k: fix rx descriptor related race condition
- LP: #1249089
  * ath9k: avoid accessing MRC registers on single-chain devices
- LP: #1249089
  * ASoC: wm8960: Fix PLL register writes
- LP: #1249089
  * rculist: list_first_or_null_rcu() should use list_entry_rcu()
- LP: #1249089
  * USB: mos7720: use GFP_ATOMIC under spinlock
- LP: #1249089
  * USB: mos7720: fix big-endian control requests
- LP: #1249089
  * staging: comedi: dt282x: dt282x_ai_insn_read() always fails
- LP: #1249089
  * usb: ehci-mxc: check for pdata before dereferencing
- LP: #1249089
  * mmc: tmio_mmc_dma: fix PIO fallback on SDHI
- LP: #1249089
  * rt2800: fix wrong TX power compensation
- LP: #1249089
  * usb: xhci: Disable runtime PM suspend for quirky controllers
- LP: #1249089
  * USB: OHCI: Allow runtime PM without system sleep
- LP: #1249089
  * ACPI / EC: Add ASUSTEK L4R to quirk list in order to validate ECDT
- LP: #1249089
  * HID: validate HID report id size
- LP: #1249089
- CVE-2013-2888
  * of: Fix missing memory initialization on FDT unflattening
- LP: #1249089
  * USB: fix build error when CONFIG_PM_SLEEP isn't enabled
- LP: #1249089
  * drm/edid: add quirk for Medion MD30217PG
- LP: #1249089
  * drm/radeon: update line buffer allocation for dce4.1/5
- LP: #1249089
  * drm/radeon: fix LCD record parsing
- LP: #1249089
  * drm/radeon: fix resume on some rs4xx boards (v2)
- LP: #1249089
  * drm/radeon: fix handling of variable sized arrays for router objects
- LP: #1249089
  * ALSA: hda - hdmi: Fallback to ALSA allocation when selecting CA
- LP: #1249089
  * fuse: postpone end_page_writeback() in fuse_writepage_locked()
- LP: #1249089
  * fuse: invalidate inode attributes on xattr modification
- LP: #1249089
  * fuse: hotfix truncate_pagecache() issue
- LP: #1249089
  * hdpvr: register the video node at the end of probe
- LP: #1249089
  * hdpvr: fix iteration over uninitialized lists in hdpvr_probe()
- LP: #1249089
  * fuse: readdir: check for slash in names
- LP: #1249089
  * HID: pantherlord: validate output report details
- LP: #1249089
- CVE-2013-2892
  * HID: ntrig: validate feat

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Launchpad Bug Tracker]

This bug was fixed in the package linux - 3.2.0-57.87

---
linux (3.2.0-57.87) precise; urgency=low

  [Steve Conklin]

  * Release Tracking Bug
- LP: #1250622

  [ Andy Whitcroft ]

  * tools -- upgrade to common generic helper
- LP: #1205284

  [ Kees Cook ]

  * SAUCE: backport ARM seccomp-bpf support
- LP: #1183616

  [ Luis Henriques ]

  * SAUCE: ACPI battery: fix compiler warning
- LP: #1247154

  [ Tim Gardner ]

  * [Config] updateconfigs: CONFIG_HAVE_AOUT=n for arm

  [ Upstream Kernel Changes ]

  * Revert "sctp: fix call to SCTP_CMD_PROCESS_SACK in
sctp_cmd_interpreter()"
- LP: #1249089
  * xen/blkback: Check device permissions before allowing OP_DISCARD
- LP: #1091187
- CVE-2013-2140
  * zram: allow request end to coincide with disksize
- LP: #1246664
  * ARM: 7373/1: add support for the generic syscall.h interface
- LP: #1183616
  * ARM: 7577/1: arch/add syscall_get_arch
- LP: #1183616
  * htb: fix sign extension bug
- LP: #1249089
  * net: check net.core.somaxconn sysctl values
- LP: #1249089
  * fib_trie: remove potential out of bound access
- LP: #1249089
  * tcp: cubic: fix overflow error in bictcp_update()
- LP: #1249089
  * tcp: cubic: fix bug in bictcp_acked()
- LP: #1249089
  * ipv6: don't stop backtracking in fib6_lookup_1 if subtree does not
match
- LP: #1249089
  * 8139cp: Add dma_mapping_error checking
- LP: #1249089
  * tun: signedness bug in tun_get_user()
- LP: #1249089
  * ipv6: remove max_addresses check from ipv6_create_tempaddr
- LP: #1249089
  * ipv6: drop packets with multiple fragmentation headers
- LP: #1249089
  * ipv6: Don't depend on per socket memory for neighbour discovery
messages
- LP: #1249089
  * net: bridge: convert MLDv2 Query MRC into msecs_to_jiffies for
max_delay
- LP: #1249089
  * ICMPv6: treat dest unreachable codes 5 and 6 as EACCES, not EPROTO
- LP: #1249089
  * tipc: fix lockdep warning during bearer initialization
- LP: #1249089
  * HID: hidraw: put old deallocation mechanism in place
- LP: #1249089
  * HID: hidraw: correctly deallocate memory on device disconnect
- LP: #1249089
  * xen-gnt: prevent adding duplicate gnt callbacks
- LP: #1249089
  * ath9k: always clear ps filter bit on new assoc
- LP: #1249089
  * libceph: unregister request in __map_request failed and nofail == false
- LP: #1249089
  * usb: config->desc.bLength may not exceed amount of data returned by the
device
- LP: #1249089
  * USB: cdc-wdm: fix race between interrupt handler and tasklet
- LP: #1249089
  * powerpc: Handle unaligned ldbrx/stdbrx
- LP: #1249089
  * intel-iommu: Fix leaks in pagetable freeing
- LP: #1249089
  * ath9k: fix rx descriptor related race condition
- LP: #1249089
  * ath9k: avoid accessing MRC registers on single-chain devices
- LP: #1249089
  * ASoC: wm8960: Fix PLL register writes
- LP: #1249089
  * rculist: list_first_or_null_rcu() should use list_entry_rcu()
- LP: #1249089
  * USB: mos7720: use GFP_ATOMIC under spinlock
- LP: #1249089
  * USB: mos7720: fix big-endian control requests
- LP: #1249089
  * staging: comedi: dt282x: dt282x_ai_insn_read() always fails
- LP: #1249089
  * usb: ehci-mxc: check for pdata before dereferencing
- LP: #1249089
  * mmc: tmio_mmc_dma: fix PIO fallback on SDHI
- LP: #1249089
  * rt2800: fix wrong TX power compensation
- LP: #1249089
  * usb: xhci: Disable runtime PM suspend for quirky controllers
- LP: #1249089
  * USB: OHCI: Allow runtime PM without system sleep
- LP: #1249089
  * ACPI / EC: Add ASUSTEK L4R to quirk list in order to validate ECDT
- LP: #1249089
  * HID: validate HID report id size
- LP: #1249089
- CVE-2013-2888
  * of: Fix missing memory initialization on FDT unflattening
- LP: #1249089
  * USB: fix build error when CONFIG_PM_SLEEP isn't enabled
- LP: #1249089
  * drm/edid: add quirk for Medion MD30217PG
- LP: #1249089
  * drm/radeon: update line buffer allocation for dce4.1/5
- LP: #1249089
  * drm/radeon: fix LCD record parsing
- LP: #1249089
  * drm/radeon: fix resume on some rs4xx boards (v2)
- LP: #1249089
  * drm/radeon: fix handling of variable sized arrays for router objects
- LP: #1249089
  * ALSA: hda - hdmi: Fallback to ALSA allocation when selecting CA
- LP: #1249089
  * fuse: postpone end_page_writeback() in fuse_writepage_locked()
- LP: #1249089
  * fuse: invalidate inode attributes on xattr modification
- LP: #1249089
  * fuse: hotfix truncate_pagecache() issue
- LP: #1249089
  * hdpvr: register the video node at the end of probe
- LP: #1249089
  * hdpvr: fix iteration over uninitialized lists in hdpvr_probe()
- LP: #1249089
  * fuse: readdir: check for slash in names
- LP: #1249089
  * HID: pantherlord: validate output report details
- LP: #1249089
- CVE-2013-2892
  * HID: ntrig: validate feature report 

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Launchpad Bug Tracker]

This bug was fixed in the package apt - 0.8.16~exp12ubuntu10.16

---
apt (0.8.16~exp12ubuntu10.16) precise; urgency=low

  * Keep linux-tools packages matching installed kernels (LP: #1205284)
 -- Adam ConradFri, 15 Nov 2013 15:16:45 +

** Changed in: apt (Ubuntu Precise)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “apt” package in Ubuntu:
  Fix Released
Status in “linux” package in Ubuntu:
  Fix Released
Status in “linux-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-lowlatency” package in Ubuntu:
  Fix Released
Status in “linux-lts-saucy” package in Ubuntu:
  Invalid
Status in “linux-meta” package in Ubuntu:
  Fix Released
Status in “linux-meta-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-meta-lowlatency” package in Ubuntu:
  Fix Released
Status in “linux-meta-ppc” package in Ubuntu:
  Fix Released
Status in “linux-ppc” package in Ubuntu:
  Fix Released
Status in “apt” source package in Precise:
  Fix Released
Status in “linux” source package in Precise:
  Fix Committed
Status in “linux-goldfish” source package in Precise:
  Invalid
Status in “linux-lowlatency” source package in Precise:
  Invalid
Status in “linux-lts-saucy” source package in Precise:
  Fix Committed
Status in “linux-meta” source package in Precise:
  Invalid
Status in “linux-meta-goldfish” source package in Precise:
  Invalid
Status in “linux-meta-lowlatency” source package in Precise:
  Invalid
Status in “linux-meta-ppc” source package in Precise:
  Invalid
Status in “linux-ppc” source package in Precise:
  Invalid
Status in “apt” source package in Saucy:
  Fix Released
Status in “linux” source package in Saucy:
  Fix Released
Status in “linux-goldfish” source package in Saucy:
  Fix Released
Status in “linux-lowlatency” source package in Saucy:
  Fix Released
Status in “linux-lts-saucy” source package in Saucy:
  Invalid
Status in “linux-meta” source package in Saucy:
  Fix Released
Status in “linux-meta-goldfish” source package in Saucy:
  Fix Released
Status in “linux-meta-lowlatency” source package in Saucy:
  Fix Released
Status in “linux-meta-ppc” source package in Saucy:
  Fix Released
Status in “linux-ppc” source package in Saucy:
  Fix Released

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source package.

  Further we would then be able to name the actual binary packages as produced 
by the 
  various source packages to be source package specific.  Thus we would have 
packages as
  below:

  linux-tools- -- coming out of the master branch
  linux-grouper-tools- -- coming out of the grouper branch

  These would be hidden from the user via the previously listed meta packages
  and would not be direct installation candidates.

  There is also an additional linux-tools-common package which represents
  the manual pages and the wrappers.  These would be only generated and
  installed from the master branch and all of the other flavours would
  (at least initially) share this package.

  The act

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Andy Whitcroft]

confirming that the linux-lts-saucy kernel installs tools to the
expected locations.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “apt” package in Ubuntu:
  Fix Released
Status in “linux” package in Ubuntu:
  Fix Released
Status in “linux-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-lowlatency” package in Ubuntu:
  Fix Released
Status in “linux-lts-saucy” package in Ubuntu:
  Invalid
Status in “linux-meta” package in Ubuntu:
  Fix Released
Status in “linux-meta-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-meta-lowlatency” package in Ubuntu:
  Fix Released
Status in “linux-meta-ppc” package in Ubuntu:
  Fix Released
Status in “linux-ppc” package in Ubuntu:
  Fix Released
Status in “apt” source package in Precise:
  Fix Committed
Status in “linux” source package in Precise:
  Fix Committed
Status in “linux-goldfish” source package in Precise:
  Invalid
Status in “linux-lowlatency” source package in Precise:
  Invalid
Status in “linux-lts-saucy” source package in Precise:
  Fix Committed
Status in “linux-meta” source package in Precise:
  Invalid
Status in “linux-meta-goldfish” source package in Precise:
  Invalid
Status in “linux-meta-lowlatency” source package in Precise:
  Invalid
Status in “linux-meta-ppc” source package in Precise:
  Invalid
Status in “linux-ppc” source package in Precise:
  Invalid
Status in “apt” source package in Saucy:
  Fix Released
Status in “linux” source package in Saucy:
  Fix Released
Status in “linux-goldfish” source package in Saucy:
  Fix Released
Status in “linux-lowlatency” source package in Saucy:
  Fix Released
Status in “linux-lts-saucy” source package in Saucy:
  Invalid
Status in “linux-meta” source package in Saucy:
  Fix Released
Status in “linux-meta-goldfish” source package in Saucy:
  Fix Released
Status in “linux-meta-lowlatency” source package in Saucy:
  Fix Released
Status in “linux-meta-ppc” source package in Saucy:
  Fix Released
Status in “linux-ppc” source package in Saucy:
  Fix Released

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source package.

  Further we would then be able to name the actual binary packages as produced 
by the 
  various source packages to be source package specific.  Thus we would have 
packages as
  below:

  linux-tools- -- coming out of the master branch
  linux-grouper-tools- -- coming out of the grouper branch

  These would be hidden from the user via the previously listed meta packages
  and would not be direct installation candidates.

  There is also an additional linux-tools-common package which represents
  the manual pages and the wrappers.  These would be only generated and
  installed from the master branch and all of the other flavours would
  (at least initially) share this package.

  The actual binaries will be moved over to names similar to below:

  /usr/lib/-tools-/

  with symlinks in as below for each flavour pointing to the above:

  /usr/lib/linux-tools/--

To manage notifications about this bug go to:
https://bugs.launchpa

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Andy Whitcroft]

confirming that the apt changes correctly add the linux-tools package
for the lts-saucy kernels into the hold list.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “apt” package in Ubuntu:
  Fix Released
Status in “linux” package in Ubuntu:
  Fix Released
Status in “linux-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-lowlatency” package in Ubuntu:
  Fix Released
Status in “linux-lts-saucy” package in Ubuntu:
  Invalid
Status in “linux-meta” package in Ubuntu:
  Fix Released
Status in “linux-meta-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-meta-lowlatency” package in Ubuntu:
  Fix Released
Status in “linux-meta-ppc” package in Ubuntu:
  Fix Released
Status in “linux-ppc” package in Ubuntu:
  Fix Released
Status in “apt” source package in Precise:
  Fix Committed
Status in “linux” source package in Precise:
  Fix Committed
Status in “linux-goldfish” source package in Precise:
  Invalid
Status in “linux-lowlatency” source package in Precise:
  Invalid
Status in “linux-lts-saucy” source package in Precise:
  Fix Committed
Status in “linux-meta” source package in Precise:
  Invalid
Status in “linux-meta-goldfish” source package in Precise:
  Invalid
Status in “linux-meta-lowlatency” source package in Precise:
  Invalid
Status in “linux-meta-ppc” source package in Precise:
  Invalid
Status in “linux-ppc” source package in Precise:
  Invalid
Status in “apt” source package in Saucy:
  Fix Released
Status in “linux” source package in Saucy:
  Fix Released
Status in “linux-goldfish” source package in Saucy:
  Fix Released
Status in “linux-lowlatency” source package in Saucy:
  Fix Released
Status in “linux-lts-saucy” source package in Saucy:
  Invalid
Status in “linux-meta” source package in Saucy:
  Fix Released
Status in “linux-meta-goldfish” source package in Saucy:
  Fix Released
Status in “linux-meta-lowlatency” source package in Saucy:
  Fix Released
Status in “linux-meta-ppc” source package in Saucy:
  Fix Released
Status in “linux-ppc” source package in Saucy:
  Fix Released

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source package.

  Further we would then be able to name the actual binary packages as produced 
by the 
  various source packages to be source package specific.  Thus we would have 
packages as
  below:

  linux-tools- -- coming out of the master branch
  linux-grouper-tools- -- coming out of the grouper branch

  These would be hidden from the user via the previously listed meta packages
  and would not be direct installation candidates.

  There is also an additional linux-tools-common package which represents
  the manual pages and the wrappers.  These would be only generated and
  installed from the master branch and all of the other flavours would
  (at least initially) share this package.

  The actual binaries will be moved over to names similar to below:

  /usr/lib/-tools-/

  with symlinks in as below for each flavour pointing to the above:

  /usr/lib/linux-tools/--

To manage notifications about this b

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Andy Whitcroft]

confirming that the linux changes correctly update the wrappers for perf
et al.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “apt” package in Ubuntu:
  Fix Released
Status in “linux” package in Ubuntu:
  Fix Released
Status in “linux-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-lowlatency” package in Ubuntu:
  Fix Released
Status in “linux-lts-saucy” package in Ubuntu:
  Invalid
Status in “linux-meta” package in Ubuntu:
  Fix Released
Status in “linux-meta-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-meta-lowlatency” package in Ubuntu:
  Fix Released
Status in “linux-meta-ppc” package in Ubuntu:
  Fix Released
Status in “linux-ppc” package in Ubuntu:
  Fix Released
Status in “apt” source package in Precise:
  Fix Committed
Status in “linux” source package in Precise:
  Fix Committed
Status in “linux-goldfish” source package in Precise:
  Invalid
Status in “linux-lowlatency” source package in Precise:
  Invalid
Status in “linux-lts-saucy” source package in Precise:
  Fix Committed
Status in “linux-meta” source package in Precise:
  Invalid
Status in “linux-meta-goldfish” source package in Precise:
  Invalid
Status in “linux-meta-lowlatency” source package in Precise:
  Invalid
Status in “linux-meta-ppc” source package in Precise:
  Invalid
Status in “linux-ppc” source package in Precise:
  Invalid
Status in “apt” source package in Saucy:
  Fix Released
Status in “linux” source package in Saucy:
  Fix Released
Status in “linux-goldfish” source package in Saucy:
  Fix Released
Status in “linux-lowlatency” source package in Saucy:
  Fix Released
Status in “linux-lts-saucy” source package in Saucy:
  Invalid
Status in “linux-meta” source package in Saucy:
  Fix Released
Status in “linux-meta-goldfish” source package in Saucy:
  Fix Released
Status in “linux-meta-lowlatency” source package in Saucy:
  Fix Released
Status in “linux-meta-ppc” source package in Saucy:
  Fix Released
Status in “linux-ppc” source package in Saucy:
  Fix Released

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source package.

  Further we would then be able to name the actual binary packages as produced 
by the 
  various source packages to be source package specific.  Thus we would have 
packages as
  below:

  linux-tools- -- coming out of the master branch
  linux-grouper-tools- -- coming out of the grouper branch

  These would be hidden from the user via the previously listed meta packages
  and would not be direct installation candidates.

  There is also an additional linux-tools-common package which represents
  the manual pages and the wrappers.  These would be only generated and
  installed from the master branch and all of the other flavours would
  (at least initially) share this package.

  The actual binaries will be moved over to names similar to below:

  /usr/lib/-tools-/

  with symlinks in as below for each flavour pointing to the above:

  /usr/lib/linux-tools/--

To manage notifications about this bug go to:
https://bugs.launchpad.net

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Tim Gardner]

** Tags removed: verification-needed-precise
** Tags added: verification-done-precise

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “apt” package in Ubuntu:
  Fix Released
Status in “linux” package in Ubuntu:
  Fix Released
Status in “linux-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-lowlatency” package in Ubuntu:
  Fix Released
Status in “linux-lts-saucy” package in Ubuntu:
  Invalid
Status in “linux-meta” package in Ubuntu:
  Fix Released
Status in “linux-meta-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-meta-lowlatency” package in Ubuntu:
  Fix Released
Status in “linux-meta-ppc” package in Ubuntu:
  Fix Released
Status in “linux-ppc” package in Ubuntu:
  Fix Released
Status in “apt” source package in Precise:
  Fix Committed
Status in “linux” source package in Precise:
  Fix Committed
Status in “linux-goldfish” source package in Precise:
  Invalid
Status in “linux-lowlatency” source package in Precise:
  Invalid
Status in “linux-lts-saucy” source package in Precise:
  Fix Committed
Status in “linux-meta” source package in Precise:
  Invalid
Status in “linux-meta-goldfish” source package in Precise:
  Invalid
Status in “linux-meta-lowlatency” source package in Precise:
  Invalid
Status in “linux-meta-ppc” source package in Precise:
  Invalid
Status in “linux-ppc” source package in Precise:
  Invalid
Status in “apt” source package in Saucy:
  Fix Released
Status in “linux” source package in Saucy:
  Fix Released
Status in “linux-goldfish” source package in Saucy:
  Fix Released
Status in “linux-lowlatency” source package in Saucy:
  Fix Released
Status in “linux-lts-saucy” source package in Saucy:
  Invalid
Status in “linux-meta” source package in Saucy:
  Fix Released
Status in “linux-meta-goldfish” source package in Saucy:
  Fix Released
Status in “linux-meta-lowlatency” source package in Saucy:
  Fix Released
Status in “linux-meta-ppc” source package in Saucy:
  Fix Released
Status in “linux-ppc” source package in Saucy:
  Fix Released

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source package.

  Further we would then be able to name the actual binary packages as produced 
by the 
  various source packages to be source package specific.  Thus we would have 
packages as
  below:

  linux-tools- -- coming out of the master branch
  linux-grouper-tools- -- coming out of the grouper branch

  These would be hidden from the user via the previously listed meta packages
  and would not be direct installation candidates.

  There is also an additional linux-tools-common package which represents
  the manual pages and the wrappers.  These would be only generated and
  installed from the master branch and all of the other flavours would
  (at least initially) share this package.

  The actual binaries will be moved over to names similar to below:

  /usr/lib/-tools-/

  with symlinks in as below for each flavour pointing to the above:

  /usr/lib/linux-tools/--

To manage notifications about this bug go to:
https://bugs.launchp

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Brad Figg]

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-
precise' to 'verification-done-precise'.

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

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “apt” package in Ubuntu:
  Fix Released
Status in “linux” package in Ubuntu:
  Fix Released
Status in “linux-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-lowlatency” package in Ubuntu:
  Fix Released
Status in “linux-lts-saucy” package in Ubuntu:
  Invalid
Status in “linux-meta” package in Ubuntu:
  Fix Released
Status in “linux-meta-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-meta-lowlatency” package in Ubuntu:
  Fix Released
Status in “linux-meta-ppc” package in Ubuntu:
  Fix Released
Status in “linux-ppc” package in Ubuntu:
  Fix Released
Status in “apt” source package in Precise:
  Fix Committed
Status in “linux” source package in Precise:
  Fix Committed
Status in “linux-goldfish” source package in Precise:
  Invalid
Status in “linux-lowlatency” source package in Precise:
  Invalid
Status in “linux-lts-saucy” source package in Precise:
  Fix Committed
Status in “linux-meta” source package in Precise:
  Invalid
Status in “linux-meta-goldfish” source package in Precise:
  Invalid
Status in “linux-meta-lowlatency” source package in Precise:
  Invalid
Status in “linux-meta-ppc” source package in Precise:
  Invalid
Status in “linux-ppc” source package in Precise:
  Invalid
Status in “apt” source package in Saucy:
  Fix Released
Status in “linux” source package in Saucy:
  Fix Released
Status in “linux-goldfish” source package in Saucy:
  Fix Released
Status in “linux-lowlatency” source package in Saucy:
  Fix Released
Status in “linux-lts-saucy” source package in Saucy:
  Invalid
Status in “linux-meta” source package in Saucy:
  Fix Released
Status in “linux-meta-goldfish” source package in Saucy:
  Fix Released
Status in “linux-meta-lowlatency” source package in Saucy:
  Fix Released
Status in “linux-meta-ppc” source package in Saucy:
  Fix Released
Status in “linux-ppc” source package in Saucy:
  Fix Released

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source package.

  Further we would then be able to name the actual binary packages as produced 
by the 
  various source packages to be source package specific.  Thus we would have 
packages as
  below:

  linux-tools- -- coming out of the master branch
  linux-grouper-tools- -- coming out of the grouper branch

  These would be hidden from the user via the previously listed meta packages
  and would not be direct installation candidates.

  There is also an additional linux-tools-common package which re

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Launchpad Bug Tracker]

** Branch linked: lp:ubuntu/precise-proposed/apt

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “apt” package in Ubuntu:
  Fix Released
Status in “linux” package in Ubuntu:
  Fix Released
Status in “linux-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-lowlatency” package in Ubuntu:
  Fix Released
Status in “linux-lts-saucy” package in Ubuntu:
  Invalid
Status in “linux-meta” package in Ubuntu:
  Fix Released
Status in “linux-meta-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-meta-lowlatency” package in Ubuntu:
  Fix Released
Status in “linux-meta-ppc” package in Ubuntu:
  Fix Released
Status in “linux-ppc” package in Ubuntu:
  Fix Released
Status in “apt” source package in Precise:
  Fix Committed
Status in “linux” source package in Precise:
  Fix Committed
Status in “linux-goldfish” source package in Precise:
  Invalid
Status in “linux-lowlatency” source package in Precise:
  Invalid
Status in “linux-lts-saucy” source package in Precise:
  Fix Committed
Status in “linux-meta” source package in Precise:
  Invalid
Status in “linux-meta-goldfish” source package in Precise:
  Invalid
Status in “linux-meta-lowlatency” source package in Precise:
  Invalid
Status in “linux-meta-ppc” source package in Precise:
  Invalid
Status in “linux-ppc” source package in Precise:
  Invalid
Status in “apt” source package in Saucy:
  Fix Released
Status in “linux” source package in Saucy:
  Fix Released
Status in “linux-goldfish” source package in Saucy:
  Fix Released
Status in “linux-lowlatency” source package in Saucy:
  Fix Released
Status in “linux-lts-saucy” source package in Saucy:
  Invalid
Status in “linux-meta” source package in Saucy:
  Fix Released
Status in “linux-meta-goldfish” source package in Saucy:
  Fix Released
Status in “linux-meta-lowlatency” source package in Saucy:
  Fix Released
Status in “linux-meta-ppc” source package in Saucy:
  Fix Released
Status in “linux-ppc” source package in Saucy:
  Fix Released

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source package.

  Further we would then be able to name the actual binary packages as produced 
by the 
  various source packages to be source package specific.  Thus we would have 
packages as
  below:

  linux-tools- -- coming out of the master branch
  linux-grouper-tools- -- coming out of the grouper branch

  These would be hidden from the user via the previously listed meta packages
  and would not be direct installation candidates.

  There is also an additional linux-tools-common package which represents
  the manual pages and the wrappers.  These would be only generated and
  installed from the master branch and all of the other flavours would
  (at least initially) share this package.

  The actual binaries will be moved over to names similar to below:

  /usr/lib/-tools-/

  with symlinks in as below for each flavour pointing to the above:

  /usr/lib/linux-tools/--

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/120528

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Colin Watson]

Hello Andy, or anyone else affected,

Accepted apt into precise-proposed. The package will build now and be
available at
http://launchpad.net/ubuntu/+source/apt/0.8.16~exp12ubuntu10.16 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed.  Your feedback will aid us getting this update
out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-needed to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Changed in: apt (Ubuntu Precise)
   Status: In Progress => Fix Committed

** Tags added: verification-needed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “apt” package in Ubuntu:
  Fix Released
Status in “linux” package in Ubuntu:
  Fix Released
Status in “linux-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-lowlatency” package in Ubuntu:
  Fix Released
Status in “linux-lts-saucy” package in Ubuntu:
  Invalid
Status in “linux-meta” package in Ubuntu:
  Fix Released
Status in “linux-meta-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-meta-lowlatency” package in Ubuntu:
  Fix Released
Status in “linux-meta-ppc” package in Ubuntu:
  Fix Released
Status in “linux-ppc” package in Ubuntu:
  Fix Released
Status in “apt” source package in Precise:
  Fix Committed
Status in “linux” source package in Precise:
  Fix Committed
Status in “linux-goldfish” source package in Precise:
  Invalid
Status in “linux-lowlatency” source package in Precise:
  Invalid
Status in “linux-lts-saucy” source package in Precise:
  Fix Committed
Status in “linux-meta” source package in Precise:
  Invalid
Status in “linux-meta-goldfish” source package in Precise:
  Invalid
Status in “linux-meta-lowlatency” source package in Precise:
  Invalid
Status in “linux-meta-ppc” source package in Precise:
  Invalid
Status in “linux-ppc” source package in Precise:
  Invalid
Status in “apt” source package in Saucy:
  Fix Released
Status in “linux” source package in Saucy:
  Fix Released
Status in “linux-goldfish” source package in Saucy:
  Fix Released
Status in “linux-lowlatency” source package in Saucy:
  Fix Released
Status in “linux-lts-saucy” source package in Saucy:
  Invalid
Status in “linux-meta” source package in Saucy:
  Fix Released
Status in “linux-meta-goldfish” source package in Saucy:
  Fix Released
Status in “linux-meta-lowlatency” source package in Saucy:
  Fix Released
Status in “linux-meta-ppc” source package in Saucy:
  Fix Released
Status in “linux-ppc” source package in Saucy:
  Fix Released

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific 

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Adam Conrad]

The apt fix for this should be backported to precise, and the linux-lts-
saucy HWE kernels have the new linux-tools scheme, so we can actually
retain them sanely via autoremove.

** Changed in: apt (Ubuntu Precise)
   Status: Invalid => In Progress

** Changed in: apt (Ubuntu Precise)
 Assignee: (unassigned) => Adam Conrad (adconrad)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “apt” package in Ubuntu:
  Fix Released
Status in “linux” package in Ubuntu:
  Fix Released
Status in “linux-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-lowlatency” package in Ubuntu:
  Fix Released
Status in “linux-lts-saucy” package in Ubuntu:
  Invalid
Status in “linux-meta” package in Ubuntu:
  Fix Released
Status in “linux-meta-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-meta-lowlatency” package in Ubuntu:
  Fix Released
Status in “linux-meta-ppc” package in Ubuntu:
  Fix Released
Status in “linux-ppc” package in Ubuntu:
  Fix Released
Status in “apt” source package in Precise:
  In Progress
Status in “linux” source package in Precise:
  Fix Committed
Status in “linux-goldfish” source package in Precise:
  Invalid
Status in “linux-lowlatency” source package in Precise:
  Invalid
Status in “linux-lts-saucy” source package in Precise:
  Fix Committed
Status in “linux-meta” source package in Precise:
  Invalid
Status in “linux-meta-goldfish” source package in Precise:
  Invalid
Status in “linux-meta-lowlatency” source package in Precise:
  Invalid
Status in “linux-meta-ppc” source package in Precise:
  Invalid
Status in “linux-ppc” source package in Precise:
  Invalid
Status in “apt” source package in Saucy:
  Fix Released
Status in “linux” source package in Saucy:
  Fix Released
Status in “linux-goldfish” source package in Saucy:
  Fix Released
Status in “linux-lowlatency” source package in Saucy:
  Fix Released
Status in “linux-lts-saucy” source package in Saucy:
  Invalid
Status in “linux-meta” source package in Saucy:
  Fix Released
Status in “linux-meta-goldfish” source package in Saucy:
  Fix Released
Status in “linux-meta-lowlatency” source package in Saucy:
  Fix Released
Status in “linux-meta-ppc” source package in Saucy:
  Fix Released
Status in “linux-ppc” source package in Saucy:
  Fix Released

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source package.

  Further we would then be able to name the actual binary packages as produced 
by the 
  various source packages to be source package specific.  Thus we would have 
packages as
  below:

  linux-tools- -- coming out of the master branch
  linux-grouper-tools- -- coming out of the grouper branch

  These would be hidden from the user via the previously listed meta packages
  and would not be direct installation candidates.

  There is also an additional linux-tools-common package which represents
  the manual pages and the wrappers.  These would be only generated and
  installed from the master branch and all of the other flavours would
  (at least initially) share this package.

  Th

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Tim Gardner]

** Changed in: linux (Ubuntu Precise)
   Status: In Progress => Fix Committed

** Also affects: linux-lts-saucy (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: linux-lts-saucy (Ubuntu Saucy)
   Status: New => Invalid

** Changed in: linux-lts-saucy (Ubuntu Precise)
   Status: New => Fix Committed

** Changed in: linux-lts-saucy (Ubuntu Precise)
 Assignee: (unassigned) => Andy Whitcroft (apw)

** Changed in: linux-lts-saucy (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “apt” package in Ubuntu:
  Fix Released
Status in “linux” package in Ubuntu:
  Fix Released
Status in “linux-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-lowlatency” package in Ubuntu:
  Fix Released
Status in “linux-lts-saucy” package in Ubuntu:
  Invalid
Status in “linux-meta” package in Ubuntu:
  Fix Released
Status in “linux-meta-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-meta-lowlatency” package in Ubuntu:
  Fix Released
Status in “linux-meta-ppc” package in Ubuntu:
  Fix Released
Status in “linux-ppc” package in Ubuntu:
  Fix Released
Status in “apt” source package in Precise:
  Invalid
Status in “linux” source package in Precise:
  Fix Committed
Status in “linux-goldfish” source package in Precise:
  Invalid
Status in “linux-lowlatency” source package in Precise:
  Invalid
Status in “linux-lts-saucy” source package in Precise:
  Fix Committed
Status in “linux-meta” source package in Precise:
  Invalid
Status in “linux-meta-goldfish” source package in Precise:
  Invalid
Status in “linux-meta-lowlatency” source package in Precise:
  Invalid
Status in “linux-meta-ppc” source package in Precise:
  Invalid
Status in “linux-ppc” source package in Precise:
  Invalid
Status in “apt” source package in Saucy:
  Fix Released
Status in “linux” source package in Saucy:
  Fix Released
Status in “linux-goldfish” source package in Saucy:
  Fix Released
Status in “linux-lowlatency” source package in Saucy:
  Fix Released
Status in “linux-lts-saucy” source package in Saucy:
  Invalid
Status in “linux-meta” source package in Saucy:
  Fix Released
Status in “linux-meta-goldfish” source package in Saucy:
  Fix Released
Status in “linux-meta-lowlatency” source package in Saucy:
  Fix Released
Status in “linux-meta-ppc” source package in Saucy:
  Fix Released
Status in “linux-ppc” source package in Saucy:
  Fix Released

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source package.

  Further we would then be able to name the actual binary packages as produced 
by the 
  various source packages to be source package specific.  Thus we would have 
packages as
  below:

  linux-tools- -- coming out of the master branch
  linux-grouper-tools- -- coming out of the grouper branch

  These would be hidden from the user via the previously listed meta packages
  and would not be direct installation candidates.

  There is also an additional linux-tools-common package which represents
  the manual pages and the wrappers.

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Andy Whitcroft]

** Also affects: apt (Ubuntu Precise)
   Importance: Undecided
   Status: New

** Also affects: linux-meta (Ubuntu Precise)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Precise)
   Importance: Undecided
   Status: New

** Also affects: linux-meta-lowlatency (Ubuntu Precise)
   Importance: Undecided
   Status: New

** Also affects: linux-lowlatency (Ubuntu Precise)
   Importance: Undecided
   Status: New

** Also affects: linux-ppc (Ubuntu Precise)
   Importance: Undecided
   Status: New

** Also affects: linux-meta-ppc (Ubuntu Precise)
   Importance: Undecided
   Status: New

** Also affects: linux-goldfish (Ubuntu Precise)
   Importance: Undecided
   Status: New

** Also affects: linux-meta-goldfish (Ubuntu Precise)
   Importance: Undecided
   Status: New

** Changed in: apt (Ubuntu Precise)
   Status: New => Invalid

** Changed in: linux (Ubuntu Precise)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Precise)
   Status: New => In Progress

** Changed in: linux-goldfish (Ubuntu Precise)
   Status: New => Invalid

** Changed in: linux-lowlatency (Ubuntu Precise)
   Status: New => Invalid

** Changed in: linux-meta (Ubuntu Precise)
   Status: New => Invalid

** Changed in: linux-ppc (Ubuntu Precise)
   Status: New => Invalid

** Changed in: linux-meta-ppc (Ubuntu Precise)
   Status: New => Invalid

** Changed in: linux-meta-lowlatency (Ubuntu Precise)
   Status: New => Invalid

** Changed in: linux-meta-goldfish (Ubuntu Precise)
   Status: New => Invalid

** Changed in: linux (Ubuntu Precise)
 Assignee: (unassigned) => Andy Whitcroft (apw)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “apt” package in Ubuntu:
  Fix Released
Status in “linux” package in Ubuntu:
  Fix Released
Status in “linux-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-lowlatency” package in Ubuntu:
  Fix Released
Status in “linux-meta” package in Ubuntu:
  Fix Released
Status in “linux-meta-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-meta-lowlatency” package in Ubuntu:
  Fix Released
Status in “linux-meta-ppc” package in Ubuntu:
  Fix Released
Status in “linux-ppc” package in Ubuntu:
  Fix Released
Status in “apt” source package in Precise:
  Invalid
Status in “linux” source package in Precise:
  In Progress
Status in “linux-goldfish” source package in Precise:
  Invalid
Status in “linux-lowlatency” source package in Precise:
  Invalid
Status in “linux-meta” source package in Precise:
  Invalid
Status in “linux-meta-goldfish” source package in Precise:
  Invalid
Status in “linux-meta-lowlatency” source package in Precise:
  Invalid
Status in “linux-meta-ppc” source package in Precise:
  Invalid
Status in “linux-ppc” source package in Precise:
  Invalid
Status in “apt” source package in Saucy:
  Fix Released
Status in “linux” source package in Saucy:
  Fix Released
Status in “linux-goldfish” source package in Saucy:
  Fix Released
Status in “linux-lowlatency” source package in Saucy:
  Fix Released
Status in “linux-meta” source package in Saucy:
  Fix Released
Status in “linux-meta-goldfish” source package in Saucy:
  Fix Released
Status in “linux-meta-lowlatency” source package in Saucy:
  Fix Released
Status in “linux-meta-ppc” source package in Saucy:
  Fix Released
Status in “linux-ppc” source package in Saucy:
  Fix Released

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Adam Conrad]

** Also affects: linux-ppc (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: linux-meta-ppc (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: linux-lowlatency (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: linux-meta-lowlatency (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: linux-lowlatency (Ubuntu Saucy)
   Status: New => Fix Released

** Changed in: linux-lowlatency (Ubuntu Saucy)
 Assignee: (unassigned) => Andy Whitcroft (apw)

** Changed in: linux-ppc (Ubuntu Saucy)
   Status: New => Fix Released

** Changed in: linux-ppc (Ubuntu Saucy)
 Assignee: (unassigned) => Andy Whitcroft (apw)

** Changed in: linux-meta-lowlatency (Ubuntu Saucy)
   Status: New => Fix Released

** Changed in: linux-meta-lowlatency (Ubuntu Saucy)
 Assignee: (unassigned) => Adam Conrad (adconrad)

** Changed in: linux-meta-ppc (Ubuntu Saucy)
   Status: New => Fix Released

** Changed in: linux-meta-ppc (Ubuntu Saucy)
 Assignee: (unassigned) => Adam Conrad (adconrad)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “apt” package in Ubuntu:
  Fix Released
Status in “linux” package in Ubuntu:
  Fix Released
Status in “linux-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-lowlatency” package in Ubuntu:
  Fix Released
Status in “linux-meta” package in Ubuntu:
  Fix Released
Status in “linux-meta-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-meta-lowlatency” package in Ubuntu:
  Fix Released
Status in “linux-meta-ppc” package in Ubuntu:
  Fix Released
Status in “linux-ppc” package in Ubuntu:
  Fix Released
Status in “apt” source package in Saucy:
  Fix Released
Status in “linux” source package in Saucy:
  Fix Released
Status in “linux-goldfish” source package in Saucy:
  Fix Released
Status in “linux-lowlatency” source package in Saucy:
  Fix Released
Status in “linux-meta” source package in Saucy:
  Fix Released
Status in “linux-meta-goldfish” source package in Saucy:
  Fix Released
Status in “linux-meta-lowlatency” source package in Saucy:
  Fix Released
Status in “linux-meta-ppc” source package in Saucy:
  Fix Released
Status in “linux-ppc” source package in Saucy:
  Fix Released

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source package.

  Further we would then be able to name the actual binary packages as produced 
by the 
  various source packages to be source package specific.  Thus we would have 
packages as
  below:

  linux-tools- -- coming out of the master branch
  linux-grouper-tools- -- coming out of the grouper branch

  These would be hidden from the user via the previously listed meta packages
  and would not be direct installation candidates.

  There is also an additional linux-tools-common package which represents
  the manual pages and the wrappers.  These would be only generated and
  installed from the master branch and all of the other flavours would
  (at least initially) share this package.

  The actual binaries will be moved

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Launchpad Bug Tracker]

This bug was fixed in the package linux - 3.11.0-7.14

---
linux (3.11.0-7.14) saucy; urgency=low

  [ Andy Whitcroft ]

  * [Packaging] sort out linux-tools naming
- LP: #1205284
  * [Packaging] linux-tools: switch to common generic version helper

  [ Paolo Pisati ]

  * [Config] highbank: ecx1000: CPU_IDLE causes instabilities, disable
it

  [ Tim Gardner ]

  * Release tracker
- LP: #1226160

  [ Tony Lindgren ]

  * SAUCE: ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus
for pandaboard

  [ Upstream Kernel Changes ]

  * USB: handle LPM errors during device suspend correctly
- LP: #1011415
  * usb: don't check pm qos NO_POWER_OFF flag in usb_port_suspend()
- LP: #1011415
  * usb: Don't fail port power resume on device disconnect.
- LP: #1011415

  [ Upstream Kernel Changes ]

  * rebase to v3.11.1
 -- Tim GardnerWed, 11 Sep 2013 07:30:17 -0600

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “apt” package in Ubuntu:
  Fix Released
Status in “linux” package in Ubuntu:
  Fix Released
Status in “linux-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-meta” package in Ubuntu:
  Fix Released
Status in “linux-meta-goldfish” package in Ubuntu:
  Fix Released
Status in “apt” source package in Saucy:
  Fix Released
Status in “linux” source package in Saucy:
  Fix Released
Status in “linux-goldfish” source package in Saucy:
  Fix Released
Status in “linux-meta” source package in Saucy:
  Fix Released
Status in “linux-meta-goldfish” source package in Saucy:
  Fix Released

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source package.

  Further we would then be able to name the actual binary packages as produced 
by the 
  various source packages to be source package specific.  Thus we would have 
packages as
  below:

  linux-tools- -- coming out of the master branch
  linux-grouper-tools- -- coming out of the grouper branch

  These would be hidden from the user via the previously listed meta packages
  and would not be direct installation candidates.

  There is also an additional linux-tools-common package which represents
  the manual pages and the wrappers.  These would be only generated and
  installed from the master branch and all of the other flavours would
  (at least initially) share this package.

  The actual binaries will be moved over to names similar to below:

  /usr/lib/-tools-/

  with symlinks in as below for each flavour pointing to the above:

  /usr/lib/linux-tools/--

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1205284/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Launchpad Bug Tracker]

This bug was fixed in the package linux-meta - 3.11.0.7.9

---
linux-meta (3.11.0.7.9) saucy; urgency=low

  * Follow changes to linux-tools naming (LP: #1205284).
 -- Andy WhitcroftWed, 11 Sep 2013 14:47:01 +0100

** Changed in: linux-meta (Ubuntu Saucy)
   Status: In Progress => Fix Released

** Changed in: linux (Ubuntu Saucy)
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “apt” package in Ubuntu:
  Fix Released
Status in “linux” package in Ubuntu:
  Fix Released
Status in “linux-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-meta” package in Ubuntu:
  Fix Released
Status in “linux-meta-goldfish” package in Ubuntu:
  Fix Released
Status in “apt” source package in Saucy:
  Fix Released
Status in “linux” source package in Saucy:
  Fix Released
Status in “linux-goldfish” source package in Saucy:
  Fix Released
Status in “linux-meta” source package in Saucy:
  Fix Released
Status in “linux-meta-goldfish” source package in Saucy:
  Fix Released

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source package.

  Further we would then be able to name the actual binary packages as produced 
by the 
  various source packages to be source package specific.  Thus we would have 
packages as
  below:

  linux-tools- -- coming out of the master branch
  linux-grouper-tools- -- coming out of the grouper branch

  These would be hidden from the user via the previously listed meta packages
  and would not be direct installation candidates.

  There is also an additional linux-tools-common package which represents
  the manual pages and the wrappers.  These would be only generated and
  installed from the master branch and all of the other flavours would
  (at least initially) share this package.

  The actual binaries will be moved over to names similar to below:

  /usr/lib/-tools-/

  with symlinks in as below for each flavour pointing to the above:

  /usr/lib/linux-tools/--

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1205284/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Launchpad Bug Tracker]

This bug was fixed in the package linux-meta-goldfish - 3.4.0.0.2

---
linux-meta-goldfish (3.4.0.0.2) saucy; urgency=low

  * Build for i386
  * Follow changes to linux-tools naming (LP: #1205284).
 -- Andy WhitcroftThu, 12 Sep 2013 14:59:01 +0100

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “apt” package in Ubuntu:
  Fix Released
Status in “linux” package in Ubuntu:
  In Progress
Status in “linux-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-meta” package in Ubuntu:
  In Progress
Status in “linux-meta-goldfish” package in Ubuntu:
  Fix Released
Status in “apt” source package in Saucy:
  Fix Released
Status in “linux” source package in Saucy:
  In Progress
Status in “linux-goldfish” source package in Saucy:
  Fix Released
Status in “linux-meta” source package in Saucy:
  In Progress
Status in “linux-meta-goldfish” source package in Saucy:
  Fix Released

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source package.

  Further we would then be able to name the actual binary packages as produced 
by the 
  various source packages to be source package specific.  Thus we would have 
packages as
  below:

  linux-tools- -- coming out of the master branch
  linux-grouper-tools- -- coming out of the grouper branch

  These would be hidden from the user via the previously listed meta packages
  and would not be direct installation candidates.

  There is also an additional linux-tools-common package which represents
  the manual pages and the wrappers.  These would be only generated and
  installed from the master branch and all of the other flavours would
  (at least initially) share this package.

  The actual binaries will be moved over to names similar to below:

  /usr/lib/-tools-/

  with symlinks in as below for each flavour pointing to the above:

  /usr/lib/linux-tools/--

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1205284/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Launchpad Bug Tracker]

This bug was fixed in the package linux-goldfish - 3.4.0-0.4

---
linux-goldfish (3.4.0-0.4) saucy; urgency=low

  [ Andy Whitcroft ]

  * [Packaging] sort out linux-tools naming
- LP: #1205284
  * [Config] switch to new linux-tools naming
- LP: #1205284
  * [Config] fix up build-depends:

  [ Tim Gardner ]

  * [Config] CONFIG_*_NS=y
- LP: #1222772
  * [Config] CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
- LP: #1222772
  * [Config] CONFIG_ANDROID_PARANOID_NETWORK=n
- LP: #1222772
 -- Andy WhitcroftWed, 11 Sep 2013 18:10:03 +0100

** Changed in: linux-goldfish (Ubuntu Saucy)
   Status: Fix Committed => Fix Released

** Changed in: linux-meta-goldfish (Ubuntu Saucy)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “apt” package in Ubuntu:
  Fix Released
Status in “linux” package in Ubuntu:
  In Progress
Status in “linux-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-meta” package in Ubuntu:
  In Progress
Status in “linux-meta-goldfish” package in Ubuntu:
  Fix Released
Status in “apt” source package in Saucy:
  Fix Released
Status in “linux” source package in Saucy:
  In Progress
Status in “linux-goldfish” source package in Saucy:
  Fix Released
Status in “linux-meta” source package in Saucy:
  In Progress
Status in “linux-meta-goldfish” source package in Saucy:
  Fix Released

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source package.

  Further we would then be able to name the actual binary packages as produced 
by the 
  various source packages to be source package specific.  Thus we would have 
packages as
  below:

  linux-tools- -- coming out of the master branch
  linux-grouper-tools- -- coming out of the grouper branch

  These would be hidden from the user via the previously listed meta packages
  and would not be direct installation candidates.

  There is also an additional linux-tools-common package which represents
  the manual pages and the wrappers.  These would be only generated and
  installed from the master branch and all of the other flavours would
  (at least initially) share this package.

  The actual binaries will be moved over to names similar to below:

  /usr/lib/-tools-/

  with symlinks in as below for each flavour pointing to the above:

  /usr/lib/linux-tools/--

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1205284/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Launchpad Bug Tracker]

** Branch linked: lp:ubuntu/saucy-proposed/linux-meta-goldfish

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “apt” package in Ubuntu:
  Fix Released
Status in “linux” package in Ubuntu:
  In Progress
Status in “linux-goldfish” package in Ubuntu:
  Fix Committed
Status in “linux-meta” package in Ubuntu:
  In Progress
Status in “linux-meta-goldfish” package in Ubuntu:
  Fix Committed
Status in “apt” source package in Saucy:
  Fix Released
Status in “linux” source package in Saucy:
  In Progress
Status in “linux-goldfish” source package in Saucy:
  Fix Committed
Status in “linux-meta” source package in Saucy:
  In Progress
Status in “linux-meta-goldfish” source package in Saucy:
  Fix Committed

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source package.

  Further we would then be able to name the actual binary packages as produced 
by the 
  various source packages to be source package specific.  Thus we would have 
packages as
  below:

  linux-tools- -- coming out of the master branch
  linux-grouper-tools- -- coming out of the grouper branch

  These would be hidden from the user via the previously listed meta packages
  and would not be direct installation candidates.

  There is also an additional linux-tools-common package which represents
  the manual pages and the wrappers.  These would be only generated and
  installed from the master branch and all of the other flavours would
  (at least initially) share this package.

  The actual binaries will be moved over to names similar to below:

  /usr/lib/-tools-/

  with symlinks in as below for each flavour pointing to the above:

  /usr/lib/linux-tools/--

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1205284/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Launchpad Bug Tracker]

** Branch linked: lp:ubuntu/saucy-proposed/linux-meta

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “apt” package in Ubuntu:
  Fix Released
Status in “linux” package in Ubuntu:
  In Progress
Status in “linux-goldfish” package in Ubuntu:
  Fix Released
Status in “linux-meta” package in Ubuntu:
  In Progress
Status in “linux-meta-goldfish” package in Ubuntu:
  Fix Released
Status in “apt” source package in Saucy:
  Fix Released
Status in “linux” source package in Saucy:
  In Progress
Status in “linux-goldfish” source package in Saucy:
  Fix Released
Status in “linux-meta” source package in Saucy:
  In Progress
Status in “linux-meta-goldfish” source package in Saucy:
  Fix Released

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source package.

  Further we would then be able to name the actual binary packages as produced 
by the 
  various source packages to be source package specific.  Thus we would have 
packages as
  below:

  linux-tools- -- coming out of the master branch
  linux-grouper-tools- -- coming out of the grouper branch

  These would be hidden from the user via the previously listed meta packages
  and would not be direct installation candidates.

  There is also an additional linux-tools-common package which represents
  the manual pages and the wrappers.  These would be only generated and
  installed from the master branch and all of the other flavours would
  (at least initially) share this package.

  The actual binaries will be moved over to names similar to below:

  /usr/lib/-tools-/

  with symlinks in as below for each flavour pointing to the above:

  /usr/lib/linux-tools/--

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1205284/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Tim Gardner]

** Changed in: linux-meta-goldfish (Ubuntu Saucy)
   Status: In Progress => Fix Committed

** Changed in: linux-goldfish (Ubuntu Saucy)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “apt” package in Ubuntu:
  Fix Released
Status in “linux” package in Ubuntu:
  In Progress
Status in “linux-goldfish” package in Ubuntu:
  Fix Committed
Status in “linux-meta” package in Ubuntu:
  In Progress
Status in “linux-meta-goldfish” package in Ubuntu:
  Fix Committed
Status in “apt” source package in Saucy:
  Fix Released
Status in “linux” source package in Saucy:
  In Progress
Status in “linux-goldfish” source package in Saucy:
  Fix Committed
Status in “linux-meta” source package in Saucy:
  In Progress
Status in “linux-meta-goldfish” source package in Saucy:
  Fix Committed

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source package.

  Further we would then be able to name the actual binary packages as produced 
by the 
  various source packages to be source package specific.  Thus we would have 
packages as
  below:

  linux-tools- -- coming out of the master branch
  linux-grouper-tools- -- coming out of the grouper branch

  These would be hidden from the user via the previously listed meta packages
  and would not be direct installation candidates.

  There is also an additional linux-tools-common package which represents
  the manual pages and the wrappers.  These would be only generated and
  installed from the master branch and all of the other flavours would
  (at least initially) share this package.

  The actual binaries will be moved over to names similar to below:

  /usr/lib/-tools-/

  with symlinks in as below for each flavour pointing to the above:

  /usr/lib/linux-tools/--

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1205284/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Launchpad Bug Tracker]

** Branch linked: lp:ubuntu/saucy-proposed/linux-goldfish

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “apt” package in Ubuntu:
  Fix Released
Status in “linux” package in Ubuntu:
  In Progress
Status in “linux-goldfish” package in Ubuntu:
  Fix Committed
Status in “linux-meta” package in Ubuntu:
  In Progress
Status in “linux-meta-goldfish” package in Ubuntu:
  Fix Committed
Status in “apt” source package in Saucy:
  Fix Released
Status in “linux” source package in Saucy:
  In Progress
Status in “linux-goldfish” source package in Saucy:
  Fix Committed
Status in “linux-meta” source package in Saucy:
  In Progress
Status in “linux-meta-goldfish” source package in Saucy:
  Fix Committed

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source package.

  Further we would then be able to name the actual binary packages as produced 
by the 
  various source packages to be source package specific.  Thus we would have 
packages as
  below:

  linux-tools- -- coming out of the master branch
  linux-grouper-tools- -- coming out of the grouper branch

  These would be hidden from the user via the previously listed meta packages
  and would not be direct installation candidates.

  There is also an additional linux-tools-common package which represents
  the manual pages and the wrappers.  These would be only generated and
  installed from the master branch and all of the other flavours would
  (at least initially) share this package.

  The actual binaries will be moved over to names similar to below:

  /usr/lib/-tools-/

  with symlinks in as below for each flavour pointing to the above:

  /usr/lib/linux-tools/--

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1205284/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Launchpad Bug Tracker]

This bug was fixed in the package apt - 0.9.9.1~ubuntu3

---
apt (0.9.9.1~ubuntu3) saucy; urgency=low

  * Keep linux-tools packages matching installed kernels (LP: #1205284)
 -- Adam ConradWed, 11 Sep 2013 11:48:09 -0400

** Changed in: apt (Ubuntu Saucy)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “apt” package in Ubuntu:
  Fix Released
Status in “linux” package in Ubuntu:
  In Progress
Status in “linux-goldfish” package in Ubuntu:
  In Progress
Status in “linux-meta” package in Ubuntu:
  In Progress
Status in “linux-meta-goldfish” package in Ubuntu:
  In Progress
Status in “apt” source package in Saucy:
  Fix Released
Status in “linux” source package in Saucy:
  In Progress
Status in “linux-goldfish” source package in Saucy:
  In Progress
Status in “linux-meta” source package in Saucy:
  In Progress
Status in “linux-meta-goldfish” source package in Saucy:
  In Progress

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source package.

  Further we would then be able to name the actual binary packages as produced 
by the 
  various source packages to be source package specific.  Thus we would have 
packages as
  below:

  linux-tools- -- coming out of the master branch
  linux-grouper-tools- -- coming out of the grouper branch

  These would be hidden from the user via the previously listed meta packages
  and would not be direct installation candidates.

  There is also an additional linux-tools-common package which represents
  the manual pages and the wrappers.  These would be only generated and
  installed from the master branch and all of the other flavours would
  (at least initially) share this package.

  The actual binaries will be moved over to names similar to below:

  /usr/lib/-tools-/

  with symlinks in as below for each flavour pointing to the above:

  /usr/lib/linux-tools/--

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1205284/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Adam Conrad]

** Changed in: apt (Ubuntu Saucy)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “apt” package in Ubuntu:
  Fix Committed
Status in “linux” package in Ubuntu:
  In Progress
Status in “linux-goldfish” package in Ubuntu:
  In Progress
Status in “linux-meta” package in Ubuntu:
  In Progress
Status in “linux-meta-goldfish” package in Ubuntu:
  In Progress
Status in “apt” source package in Saucy:
  Fix Committed
Status in “linux” source package in Saucy:
  In Progress
Status in “linux-goldfish” source package in Saucy:
  In Progress
Status in “linux-meta” source package in Saucy:
  In Progress
Status in “linux-meta-goldfish” source package in Saucy:
  In Progress

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source package.

  Further we would then be able to name the actual binary packages as produced 
by the 
  various source packages to be source package specific.  Thus we would have 
packages as
  below:

  linux-tools- -- coming out of the master branch
  linux-grouper-tools- -- coming out of the grouper branch

  These would be hidden from the user via the previously listed meta packages
  and would not be direct installation candidates.

  There is also an additional linux-tools-common package which represents
  the manual pages and the wrappers.  These would be only generated and
  installed from the master branch and all of the other flavours would
  (at least initially) share this package.

  The actual binaries will be moved over to names similar to below:

  /usr/lib/-tools-/

  with symlinks in as below for each flavour pointing to the above:

  /usr/lib/linux-tools/--

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1205284/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Andy Whitcroft]

We need the kernel autoclean support to understand the tools packages as
well as they are abi specific.  Adding a task for apt.

** Also affects: linux (Ubuntu Saucy)
   Importance: Medium
 Assignee: Andy Whitcroft (apw)
   Status: In Progress

** Also affects: linux-meta (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: linux-meta (Ubuntu Saucy)
   Status: New => In Progress

** Changed in: linux-meta (Ubuntu Saucy)
 Assignee: (unassigned) => Andy Whitcroft (apw)

** Also affects: apt (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: apt (Ubuntu Saucy)
 Assignee: (unassigned) => Adam Conrad (adconrad)

** Changed in: apt (Ubuntu Saucy)
   Importance: Undecided => Medium

** Changed in: apt (Ubuntu Saucy)
   Status: New => In Progress

** Changed in: linux-meta (Ubuntu Saucy)
   Importance: Undecided => Medium

** Also affects: linux-goldfish (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: linux-meta-goldfish (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “apt” package in Ubuntu:
  In Progress
Status in “linux” package in Ubuntu:
  In Progress
Status in “linux-goldfish” package in Ubuntu:
  New
Status in “linux-meta” package in Ubuntu:
  In Progress
Status in “linux-meta-goldfish” package in Ubuntu:
  New
Status in “apt” source package in Saucy:
  In Progress
Status in “linux” source package in Saucy:
  In Progress
Status in “linux-goldfish” source package in Saucy:
  New
Status in “linux-meta” source package in Saucy:
  In Progress
Status in “linux-meta-goldfish” source package in Saucy:
  New

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source package.

  Further we would then be able to name the actual binary packages as produced 
by the 
  various source packages to be source package specific.  Thus we would have 
packages as
  below:

  linux-tools- -- coming out of the master branch
  linux-grouper-tools- -- coming out of the grouper branch

  These would be hidden from the user via the previously listed meta packages
  and would not be direct installation candidates.

  There is also an additional linux-tools-common package which represents
  the manual pages and the wrappers.  These would be only generated and
  installed from the master branch and all of the other flavours would
  (at least initially) share this package.

  The actual binaries will be moved over to names similar to below:

  /usr/lib/-tools-/

  with symlinks in as below for each flavour pointing to the above:

  /usr/lib/linux-tools/--

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1205284/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Andy Whitcroft]

** Changed in: linux-goldfish (Ubuntu Saucy)
   Status: New => In Progress

** Changed in: linux-goldfish (Ubuntu Saucy)
 Assignee: (unassigned) => Andy Whitcroft (apw)

** Changed in: linux-goldfish (Ubuntu Saucy)
   Importance: Undecided => Medium

** Changed in: linux-meta-goldfish (Ubuntu Saucy)
   Importance: Undecided => Medium

** Changed in: linux-meta-goldfish (Ubuntu Saucy)
   Status: New => In Progress

** Changed in: linux-meta-goldfish (Ubuntu Saucy)
 Assignee: (unassigned) => Andy Whitcroft (apw)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “apt” package in Ubuntu:
  In Progress
Status in “linux” package in Ubuntu:
  In Progress
Status in “linux-goldfish” package in Ubuntu:
  In Progress
Status in “linux-meta” package in Ubuntu:
  In Progress
Status in “linux-meta-goldfish” package in Ubuntu:
  In Progress
Status in “apt” source package in Saucy:
  In Progress
Status in “linux” source package in Saucy:
  In Progress
Status in “linux-goldfish” source package in Saucy:
  In Progress
Status in “linux-meta” source package in Saucy:
  In Progress
Status in “linux-meta-goldfish” source package in Saucy:
  In Progress

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source package.

  Further we would then be able to name the actual binary packages as produced 
by the 
  various source packages to be source package specific.  Thus we would have 
packages as
  below:

  linux-tools- -- coming out of the master branch
  linux-grouper-tools- -- coming out of the grouper branch

  These would be hidden from the user via the previously listed meta packages
  and would not be direct installation candidates.

  There is also an additional linux-tools-common package which represents
  the manual pages and the wrappers.  These would be only generated and
  installed from the master branch and all of the other flavours would
  (at least initially) share this package.

  The actual binaries will be moved over to names similar to below:

  /usr/lib/-tools-/

  with symlinks in as below for each flavour pointing to the above:

  /usr/lib/linux-tools/--

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1205284/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Launchpad Bug Tracker]

** Branch linked: lp:ubuntu/saucy-proposed/apt

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “apt” package in Ubuntu:
  In Progress
Status in “linux” package in Ubuntu:
  In Progress
Status in “linux-goldfish” package in Ubuntu:
  New
Status in “linux-meta” package in Ubuntu:
  In Progress
Status in “linux-meta-goldfish” package in Ubuntu:
  New
Status in “apt” source package in Saucy:
  In Progress
Status in “linux” source package in Saucy:
  In Progress
Status in “linux-goldfish” source package in Saucy:
  New
Status in “linux-meta” source package in Saucy:
  In Progress
Status in “linux-meta-goldfish” source package in Saucy:
  New

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source package.

  Further we would then be able to name the actual binary packages as produced 
by the 
  various source packages to be source package specific.  Thus we would have 
packages as
  below:

  linux-tools- -- coming out of the master branch
  linux-grouper-tools- -- coming out of the grouper branch

  These would be hidden from the user via the previously listed meta packages
  and would not be direct installation candidates.

  There is also an additional linux-tools-common package which represents
  the manual pages and the wrappers.  These would be only generated and
  installed from the master branch and all of the other flavours would
  (at least initially) share this package.

  The actual binaries will be moved over to names similar to below:

  /usr/lib/-tools-/

  with symlinks in as below for each flavour pointing to the above:

  /usr/lib/linux-tools/--

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1205284/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Andy Whitcroft]

/me will bring a sample patch set to sprint for this.

** Description changed:

- We need to sort out naming for linux-tools as it is not sensible in the
- face of multiple source packages.
+ The linux tools packages are not currently scalable to multiple source
+ package branches.  This is because the packages are actually per
+ architecture (not flavour) in both contents and naming but may differ
+ between source packages which may be at different versions.  This prevents
+ us safely emitting linux-tools packages from branches other than master.
+ 
+ We have a policy of insulating people from the source package from which a
+ kernel comes.  We do this via the linux-- package naming,
+ which is consistant regardless of overall package.  It therefore makes
+ a lot of sense to extend this to the tools package.  Such that we would
+ have the following user consumable packages as below:
+ 
+ linux-tools- -- tools to match linux-image-
+ linux-tools--   -- tools to match 
linux-image--
+ 
+ In order to allow linux-tools to be still be a valid install target the
+ first of these would additionally Provides: linux-tools to allow simple
+ selection of the appropriate flavour specific package where there is only
+ one, or to help the user make an informed choice where there is more.
+ 
+ The first would be the logical choice when wanting to maintain tools
+ installed for all future version of the kernel, mirroring the kernels as
+ installed by the linux- and linux-image- packages and
+ keeping the user up to date in tools.  The second would be the appropriate
+ package to request installation when trying to target a specific
+ kernel version and would be used by the wrapper when requesting manual
+ intervention such as when the linux-tools- is not installed.
+ 
+ The first of these would be added to the appropriate meta package, the
+ second would come out of the flavour specific packages in the main kernel
+ source package.
+ 
+ Further we would then be able to name the actual binary packages as produced 
by the 
+ various source packages to be source package specific.  Thus we would have 
packages as
+ below:
+ 
+ linux-tools- -- coming out of the master branch
+ linux-grouper-tools- -- coming out of the grouper branch
+ 
+ These would be hidden from the user via the previously listed meta packages
+ and would not be direct installation candidates.
+ 
+ There is also an additional linux-tools-common package which represents
+ the manual pages and the wrappers.  These would be only generated and
+ installed from the master branch and all of the other flavours would
+ (at least initially) share this package.
+ 
+ The actual binaries will be moved over to names similar to below:
+ 
+ /usr/lib/-tools-/
+ 
+ with symlinks in as below for each flavour pointing to the above:
+ 
+ /usr/lib/linux-tools/--

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “linux” package in Ubuntu:
  In Progress

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-- package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

  linux-tools- -- tools to match linux-image-
  linux-tools--   -- tools to match 
linux-image--

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux- and linux-image- packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools- is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source pac

[Kernel-packages] [Bug 1205284] Re: linux-tools naming is not scalable to multiple source packages

[Tim Gardner]

Could you provide some examples of why the current naming scheme is
insufficient ?

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “linux” package in Ubuntu:
  In Progress

Bug description:
  We need to sort out naming for linux-tools as it is not sensible in
  the face of multiple source packages.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1205284/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp