Bug#638878: linux-image-3.0.0-1-amd64: Maybe report Debian kernel version with uname

08-22-2011, 04:35 PM

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

08-22-2011, 04:54 PM

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

08-22-2011, 06:44 PM

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

08-22-2011, 07:10 PM

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

08-22-2011, 07:15 PM

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

08-22-2011, 07:23 PM

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

08-22-2011, 07:44 PM

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

08-22-2011, 07:54 PM

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

08-23-2011, 04:52 AM

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.

08-23-2011, 06:13 AM

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