Bug#638878: linux-image-3.0.0-1-amd64: Maybe report Debian kernel version with uname
Package: linux-2.6
Version: 3.0.0-2 Severity: wishlist Would it be possible to report Debian kernel version in uname output? Maybe it can be added to "kernel version" string, uname -v (now it's "#1 SMP Wed Aug 17 05:07:22 UTC 2011". This information is present in /proc/version and could be in uname too. -- Package-specific info: ** Version: Linux version 3.0.0-1-amd64 (Debian 3.0.0-2) (ben@decadent.org.uk) (gcc version 4.5.3 (Debian 4.5.3-5) ) #1 SMP Wed Aug 17 05:07:22 UTC 2011 ** Model information sys_vendor: ASUSTeK Computer INC. product_name: 1215B product_version: x.x chassis_vendor: ASUSTeK Computer INC. chassis_version: x.x bios_vendor: American Megatrends Inc. bios_version: 0401 board_vendor: ASUSTeK Computer INC. board_name: 1215B board_version: x.xx ** PCI devices: 00:00.0 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1510] Subsystem: Advanced Micro Devices [AMD] Device [1022:1510] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 32 00:01.0 VGA compatible controller [0300]: ATI Technologies Inc Device [1002:9802] (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device [1043:84a5] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 43 Region 0: Memory at c0000000 (32-bit, prefetchable) [size=256M] Region 1: I/O ports at f000 [size=256] Region 2: Memory at feb00000 (32-bit, non-prefetchable) [size=256K] Expansion ROM at <unassigned> [disabled] Capabilities: <access denied> Kernel driver in use: radeon 00:01.1 Audio device [0403]: ATI Technologies Inc Device [1002:1314] Subsystem: ASUSTeK Computer Inc. Device [1043:84a5] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 44 Region 0: Memory at feb44000 (32-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: HDA Intel 00:04.0 PCI bridge [0604]: Advanced Micro Devices [AMD] Device [1022:1512] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory behind bridge: fea00000-feafffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: <access denied> Kernel driver in use: pcieport 00:11.0 SATA controller [0106]: ATI Technologies Inc SB700/SB800 SATA Controller [AHCI mode] [1002:4391] (prog-if 01 [AHCI 1.0]) Subsystem: ATI Technologies Inc Device [1002:4390] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 32 Interrupt: pin A routed to IRQ 19 Region 0: I/O ports at f140 [size=8] Region 1: I/O ports at f130 [size=4] Region 2: I/O ports at f120 [size=8] Region 3: I/O ports at f110 [size=4] Region 4: I/O ports at f100 [size=16] Region 5: Memory at feb4c000 (32-bit, non-prefetchable) [size=1K] Capabilities: <access denied> Kernel driver in use: ahci 00:12.0 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller [1002:4397] (prog-if 10 [OHCI]) Subsystem: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller [1002:4397] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 32, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at feb4b000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ohci_hcd 00:12.2 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB EHCI Controller [1002:4396] (prog-if 20 [EHCI]) Subsystem: ATI Technologies Inc SB700/SB800 USB EHCI Controller [1002:4396] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 32, Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 17 Region 0: Memory at feb4a000 (32-bit, non-prefetchable) [size=256] Capabilities: <access denied> Kernel driver in use: ehci_hcd 00:13.0 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller [1002:4397] (prog-if 10 [OHCI]) Subsystem: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller [1002:4397] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 32, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at feb49000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ohci_hcd 00:13.2 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB EHCI Controller [1002:4396] (prog-if 20 [EHCI]) Subsystem: ATI Technologies Inc SB700/SB800 USB EHCI Controller [1002:4396] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 32, Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 17 Region 0: Memory at feb48000 (32-bit, non-prefetchable) [size=256] Capabilities: <access denied> Kernel driver in use: ehci_hcd 00:14.0 SMBus [0c05]: ATI Technologies Inc SBx00 SMBus Controller [1002:4385] (rev 42) Subsystem: ATI Technologies Inc SBx00 SMBus Controller [1002:4385] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Kernel driver in use: piix4_smbus 00:14.2 Audio device [0403]: ATI Technologies Inc SBx00 Azalia (Intel HDA) [1002:4383] (rev 40) Subsystem: ASUSTeK Computer Inc. Device [1043:841c] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 32, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at feb40000 (64-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: HDA Intel 00:14.3 ISA bridge [0601]: ATI Technologies Inc SB700/SB800 LPC host controller [1002:439d] (rev 40) Subsystem: ATI Technologies Inc SB700/SB800 LPC host controller [1002:439d] Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 00:14.4 PCI bridge [0604]: ATI Technologies Inc SBx00 PCI to PCI Bridge [1002:4384] (rev 40) (prog-if 01 [Subtractive decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop+ ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64 Bus: primary=00, secondary=02, subordinate=02, sec-latency=64 Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- 00:15.0 PCI bridge [0604]: ATI Technologies Inc Device [1002:43a0] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=03, subordinate=05, sec-latency=0 I/O behind bridge: 0000e000-0000efff Memory behind bridge: fdf00000-fe8fffff Prefetchable memory behind bridge: 00000000d0000000-00000000dfffffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: <access denied> Kernel driver in use: pcieport 00:15.2 PCI bridge [0604]: ATI Technologies Inc Device [1002:43a2] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=06, subordinate=06, sec-latency=0 Memory behind bridge: fe900000-fe9fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: <access denied> Kernel driver in use: pcieport 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 0 [1022:1700] (rev 43) Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- 00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 1 [1022:1701] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- 00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 2 [1022:1702] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- 00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 3 [1022:1703] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Capabilities: <access denied> Kernel driver in use: k10temp 00:18.4 Host bridge [0600]: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 4 [1022:1704] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- 00:18.5 Host bridge [0600]: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 6 [1022:1718] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- 00:18.6 Host bridge [0600]: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 5 [1022:1716] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- 00:18.7 Host bridge [0600]: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 7 [1022:1719] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- 01:00.0 Network controller [0280]: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller [14e4:4727] (rev 01) Subsystem: AzureWave Device [1a3b:2047] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at fea00000 (64-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: brcmsmac 06:00.0 USB Controller [0c03]: Device [1b21:1042] (prog-if 30) Subsystem: ASUSTeK Computer Inc. Device [1043:8488] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at fe900000 (64-bit, non-prefetchable) [size=32K] Capabilities: <access denied> Kernel driver in use: xhci_hcd ** USB devices: Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 003: ID 13d3:5711 IMC Networks Bus 002 Device 002: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub -- System Information: Debian Release: 6.0.2 APT prefers stable APT policy: (900, 'stable'), (700, 'testing'), (600, 'unstable'), (500, 'stable-updates') Architecture: i386 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages linux-image-3.0.0-1-amd64 depends on: ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy ii initramfs-tools [linux-initra 0.99 tools for generating an initramfs ii linux-base 3.3 Linux image base package ii module-init-tools 3.12-1 tools for managing Linux kernel mo Versions of packages linux-image-3.0.0-1-amd64 recommends: ii firmware-linux-free 3 Binary firmware for various driver ii libc6-i686 2.11.2-10 Embedded GNU C Library: Shared lib Versions of packages linux-image-3.0.0-1-amd64 suggests: ii grub-pc 1.98+20100804-14 GRand Unified Bootloader, version pn linux-doc-3.0.0 <none> (no description available) Versions of packages linux-image-3.0.0-1-amd64 is related to: pn firmware-bnx2 <none> (no description available) pn firmware-bnx2x <none> (no description available) pn firmware-ipw2x00 <none> (no description available) pn firmware-ivtv <none> (no description available) pn firmware-iwlwifi <none> (no description available) ii firmware-linux 0.33 Binary firmware for various driver ii firmware-linux-nonfree 0.33 Binary firmware for various driver pn firmware-qlogic <none> (no description available) pn firmware-ralink <none> (no description available) pn xen-hypervisor <none> (no description available) -- debconf information excluded -- To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: 20110822163533.4978.87865.reportbug@lisko">http://lists.debian.org/20110822163533.4978.87865.reportbug@lisko |
Bug#638878: linux-image-3.0.0-1-amd64: Maybe report Debian kernel version with uname
reassign 638878 coreutils 8.5-1
quit Hi Touko, Touko Korpela wrote: > Would it be possible to report Debian kernel version in uname > output? Maybe it can be added to "kernel version" string, uname -v > (now it's "#1 SMP Wed Aug 17 05:07:22 UTC 2011". > This information is present in /proc/version and could be in uname too. The uname utility is provided by coreutils, which could read this information from /proc/version if it's desirable (no opinion on that personally). -- To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: 20110822165449.GA11875@elie.gateway.2wire.net">htt p://lists.debian.org/20110822165449.GA11875@elie.gateway.2wire.net |
Bug#638878: linux-image-3.0.0-1-amd64: Maybe report Debian kernel version with uname
Ben Hutchings wrote:
>> Touko Korpela wrote: >>> Would it be possible to report Debian kernel version in uname >>> output? Maybe it can be added to "kernel version" string, uname -v >>> (now it's "#1 SMP Wed Aug 17 05:07:22 UTC 2011". >>> This information is present in /proc/version and could be in uname too. [...] > I don't think uname(1) should be changed; it is supposed to report > just what uname(2) does. We should change the behaviour of the > latter, if anything. Ah, ok. I admit my bias is towards not passing this information back from uname(2), since application authors could be tempted to parse it to provide Debian-specific behavior changes (for example, to work around bugs using the Debian kernel version number instead of finding some robust way to work around them that applies to other distros, too). On the other hand, as a human-readable version identifier, "linux-2.6 3.0.0-2 as compiled by Ben Hutchings on 2011-08-17 04:08:52" is more convenient than Linux 3.0.0-1-amd64 #1 SMP Wed Aug 17 04:08:52 UTC 2011 x86_64 GNU/Linux What is the underlying problem being solved? Is it that it is hard when reporting bugs to tell the difference between the package version and ABI version in order to provide the former? -- To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: 20110822184402.GF11875@elie.gateway.2wire.net">htt p://lists.debian.org/20110822184402.GF11875@elie.gateway.2wire.net |
Bug#638878: linux-image-3.0.0-1-amd64: Maybe report Debian kernel version with uname
On Mon, Aug 22, 2011 at 01:44:03PM -0500, Jonathan Nieder wrote:
> Ben Hutchings wrote: > >> Touko Korpela wrote: > > >>> Would it be possible to report Debian kernel version in uname > >>> output? Maybe it can be added to "kernel version" string, uname -v > >>> (now it's "#1 SMP Wed Aug 17 05:07:22 UTC 2011". > >>> This information is present in /proc/version and could be in uname too. > [...] > > I don't think uname(1) should be changed; it is supposed to report > > just what uname(2) does. We should change the behaviour of the > > latter, if anything. > > Ah, ok. I admit my bias is towards not passing this information back > from uname(2), since application authors could be tempted to parse it > to provide Debian-specific behavior changes (for example, to work > around bugs using the Debian kernel version number instead of finding > some robust way to work around them that applies to other distros, > too). On the other hand, as a human-readable version identifier, > "linux-2.6 3.0.0-2 as compiled by Ben Hutchings on 2011-08-17 > 04:08:52" is more convenient than > > Linux 3.0.0-1-amd64 #1 SMP Wed Aug 17 04:08:52 UTC 2011 x86_64 GNU/Linux > > What is the underlying problem being solved? Is it that it is hard > when reporting bugs to tell the difference between the package version > and ABI version in order to provide the former? I think the problem is that many generic scripts that attempt to capture the kernel version will not use 'uname -a', 'uname -rv', or similar. If they were to use /proc/version, that would be sufficient, but then the uname commands probably work for almost every other distribution. A generic script won't check package status (which in any case doesn't necessarily match the running kernel version). (We have an even worse problem with kernel tracebacks; they only show the release e.g. '2.6.32-5-amd64'. But we could change that too.) Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: 20110822191041.GB29924@decadent.org.uk">http://lists.debian.org/20110822191041.GB29924@decadent.org.uk |
Bug#638878: linux-image-3.0.0-1-amd64: Maybe report Debian kernel version with uname
On Mon, Aug 22, 2011 at 01:44:03PM -0500, Jonathan Nieder wrote:
> Ben Hutchings wrote: > >> Touko Korpela wrote: > > >>> Would it be possible to report Debian kernel version in uname > >>> output? Maybe it can be added to "kernel version" string, uname -v > >>> (now it's "#1 SMP Wed Aug 17 05:07:22 UTC 2011". > >>> This information is present in /proc/version and could be in uname too. > [...] > > I don't think uname(1) should be changed; it is supposed to report > > just what uname(2) does. We should change the behaviour of the > > latter, if anything. > > Ah, ok. I admit my bias is towards not passing this information back > from uname(2), since application authors could be tempted to parse it > to provide Debian-specific behavior changes (for example, to work > around bugs using the Debian kernel version number instead of finding > some robust way to work around them that applies to other distros, > too). On the other hand, as a human-readable version identifier, > "linux-2.6 3.0.0-2 as compiled by Ben Hutchings on 2011-08-17 > 04:08:52" is more convenient than > > Linux 3.0.0-1-amd64 #1 SMP Wed Aug 17 04:08:52 UTC 2011 x86_64 GNU/Linux > > What is the underlying problem being solved? Is it that it is hard > when reporting bugs to tell the difference between the package version > and ABI version in order to provide the former? For example when reporting bugs upstream and using their scripts. It's true that you can sometimes guess Debian version number from the compile time (that shows in uname) but if Debian version can be added there I say go for it. -- To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: 20110822191533.GA31021@tiikeri.vuoristo.local">htt p://lists.debian.org/20110822191533.GA31021@tiikeri.vuoristo.local |
Bug#638878: linux-image-3.0.0-1-amd64: Maybe report Debian kernel version with uname
On Mon, Aug 22, 2011 at 08:10:41PM +0100, Ben Hutchings wrote:
I think the problem is that many generic scripts that attempt to capture the kernel version will not use 'uname -a', 'uname -rv', or similar. If they were to use /proc/version, that would be sufficient, but then the uname commands probably work for almost every other distribution. A generic script won't check package status (which in any case doesn't necessarily match the running kernel version). I'd call it a simple expectation problem; people would like uname to say something like 2.6.32-34squeeze1 rather than "#1 SMP Wed May 18 07:08:50 UTC 2011" when they ask about the kernel version. Mike Stone -- To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: b4aaaf12-ccf3-11e0-a18f-001cc0cda50c@msgid.mathom.us">http://lists.debian.org/b4aaaf12-ccf3-11e0-a18f-001cc0cda50c@msgid.mathom.us |
Bug#638878: linux-image-3.0.0-1-amd64: Maybe report Debian kernel version with uname
On Mon, Aug 22, 2011 at 11:27:10AM -0600, Bob Proulx wrote:
> tags 638878 + moreinfo > thanks > > Touko Korpela wrote: > > Would it be possible to report Debian kernel version in uname > > output? Maybe it can be added to "kernel version" string, uname -v > > (now it's "#1 SMP Wed Aug 17 05:07:22 UTC 2011". > > This information is present in /proc/version and could be in uname too. > > Exactly what information is it precisely that you wish included in > 'uname' output? Because uname already includes the kernel version > information. > > $ uname -a > Linux example 3.0.0-1-amd64 #1 SMP Sun Jul 24 02:24:44 UTC 2011 x86_64 GNU/Linux It shows now only Debian package name (3.0.0-1-amd64 part), not version (3.0.0-2). > > I don't yet know what information you want to access from > /proc/version but since accessing specific information from > /proc/version is intrinsically non-portable it seems bad to hack it > into 'uname' making it more non-portable. And since it is trivial to > read it from /proc/version directly there doesn't seem to be any need > to hack this into 'uname'. Why not read it from /proc/version directly? It's simpler if you don't need to find data from many places. I think "uname -a" should tell version of kernel package used if that information is available. -- To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: 20110822194408.GB31021@tiikeri.vuoristo.local">htt p://lists.debian.org/20110822194408.GB31021@tiikeri.vuoristo.local |
Bug#638878: linux-image-3.0.0-1-amd64: Maybe report Debian kernel version with uname
Ben Hutchings wrote:
> I think the problem is that many generic scripts that attempt to > capture the kernel version will not use 'uname -a', 'uname -rv', or > similar. If they were to use /proc/version, that would be sufficient, > but then the uname commands probably work for almost every other > distribution. A generic script won't check package status (which > in any case doesn't necessarily match the running kernel version). > > (We have an even worse problem with kernel tracebacks; they only show > the release e.g. '2.6.32-5-amd64'. But we could change that too.) Thanks for explaining. I fear this gets into thorny territory quickly --- the ideal behavior would be $ uname -r 3.0.0-2 but it is not uncommon to want to examine the linux-image-$(uname -r) package and various scripts assume that modules live in /lib/modules/$(uname -r). Thus a proper fix involves finding a way for (out-of-tree) modules to be shared between kernels with different ABI as long as they are compatible with the module, so the ABI version could be bumped for every stable update. Which is something that was wanted anyway. In the short term, though, some hack like the following could help, to tweak "uname -v" output. (And maybe including UTS_VERSION in tracebacks as an additional patch, as you mentioned.) --- diff --git i/scripts/mkcompile_h w/scripts/mkcompile_h index f221ddf69080..2147f577e6f9 100755 --- i/scripts/mkcompile_h +++ w/scripts/mkcompile_h @@ -53,7 +53,11 @@ else LINUX_COMPILE_HOST=$KBUILD_BUILD_HOST fi -UTS_VERSION="#$VERSION" +if test -z "$UTS_VERSION_OVERRIDE"; then + UTS_VERSION="#$VERSION" +else + UTS_VERSION=$UTS_VERSION_OVERRIDE +fi CONFIG_FLAGS="" if [ -n "$SMP" ] ; then CONFIG_FLAGS="SMP"; fi if [ -n "$PREEMPT" ] ; then CONFIG_FLAGS="$CONFIG_FLAGS PREEMPT"; fi -- -- To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: 20110822195446.GG11875@elie.gateway.2wire.net">htt p://lists.debian.org/20110822195446.GG11875@elie.gateway.2wire.net |
Bug#638878: linux-image-3.0.0-1-amd64: Maybe report Debian kernel version with uname
On Mon, 2011-08-22 at 14:54 -0500, Jonathan Nieder wrote:
> Ben Hutchings wrote: > > > I think the problem is that many generic scripts that attempt to > > capture the kernel version will not use 'uname -a', 'uname -rv', or > > similar. If they were to use /proc/version, that would be sufficient, > > but then the uname commands probably work for almost every other > > distribution. A generic script won't check package status (which > > in any case doesn't necessarily match the running kernel version). > > > > (We have an even worse problem with kernel tracebacks; they only show > > the release e.g. '2.6.32-5-amd64'. But we could change that too.) > > Thanks for explaining. I fear this gets into thorny territory quickly > --- the ideal behavior would be > > $ uname -r > 3.0.0-2 > > but it is not uncommon to want to examine the linux-image-$(uname -r) > package and various scripts assume that modules live in > /lib/modules/$(uname -r). Thus a proper fix involves finding a way > for (out-of-tree) modules to be shared between kernels with different > ABI as long as they are compatible with the module, so the ABI version > could be bumped for every stable update. Which is something that was > wanted anyway. Right. > In the short term, though, some hack like the following could help, to > tweak "uname -v" output. (And maybe including UTS_VERSION in > tracebacks as an additional patch, as you mentioned.) [...] We already patch scripts/mkcompile_h to add the Debian-specific information to /proc/version (see debian/patches/debian/version.patch). We definitely shouldn't replace any information in custom builds from linux-source-*, but there isn't generally enough space to append the full Debian version. So I would suggest something like: --- a/scripts/mkcompile_h +++ b/scripts/mkcompile_h @@ -58,6 +58,13 @@ if [ -n "$SMP" ] ; then CONFIG_FLAGS="SMP"; fi if [ -n "$PREEMPT" ] ; then CONFIG_FLAGS="$CONFIG_FLAGS PREEMPT"; fi UTS_VERSION="$UTS_VERSION $CONFIG_FLAGS $TIMESTAMP" + +DISTRIBUTION=$(lsb_release -is 2>/dev/null) +DISTRIBUTION=${DISTRIBUTION:-Debian} + +if [ "$DISTRIBUTION_OFFICIAL_BUILD" ]; then + UTS_VERSION="#0 $DISTRIBUTION $DISTRIBUTION_VERSION" +fi # Truncate to maximum length --- END --- Ben. |
Bug#638878: linux-image-3.0.0-1-amd64: Maybe report Debian kernel version with uname
Ben Hutchings wrote:
> --- a/scripts/mkcompile_h > +++ b/scripts/mkcompile_h > @@ -58,6 +58,13 @@ > if [ -n "$SMP" ] ; then CONFIG_FLAGS="SMP"; fi > if [ -n "$PREEMPT" ] ; then CONFIG_FLAGS="$CONFIG_FLAGS PREEMPT"; fi > UTS_VERSION="$UTS_VERSION $CONFIG_FLAGS $TIMESTAMP" > + > +DISTRIBUTION=$(lsb_release -is 2>/dev/null) > +DISTRIBUTION=${DISTRIBUTION:-Debian} > + > +if [ "$DISTRIBUTION_OFFICIAL_BUILD" ]; then > + UTS_VERSION="#0 $DISTRIBUTION $DISTRIBUTION_VERSION" > +fi > > # Truncate to maximum length Thanks. Looks good to me, for what it's worth. -- To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: 20110823061317.GF4623@elie.gateway.2wire.net">http ://lists.debian.org/20110823061317.GF4623@elie.gateway.2wire.net |
| All times are GMT. The time now is 08:14 PM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.