Bug#1024149: linux-image-amd64: 32-bit mmap() puts large files at non-random address
On Sat, 14 Jan 2023 16:12:47 +0100 Salvatore Bonaccorso wrote: > Hi Jakub, > > On Thu, Jan 12, 2023 at 01:24:16PM +0100, Jakub Wilk wrote: > > * Salvatore Bonaccorso , 2022-11-19 11:11: > > > Given you were able to tackle the issue further, can you report the > > > issue to upstream > > > > Don't count on me. Sorry! > > Okay thanks for beeing explicit on that. Then I guess it's on our end > to try to get that upstream. > > Regards, > Salvatore > > This bug seems to also affect 64-bit mmap (though not nearly as badly), and is written about here: https://zolutal.github.io/aslrnt/
Bug#996713: firmware-brcm80211: firmware becomes non-responsive while running as an access point on RPI4
On Mon, 25 Oct 2021 18:00:16 -0400 Andres Salomon wrote: > > > Now I'll try a 5.14 kernel backport (with the firmware from bullseye). > If it STILL happens, then I'll try and get a patch upstream to detect > this issue and reinit the hardware. > > Just an update - shortly after I tried testing the 5.14 kernel, the microsd card in my pi4 died. While I waited for a new card to arrive, I also picked up a much faster wifi adapter. So while I'm still using the brcm80211 chip for our 2.4ghz AP, I have a 5ghz that every other device in our house except for one is using. So despite still using a 5.10 kernel, I haven't been able to reproduce this because the 2.4ghz wifi just isn't that busy. Clearly the bug was being triggered by either multiple 2.4ghz wifi devices, or a lot of 2.4ghz traffic (or both).
Bug#996713: firmware-brcm80211: firmware becomes non-responsive while running as an access point on RPI4
On 11/15/21 3:22 AM, Diederik de Haas wrote: Andres: You mentioned bullseye in your initial report, but it didn't have the usual footer mentioning various program versions and I'm especially interested in the kernel version. Could you mention that in subsequent reports (if any)? The user in #debian-raspberrypi was using kernel 5.10.0-9-arm64 on a Bullseye system. I then suggested to try the firmware-brcm80211 from testing to see whether that would make a difference. I'll leave the progress reporting up to the users themselves. I was originally using 5.10.0-9-arm64 5.10.70-1, and that is what I tested both firmware-brcm80211 packages with. I haven't tried earlier 5.10 kernels.
Bug#996713: firmware-brcm80211: firmware becomes non-responsive while running as an access point on RPI4
On Sun, 17 Oct 2021 13:10:19 -0400 Andres Salomon wrote: [...] > > I'm currently trying a newer Cypress firmware (from unstable), so > we'll see if it also has the same crash. > Same thing with the firmware-brcm80211 20210818-1 in unstable. Oct 17 12:49:58 wifi1 kernel: [ 14.057714] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.clm_blob Oct 17 12:49:58 wifi1 kernel: [ 14.065628] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Apr 15 2021 03:03:20 version 7.45.234 (4ca95bb CY) FWID 01-996384e2 [709371.885059] ieee80211 phy0: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110 [709374.445137] ieee80211 phy0: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110 [709374.448854] ieee80211 phy0: brcmf_cfg80211_get_station: GET STA INFO failed, -110 [709384.429474] ieee80211 phy0: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110 [709386.989536] ieee80211 phy0: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110 Now I'll try a 5.14 kernel backport (with the firmware from bullseye). If it STILL happens, then I'll try and get a patch upstream to detect this issue and reinit the hardware.
Bug#996713: firmware-brcm80211: firmware becomes non-responsive while running as an access point on RPI4
Package: firmware-brcm80211 Version: 20210315-3 Severity: normal This bug is mostly for documentation purposes. When running a raspberry pi 4b as an access point, after a random period of time the on-chip firmware will crash and leave the wireless driver (brcmfmac) unusable until the chip is reset. The rest of the kernel is still fine, but the driver is unusable. Here's the firmware version that's in Debian 11 (bullseye): [ 16.365079] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.clm_blob [ 16.373443] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Sep 18 2020 02:27:58 version 7.45.221 (3a6d3a0 CY) FWID 01-bbd9282b Here's one example of the firmware crashing: Oct 12 17:40:06 wifi1 kernel: [263542.782712] brcmfmac: mmc_submit_one: CMD53 sg block write failed -84 Oct 12 17:40:06 wifi1 kernel: [263542.785401] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame Oct 12 17:40:52 wifi1 kernel: [263589.238359] brcmfmac: brcmf_sdio_hdparse: seq 77: max tx seq number error Oct 12 17:40:54 wifi1 kernel: [263591.678597] brcmfmac: brcmf_sdio_hdparse: seq 240: max tx seq number error Oct 12 17:40:54 wifi1 kernel: [263591.681542] brcmfmac: brcmf_sdio_hdparse: seq 241: max tx seq number error Oct 12 17:40:54 wifi1 kernel: [263591.684591] brcmfmac: brcmf_sdio_hdparse: seq 242: max tx seq number error Oct 12 17:40:54 wifi1 kernel: [263591.687778] brcmfmac: brcmf_sdio_hdparse: seq 252: max tx seq number error Oct 12 17:40:54 wifi1 kernel: [263591.690801] brcmfmac: brcmf_sdio_hdparse: seq 253: max tx seq number error Oct 12 17:40:54 wifi1 kernel: [263591.693780] brcmfmac: brcmf_sdio_hdparse: seq 254: max tx seq number error Oct 12 17:41:36 wifi1 kernel: [263633.105406] brcmfmac: brcmf_sdio_hdparse: seq 171: max tx seq number error Oct 12 17:50:57 wifi1 kernel: [264194.196126] brcmfmac: mmc_submit_one: CMD53 sg block write failed -84 Oct 12 17:50:57 wifi1 kernel: [264194.199127] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame Oct 12 17:52:12 wifi1 kernel: [264268.874931] ieee80211 phy0: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110 Oct 12 17:52:14 wifi1 kernel: [264271.434963] ieee80211 phy0: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110 Oct 12 17:52:14 wifi1 kernel: [264271.438681] ieee80211 phy0: brcmf_cfg80211_get_station: GET STA INFO failed, -110 Here's another one: Oct 9 15:59:31 wifi1 kernel: [1543849.606976] ieee80211 phy0: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110 Oct 9 15:59:34 wifi1 kernel: [1543852.169907] ieee80211 phy0: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110 Oct 9 15:59:34 wifi1 kernel: [1543852.173684] ieee80211 phy0: brcmf_cfg80211_get_station: GET STA INFO failed, -110 Oct 9 15:59:42 wifi1 kernel: [1543860.103164] ieee80211 phy0: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110 Oct 9 15:59:44 wifi1 kernel: [1543862.663196] ieee80211 phy0: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110 Oct 9 15:59:44 wifi1 kernel: [1543862.666950] ieee80211 phy0: brcmf_cfg80211_get_station: GET STA INFO failed, -110 Oct 9 15:59:57 wifi1 kernel: [1543875.207367] ieee80211 phy0: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110 Oct 9 15:59:59 wifi1 kernel: [1543877.767429] ieee80211 phy0: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110 Notice how the crashes happened 3 days apart. The crash prior to Oct 9th happened a full month before, so I no longer have logs. I haven't found any kind of pattern in timing. I'm currently trying a newer Cypress firmware (from unstable), so we'll see if it also has the same crash.
Bug#991968: firmware-brcm80211: security updates for wifi FragAttacks
Package: firmware-brcm80211 Version: 20210315-3 Severity: important Tags: security X-Debbugs-Cc: Debian Security Team A whole bunch of wifi (protocol-level) security flaws were published here: https://www.fragattacks.com/ Cypress (AKA Infineon), who maintains some of the broadcom firmware blobs, published this in response: https://community.cypress.com/t5/Security-Bulletin/Potential-Fragmentation-Vulnerabilities-for-Wi-Fi-Devices/ba-p/276441 You can see from that that CVE-2020-24587, CVE-2020-24588, CVE-2020-26145, and CVE-2020-26146 DEFINITELY impact their wifi chipsets, while CVE-2020-26142 and CVE-2020-26144 MAY impact their devices. They have since released updated firmwares to mitigate those security issues. They appear to already be upstream: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/cypress https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/cypress?id=f97e316775237ca5d46a4bc0614a3073ebec5a9e Please provided updated packages for sid and bullseye, if possible (I understand that non-free doesn't necessarily get security updates). I don't know if they changed anything else, but I'm happy to test out a security update package on my Pi 4b (which uses the 43455-sdio blob) if it's helpful for a bullseye update.
Bug#984489: firmware-brcm80211: newer versions fail to load on raspberry pi 4b with "brcmf_sdio_htclk: HT Avail timeout"
Package: firmware-brcm80211 Version: 20210208-3 Severity: important The version of firmware-brcm80211 in bullseye (specifically 20201218-3) works fine on my Rasperry Pi 4 board. However, the version in sid does not. Specifically, the brcmfmac kernel driver fails to load with some clock errors. Here's snippets from boot dmesg: [0.00] Linux version 5.10.0-3-arm64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.10.13-1 (2021-02-06) [0.00] Machine model: Raspberry Pi 4 Model B Rev 1.1 [...] [ 10.308867] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [ 10.318818] usbcore: registered new interface driver brcmfmac [ 10.322875] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4]) [ 10.335422] vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops [vc4]) [ 10.343356] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4]) [ 10.350443] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 10.358185] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 10.365828] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 10.373704] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 10.376815] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.bin [ 10.384437] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0 [ 10.398479] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt [...] [ 11.462064] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100): clkctl 0x50 [...] [ 12.471809] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100): clkctl 0x50 You can specifically see that the driver times out after one second with that error message, then times out again with the error and gives up. No wlan0 is available. There are some pretty major firmware updates between those two versions, and they are generally Good. However, there's also some minor updates to the raspi4 board file /lib//firmware/brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt If we revert the line "boardflags3=0x48200100" in that file back to what was in the 20201218-3 version (so it would instead be "boardflags3=0x44200100"), and then reboot, the driver now loads: [ 13.342844] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [ 13.353195] usbcore: registered new interface driver brcmfmac [ 13.465495] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.bin [ 13.472403] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 13.488397] hub 1-1:1.0: 4 ports detected [ 13.488428] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 13.500413] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt [ 13.673868] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [ 13.812345] usb 1-1.3: new high-speed USB device number 3 using xhci_hcd [ 13.856502] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.clm_blob [ 13.869572] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Sep 18 2020 02:27:58 version 7.45.221 (3a6d3a0 CY) FWID 01-bbd9282b [...] [ 23.951744] br0: port 2(wlan0) entered blocking state [ 23.953859] br0: port 2(wlan0) entered disabled state [ 23.956221] device wlan0 entered promiscuous mode [ 23.961230] br0: port 3(wlan1) entered blocking state [ 23.963358] br0: port 3(wlan1) entered disabled state [ 23.966488] device wlan1 entered promiscuous mode [ 29.417766] br0: port 2(wlan0) entered blocking state [ 29.419853] br0: port 2(wlan0) entered forwarding state I'm not sure if the driver needs fixing, or if the boardflags need fixing, but the boardflags thing seems to be a functional workaround for users hitting this issue. Thanks to Steev Klimaszewski for helping me figure out the workaround.
Bug#733088: linux-image-3.2.0-4-686-pae: tpm_tis module breaks suspend on x200s
Package: linux-image-3.2.0-4-686-pae Version: 3.2.51-1 Severity: normal With the standard wheezy kernel, suspend fails: [ 31.357482] PM: Syncing filesystems ... done. [ 31.357913] PM: Preparing system for mem sleep [ 31.424249] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 31.440124] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [ 31.456115] PM: Entering mem sleep [ 31.456175] Suspending console(s) (use no_console_suspend to debug) [ 31.456538] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 31.462322] sd 0:0:0:0: [sda] Stopping disk [ 31.512132] legacy_suspend(): pnp_bus_suspend+0x0/0x61 returns 28 [ 31.512136] PM: Device 00:0a failed to suspend: error 28 [ 31.709570] PM: Some devices failed to suspend [ 31.714160] sd 0:0:0:0: [sda] Starting disk [ 31.903446] PM: resume of devices complete after 193.872 msecs [ 31.903558] PM: Finishing wakeup. I tried upgrading to linux-image-3.11-0.bpo.2-686-pae from wheezy-backports, and suspend with that kernel works just fine. Googling turned up https://bugzilla.kernel.org/show_bug.cgi?id=16256. Sure enough, unloading the tpm_tis module allows suspend to work: [ 339.014601] PM: Syncing filesystems ... done. [ 339.015137] PM: Preparing system for mem sleep [ 339.080271] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 339.096137] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [ 339.112115] PM: Entering mem sleep [ 339.112173] Suspending console(s) (use no_console_suspend to debug) [ 339.112834] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 339.121793] sd 0:0:0:0: [sda] Stopping disk [ 339.134530] pciehp :00:1c.3:pcie04: pciehp_suspend ENTRY [ 339.134558] pciehp :00:1c.1:pcie04: pciehp_suspend ENTRY [ 339.134567] pciehp :00:1c.0:pcie04: pciehp_suspend ENTRY [ 339.148126] i915 :00:02.0: power state changed by ACPI to D3 [ 339.228355] e1000e :00:19.0: wake-up capability enabled by ACPI [ 339.384169] PM: suspend of devices complete after 271.791 msecs [ 339.400269] ehci_hcd :00:1d.7: wake-up capability enabled by ACPI [ 339.416111] ehci_hcd :00:1d.7: power state changed by ACPI to D3 [ 339.416252] uhci_hcd :00:1d.0: wake-up capability enabled by ACPI [ 339.416257] uhci_hcd :00:1d.0: power state changed by ACPI to D2 [ 339.416306] ehci_hcd :00:1a.7: wake-up capability enabled by ACPI [ 339.432121] ehci_hcd :00:1a.7: power state changed by ACPI to D3 [ 339.432187] uhci_hcd :00:1a.2: wake-up capability enabled by ACPI [ 339.432192] uhci_hcd :00:1a.2: power state changed by ACPI to D2 [ 339.432283] uhci_hcd :00:1a.0: wake-up capability enabled by ACPI [ 339.432287] uhci_hcd :00:1a.0: power state changed by ACPI to D2 [ 339.432347] PM: late suspend of devices complete after 48.171 msecs [ 339.433238] ACPI: Preparing to enter system sleep state S3 [ 339.604173] PM: Saving platform NVS memory [ 339.605674] Disabling non-boot CPUs ... [ 339.708106] CPU 1 is now offline I suspect some variant of commit 59f6fbe429 is needed, but I haven't verified what's in the wheezy kernel git tree. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131225025228.6e8a6...@dev.lan
Bug#729542: firmware-ipw2200: instability with firmware 3.1
BTW, the original download site for the firmware gives me a 404. I snagged the 3.0 version from fedora: http://pkgs.fedoraproject.org/repo/pkgs/ipw2200-firmware/ipw2200-fw-3.0.tgz/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131116104352.4c251...@dev.lan
Bug#729542: firmware-ipw2200: instability with firmware 3.1
I've been actively using the machine for 48 hrs now, with no network problems. I think it's safe to say that the 3.0 works well with ipw2200s, while 3.1 is buggy. Please consider downgrading the firmware. Thanks! -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131116104150.12266...@dev.lan
Bug#715370: Acknowledgement (linux-image-3.9-1-486: CONFIG_GPIO_CS5535 has been set to 'y' when it should be 'M')
Yes, CONFIG_GPIO_CS5535 is forced to 'Y' because the OLPC XO-1 power management settings (CONFIG_OLPC_XO1_PM, CONFIG_OLPC_XO1_SCI, and a few other related options) are boolean. Making the PM code modular is the only way to fix this, but doing so would be racy due to the various hooks that are registered (and really, are required by the system). It's not impossible, simply difficult. The right answer would be to have a module that doesn't allow removal. There may be additional issues as well, I don't recall. As far as CONFIG_GPIO_SYSFS, I don't know why that's unset. I'm assuming it's the case because GPIOs aren't widely used on x86, and twiddling GPIO lines from userspace even less so? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130708134916.19e81...@dev.queued.net
Bug#705788: fb-modules-3.2.0-4-486-di: please include viafb module for OLPC XO-1.5 support in d-i
On Sat, 20 Apr 2013 16:07:47 +0100 Ben Hutchings b...@decadent.org.uk wrote: Control: tag -1 patch On Fri, 2013-04-19 at 22:07 -0700, Andres Salomon wrote: Package: fb-modules-3.2.0-4-486-di Version: 3.2.41-2 The OLPC XO-1.5 doesn't support VESA. It needs the viafb driver in order to get display output. Similar to #705780, please consider including viafb.ko in the fb-modules udeb. I just tried loading viafb on a VIA Epia board (Unichrome CLE266) running squeeze, and the console is now broken. I can see the GRUB boot messages (from weeks ago) and a mess of dots in various colours. The module also has a whole lot of parameters which suggest that it may need board-specific configuration. So I don't think we can allow it to be autoloaded on the whole range of device IDs it claims. What if we apply a patch (attached) to match the specific subsystem ID on the XO 1.5? (I got this from the Openchrome source so hopefully it's correct.) This still leaves us needing to update udev and then worry about kernel vs udev versions, but it should cover the installer. The idea seems fine to me, though I think that VX855 is in other systems besides OLPC ones. Cc'ing Daniel, maybe he has some other ideas? Note that simply including the module in debian-installer doesn't cause the module to be loaded as far as I can tell (even with a PCI device id match). It still needs to be manually loaded, so it would seem safe for d-i. signature.asc Description: PGP signature
Bug#705780: fb-modules-3.2.0-4-486-di: please include lxfb module for OLPC XO-1 support in d-i
Package: fb-modules-3.2.0-4-486-di Version: 3.2.41-2 The Geode LXFB driver used to be built into the Debian kernel. With bug #686528, it was made modular, which makes things more difficult for the XO-1 platform. OLPC XO-1 doesn't support VESA, which means the lxfb driver is required in order to get display output. Including lxfb.ko in the fb-modules udeb is necessary to add OLPC XO-1 support to d-i. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130419143805.3923b...@dev.queued.net
Bug#705788: fb-modules-3.2.0-4-486-di: please include viafb module for OLPC XO-1.5 support in d-i
Package: fb-modules-3.2.0-4-486-di Version: 3.2.41-2 The OLPC XO-1.5 doesn't support VESA. It needs the viafb driver in order to get display output. Similar to #705780, please consider including viafb.ko in the fb-modules udeb. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130419220739.3883d...@dev.queued.net
Bug#686528: linux-image-3.2.0-3-486: [lxfb] doesn't understand modes passed via GRUB_GFXPAYLOAD_LINUX in /etc/default/grub
On Sun, 02 Sep 2012 21:26:21 +0100 Ben Hutchings b...@decadent.org.uk wrote: I'm cc'ing Andres because he's previously requested various Geode config changes to support OLPC. Thanks! On Sun, 2012-09-02 at 22:38 +0300, Martin-Éric Racine wrote: Package: src:linux Version: 3.2.23-1 Severity: normal For some reason, lxfb doesn't understand the recommended method for setting the screen mode on non-KMS framebuffers via GRUB_GFXPAYLOAD_LINUX in /etc/default/grub. I think this hand-over only works with basic VGA and VESA drivers, not with any 'native' video driver. This, combined with the fact that lxfb recently started to ship as a compiled-in feature, rather than as a module, It looks like lxfb was always built-in on the 486 flavour and modular on the 686 flavour, so this change results from the removal of the 686 flavour. I don't see any good reason for the difference and I think it should be modular on 486 too. (Also, I notice that the Geode framebuffer drivers are enabled on the 686-pae flavour, which doesn't run on any of the Geode SoCs!) I'd certainly prefer it to be modular. Module autoloading happens properly thanks to the video chip being a (virtual) PCI device. systematically results in this host booting to a rather small 80x30 console, rather than a graphic framebuffer at a larger resolution. What I have configuered: GRUB_GFXMODE=800x600x32,800x600x24,800x600x16,800x600x8,800x600 GRUB_GFXPAYLOAD_LINUX=1280x1024x32,1280x1024x24,1280x1024x16,1280x1024x8,1280x1024 ... which works fine whenever vesafb use is enforced over lxfb via cmdline option video=vesafb, but fails whenever I let the kernel choose lxfb as its preferred driver. Apparently the lxfb driver requires you to specify the mode through the 'lxfb' kernel parameter or the 'mode_option' module parameter. That's correct. On olpc, we need to boot with video=lxfb in order to have the framebuffer come up properly. Maybe someday someone will port lxfb to kms, but I'm not holding my breath. signature.asc Description: PGP signature
Bug#569494: linux-image-2.6.32-trunk-686: pcspkr sometimes breaks audio
On Sat, 3 Sep 2011 09:14:39 -0500 Jonathan Nieder jrnie...@gmail.com wrote: Hi Andres, [...] Ways forward: - libasound2 could use Suggests: alsa-base. (Recommends would be too strong because alsa-base has nontrivial dependencies itself and it is not too unusual to use binaries linked to the ALSA libs on a system that doesn't need sound support.) - Should /etc/modprobe.d/alsa-base.conf be shipped in udev instead of alsa-base? - Is there any long-term path away from (1)? Thanks, and sorry for the long quiet. Jonathan Note that I no longer have the hardware that was described in the bug report, and I don't actually recall what the problem was anymore.. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110913135313.1064d...@queued.net
Bug#640964: linux-image-3.1.0-rc4-486: BUG() triggered on XO-1 hardware
Package: linux-image-3.1.0-rc4-486 Version: 3.1.0~rc4-1~experimental.1 Severity: normal During boot on an OLPC XO-1, I encounter the following problem. I believe it's the statement BUG_ON(a-cpuid = NCAPINTS*32), though I'm not staring at an exact copy of linux-2.6 source. Boot device: /pci/nandflash@c:\vmlinuz Arguments: ro redboot.directory=0 ubi.mtd=root root=ubi:root rootfstype=ubifs video=lxfb fbcon=font:SUN12x22 console=ttyS0,115200 console=tty0 Loading ramdisk image from /pci/nandflash@c:\initrd.img ... [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.1.0-rc4-486 (Debian 3.1.0~rc4-1~experimental.1) (b...@decadent.org.uk) (gcc version 4.5.3 (Debian 4.5.3-8) ) #1 Wed Aug 31 19:39:30 UTC 2011 [0.00] OFW detected in memory, cif @ 0xff8378f0 (reserving top 8MB) [0.00] Reserving virtual address space above 0xff80 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e801: - 0009f000 (usable) [0.00] BIOS-e801: 0010 - 0d5e1000 (usable) [0.00] Notice: NX (Execute Disable) protection missing in CPU! [0.00] DMI 2.1 present. [0.00] last_pfn = 0xd5e1 max_arch_pfn = 0x10 [0.00] init_memory_mapping: -0d5e1000 [0.00] RAMDISK: 0d5e1000 - 0ec0 [0.00] Allocated new RAMDISK: 0bfc2000 - 0d5e1000 [0.00] Move RAMDISK from 0d5e1000 - 0ebf to 0bfc2000 - 0d5e0fff [0.00] ACPI Error: A valid RSDP was not found (20110623/tbxfroot-219) [0.00] 0MB HIGHMEM available. [0.00] 213MB LOWMEM available. [0.00] mapped low ram: 0 - 0d5e1000 [0.00] low ram: 0 - 0d5e1000 [0.00] PROM DT: Old firmware detected, applying fixes [0.00] PROM DT: Built device tree with 40960 bytes of memory. [0.00] Zone PFN ranges: [0.00] DMA 0x0010 - 0x1000 [0.00] Normal 0x1000 - 0xd5e1 [0.00] HighMem empty [0.00] Movable zone start PFN for each node [0.00] early_node_map[2] active PFN ranges [0.00] 0: 0x0010 - 0x009f [0.00] 0: 0x0100 - 0xd5e1 [0.00] Using APIC driver default [0.00] SFI: Simple Firmware Interface v0.81 http://simplefirmware.org [0.00] Error: No information about IO-APIC in OF. [0.00] No local APIC present or hardware disabled [0.00] APIC: disable apic facility [0.00] APIC: switched to apic NOOP [0.00] PM: Registered nosave memory: 0009f000 - 0010 [0.00] Allocating PCI resources starting at d5e1000 (gap: d5e1000:f2a1f000) [0.00] Booting paravirtualized kernel on bare hardware [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 54212 [0.00] Kernel command line: ro redboot.directory=0 ubi.mtd=root root=ubi:root rootfstype=ubifs video=lxfb fbcon=font:SUN12x22 console=ttyS0,115200 console=tty0 [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Initializing CPU#0 [0.00] Initializing HighMem for node 0 (:) [0.00] Memory: 189012k/219012k available (2556k kernel code, 29548k reserved, 1342k data, 444k init, 0k highmem) [0.00] virtual kernel memory layout: [0.00] fixmap : 0xff7a1000 - 0xff7ff000 ( 376 kB) [0.00] pkmap : 0xff00 - 0xff40 (4096 kB) [0.00] vmalloc : 0xcdde1000 - 0xfeffe000 ( 786 MB) [0.00] lowmem : 0xc000 - 0xcd5e1000 ( 213 MB) [0.00] .init : 0xc13cf000 - 0xc143e000 ( 444 kB) [0.00] .data : 0xc127f32c - 0xc13ced00 (1342 kB) [0.00] .text : 0xc100 - 0xc127f32c (2556 kB) [0.00] Checking if this processor honours the WP bit even in supervisor mode...Ok. [0.00] NR_IRQS:288 [0.00] Console: colour EGA 80x25 [0.00] console [tty0] enabled [0.00] console [ttyS0] enabled [0.00] Fast TSC calibration using PIT [0.00] Detected 430.942 MHz processor. [0.012008] Calibrating delay loop (skipped), value calculated using timer frequency.. 861.88 BogoMIPS (lpj=1723768) [0.018781] pid_max: default: 32768 minimum: 301 [0.020245] Security Framework initialized [0.024023] SELinux: Disabled at boot. [0.028091] Mount-cache hash table entries: 512 [0.037485] Initializing cgroup subsys cpuacct [0.040046] Initializing cgroup subsys memory [0.044059] Initializing cgroup subsys devices [0.048016] Initializing cgroup subsys freezer [0.052015] Initializing cgroup subsys net_cls [0.056016] Initializing cgroup subsys blkio [0.060170] CPU:
Bug#639113: linux-image-3.0.0-1-486: please enable various OLPC drivers
Package: linux-image-3.0.0-1-486 Version: 3.0.0-2 Severity: wishlist OLPC support is partially enabled in this kernel, but a few drivers that have gone upstream (or been reworked) are missing from the config. Please consider enabling the following config options: CONFIG_MFD_CS5535=m (used by the XO-1) CONFIG_MFD_VX855=m (used by the XO-1.5) CONFIG_GEODE_WDT=m (nominally used by the XO-1) CONFIG_GPIO_CS5535=m(used by the XO-1) CONFIG_CS5535_MFGPT=m (used by the XO-1) CONFIG_CS5535_MFGPT_DEFAULT_IRQ=7 CONFIG_CS5535_CLOCK_EVENT_SRC=m -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110824012804.66263caf@debxo
Bug#639113: linux-image-3.0.0-1-486: please enable various OLPC drivers
Oh, and the 3.1 kernel will be including the following new symbols as well: CONFIG_OLPC_XO1_PM=y CONFIG_OLPC_XO1_RTC=y CONFIG_OLPC_XO1_SCI=y CONFIG_OLPC_XO15_SCI=y It would be nice to have those in -486 as well. The -686-pae kernel won't be used for OLPC, because PAE conflicts with it. So, despite both XO-1 and XO-1.5 machines being closer to 686, the -486 image will be required. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110824092841.54c10189@debxo
Bug#569494: linux-image-2.6.32-trunk-686: pcspkr sometimes breaks audio
In theory, this should never happen; snd_card_create() takes an idx that sets the order of cards, /etc/modprobe.d/alsa-base-blacklist.conf blacklists snd-pcsp (so it should never be loaded!), and /etc/modprobe.d/alsa-base.conf sets idx=-2 for snd_pcsp so that it's not loaded as the first soundcard. This is a fresh install; alsa-base was not initially installed (I did a minimal install, and then installed packages manually). That's why I hit this. I'd suggest adding alsa-base as a Recommends or Suggests for linux-image-2.6*-686 (and possibly others). -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: Bug handling policy
Hi Ben, Ack on everything below. Some comments are below. On Sat, 17 Oct 2009 17:14:54 +0100 Ben Hutchings b...@decadent.org.uk wrote: I've drafted a policy based on what I believe to be best practice. Please comment - is anything wrong, or anything missing? I also left some questions in square brackets. Ben. --- 1. Required information Submitters are expected to run reportbug or other tool that runs our 'bug' script under the kernel version in question. The response to reports without this information should be a request to follow-up using reportbug. If we do not receive this the bug may be closed [after how long?]. As Dann said, 1 month seems reasonable. Exceptions: * If the kernel does not boot or is very unstable, instead of the usual system information we need the console messages in a clear photograph or via serial console or netconsole (or even retyping as a last resort). Ask the submitter to remove 'quiet' and add 'vga=6' (where applicable) to the kernel command line. Information should be available telling a user (or pointing them to docs about) how to get information via serial/netconsole/etc. It should presumably live @ http://wiki.debian.org/DebianKernelReportingBugs. When users don't provide enough information, they can just be pointed there (ideally w/ an anchor that takes them directly to the correct section). If users are willing, having documentation describing how to bisect would be quite helpful for diagnosing such critical bugs. I'd also recommend explicitly disallowing photographs of oopses, as they tend to miss a lot of information that's scrolled off the screen. Even if the entire oops is included, it may be an oops that resulted from an earlier oops (causing someone to chase a non-bug). * If the report is relaying information about a bug acknowledged upstream, we do not need system information but we do need specific references (bugzilla.kernel.org or git commit id). * If the bug is clearly not hardware-specific (e.g. packaging error), we do not need system information. 2. Severities Many submitters believe that their bug meets one of the following criteria for high severity. We interpret them as follows and will downgrade as appropriate: 'critical: makes unrelated software on the system (or the whole system) break...' The bug must make the kernel unbootable or unstable on common hardware or all systems that a specific flavour is supposed to support. There is no 'unrelated software' since everything depends on the kernel. 'grave: makes the package in question unusable or mostly so...' If the kernel is unusable, this already qualifies as critical. [Alternately: given that the user can normally reboot into an earlier kernel version, does that mean the bug is 'grave', not 'critical'?] No. Rebooting into an earlier kernel means that the user ends up with known security holes. That should never be something that's encouraged. 'grave: ...or causes data loss...' We exclude loss of data in memory due to a crash. Only corruption of data in storage or communication, or silent failure to write data, qualifies. It happens rarely, but it does happen - you might want to also mention hardware damage here. Overheating due to ACPI bugs where fans don't get turned on, filesystems trashing flash memory due to numerous writes to the same area, and so on. 3. Tagging We do not use user-tags, but in order to aid bug triage we should: * Add 'moreinfo' whenever we are waiting for a response from the submitter and remove it when we are not. * Add 'upstream', 'fixed-upstream', 'patch', 'help' where appropriate * Not add 'unreproducible', since bugs are commonly hardware-dependent 4. Analysis by maintainers Generally we should not expect to be able to reproduce bugs without having similar hardware. We should consider: * Searching bugzilla.kernel.org (including closed bugs) or other relevant bug tracker * Searching kernel mailing lists (of the many archives, http://news.gmane.org seems to suck least) http://patchwork.kernel.org/ is pretty awesome, too. Useful when gmane mangles a patch (which it has been known to do). * Viewing git commit logs for relevant source files - In case of a regression, from the known good to the bad version - In other cases, from the bad version forwards, in case the bug has been fixed since * Searching kerneloops.org for similar oopses * Matching the machine code and registers in an 'oops' against the source and deducing how the impossible happened (this doesn't work that often but when it does you look like a genius ;-) 5. Testing by submitter Depending on the technical sophistication of the submitter and the service requirements of the system in question (e.g. whether it's a production server) we can request one or more of the following: * Gathering more information passively (e.g. further logging,
Re: RFC: Bug handling policy
On Wed, 28 Oct 2009 19:38:49 + Berni Elbourn be...@elbournb.fsnet.co.uk wrote: Andres Salomon wrote: 2. Severities Many submitters believe that their bug meets one of the following criteria for high severity. We interpret them as follows and will downgrade as appropriate: 'critical: makes unrelated software on the system (or the whole system) break...' The bug must make the kernel unbootable or unstable on common hardware or all systems that a specific flavour is supposed to support. There is no 'unrelated software' since everything depends on the kernel. 'grave: makes the package in question unusable or mostly so...' If the kernel is unusable, this already qualifies as critical. [Alternately: given that the user can normally reboot into an earlier kernel version, does that mean the bug is 'grave', not 'critical'?] No. Rebooting into an earlier kernel means that the user ends up with known security holes. That should never be something that's encouraged. May I comment here please. Reversion should be accommodated appropriately in this process. Production sites may have no option but to revert as a last resort...such bugs are critical and need tlc. The good news is the site is likely to cooperate with lots of follow up information after reverting simply because of the user visibility of the problem. Subsequent diagnosis of that information should allow the real bug and its severity to be established. Finally I want to say that it risks turning a site away from Debian forever if we just tell them they did wrong by reverting. That's not what I'm saying. If they want to revert, that's fine; so long as they understand the risks. It should not be acceptable for *Debian* to say, oh, just run the unsupported version for a few months. And the way that I read Ben's comment, it sounded like a bug should be less severe if users can be told to run an older (unsupported) version. Ben, please correct me if I'm wrong. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551542: fscache: null pointer dereference in fscache_object_slow_work_execute
Oh and just to let you know, it does say you guys are the maintainers. :) Let me know if you need anything else. ~Matt I'd be interested to know if this still occurs on 2.6.31. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551393: drmRadeonCmdBuffer: -12. Kernel failed to parse or rejected command stream
On Sun, 18 Oct 2009 09:20:28 +1030 Arthur Marsh arthur.ma...@internode.on.net wrote: Package: linux-2.6 Version: 2.6.31-1~experimental.2 Severity: normal I attempted to run extremetuxracer on this machine with radeon9200se and radeon driver and received the following output: How reproducible is this? Does it occur every time you run tuxracer (even after rebooting), or does it only happen every once in a while? [...] [ 7176.628526] Call Trace: [ 7176.628607] [c1083110] ? __alloc_pages_nodemask+0x430/0x474 [ 7176.628669] [c109f35d] ? cache_alloc_refill+0x242/0x40c [ 7176.628711] [c109f5aa] ? __kmalloc+0x83/0xda [ 7176.628973] [d93ebac6] ? radeon_cp_cmdbuf+0xfb/0x117a [radeon] radeon_cp_cmdbuf's kmalloc failed, but the kmalloc allocation size should be limited to 64k.. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550190: linux-image-2.6.31-trunk-amd64: SCSI warnings/errors with LSI SAS1064E controller
On Thu, 8 Oct 2009 08:54:49 -0600 dann frazier da...@debian.org wrote: On Thu, Oct 08, 2009 at 08:17:30PM +1100, Jason White wrote: Package: linux-2.6 Version: 2.6.31-1~experimental.1 Severity: normal After upgrading to 2.6.31 from 2.6.30, I get the following, quite frequently, in my log. Oct 8 19:15:03 jdc kernel: [34919.532016] sd 6:1:0:0: strange observation, the queue depth is (64) meanwhile fw queue depth (65) Oct 8 19:15:37 jdc kernel: [34953.528772] sd 6:1:0:0: strange observation, the queue depth is (64) meanwhile fw queue depth (65) Oct 8 19:15:37 jdc kernel: [34953.540511] sd 6:1:0:0: Queue depth not changed yet hmm.. wonder if this would help: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9d2e9d66a3f032667934144cd61c396ba49f090d Would you be able to test that? If you're definitely certain that it showed up between 2.6.30 and 2.6.31, you could try bisecting it: http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html That would be helpful to everyone involved.. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548397: linux-image-2.6.30-2-686-bigmem: Random Lockup with automount, mysqld, and kswapd0 error messages.
On Fri, 25 Sep 2009 23:33:45 -0500 Paul Logasa Bogen II p...@tamu.edu wrote: After a semi-random period of normal operation (anywhere from a few hours to a week) the machine will suddenly get a series of page allocation errors followed by a series of soft lockup - CPU#[X] stuck messages after which the machine is completely non responsive and has to be hard restarted. Perhaps there's a resource leak of some type? Can you try rebuilding the kernels on these systems with CONFIG_DEBUG_KMEMLEAK? This describes the process of inspecting for memory leaks: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/kmemleak.txt;h=34f6638aa5aceec30d290812fdc7fcebf3b86621;hb=HEAD It would be useful to know the state of the system(s) prior to crash (perhaps with a while (sleep 600); do cat /sys/kernel/debug/kmemleak log; done or something?) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546213: severity of 546213 is normal
On Fri, 25 Sep 2009 10:12:06 +0200 Patrick Schoenfeld schoenf...@debian.org wrote: On Thu, Sep 24, 2009 at 11:01:45PM -0400, Andres Salomon wrote: This sounds an awful lot like a firmware bug, as well (for which we don't have the source code for). Perhaps you could try downgrading your firmware-iwlwifi package and let us know whether that fixes the issue? It sounds like the driver itself is doing the right thing by detecting a firmware problem and reloading. Hmm. No, I haven't yet considered this. The thing is: The driver and the firmware work flawless in 2.6.29, so I guess that this might be a firmware problem, but more likely the driver changed since then and doesn't work with the firmware anymore. But AFAICT there were new release.. So you've verified that you were using the same version of firmware-iwlwifi with 2.6.29 and 2.6.30 then, yes? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546213: severity of 546213 is normal
On Mon, 14 Sep 2009 10:33:21 +0200 Patrick Schoenfeld schoenf...@debian.org wrote: Hi, On Mon, Sep 14, 2009 at 04:31:17AM +0100, Ben Hutchings wrote: On Sun, 2009-09-13 at 22:21 +0200, Patrick Schoenfeld wrote: Hi, Bastian, would you mind *explaining* why you think its justified to decrease the severity of this bug to normal? The bug effectively renders my WLAN useless. I consider that quiet having major effect on the usability of a package without rendering it unusable to everyone. So - why do you think it doesn't and why do you think just downgrading with no explanation is reasonable? Since this is a hardware-specific bug, it has absolutely zero impact on most users. well, kernel bugs are most likely hardware-specific unless they affect components like filesystem drivers etc. According to the severity description it also does not need to impact other users. This sounds an awful lot like a firmware bug, as well (for which we don't have the source code for). Perhaps you could try downgrading your firmware-iwlwifi package and let us know whether that fixes the issue? It sounds like the driver itself is doing the right thing by detecting a firmware problem and reloading. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525351: linux-image-2.6.29-1-686: audio broken on x40
On Tue, 25 Aug 2009 23:44:00 +0200 Moritz Muehlenhoff j...@inutil.org wrote: On Thu, Apr 23, 2009 at 05:53:24PM -0400, Andres Salomon wrote: Package: linux-image-2.6.29-1-686 Version: 2.6.29-3 Hi, On my x40, audio is now broken with 2.6.29-1-686. I believe that this is a Debian-specific regression, as a stock Linus kernel (tag v2.6.29) doesn't have this problem. Some apps (ie, ones using gstreamer) simply refuse to run; others simply output white noise through the speakers/headphones. Is this still an issue with 2.6.30? Hi, Audio on my x40 appears to work correctly with linux-image-2.6.30-1-686 2.6.30-6. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539026: linux-image-2.6.30-1-686: agpgart module fails to initialize
Package: linux-image-2.6.30-1-686 Version: 2.6.30-3 During boot, I see: [1.347047] Linux agpgart interface v0.103 [1.366133] [drm] Initialized drm 1.1.0 20060810 [1.378704] i915 :00:02.0: power state changed by ACPI to D0 [1.378719] i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [1.378726] i915 :00:02.0: setting latency timer to 64 [1.378745] [drm:drm_fill_in_dev] *ERROR* Cannot initialize the agpgart module. [1.378807] DRM: Fill_in_dev failed. [1.378862] i915 :00:02.0: PCI INT A disabled [1.378870] i915: probe of :00:02.0 failed with error -22 This is with the following /proc/cmdline: root=/dev/sda1 ro quiet And the following in /etc/initramfs-tools/modules: i915 modeset=1 This is problematic because it breaks KMS. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525351: linux-image-2.6.29-1-686: audio broken on x40
Package: linux-image-2.6.29-1-686 Version: 2.6.29-3 Hi, On my x40, audio is now broken with 2.6.29-1-686. I believe that this is a Debian-specific regression, as a stock Linus kernel (tag v2.6.29) doesn't have this problem. Some apps (ie, ones using gstreamer) simply refuse to run; others simply output white noise through the speakers/headphones. The audio card is: 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) 00:1f.5 0401: 8086:24c5 (rev 01) On 2.6.29-1-686, I see the following in dmesg: [ 12.256024] intel8x0_measure_ac97_clock: measured 55438 usecs [ 12.256069] intel8x0: clocking to 48000 [ 12.256433] Intel ICH Modem :00:1f.6: PCI INT B - GSI 17 (level, low) - IRQ 17 [ 12.256507] Intel ICH Modem :00:1f.6: setting latency timer to 64 [ 12.360065] MC'97 1 converters and GPIO not ready (0xff00) When attempting to play audio via gstreamer/totem: ** Message: Error: Could not get/set settings from/on resource. gstalsasink.c(523): set_hwparams (): /GstPlayBin:play/GstBin:abin/GstBin:audiosinkbin/GstGConfAudioSink:audio-sink/GstBin:bin4/GstAutoAudioSink:autoaudiosink1/GstAlsaSink:autoaudiosink1-actual-sink-alsa: Unable to set hw params for playback: Invalid argument aplay -l shows: List of PLAYBACK Hardware Devices card 0: pcsp [pcsp], device 0: pcspeaker [pcsp] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: I82801DBICH4 [Intel 82801DB-ICH4], device 0: Intel ICH [Intel 82801DB-ICH4] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: I82801DBICH4 [Intel 82801DB-ICH4], device 4: Intel ICH - IEC958 [Intel 82801DB-ICH4 - IEC958] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: Modem [Intel 82801DB-ICH4 Modem], device 0: Intel ICH - Modem [Intel 82801DB-ICH4 Modem - Modem] Subdevices: 1/1 Subdevice #0: subdevice #0 With a stock Linus kernel, totem works, and dmesg shows: [ 10.556026] intel8x0_measure_ac97_clock: measured 55331 usecs [ 10.556075] intel8x0: clocking to 48000 [ 10.556431] Intel ICH Modem :00:1f.6: PCI INT B - GSI 17 (level, low) - IRQ 17 [ 10.556507] Intel ICH Modem :00:1f.6: setting latency timer to 64 [ 10.660068] ALSA sound/pci/ac97/ac97_codec.c:2159: MC'97 1 converters and GPIO not ready (0xff00) aplay -l shows: List of PLAYBACK Hardware Devices card 0: I82801DBICH4 [Intel 82801DB-ICH4], device 0: Intel ICH [Intel 82801DB-ICH4] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: I82801DBICH4 [Intel 82801DB-ICH4], device 4: Intel ICH - IEC958 [Intel 82801DB-ICH4 - IEC958] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: Modem [Intel 82801DB-ICH4 Modem], device 0: Intel ICH - Modem [Intel 82801DB-ICH4 Modem - Modem] Subdevices: 1/1 Subdevice #0: subdevice #0 Note the lack of pcspeaker in the list of alsa devices; I suspect that the problem is related to alsa attempting to pipe audio through the pcspeaker hw device rather than the soundcard's normal device0. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504549: initramfs-tools: please add mtd/jffs2/ubifs modules to initrd when 'most' is selected
Package: initramfs-tools
Version: 0.92l
Severity: wishlist
OLPC laptops use jffs2 or ubifs for their root filesystem, along with
cafe_nand and mtd for the lower level devices. The following patch is
necessary for building a modular kernel on the XO. Please consider
including it!
From 8854095ef36c80a4178bc2ea93fe80415019bc34 Mon Sep 17 00:00:00 2001
From: Andres Salomon [EMAIL PROTECTED]
Date: Tue, 14 Oct 2008 14:19:12 -0400
Subject: [PATCH] include mtd, jffs2, and ubifs modules
This adds support for mtd/jffs/ubifs when 'most' is selected. Note
that this doesn't fix 'dep'.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
---
debian/changelog |7 +++
hook-functions |7 +++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 1d73a4a..de7f8f5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+initramfs-tools (0.92l.1) unstable; urgency=high
+
+ * NMU
+ * include mtd/jffs2/ubifs modules when 'most' is selected.
+
+ -- Andres Salomon [EMAIL PROTECTED] Tue, 14 Oct 2008 14:16:50 -0400
+
initramfs-tools (0.92l) unstable; urgency=high
* Revert initramfs-tools: Add support for linux-2.6 make deb-pkg
diff --git a/hook-functions b/hook-functions
index 53867da..1c9f303 100644
--- a/hook-functions
+++ b/hook-functions
@@ -347,6 +347,12 @@ auto_add_modules()
mmc)
copy_modules_dir kernel/drivers/mmc
;;
+ mtd)
+ copy_modules_dir kernel/drivers/mtd
+ for x in jffs2 ubifs; do
+ manual_add_modules ${x}
+ done
+ ;;
scsi)
copy_modules_dir kernel/drivers/scsi
for x in mptfc mptsas mptscsih mptspi zfcp; do
@@ -392,6 +398,7 @@ auto_add_modules()
auto_add_modules ieee1394
auto_add_modules firewire
auto_add_modules mmc
+ auto_add_modules mtd
;;
esac
}
--
1.5.6.5
Bug#504550: initramfs-tools:
Package: initramfs-tools Version: 0.92l Severity: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504551: initramfs-tools: please add support for upstream kernel's make deb-pkg
Package: initramfs-tools Version: 0.92l Severity: wishlist Hi, This was already included in an initramfs-tools release, but was the reverted (due to #499270). This patch should enable it with a workaround that allows the two postinst schemes to coexist without conflict. Please consider including it. From d86b9926cba57a91abb7096c5f467d41cbfb4ebc Mon Sep 17 00:00:00 2001 From: Andres Salomon [EMAIL PROTECTED] Date: Tue, 14 Oct 2008 15:02:17 -0400 Subject: [PATCH] add support for linux-2.6's deb-pkg ..via /etc/kernel Signed-off-by: Andres Salomon [EMAIL PROTECTED] --- debian/changelog |1 + debian/initramfs-tools.install|1 + debian/rules |2 +- kernel/postinst.d/initramfs-tools | 10 ++ kernel/postrm.d/initramfs-tools | 10 ++ 5 files changed, 23 insertions(+), 1 deletions(-) create mode 100755 kernel/postinst.d/initramfs-tools create mode 100755 kernel/postrm.d/initramfs-tools diff --git a/debian/changelog b/debian/changelog index de7f8f5..babb190 100644 --- a/debian/changelog +++ b/debian/changelog @@ -2,6 +2,7 @@ initramfs-tools (0.92l.1) unstable; urgency=high * NMU * include mtd/jffs2/ubifs modules when 'most' is selected. + * add support for linux-2.6's deb-pkg (via /etc/kernel). -- Andres Salomon [EMAIL PROTECTED] Tue, 14 Oct 2008 14:16:50 -0400 diff --git a/debian/initramfs-tools.install b/debian/initramfs-tools.install index fb1c088..71670ef 100644 --- a/debian/initramfs-tools.install +++ b/debian/initramfs-tools.install @@ -10,3 +10,4 @@ conf/modules usr/share/initramfs-tools update-initramfs usr/sbin debian/script usr/share/bug/initramfs-tools debian/lintian/initramfs-tools usr/share/lintian/overrides +kernel etc diff --git a/debian/rules b/debian/rules index 2a5ae55..1376aa9 100755 --- a/debian/rules +++ b/debian/rules @@ -5,6 +5,6 @@ include /usr/share/cdbs/1/rules/debhelper.mk pre-build:: chmod +x init mkinitramfs chmod +x hooks/* - for x in `find scripts/ -maxdepth 1 -type d | tail -n+2`; do \ + for x in `find scripts/ kernel/ -maxdepth 1 -type d | tail -n+2`; do \ chmod -R +x $$x; \ done diff --git a/kernel/postinst.d/initramfs-tools b/kernel/postinst.d/initramfs-tools new file mode 100755 index 000..423373c --- /dev/null +++ b/kernel/postinst.d/initramfs-tools @@ -0,0 +1,10 @@ +#!/bin/sh + +# passing the kernel version is required +[ -z $1 ] exit 0 + +# kernel-package passes an extra arg; hack to not run under kernel-package +[ -z $2 ] || exit 0 + +# we're good - create initramfs. update runs do_bootloader +update-initramfs -t -u -k $1 diff --git a/kernel/postrm.d/initramfs-tools b/kernel/postrm.d/initramfs-tools new file mode 100755 index 000..278a6fc --- /dev/null +++ b/kernel/postrm.d/initramfs-tools @@ -0,0 +1,10 @@ +#!/bin/sh + +# passing the kernel version is required +[ -z $1 ] exit 0 + +# kernel-package passes an extra arg; hack to not run under kernel-package +[ -z $2 ] || exit 0 + +# delete initramfs +update-initramfs -d -k $1 -- 1.5.6.5
Bug#504553: initramfs-tools: include framebuffer modules when 'most' is selected
Package: initramfs-tools
Version: 0.92l
Severity: wishlist
Hi,
There is currently support for modular framebuffers in initramfs-tools
(modules are loaded when the kernel is passed video=$mod), but those
framebuffer modules aren't normally included. Please consider the
following patch which includes framebuffer modules.
From c52b4d1346055c0c33c2474162585be7dde7c9dd Mon Sep 17 00:00:00 2001
From: Andres Salomon [EMAIL PROTECTED]
Date: Tue, 14 Oct 2008 15:31:24 -0400
Subject: [PATCH] include video (framebuffer, fbcon) modules
This adds support for video/fbcon when 'most' is selected.
Note that this doesn't fix 'dep'.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
---
debian/changelog |1 +
hook-functions |4
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index babb190..833dcfa 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,6 +3,7 @@ initramfs-tools (0.92l.1) unstable; urgency=high
* NMU
* include mtd/jffs2/ubifs modules when 'most' is selected.
* add support for linux-2.6's deb-pkg (via /etc/kernel).
+ * include video (framebuffer, fbcon) modules when 'most' is selected.
-- Andres Salomon [EMAIL PROTECTED] Tue, 14 Oct 2008 14:16:50 -0400
diff --git a/hook-functions b/hook-functions
index 1c9f303..7d0ad15 100644
--- a/hook-functions
+++ b/hook-functions
@@ -353,6 +353,9 @@ auto_add_modules()
manual_add_modules ${x}
done
;;
+ video)
+ copy_modules_dir kernel/drivers/video
+ ;;
scsi)
copy_modules_dir kernel/drivers/scsi
for x in mptfc mptsas mptscsih mptspi zfcp; do
@@ -399,6 +402,7 @@ auto_add_modules()
auto_add_modules firewire
auto_add_modules mmc
auto_add_modules mtd
+ auto_add_modules video
;;
esac
}
--
1.5.6.5
Bug#497133: initramfs-tools: explodes when kernel is booted
Hi,
Along with an earlier submitted patch to include the mtd and jffs modules
in the initrd image, the attached patch is needed for booting with root=mtd0.
Basically, the init scripts assume the root device should have a special
device file somewhere, and if not will wait for it to appear. This patch
changes it so that it only waits for a device file to appear if $ROOT starts
with /dev. In the case of things like ROOT=LABEL=foo, the init scripts
will translate that to a device. With ROOT=mtd0, the init scripts will not
check for a device, and will successfully mount the root filesystem.
From 586f67264971f0b8432aa99c13c9e16f009a729f Mon Sep 17 00:00:00 2001
From: Andres Salomon [EMAIL PROTECTED]
Date: Tue, 14 Oct 2008 18:04:09 -0400
Subject: [PATCH] allow root=mtd0 to be used
skip root checks if ROOT doesn't start with /dev.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
---
debian/changelog |2 ++
scripts/local| 14 --
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 833dcfa..4fdf762 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -4,6 +4,8 @@ initramfs-tools (0.92l.1) unstable; urgency=high
* include mtd/jffs2/ubifs modules when 'most' is selected.
* add support for linux-2.6's deb-pkg (via /etc/kernel).
* include video (framebuffer, fbcon) modules when 'most' is selected.
+ * allow root=mtd0 to be used; skip root checks if ROOT doesn't start
+with /dev.
-- Andres Salomon [EMAIL PROTECTED] Tue, 14 Oct 2008 14:16:50 -0400
diff --git a/scripts/local b/scripts/local
index 85d62af..b6bd192 100644
--- a/scripts/local
+++ b/scripts/local
@@ -24,8 +24,7 @@ get_fstype ()
return ${RET}
}
-# Parameter: Where to mount the filesystem
-mountroot ()
+pre_mountroot()
{
[ $quiet != y ] log_begin_msg Running /scripts/local-top
run_scripts /scripts/local-top
@@ -33,6 +32,12 @@ mountroot ()
wait_for_udev 10
+ # Don't wait for a root device that doesn't have a corresponding
+ # device in /dev (ie, mtd0)
+ if [ ${ROOT#/dev} = ${ROOT} ]; then
+ return
+ fi
+
# If the root device hasn't shown up yet, give it a little while
# to deal with removable devices
if [ ! -e ${ROOT} ] || ! $(get_fstype ${ROOT} /dev/null); then
@@ -94,6 +99,11 @@ mountroot ()
echo - Missing modules (cat /proc/modules; ls /dev)
panic ALERT! ${ROOT} does not exist. Dropping to a shell!
done
+}
+
+mountroot()
+{
+ pre_mountroot
# Get the root filesystem type if not set
if [ -z ${ROOTFSTYPE} ]; then
--
1.5.6.5
Bug#504555: initramfs-tools: fix reboot partition support
Package: initramfs-tools
Version: 0.92l
Severity: normal
Hi,
Redboot partitioning (used by mtd devices) provides devices with names like
mtd:foo. Unfortunately, when booting with root=mtd:foo, the *:* check in
parse_numeric is matched and things break (the code expects major:minor
numbers). This patch fixes that by explicitly checking for something that
starts with a number.From 7651875d24f8e35bf4b601beef7b7a4e8b92ad9d Mon Sep 17 00:00:00 2001
From: Andres Salomon [EMAIL PROTECTED]
Date: Fri, 17 Oct 2008 17:56:22 -0400
Subject: [PATCH] fix redboot partition support
Fix buglet in parse_numeric where *:* would match mtd:root. We only
want to match numbers. This fixes redboot partition support.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
---
debian/changelog |2 ++
scripts/functions |2 +-
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 4fdf762..20af58e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -6,6 +6,8 @@ initramfs-tools (0.92l.1) unstable; urgency=high
* include video (framebuffer, fbcon) modules when 'most' is selected.
* allow root=mtd0 to be used; skip root checks if ROOT doesn't start
with /dev.
+ * Fix buglet in parse_numeric where *:* would match mtd:root. We only
+want to match numbers. This fixes redboot partition support.
-- Andres Salomon [EMAIL PROTECTED] Tue, 14 Oct 2008 14:16:50 -0400
diff --git a/scripts/functions b/scripts/functions
index 299c29c..ba6b2fc 100644
--- a/scripts/functions
+++ b/scripts/functions
@@ -238,7 +238,7 @@ parse_numeric() {
/*)
return
;;
- *:*)
+ [0-9]*:[0-9]*)
minor=${1#*:}
major=${1%:*}
;;
--
1.5.6.5
Bug#499270: initramfs-tools: postrm.d/update-initramfs breaks removal of old kernel
Hi, We can possibly distinguish between /etc/kernel/postinst.d getting called from kernel-package context, and upstream debpkg context. debpkg calls with the following: test -d /etc/kernel/postinst.d run-parts --arg=$version /etc/kernel/postinst.d kernel-package's uses: system (run-parts --verbose --exit-on-error --arg=$version . --arg=$realimageloc$kimage-$version . /etc/kernel/postinst.d) Note that kernel-package's passes two arguments. In theory, we could have an /etc/kernel/postinst.d/update-initramfs (or /etc/kernel/postinst.d/initramfs-tools, if we want to match the package name) that does: # passing the kernel version is required [ -z $1 ] exit 0 # kernel-package passes an extra arg; hack to not run under kernel-package [ -z $2 ] || exit 0 # we're good - create initramfs. update runs do_bootloader update-initramfs -t -u -k $1 Thoughts? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497133: initramfs-tools: explodes when kernel is booted with root=mtd0
On Mon, 1 Sep 2008 15:58:15 +0200
maximilian attems [EMAIL PROTECTED] wrote:
On Sat, 30 Aug 2008, Andres Salomon wrote:
Package: initramfs-tools
Version: 0.92f
On OLPC machines, root is a nand device that is mounted as mtd0 (it
is neither a block device nor a char device). The arguments passed
to the kernel are ro root=mtd0 rootfstype=jffs2.
could you try to give the full device string root=/dev/mtd0
Already tried that, it simply fails to find root then. I also tried
root=/dev/mtdblock0, but that's not a real solution (mtd block emulation
is slower than just mtd).
Unfortunately, attempting to use an initrd based upon
initramfs-tools on such a machine results in a kernel panic and a
syntax error.
Begin: Mounting root file system ... /init: line 172: syntax error:
0xmtd0
The probably appears to be in parse_numeric(); the init scripts
assume that normal devices are always prefixed with /, and root=
strings that aren't are raw device numbers (prefixing them with
0x). I'm not sure if there are other devices similar to mtd that
don't begin with a /.
parse_numeric is for legacy lilo support, right. does aboves
circumvent it?
thanks for report!
How about something like the following (untested) patch? It's not foolproof,
but it at least ignores things that can't possibly be hex strings.
--- /usr//share/initramfs-tools/scripts/functions.orig 2008-09-01
11:14:11.0 -0400
+++ /usr//share/initramfs-tools/scripts/functions 2008-09-01
11:18:57.0 -0400
@@ -242,11 +242,14 @@ parse_numeric() {
minor=${1#*:}
major=${1%:*}
;;
- *)
+ [A-Fa-f0-9]*)
value=$(( 0x${1} ))
minor=$(( ${value} % 256 ))
major=$(( ${value} / 256 ))
;;
+ *)
+ return
+ ;;
esac
mknod -m 600 /dev/root b ${major} ${minor}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497133: initramfs-tools: explodes when kernel is booted with root=mtd0
On Mon, 1 Sep 2008 17:37:28 +0200
maximilian attems [EMAIL PROTECTED] wrote:
On Mon, Sep 01, 2008 at 11:22:34AM -0400, Andres Salomon wrote:
[...]
--- /usr//share/initramfs-tools/scripts/functions.orig
2008-09-01 11:14:11.0 -0400
+++ /usr//share/initramfs-tools/scripts/functions 2008-09-01
11:18:57.0 -0400 @@ -242,11 +242,14 @@ parse_numeric() {
what i'd be interested is the failure that happens with this patch
applied, there is no way $ROOT aka mtd0 will be found?!
Correct, but at least it drops me into a shell (rather than giving me a
syntax error and panicking :)
I'm still trying to figure out how to deal w/ root=mtd0 (and wondering
whether it's even worth dealing with, or if I can do something
clever with UBI or flash partitioning)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497133: initramfs-tools: explodes when kernel is booted with root=mtd0
Package: initramfs-tools Version: 0.92f On OLPC machines, root is a nand device that is mounted as mtd0 (it is neither a block device nor a char device). The arguments passed to the kernel are ro root=mtd0 rootfstype=jffs2. Unfortunately, attempting to use an initrd based upon initramfs-tools on such a machine results in a kernel panic and a syntax error. Begin: Mounting root file system ... /init: line 172: syntax error: 0xmtd0 The probably appears to be in parse_numeric(); the init scripts assume that normal devices are always prefixed with /, and root= strings that aren't are raw device numbers (prefixing them with 0x). I'm not sure if there are other devices similar to mtd that don't begin with a /. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny (was: 2.6.25-2 testing sync)
On Tue, 8 Jul 2008 09:15:14 +0200 maximilian attems [EMAIL PROTECTED] wrote: On Mon, Jul 07, 2008 at 10:09:43PM +0200, Frans Pop wrote: [...] I'm having serious trouble parsing what you're trying to say here. Could you rephrase? you never checked the rh kernel. they do a *lot* of backporting and have a big team working on that. so you'll notice that none of those patches landed in ours. so your argument sounds nice, but doesn't help in practise. .26 got a *lot* upstream attention and solves a number of .25 regressions. it is wanted for read-only bind mounts, kernel debugger, kvm + xen + wireless improvements, allmost net namespaces and uvc cam support. Not to mention OLPC support; it would be *really* nice to be able to use d-i to install Debian onto an XO. Of course, other things (grub-under-OFW or just plain OFW support, jffs2 formatting support, etc) would need to be in place as well for it to work. I haven't kept up on the status of those things, but I know that people have been working on them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485192: SDHCI hacks used on OLPC
On Thu, 26 Jun 2008 09:51:52 +0200 Robert Millan [EMAIL PROTECTED] wrote: Hi! These are the patches Andres made sent upstream: http://www.gossamer-threads.com/lists/linux/kernel/936294 http://www.gossamer-threads.com/lists/linux/kernel/937056 If they don't make it to 2.6.26, I'd suggest having them applied in the package (unless Andres has any objections, of course). I just heard back from Pierre; it sounds like those patches will be different from what goes upstream, but they're fine (for Debian's purposes) for 2.6.26. The ones that go upstream need to be reworked for changes that are in Pierre's -next tree. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485192: SDHCI hacks used on OLPC
On Mon, 09 Jun 2008 01:28:10 + Robert Millan [EMAIL PROTECTED] wrote: Package: linux-2.6 Version: 2.6.26~rc4-1~experimental.1 Severity: normal This diff was extracted from OLPC branch. Without it, MMC cards are not detected. I'm not setting the patch tag since the last hunks look like a kludge (specially the off-by-one thing). Putting Andres Salomon on CC, as he probably knows about the reasons this was added. These are hardware workarounds; I would highly suggest waiting for this stuff to go upstream first.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400752: linux-modules-extra-2.6: include ndiswrapper
Daniel Baumann wrote: Sam Morris wrote: Andreas is MIA? Or do I misunderstand? Andres didn't say something about inclusion so far, only Kel. And Kel has a bouncing email address. Sorry, that's my fault; he has updated packages for me to sponsor, but I just haven't had time. Anyways, try [EMAIL PROTECTED]. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400752: linux-modules-extra-2.6: include ndiswrapper
Sam Morris wrote: On Mon, 2007-02-12 at 12:45 -0500, Andres Salomon wrote: Daniel Baumann wrote: Sam Morris wrote: Andreas is MIA? Or do I misunderstand? Andres didn't say something about inclusion so far, only Kel. And Kel has a bouncing email address. Sorry, that's my fault; he has updated packages for me to sponsor, but I just haven't had time. Anyways, try [EMAIL PROTECTED]. Ah, now I understand. May I suggest you make this relationship more explicit in the package metadata, with something like: Maintainer: Kel Modderman [EMAIL PROTECTED] Uploaders: Andres Salomon [EMAIL PROTECTED] Well, it was the other way because I was originally maintaining it. At some point, I will be removed altogether; I no longer use ndiswrapper. However, I need to talk to kel about going through NM or finding a new sponsor. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362064: udev: udev tries to write to an installed, working initrd without asking
Hi, Here's a use case where having initramfs-tools unconditionally update initramfs images is a bad thing (at the very least, violating the principal of least surprise). I had a machine that was had a poorly supported sata_mv chipset; dapper nor sarge w/ 2.6.15/2.6.16 images would install onto it. I had to make a custom cd w/ backported libata and sata_mv drivers. Needless to say, it was a pain in the ass to get installed. After installation, I backported etch versions of busybox and initramfs-tools (uploading the latter to backports.org) in order to do some testing to see if I could get some installation and boot bugs fixed. I installed both backports, then I backed up the existing initramfs image and created a new image. The intent was to pull new busybox binaries into the new initramfs, and keep the old initramfs around in order to recover the system. I did not realize that during the package's postinst, existing images would be updated; so, the backup initramfs image that I had copied also had the new version of busybox in it. As it turns out, the busybox backport was broken (not sure if it was the build, or some interaction w/ the rest of the system). Booting using either image would not work, and I had no way to recover the system (due to bugs in my custom installer cd, recovery didn't seem to work). I ended up having to reinstall the system using the custom installer cd. I was not pleased. I expect that if I have a working initramfs image in /boot, it should remain untouched until I explicitly give permission for it to be touched. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
additional mailing list request
Hi, I've made a new request for an additional kernel discussion list: http://bugs.debian.org/358625 Part of the process involves other interested people following up to the bug. So, can people who would like to see the additional list please follow up to [EMAIL PROTECTED] and express their interest? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
removal of svenl from the kernel team
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I would like to remove Sven Luther from the kernel team (that is, remove his svn commit privileges, as well as remove him from the Uploaders field of kernel packages), and remove him from the debian-kernel (and debian-kernel-devel, when it is created) mailing lists. I have no desire to work w/ him any further in the context of kernel packaging. I shouldn't need to explain to you why he is destructive to the kernel team; you've all worked w/ him. Since we don't have a clear-cut leader, I'm going to put it to a vote. This vote is open to all current members of the kernel team; that is, everyone listed http://alioth.debian.org/project/memberlist.php?group_id=30428 (I count 28 people). If you agree that Sven should be removed, please respond to this mail with Yes. If you do not believe that Sven should be removed, please respond with No. Developers, please sign your mails with your GPG key. I have set the reply-to of this email to go to myself and [EMAIL PROTECTED]; we will tally results. This is a simple majority vote; if (for example) 19 people respond, and 10 of those are votes to remove Sven, I will remove him from the alioth project, and request that the listmasters ban him from the kernel mailing list(s). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEIw9UOmXwGc/ULyYRAibxAJ0aD/BFzuAePAzAazlwtZzS9vu1VQCaAho4 ldoLZ/FBj5oRzapOBQ586/s= =NmJg -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removal of svenl from the kernel team
Alright Sven, this is the last time I'm ever going to respond to you. I've wasted enough time on this. Sven Luther wrote: On Thu, Mar 23, 2006 at 04:23:11PM -0500, Andres Salomon wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I would like to remove Sven Luther from the kernel team (that is, remove his svn commit privileges, as well as remove him from the Uploaders field of kernel packages), and remove him from the debian-kernel (and debian-kernel-devel, when it is created) mailing lists. I have no desire to work w/ him any further in the context of kernel packaging. Andres, i would really like to know why you hate me so much. I have restrained from participating here, and if i posted today, it was only with technical content and none of the stuff you complained about in the first time. I don't hate you. I think you're destructive to the project as a whole, and specifically to the kernel team. People have stopped working on the kernel team because of you. I have watched you be very aggressive with users who asked simple questions. I have watched you argue and personally insult members of the kernel team, as well as developers outside of the kernel team. I have watched people get absolutely frustrated with you while attempting to reason with you, as you repeat the same arguments over and over. Etc. Quite simply, I don't want to represent a team that treats people the way you treat people. I don't want to have to mediate discussions between you and whoever you've managed to piss off this week. I don't want to have to apologize for you, and I don't want to have to lecture you and ask you to apologize to someone else. I didn't join the kernel team (and debian) to do that sort of thing; I did it to actually get work done. Furthermore, i believe that the actions you have done against me, have hurt the project more than anything i could have said or done on the lists, and the way you act against me is anathema to anything debian stands for. I hope that you will find the dignity to realize what you are doing, and present your apologize, not because of your first actions, which may have been understandable to a point, but because you are clearly doign exactly the same thing i was accused of, and furthemore doing it in full knowledge that it will hurt me personally, and this is worse than anything i have ever done. Are you kidding? Actually, don't answer that; I don't need the additional clutter in my inbox. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Modules packaging policy - call for discussion
Jurij Smakov wrote: Hi, It is pretty obvious (to me, at least) that the need for the official packaging policy for the out-of-tree kernel modules is long overdue. As mentioned on the wiki page dedicated to it [0], the current situation is a mess. I would like to call for a formal discussion, which will eventually lead to the formulation of such policy. As a first step I propose to just throw the ideas around and figure out what we want the module infra- stracture to be capable of. Then, we can discuss technical aspects of it, and prepare a draft policy. Below are the things I would like to see implemented in module building infrastructure. Note that I do not maintain any module packages myself, so my opinions and proposals might be naive in some aspects, so feel free to correct. * Unified way to build the modules. I think module-assistant is the sanest way to implement it in a reasonable time frame. Agreed. M-a has documentation that describes how to package your third party module. We should also make it policy that module source packages should simply create modname-source; it should have no binary modules created. Other stuff should take care of that. That other stuff is what I'm interested in, at this point; waldi claims to be working on stuff[0]. Waldi, can you please expand upon that? It would be nice to automate binary module package creation when a new kernel is released. The last I heard, this was planned by making the buildds automatically rebuild packages. If that is the case, who will be handling the source packages for those binary module packages? * Robustness. Packaged kernel modules *must* build against official kernel headers packages. I am aware of at least one module (lirc), which requires additional header files which we currently do not ship in linux-headers. That's probably broken since such modules are not using the publicly exported kernel API, so it's probably fair to require that they either get fixed or include necessary files in the module source package. Our policy on this has always been that they should simply include the necessary files in the module source package. [0] http://lists.debian.org/debian-devel/2006/03/msg00801.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removal of svenl from the project
On Wed, 2006-03-15 at 11:25 +0100, Pierre Habouzit wrote: Le Mer 15 Mars 2006 03:01, Andres Salomon a écrit : Hi, I am going through the expulsion process to have Sven Luther removed from the project. The process is outlined here: http://lists.debian.org/debian-devel-announce/2005/08/msg5.html , and I have already completed step 1. I strongly oppose to such an expulsion. It amazes me that people oppose expulsion, but are perfectly happy to allow the DAMs to decide whether or not a NM is to be let into the project. Why do we trust the DAM's judgement in one scenario but not the other? what is wrong with you ? are you gone completely insane or what ? I'm tired of discussions immediately degrading into personal insults. I know Sven may sometimes be a bit overpresent in some trolls, he also may answer too quick, without having read the mail he answers to correctly enough. But AFAICT, I've always seen him apologies when he did so (I can provide links if you can't believe me…). That is not the case. Furthermore, apologizing repeatedly does not make his behavior right. If you want to expulse any DD that taunts a release manager, a ftp-master or a debian sys-admin, hey, please begin with the recent thread about the NEW queue beeing stuck again. There is a lot of DDs that need you to rule about them. This is not about taunting a release manager, an ftp master, or a DAM. This is about repeated aggressive, childish behavior, against a number of people. Sven seems to anger almost everyone he works closely with. The examples I provided are just the tip of the iceberg. I thought I explained this in my followup email[0]. [0] http://lists.debian.org/debian-devel/2006/03/msg00621.html signature.asc Description: This is a digitally signed message part
Re: removal of svenl from the project
The DAM has accepted the request; please send seconds directly to [EMAIL PROTECTED], cc'ing me as well. For the people who seem to think that there are more constructive ways of dealing w/ this issue rather than the expulsion process: http://squishy.cc/svenl.txt This is a lot from two weeks ago, right after Sven threatened Jonas. If he had actually changed his behavior sometime in the past two years, rather than just viewing every discussion as a battle that must be won at all costs, I would not be making this request. signature.asc Description: This is a digitally signed message part
removal of svenl from the project
Hi,
I am going through the expulsion process to have Sven Luther removed
from the project. The process is outlined here:
http://lists.debian.org/debian-devel-announce/2005/08/msg5.html,
and I have already completed step 1.
Step #2 requires the support of some 15 developers. I am attempting to
find people that are interested in publically seconding my explusion
request. If you are interested, please email me. Remember that your
request will be public, and you will have to provide reasons why you
feel that his removal will benefit the project. I'm looking both for
people who have had conflicts w/ him (logs are always good, too), as
well as people who have just seen the effects of his actions (ie,
unbiased opinions).
Sven has always been a nuisance to deal w/, but up until now I have not
considered this action. In the past two weeks, the following comments
made by him have changed my mind:
2006-03-07:
svenl jonas: i hope we never again meet in public, because i promise i
will hit you if i do.
2006-03-14:
svenl vorlon: so, you think it is correct of jonas to mention
traveller and thanking him for investigating the issue, while fully
ignoring my own contribution ?
-- vorlon ([EMAIL PROTECTED]) has left
#debian-kernel
svenl yeah, coward.
Sven's behavior has always been combative (and some might argue
hostile), but this is beyond what is acceptable. He threatens bodily
harm upon another developer in a public forum, and then a week later
publically insults/taunts a developer (one of the Release Managers,
even), behind his back. This is incredibly childish, aggressive
behavior, and should not be tolerated within the project (IMO).
Some might argue that we should just kick him from the channel and
remove his commit access to the debian-kernel project, but that does not
solve the problem of him abusing other teams, as well as his abusive
mailing list posts. He also {co-,}maintains some 47 packages, which
means users for those packages will have to deal w/ him as well. I
believe it is better if he is removed from the project altogether, as he
damages it more than he helps.
So, if you are interested in seconding the expulsion request, please let
me know. Please do not turn this into a flamewar; I don't care about
your reasons why people should not be forcefully removed from the
project. Those who feel this way probably have not had to work w/ Sven
on a team for the past 2 years.
signature.asc
Description: This is a digitally signed message part
Re: removal of svenl from the project
On Tue, 2006-03-14 at 21:01 -0500, Andres Salomon wrote: [...] Sven has always been a nuisance to deal w/, but up until now I have not considered this action. In the past two weeks, the following comments made by him have changed my mind: 2006-03-07: svenl jonas: i hope we never again meet in public, because i promise i will hit you if i do. 2006-03-14: svenl vorlon: so, you think it is correct of jonas to mention traveller and thanking him for investigating the issue, while fully ignoring my own contribution ? -- vorlon ([EMAIL PROTECTED]) has left #debian-kernel svenl yeah, coward. A few clarifications/comments based upon what people have said: 1) These quotes are examples of his destructive behavior. One can find plenty more in the mailing lists. The ones I supplied here are the ones that made *me* decide to take action. 2) Yes, I have tried talking to him. After a number of blowups on the debian-kernel list, myself and a number of kernel team members have talked to him to calm him down (and in some cases getting him to apologize). The behavior he displays happens repeatedly, despite warnings and requests that he behave himself. The rest of the IRC log from when he threatened Jonas is basically me attempting to show Sven how destructive his behavior is. The fact that, a week later, he continues w/ this behavior (after years of doing the same thing) is why you're seeing this request. 3) If he was in the NM queue, and you were his AM, would you accept him after seeing how he behaves? If not, why is that so different from kicking him out of the project (other than asking that he be banned from the lists, but this is a request of the list masters, not the DAM)? In that regards, I have a wonderful quote from Sven: I am not in the AM queue, so i can be as rude as i want. [0] I presume he meant the NM queue. [0] http://lists.debian.org/debian-legal/2004/07/msg00967.html signature.asc Description: This is a digitally signed message part
volatile backport
I'm working on a backport of linux-2.6 for volatile; the goal is to not have it require any further backports. My current patch is attached; I need to figure out what was actually added to kernel-package wrt mkvmlinuz that powerpc might need. Is there any other arch-specific stuff that I might be missing, also? I still need to test it out against the udev that's in sarge. (I'll use 2.6.12-9 or whatever actually builds on all archs, once it proves itself against the buildds.) --- linux-2.6-2.6.12.orig/debian/changelog 2005-09-26 00:58:35.0 -0400 +++ linux-2.6-2.6.12/debian/changelog 2005-09-26 00:49:36.0 -0400 @@ -1,3 +1,13 @@ +linux-2.6 (2.6.12-5volatile1) sarge-volatile; urgency=high + + * Backport/rebuild for volatile. + * Drop make-kpkg defconfig usage; use oldconfig instead, w/ a random +.config from the arch/subarch directory. + * Lower kernel-package versioned build-dep. + * Drop gcc-4.0 build dep. + + -- Andres Salomon [EMAIL PROTECTED] Mon, 26 Sep 2005 00:22:34 -0400 + linux-2.6 (2.6.12-6) unstable; urgency=high [ Andres Salomon, Bastian Blank ] --- linux-2.6-2.6.12.orig/debian/templates/control.source.in2005-09-26 00:58:35.0 -0400 +++ linux-2.6-2.6.12/debian/templates/control.source.in 2005-09-26 00:49:10.0 -0400 @@ -4,5 +4,5 @@ Maintainer: Debian Kernel Team debian-kernel@lists.debian.org Uploaders: Andres Salomon [EMAIL PROTECTED], Bastian Blank [EMAIL PROTECTED] Standards-Version: 3.6.1.0 -Build-Depends: gcc (= 4:4.0) [!arm !sparc !alpha !m68k], gcc-3.3 [arm sparc alpha m68k], binutils-hppa64 [hppa], gcc-4.0-hppa64 [hppa], debhelper (= 4.1.0), module-init-tools, dpkg-dev (= 1.10.23), debianutils (= 1.6), bzip2, console-tools [!s390], sparc-utils [sparc], kernel-package (= 9.005) +Build-Depends: binutils-hppa64 [hppa], gcc-4.0-hppa64 [hppa], debhelper (= 4.1.0), module-init-tools, dpkg-dev (= 1.10.23), debianutils (= 1.6), bzip2, console-tools [!s390], sparc-utils [sparc], kernel-package (= 8.135) Build-Depends-Indep: docbook-utils, gs, transfig, xmlto, dh-kpatches (= 0.99.3) --- linux-2.6-2.6.12.orig/debian/control2005-09-26 00:58:35.0 -0400 +++ linux-2.6-2.6.12/debian/control 2005-09-26 00:49:43.0 -0400 @@ -4,7 +4,7 @@ Maintainer: Debian Kernel Team debian-kernel@lists.debian.org Uploaders: Andres Salomon [EMAIL PROTECTED], Bastian Blank [EMAIL PROTECTED] Standards-Version: 3.6.1.0 -Build-Depends: gcc (= 4:4.0) [!arm !sparc !alpha !m68k], gcc-3.3 [arm sparc alpha m68k], binutils-hppa64 [hppa], gcc-4.0-hppa64 [hppa], debhelper (= 4.1.0), module-init-tools, dpkg-dev (= 1.10.23), debianutils (= 1.6), bzip2, console-tools [!s390], sparc-utils [sparc], kernel-package (= 9.005) +Build-Depends: binutils-hppa64 [hppa], gcc-4.0-hppa64 [hppa], debhelper (= 4.1.0), module-init-tools, dpkg-dev (= 1.10.23), debianutils (= 1.6), bzip2, console-tools [!s390], sparc-utils [sparc], kernel-package (= 8.135) Build-Depends-Indep: docbook-utils, gs, transfig, xmlto, dh-kpatches (= 0.99.3) Package: linux-source-2.6.12 @@ -60,8 +60,8 @@ Architecture: all Section: devel Priority: optional -Depends: linux-patch-debian-2.6.12 (= 2.6.12-6), linux-source-2.6.12 (= 2.6.12-1) | linux-source-2.6.12 (= 2.6.12-2) | linux-source-2.6.12 (= 2.6.12-3) | linux-source-2.6.12 (= 2.6.12-4) | linux-source-2.6.12 (= 2.6.12-5) | linux-source-2.6.12 (= 2.6.12-6) -Provides: linux-tree-2.6.12-1, linux-tree-2.6.12-2, linux-tree-2.6.12-3, linux-tree-2.6.12-4, linux-tree-2.6.12-5, linux-tree-2.6.12-6 +Depends: linux-patch-debian-2.6.12 (= 2.6.12-5volatile1), linux-source-2.6.12 (= 2.6.12-1) | linux-source-2.6.12 (= 2.6.12-2) | linux-source-2.6.12 (= 2.6.12-3) | linux-source-2.6.12 (= 2.6.12-4) | linux-source-2.6.12 (= 2.6.12-5) | linux-source-2.6.12 (= 2.6.12-6) | linux-source-2.6.12 (= 2.6.12-5volatile1) +Provides: linux-tree-2.6.12-1, linux-tree-2.6.12-2, linux-tree-2.6.12-3, linux-tree-2.6.12-4, linux-tree-2.6.12-5, linux-tree-2.6.12-6, linux-tree-2.6.12-5volatile1 Description: Linux kernel source tree for building Debian kernel images This meta package is used as a build dependency of Debian linux-image packages to prevent a version discrepancy between the linux-image and --- linux-2.6-2.6.12.orig/debian/rules.real 2005-09-26 00:58:35.0 -0400 +++ linux-2.6-2.6.12/debian/rules.real 2005-09-26 00:47:47.0 -0400 @@ -43,7 +43,7 @@ kpkg_header += make-kpkg --append-to-version $(append)-$(ABINAME) kpkg_header += --arch $(ARCH) kpkg_header += --stem linux -kpkg_header += --config defconfig +kpkg_header += --config oldconfig kpkg_image := make-kpkg --append-to-version -$(ABINAME)-$(FLAVOUR) kpkg_image += --arch $(ARCH) kpkg_image += --stem linux @@ -196,6 +196,13 @@ $(STAMPS_DIR)/setup-$(ARCH)-$(SUBARCH): $(STAMPS_DIR)/source-$(ARCH)-$(SUBARCH) rm -rf $(DIR) cp -al $(SOURCE_DIR) $(DIR) + rm -f $(DIR)/.config + for i in $(ccommon); do \ + if [ -f
Re: standardizing on a language
Ok, looks like people seem to want python more; I'll start rewriting my tools to be in python, and working on the common lib stuff. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: standardizing on a language
On Thu, Sep 08, 2005 at 01:23:30AM -0400, Andres Salomon wrote: [...] Preferences? Once we have a common language, we can have a common library as well (ages ago, I wrote half a Kconfig parser in racc; that seems like it'd be useful for all kinds of scripts, but I'm not going to spend any more time on it until we decide whether I should continue in racc, or use something python-y). I'm rather disappointed by the lack of responses to this. I don't intend to do any more infrastructure work on the kernel packages until we pick something; I don't particularly feel like having the things I write rewritten multiple times, nor do I want to bother rewriting other people's stuff. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: standardizing on a language
On Tue, Sep 20, 2005 at 06:52:23AM -0400, Andres Salomon wrote: On Thu, Sep 08, 2005 at 01:23:30AM -0400, Andres Salomon wrote: [...] I'm rather disappointed by the lack of responses to this. I don't intend to do any more infrastructure work on the kernel packages until we pick something; I don't particularly feel like having the things I write rewritten multiple times, nor do I want to bother rewriting other people's stuff. Hm, for some reason muttng [1] doesn't show waldi's response. Anyways, to follow up: I'm comfortable with either ruby or python; I suppose it depends on what others are more comfortable with. I don't know anything about ruby. Well, others are going to have to learn as well. As I said, I don't care which is chosen, but I'd like to get others input as well. The only person I'm aware of on the kernel team that already knows ruby is joshk; I know you and Jurij know python already. I want to hear what other people prefer as well, but I haven't heard many responses. If it turns out that no one else knows ruby or python (or has a preference of what they want to learn), I'll pick python.. Once we have a common language, we can have a common library as well linux-2.6/debian/lib/python already exists. Right, which is fairly new, and assumes everyone knows python. (ages ago, I wrote half a Kconfig parser in racc; I have a fullblown parser which is derived from the original yacc and flex files written in python. Is it functional? I remember seeing you working on it on IRC, but were having problems; does this mean you finished it? [1] why must all nntp readers (and mail clients) suck? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: standardizing on a language
On Tue, Sep 20, 2005 at 03:47:34PM +0200, Bastian Blank wrote: On Tue, Sep 20, 2005 at 07:53:18AM -0400, Andres Salomon wrote: On Tue, Sep 20, 2005 at 06:52:23AM -0400, Andres Salomon wrote: I don't know anything about ruby. Well, others are going to have to learn as well. As I said, I don't care which is chosen, but I'd like to get others input as well. One of my problem with this language is, that most of the code I ever read described it as another WORN language like perl and I'm completely incompatible with such languages. I'm not convinced you actually understand Ruby; it's far from a WORN language. If it wasn't, I wouldn't be suggesting it alongside python, while at the same time saying that perl is a bad idea. (ages ago, I wrote half a Kconfig parser in racc; I have a fullblown parser which is derived from the original yacc and flex files written in python. Is it functional? I remember seeing you working on it on IRC, but were having problems; does this mean you finished it? The parser works fine. The parse-tree needs some postprocessing. Where is it? I haven't seen it in svn. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: modules
On Mon, 2005-09-19 at 19:24 +0200, Sven Luther wrote: On Mon, Sep 19, 2005 at 01:25:31PM -0400, Andres Salomon wrote: [...] Alright, I think I'm a fan of #2. The module maintainers upload their packages to sid, with the binary package module-source in there. We have a package called linux-external-modules that build-deps on all the -source packages, and builds packages based upon them. The infrastructure would be similar to the linux-2.6 package; gencontrol.py creates a huge control file that lists each module (perhaps getting this list from the build-dep list). This would look something like Problem with this would be that any -source breaking might mean breaking it all. That's why we test! ;) Anyways, it wouldn't break all, it would break all for a single architecture. But yes, we would have to be pretty dynamic with what we actually provide in terms of the modules, and apply pressure to -source maintainers to fix FTBFS issues. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: modules
On Mon, 2005-09-19 at 19:36 +0200, Sven Luther wrote: On Mon, Sep 19, 2005 at 01:34:22PM -0400, Andres Salomon wrote: On Mon, 2005-09-19 at 19:24 +0200, Sven Luther wrote: On Mon, Sep 19, 2005 at 01:25:31PM -0400, Andres Salomon wrote: [...] Alright, I think I'm a fan of #2. The module maintainers upload their packages to sid, with the binary package module-source in there. We have a package called linux-external-modules that build-deps on all the -source packages, and builds packages based upon them. The infrastructure would be similar to the linux-2.6 package; gencontrol.py creates a huge control file that lists each module (perhaps getting this list from the build-dep list). This would look something like Problem with this would be that any -source breaking might mean breaking it all. That's why we test! ;) Anyways, it wouldn't break all, it would break all for a single architecture. But yes, we would have to be pretty dynamic with what we actually provide in terms of the modules, and apply pressure to -source maintainers to fix FTBFS issues. What if the maintainers of those modules are MIA or otherwise unresponsive ? I would go for that only for out-of-tree modules that are hosted on either our kernel svn repo, or on a new kernel-modules svn repo (if we are afraid of giving commit rights to everyone). We'd drop the build-dep on the broken modules. #3 in dannf's list also seemed like a good idea, but we just need to get infrastructure in place for that; is anyone working on it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Secure-testing-team] kernel update
On Thu, 2005-09-15 at 11:03 +0200, Moritz Muehlenhoff wrote: Joey Hess wrote: Now that 2.6.12 is finally in testing and work is well underway to remove 2.6.8, I think we can switch to tracking security holes in the new kernel now. There are several items listed as unfixed in 2.6.8, would it be possible for someone to double check if any of these also still apply to 2.6.12? For many of these the fix is confirmed to be in mainline, but for a few I could only find references to advisories from Red Hat and SuSE, so we should double-check this. # kernel-image-2.6.8-i386 (unfixed; bug #309308) for CAN-2005-2548 Fixed in linux-2.6 Specifically, in 2.6.9-rc2. # kernel-source-2.6.8 (unfixed; bug #295949) for CAN-2005-0449 This one is the infamous ABI breaking kernel vulnerability. Probably fixed in mainline? Yep; fixed in 2.6.11, I believe. It's definitely in 2.6.12 (look for ip_defrag_users in net/ip.h; that's the enum that defines the local queue types). # kernel-source-2.6.8 (unfixed; bug #322339) for CAN-2004-2302 Fixed in linux-2.6 2.6.10, according to the bug report. Verified that it's in 2.6.12. # kernel-source-2.6.8 2.6.8-16sarge1 needed, have 2.6.8-16 for CAN-2005-1765, Fixed in linux-2.6 No longer relevant; the entire chunk of code was ripped out with http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1e01441051dda3bb01c455b6e20bce6d00563d82 CAN-2005-1763, Double-check. Couldn't find a reference yet that it's fixed in mainline. Indeed, it is: http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f6b8d4778c04148729cc0b0dcd335a4411c44276 CAN-2005-1762, Fixed in linux-2.6. It's in 2.6.12: http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d1099e8a18960693c04507bdd7b9403db70bfd97 CAN-2005-1761, Fixed in linux-2.6. How can you tell? The mitre description is absolutely useless. I fucking hate this stupid vendor-sec/mitre non-disclosure policy, it makes actually attempting to cross reference stuff so much harder than it needs to be. I don't see mention of it in Ubuntu's changelog, but Martin Pitt tells me the following: pitti CAN-2005-1767 pitti x86_64: Disable exception stack for stack faults pitti http://kernel.org/git/?p=linux/kernel/git/marcelo/linux-2.4.git;a=commitdiff;h=51e31546a2fc46cb978da2ee0330a6a68f07541e pitti sufficient patch: pitti - set_intr_gate_ist(12,stack_segment,STACKFAULT_STACK); pitti + set_intr_gate(12,stack_segment); pitti patch is for 2.4, but 2.6 also seems to be affected I suspect this is fixed in http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0a65800243742480b4b594b619b759749a3cfef4 If that is indeed the case, then it is fixed in 2.6.12. CAN-2005-0757, Double-check. Couldn't find a reference yet that it's fixed in mainline. Oh good, another useless CAN entry. That turns out to be: http://svn.debian.org/wsvn/kernel/releases/kernel-2.4/source/kernel-source-2.4.27-2.4.27/2.4.27-11/debian/patches/168_fs_ext3_64bit_offset.diff?op=filerev=0sc=0 The equivalent lines of code start at line 730 in xattr.c in 2.6. I'll check this one out later. CAN-2005-0756 Double-check. Couldn't find a reference yet that it's fixed in mainline. http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c4d1fcf3a2ea89b6d6221fa8b4588c77aff50995 # kernel-source-2.6.8 2.6.8-16sarge2 needed, have 2.6.8-16 for CAN-2005-2555 Fixed in linux-2.6. Fixed in debian/patches-debian/2.6.12.6.patch, specifically. # kernel-source-2.6.8 2.6.8-17 needed, have 2.6.8-16 for CAN-2005-1765, CAN-2005-1763, CAN-2005-1762, CAN-2005-1761, CAN-2005-1265, CAN-2005-0757, CAN-2005-0756 These are all duplications from the above, so already fixed as well. Well, 1265 isn't; this is fixed in 2.6.12, however. So to summarize, the only questionable one is CAN-2005-0757. The rest are fixed in linux-2.6 2.6.12-6. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: In preparation for 2.6.13 - initrd issues
On Sun, Sep 11, 2005 at 06:23:25PM -0700, Jurij Smakov wrote: Hello, As you probably know, the 2.6.13 kernel is out, and we are facing some problems with packaging it for Debian. A major change compared to 2.6.12 is the discontinued support for devfs, which, I understand, renders current initrd-tools unusable. As I see it, there are two major problems which need to [...] Talk to jbailey before making any decisions about this, as he has the best grasp on initramfs. I believe maks was also working on this. I'm told that there are currently some issues with other archs and initramfs (ie, oopsing during boot), but this is to be expected as we (debian) will probably be using it on untested platforms. It's broken on sparc, at least.. FWIW, I'm all for initramfs; it moves logic/magic out of kernelspace into userspace, and sounds like it will allow us much more flexibility wrt early userspace stuff. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to detect a debian kernel from `uname -r`
On Fri, Sep 09, 2005 at 11:16:38PM +0200, Andrea Arcangeli wrote: Hello everyone, I'm trying to detect a debian kernel from uname -r. My suggestion would be to add a -debian at the end of the localversion of kernels _patched_/modified by debian, and to leave the localversion completely _empty_ (or an unchanged localversion compared to the mainline defconfig) for unmodified mainline kernels shipped by debian (if you ship them in the first place). Quite honestly, I don't think we deviate enough from the mainline kernels enough to warrant such a thing. The main patches we include are the stable kernel patches, misc fixes backported from linus' git repo, architecture patches (that don't affect 99% of our users, as 99% of our users are using x86 or x86_64 kernels), and legacy feature/modularization patches that we're trying to get rid of. When we upgrade to the latest linus release, we end up dropping the majority of our patches. Our goal is to get as close to mainline as possible, so that we're not maintaining a huge set of patches. I also wonder how to detect ubuntu kernels, perhaps they're the same as debian I don't know. If they're the same from a sourcecode standpoint then I guess it's better to call them -debian too at the end of the extraversion. Ubuntu kernels, otoh, deviate from mainline a *lot* more; specifically, they include a lot of laptop and acpi specific patches that are not found in mainline. We do not currently share codebases at all (although this may change at some point; BenC just took over mainenance of the Ubuntu kernels, so I'm not sure what'll happen there). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
standardizing on a language
On Thu, 2005-09-08 at 13:26 +0900, Horms wrote: Hi Andres, In the course of using split-config I have noticed a small problem. In some cases it is not safe to remove an option from a config, unless it is removed gloablly. When I say not safe, nothing particularly catastropic happens, but each time you run split-config, you have to wade through a mountain of this option was removed, what shall i do, messages. To demonstrate this, try split-config on arm/rpc, twice. Do you mean *removed* or *disabled*? If you mean removed; I changed split-config to ignore removals, it should be in svn (unless I only committed it to a local bzr repo, or it got lost in the shuffle..). If you mean disabled; I haven't seen that problem yet. If it is the case, I'll take a look. The patch below should aleviate this problem, by adding an annotation to the debian configs if a option has been removed, but is not removed globablly. Cool; feel free to commit if you think it's suitable, the worst that can happen is I revert it if it's broken. Its my first peek into the world or ruby, so please forgive any stupidity on my part. This brings up something I've been meaning to bring up. Right now, we've got a mix of python, ruby, shell, and perl in svn. I'd like to standardize on a language. Naturally, we'll still need to have things that end up being run on the user's system in perl or shell (shell for things that can't use or are too simplistic perl, and perl for other things). However, for our standard tools to manage various things (configs, control files, etc), we should choose either ruby or python. I don't want to see perl used, since I don't think perl is suitable for large scripts, and is difficult to maintain. I'm comfortable with either ruby or python; I suppose it depends on what others are more comfortable with. If necessary, I can rewrite split-config in python; I've already started toying around w/ python scripts (see scripts/testconfigs). Preferences? Once we have a common language, we can have a common library as well (ages ago, I wrote half a Kconfig parser in racc; that seems like it'd be useful for all kinds of scripts, but I'm not going to spend any more time on it until we decide whether I should continue in racc, or use something python-y). -- Andres Salomon [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
2.6.12-6 release
Unless anyone has objections, I intend to upload 2.6.12-6 tomorrow. The only flavour that fails to oldconfig is arm/config.s3c2410; Vincent, can you please fix that? The following shouldn't prompt: cat debian/arch/config .config cat debian/arch/arm/config.s3c2410 .config make oldconfig ARCH=arm [Note: for automated testing of all flavours, try trunk/scripts/testconfigs.] For other architectures, if there are any issues, let me know; otherwise I'll build and upload 2.6.12-6 tomorrow. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
svn layout confusion
Ok, so now that we have dists/sid and dists/trunk (which is for development and experimental stuff); how is this actually supposed to work? I understand the scenario when we have 2.6.12 in sid and 2.6.13rc in trunk; stick any new development stuff in trunk, backport to sid if desired, do sid releases from dists/sid, and experimental releases from dists/trunk. What about the case where we have 2.6.13 in both? Are we supposed to do all releases from trunk, and branch/cp to sid? Are we supposed to do releases from sid, and keep trunk ready for 2.6.14 development; regularly forward-porting changelogs and stuff? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: svn layout confusion
On Tue, 2005-09-06 at 22:25 +0900, Horms wrote: On Tue, Sep 06, 2005 at 08:51:06AM -0400, Andres Salomon wrote: Ok, so now that we have dists/sid and dists/trunk (which is for development and experimental stuff); how is this actually supposed to work? I understand the scenario when we have 2.6.12 in sid and 2.6.13rc in trunk; stick any new development stuff in trunk, backport to sid if desired, do sid releases from dists/sid, and experimental releases from dists/trunk. What about the case where we have 2.6.13 in both? Are we supposed to do all releases from trunk, and branch/cp to sid? Are we supposed to do releases from sid, and keep trunk ready for 2.6.14 development; regularly forward-porting changelogs and stuff? I think this is pretty confusing myself, though I believe that the idea is that if sid and trunk are the same, then you nuke the sid branch. So basically things only exist in sid/ if we are working on something newer than what is in sid (and being maintained). Pretty much what I was thinking; why keep a branch around when we're not using it? Why not just create trunk only when it's different from sid (or vice versa, whatever the svn users like to call HEAD). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: svn layout confusion
On Tue, 2005-09-06 at 15:20 +0200, Sven Luther wrote: On Tue, Sep 06, 2005 at 08:51:06AM -0400, Andres Salomon wrote: Ok, so now that we have dists/sid and dists/trunk (which is for development and experimental stuff); how is this actually supposed to work? I understand the scenario when we have 2.6.12 in sid and 2.6.13rc in trunk; stick any new development stuff in trunk, backport to sid if desired, do sid releases from dists/sid, and experimental releases from dists/trunk. What Indeed. about the case where we have 2.6.13 in both? Are we supposed to do all releases from trunk, and branch/cp to sid? Are we supposed to do releases from sid, and keep trunk ready for 2.6.14 development; regularly forward-porting changelogs and stuff? The plan, as i see it, is that as soon as 2.6.12 is in etch, we are going to upload 2.6.13 kernels anyway to sid, and continue to make 2.6.12 bug-fix uploads to etch by t-p-u (if this is not still broken). I wouldn't really consider 2.6.12 to be etch release-material until the packaging changes settle down; more of something for d-i and etch users to use while we finalize the packaging. I wouldn't want to see etch actually release w/ -6. But yes, your explanation makes sense for 2.6.13 (assuming we want to release with it). Also, we'll probably be doing uploads to testing-security more often than t-p-u. So, the natural thing to do then, is to svn mv dists/sid to /dists/etch at that time, and svn cp dists/trunk as dists/sid. cp or mv? If we only cp, dists/trunk gets stale as we work on dists/sid, and would need to be manually synched. Then we make 2.6.13 releases in dists/sid, while 2.6.12 is slowly phased out, and make brand-new-out-of-git 2.6.14-rc or whatever uploads to experimental from dists/trunk. How often do we intend to do those? I don't like the idea of two possible development trees getting out of synch; if dists/sid only contains patch updates, that's fine. However, if dists/sid contains packaging updates (ie, fixes to gencontrol.py and such), then keeping dists/trunk in synch with that will become troublesome.. It sounds to me like dists/trunk should be a branch of dists/sid, created whenever there's experimental packaging or patch work being done. That said, i believe that the single linux-2.6 thingy is maybe not the best idea after all, but maybe we can, if t-p-u is still broken, as it seems to be as far as i remember, do linux-2.6.12 uploads out of dists/etch, in parallel to linux-2.6 uploads (which will be 2.6.13) out of dists/sid. Yea, the dists/etch thing makes sense. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12-6 release
On Tue, Sep 06, 2005 at 04:15:25AM -0400, Andres Salomon wrote: [...] For other architectures, if there are any issues, let me know; otherwise I'll build and upload 2.6.12-6 tomorrow. http://people.debian.org/~dilinger/kernel/2.6.12-6/ Go nuts. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: modules
On Sat, Sep 03, 2005 at 11:28:51PM +0200, Sven Luther wrote: [...] Well, my idea is to try to host all those module package in the kernel subversion tree (under modules), in such a way that we can trigger automated or semi-automated uploads of them in case of kernel abi changes. I assume this means giving the module maintainers svn commit access. I'm not sure I'm in favor of this, given the recent problems w/ people playing the svn-tree-layout-rework game. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: firmware packages
On Sat, Sep 03, 2005 at 09:11:22PM +0200, Bastian Blank wrote: Hi folks Are there any attempts to provide firmware images which are needed for several hardware and not included in the kernel as packages? Such as? I'm not aware of any firmware that's not included in the kernel that we're allowed to redistribute (at all). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: changelog format
On Fri, 2005-09-02 at 08:59 +0900, Horms wrote: On Thu, Sep 01, 2005 at 02:58:30PM -0400, Andres Salomon wrote: On Thu, Sep 01, 2005 at 07:35:25AM +0200, Sven Luther wrote: On Thu, Sep 01, 2005 at 12:30:41AM -0400, Andres Salomon wrote: [...] Well, we have not decided, the first [author] is thrown in by dch, and people are still using the same format as always, and maybe not always remove the [author] bit. Notice that the [author] part will probably become a standard all among debian as dch enforces it, so maybe it is worthwhile thinking about it. Yes, perhaps I should be attacking the root of the problem. See #326064. Perhaps discussion of this is a bit premature until we hear back from the devscripts people. Or perhaps we should avoid using dch, or provide our own version of dch.. I think going against the dch flow would be difficult. How widespread is dch usage? I hadn't heard of it until this thread.. [...] IMHO, anyways. I think there's enough people scanning the kernel changelogs for security bits and CAN numbers (the various teams, people doing backports to older kernels, possibly other distributions, and so on) that we want to emphasize that as much as possible. I'm all for more information than less. And I would really like to see the name of the patch or patches incoporated into the changelog entry, so there is a clear association between the description of a fix, and the code of a fix. Too many times I have hunted through packages and not had this, and been horribly frustrated. I'm not saying not to include the information; I'm just saying to order the most important fields first, so they stick out. If the fix is only for a certain arch, by all means include that information in the changelog entry. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324202: include ReiserFS ACL support in 2.6.12 kernel
On Fri, Sep 02, 2005 at 09:45:18AM +0200, Eduard Bloch wrote: [...] First: this discussion is pointless and always ends in people promoting their favorite toy (only). Pretty much. So how do you know they are reliable? For me, XFS began eating my files after 1.5years of usage, and the tools did not detect any errer leading to systematic damages. I've heard horror stories w/ both reiser and XFS. I have heard good things of JFS. And, of course, ext3 continues to be incredibly reliable (albeit not overly-quick, but..). I wouldn't use any other filesystem except for network-cache-like things that need speed but not reliability. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: changelog format
On Thu, Sep 01, 2005 at 07:35:25AM +0200, Sven Luther wrote: On Thu, Sep 01, 2005 at 12:30:41AM -0400, Andres Salomon wrote: [...] Well, we have not decided, the first [author] is thrown in by dch, and people are still using the same format as always, and maybe not always remove the [author] bit. Notice that the [author] part will probably become a standard all among debian as dch enforces it, so maybe it is worthwhile thinking about it. Yes, perhaps I should be attacking the root of the problem. See #326064. Perhaps discussion of this is a bit premature until we hear back from the devscripts people. Or perhaps we should avoid using dch, or provide our own version of dch.. [...] Architecture-specific changes should have their description line start with [arch]. The arch should be in all lowercase. Security fixes should have their description line start with [SECURITY] (reasoning: the fact that it's a security fix takes precedence over what arch if affects; if it really is a fix that affects only one arch, just mention that in the description somewhere). Security fixes that have CVE entries/CAN numbers should have their description line start with [SECURITY: CAN]. What about [SECURITY,arch] ? I wouldn't want to see that get too cluttered; and for security fixes, I really don't think the arch is as important. Otherwise, we'll end up w/ something like: * [SECURITY, amd64: CAN-2005-,CAN-2005-1112] User could frobnicate as another user. That's really not much easier to read, or pick out the important bits. The following, on the other hand, makes the CAN and security tag much more noticable: * [SECURITY: CAN-2005-,CAN-2005-1112] User could frobnicate as another user (amd64 only). IMHO, anyways. I think there's enough people scanning the kernel changelogs for security bits and CAN numbers (the various teams, people doing backports to older kernels, possibly other distributions, and so on) that we want to emphasize that as much as possible. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
changelog format
Argh. 2.6.12-6's changelog is awful; there are multiple types of styles in there. Can we *please* have some consistency in the changelog entries? The format that we've used for ages has been: * description (author) (closes: bug#) If the fix is a security or arch-specific fix, it's been: * [arch] description (author) (closes: #bug#) Sometimes we include patches: * patch1, patch2 desc (author) And for large changes: * desc o subdesc1 o subdesc2 [CVE entry] ..and so on. Now we've decided to throw in: [author] * desc (closes: #bug#) (authors) Why are we listing authors twice? And why doesn't anyone else think that looks absolutely horrid (putting the author first), emphasizing who did the change, rather than the change itself. And: [ author ] * [arch] - desc1 - desc2 While I think the above is ugly, I would be happy w/ *consistency* if we decide on that. I'm going to propose the following for changelog entries. Whatever we decide on, can we please attempt to stick to the same style? For packaging related changes: * desc (closes: #bug#) (author) My reasoning for the above: bug closings are closely related to the description, so they should be next to each other. For patch related changes: * patchname: desc (closes: #bug#) (author) For large patches (ie, 2.6.12.6): * patchname: desc o subdesc1 (closes: #bug#) o subdesc2 (author) Multiple patches, if related, can be separated by commas. If the desc is very short (ie, because the patch name is descriptive), you can put the patchname and desc on the same line: * patchname: Added (closes: #bug#) (author) Architecture-specific changes should have their description line start with [arch]. The arch should be in all lowercase. Security fixes should have their description line start with [SECURITY] (reasoning: the fact that it's a security fix takes precedence over what arch if affects; if it really is a fix that affects only one arch, just mention that in the description somewhere). Security fixes that have CVE entries/CAN numbers should have their description line start with [SECURITY: CAN]. Changelog entries should be separated by a newline. Here's 2.6.12-6 following the above convention: * Change ATM and Classical-IP-over-ATM to be modular, instead of being statically included (closes: #323143). (Andres Salomon, Bastian Blank) * powerpc-apus.patch: Added preliminary apus patch, not applied though. (Sven Luther) * powerpc-pmac-sound-check.patch: Added. (Sven Luther) * [i386] Unset CC_OPTIMIZE_FOR_SIZE in i386 config, it breaks iproute's (and other netlink users) ability to set routes. (closes: #322723) (Simon Horman) * [SECURITY: CAN-2005-2457] 2.6.12.5.patch: CAN number added, as patch contains zlib deflateBound() fix. (Someone Who Forgot To Put Their Name) (NOTE for the above: instead of doing that, I would just edit the original 2.6.12.5 changelog entry, adding the CAN# to it.) * 2.6.12.6.patch: Added o [SECURITY: CAN-2005-2555] Restrict socket policy loading to CAP_NET_ADMIN. o [SECURITY] Fix DST leak in icmp_push_reply(). No CAN# assigned yet; possible security hole. o [SECURITY]: NPTL signal delivery deadlock fix; local DoS. o fix gl_skb/skb type error in genelink driver in usbnet. o [SECURITY]: fix a memory leak in devices seq_file implementation; possible local DoS. o [SECURITY]: Fix SKB leak in ip6_input_finish(). Possible resource exhaustion DoS. (Another Person) -- Bastian Blank [EMAIL PROTECTED] Fri, 19 Aug 2005 14:39:16 +0200 There's my recommendations. Thoughts? Comments? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN layout
On Tue, 2005-08-30 at 15:33 +0200, Sven Luther wrote:
On Tue, Aug 30, 2005 at 05:41:34PM +0900, Horms wrote:
On Fri, Aug 26, 2005 at 05:53:38PM -0400, Andres Salomon wrote:
On Thu, Aug 25, 2005 at 05:53:41PM +0900, Horms wrote:
[...]
svk may be different, if so,
this is a excellent time to discuss that.
It just gets crazy if it can't find merge points.
Could you elaborate a little. I think you are the only one using
svk at this point. So perhaps you are seeing problems that aren't
apparent when svn is used.
When you say merge point? Does svk dictate that your head is
in trunk/ and directories in branch/ are siblings of it?
Or is it just a matter of knowing where each tree is in
the overall hierachy.
If we're going to start catering towards people using the kernel
repository with distribution revision control tools, why not just
use a proper distributed revision control system? I'm quite tired
of dealing w/ SVN; I consider all these discussions about branches,
naming, etc to be a complete waste of time brought about by SVN's
utterly stupid (lack of) branching and naming policy. When doing
offline development, I've tended to work using bazaar; online
development usually consists of me flooding #debian-kernel with minor
little commits, as well as dealing w/ conflicts as people write
changelog entries at the same time I do. It feels a whole lot like
SVN wastes a lot more time than it saves.
I can deal w/ SVN for the immediate future, but if people start using
svk anyways, I suggest we simply switch to something like git(/cogito)
or bzr.
Bastian seems to have gone ahead and rearanged SVN to his own liking,
so I'll close the book on trying to discuss that out on this list.
I like your idea of using bzr, for starters, it has
branching and merging. For seconds, people can do
this however they please, so we don't need these tedious
debates. And there are all sorts of other good things,
like with ubuntu, which might well make things like
security patches less of a burden.
Questions
1. How, if at all, do you interface baz/bzr with svn.
Is it just a manual process?
What do you mean, interface? Do you mean converting the repository?
If there's not already svn2bzr and svn2git tools, I can't imagine they'd
be that difficult to create (there's already various other tools to
convert between the various free RCS's). Or do you mean keeping the
main repository in svn while working locally w/ baz/bzr? For me, it's
been a manual process; I've only recently started using bzr, my offline
debian-kernel stuff has been done using baz.
2. Who doesn't want to use baz/bzr instead of svn.
Well, to clarify; I wouldn't want to use baz. It's inflexible and
difficult to use (thanks to its tla ancestry). However, bzr would
certainly make a fine choice, and it's pretty simple to use.
Just a quick question, as i am not familiar with either revision control
system, but wouldn't it make more sense to use git, seeing as the kernel is
using it, and we could then even handle our own whole kernel tree in it,
tracking upstream or whatever. Not sure about the difference between them
I don't think it would make too much of a difference; both have pros and
cons. However, both are also under heavy development; so, their
downsides are quickly becoming less and less. I don't think upstream's
choice should really affect ours. My main concern w/ using either of
them is their source format changing, breaking things; for example, I
maintain gitweb, and have had problems w/ newer versions of git/cogito
entering sid that completely break gitweb.
though, and if this makes sense or not, but as far as learning
yet-another-versioning-system, i guess it is easier to learn the one used by
upstream kernel developers.
The learning curve for both is pretty minimal.
And is baz/bzr different or mostly the same as uncomprehensible arch/tla ?
baz is pretty incomprehensible. bzr is not; it's about as easy to use,
if not easier, than svn. cogito is pretty easy to use as well; however,
the command line usage takes a bit of getting used to (instead of
{cvs,svn,bzr} command, commands are in the form cg-command for
example). I use both regularly; my worst problem with them tends to be
running bzr commands in a git repository, or vice versa. :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: prepare 2.6.13
On Mon, Aug 29, 2005 at 12:22:08PM +0200, Bastian Blank wrote: On Mon, Aug 29, 2005 at 11:50:33AM +0200, Sven Luther wrote: BTW, was 2.6.13 already released ? Or any idea when it will be ? The mail arrived 2:17 MEST. Also, i believe we need a 2.6.12-6 upload which fix the remaining problems and can go into sarge. Do we have any plans regarding that ? In preperation. Good, I would rather see at least one more 2.6.12 release before we switch to 2.6.13. I assume you're working on this? Let me know if you need any help w/ this, I'll be playing around w/ initramfs and 2.6.13 config stuff in the meantime. (BTW, I've gone over to [EMAIL PROTECTED], if you need me for anything; I've had enough of freenode.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH 0/2] Debian mkinitrd: Integrate kdump
On Wed, Aug 24, 2005 at 08:07:29PM +0530, Rachita Kothiyal wrote: Hi The following set of patches made on mkinitrd (from initrd-tools package:version 0.1.82), would enable the integration of kdump with Debian. For more details about the kexec based kdump solution please refer to Documentation/kdump/kdump.txt in the kernel source tree. This first patch (to be applied on the mkinitrd), would enable the generation of the initrd for the dump capture kernel. Sounds cool, but most people here don't want to touch mkinitrd. It's a fragile script that tends to break easily. My suggestion would be to either talk to the people who aren't afraid to break initrd-tools (Jeff Bailey comes to mind), or start looking at integrating this into the initramfs toolset, which we'll most likely switch to (replacing initrd-tools) at some point in the future. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN layout
On Thu, Aug 25, 2005 at 05:53:41PM +0900, Horms wrote: [...] svk may be different, if so, this is a excellent time to discuss that. It just gets crazy if it can't find merge points. Could you elaborate a little. I think you are the only one using svk at this point. So perhaps you are seeing problems that aren't apparent when svn is used. When you say merge point? Does svk dictate that your head is in trunk/ and directories in branch/ are siblings of it? Or is it just a matter of knowing where each tree is in the overall hierachy. If we're going to start catering towards people using the kernel repository with distribution revision control tools, why not just use a proper distributed revision control system? I'm quite tired of dealing w/ SVN; I consider all these discussions about branches, naming, etc to be a complete waste of time brought about by SVN's utterly stupid (lack of) branching and naming policy. When doing offline development, I've tended to work using bazaar; online development usually consists of me flooding #debian-kernel with minor little commits, as well as dealing w/ conflicts as people write changelog entries at the same time I do. It feels a whole lot like SVN wastes a lot more time than it saves. I can deal w/ SVN for the immediate future, but if people start using svk anyways, I suggest we simply switch to something like git(/cogito) or bzr. /rant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Secure-testing-team] Re: Moving forward with the 2.4.27 and 2.6.8 kernels
On Thu, 2005-08-18 at 18:51 +0900, Horms wrote: [...] Obviously the security team needs to be involved. However CCing them on emails seems largely fruitless. Do you have any ideas on how to work with them to make this release happen? It is becoming quite frustrating to say the least. My recommendation is to join the security team. :D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323452: hda: dma_timer_expiry: dma status == 0x21 errors + freeze (VIA VT82C686 chipset)
On Wed, Aug 17, 2005 at 12:02:31PM +0200, Vincent Lefevre wrote: [...] Then is there any reason why SMART doesn't detect any problem except some errors at power-on time? And why don't I get such errors with a 2.6 kernel (though I haven't done much testing) if it is not a problem with the 2.4 kernel? What exactly are the SMART errors? If you force a smart short or long test, do you get errors? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
cross compilation breaking sparc build?
Hi, Specifying --arch $(ARCH) unconditionally is what's breaking the sparc kernel build (and it just seems like a bad idea). First, shouldn't we just specify this if we're cross-compiling (ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))) ? Second, --arch's arg needs to match what include/asm points to; how to best handle that, I'm not sure. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323143: ip neigh flush (iproute) hangs because CONFIG_ATM_CLIP=y
severity 323143 wishlist retitle 323143 linux-2.6: CONFIG_ATM_CLIP should be configured as a module thanks On Sun, Aug 14, 2005 at 05:08:18PM -0700, Alvaro Martinez Echevarria wrote: Package: linux-source-2.6.12 Version: 2.6.12-1 Severity: normal Hi, Regarding this problem with iproute: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=282492 Would it be possible to include a fix for this, or at least make CONFIG_ATM_CLIP a module instead of a yes in the stock kernel? I'm suffering it right now, and it is the only reason that forces me to compile my own kernels... Thanks, This should probably be the case anyways, as it appears to be marked EXPERIMENTAL, and the config does support tristate. Not only that, but it's configured differently across different archs; definitely a candidate for a global config. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322723: Bug#323143: ip neigh flush (iproute) hangs because CONFIG_ATM_CLIP=y
On Wed, 2005-08-17 at 02:13 +0200, Frans Pop wrote: On Tuesday 16 August 2005 19:35, Andres Salomon wrote: [...] This should probably be the case anyways, as it appears to be marked EXPERIMENTAL, and the config does support tristate. Not only that, but it's configured differently across different archs; definitely a candidate for a global config. Could this also be the cause of #322723 (d-i installs failing because of failing ip route command)? It seems somewhat similar. If so, please implement the change soonest. This has been done for all archs, and will show up in 2.6.12-6 (unless someone has a reason why ATM and ATM_CLIPS shouldn't be modular). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#323183: Please remove some linux packages from sid
On Tue, Aug 16, 2005 at 02:43:36PM -0700, Matt Zimmerman wrote: On Tue, Aug 16, 2005 at 02:22:33PM -0700, Steve Langasek wrote: On Tue, Aug 16, 2005 at 09:23:52AM -0400, Joey Hess wrote: Jeroen van Wolffelaar wrote: This will break a lot packages depending on one of those, including but not limited to things like linux-kernel-di-hppa-2.6, pwc, user-mode-linux, kernel-headers-2.6-generic (alpha), etc etc. FWIW, u-m-l seems to still be unmaintained and not going anywhere fast. It should be removed from unstable if no one steps up to maintain it; it needs to be repackaged more or less from scratch in order to migrate to 2.6 and I will not be effecting that transition because I no longer use UML. It would be quite a shame to see it completely gone from sid; I find it comes in handy now and then. However, I'd have no desire to deal w/ the 2.4 version. For 2.6, instead of building it as an outside package, perhaps it should be an i386 subarch or flavour within the linux-2.6 package? It seems like it would be a better fit, as we could manage config options (keeping the global ones in sync even across uml), as well as trigger an automatic rebuild of uml easily for each new kernel upload (and security update!). If it needs additional patches that aren't compatible w/ other architectures, it would be a candidate for subarch inclusion; otherwise, it could just as easily be another i386 flavour (I believe the current linux-2.6 packaging supports the cross-compilation stuff necessary to override ARCH=um?). According to the sf uml page, past 2.6.9, a separate patch is not needed for uml. What about the skas patch, was a version of that ever merged into 2.6? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 in volatile?
On Wed, Aug 10, 2005 at 07:21:06AM +0200, Sven Luther wrote: [...] Wrong, linux-2.6 needs at least version 9.005 of kernel-package. So either we backport it to sarge, or i provide a patch of the needed functionality for the version of kernel-package in sarge. Is it just powerpc that needs it? If so, how difficult is it to just backport the powerpc-specific bits to the kernel-package that's in sarge? I'd rather stick w/ a known-good kernel-package, if possible. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295678: kernel-image packages with CONFIG_HIGHMEM64G=y enabled
On Wed, Aug 10, 2005 at 11:57:35AM +0900, Horms wrote: On Tue, Aug 09, 2005 at 05:34:33PM -0600, dann frazier wrote: On Tue, 2005-08-09 at 11:29 +0200, Christian Hammers wrote: Hello The problems is not Dell PowerEdge specific. My TYAN Tiger-i7320-S5350 (standard dual xeon server from www.ipc2u.com) also reports only 3.5GB after booting the Sarge 2.6 kernel :-( The BIOS reports full 4GB. So if it does not hurt anybody I suggest turning on 64GB support. From arch/i386/Kconfig: If more than 4 Gigabytes is used then answer 64GB here. This selection turns Intel PAE (Physical Address Extension) mode on. PAE implements 3-level paging on IA32 processors. PAE is fully supported by Linux, PAE mode is implemented on all recent Intel processors (Pentium Pro and better). NOTE: If you say 64GB here, then the kernel will not boot on CPUs that don't support PAE! So it looks like this would hurt other users. And, on machines that do support PAE, I've seen benchmarks that demonstrate a significant performance loss. However, this was on a 2.4.25 kernel, not a recent 2.6, and I no longer have a link to those results - google might. I think supporting these machines would mean adding an additional x86 kernel-image flavor. I think if it is a performance hit (on a sufficiently prevalent set of hardware) then a new flavour would be in order. On the machines not booting front, it seems those machines are probably going to be using the 383 or 586 flavours rather than the 686 flavour, so adding this option to the latter shouldn't cause those machines to stop booting. I can't say I'm a fan of adding another flavour. How many people are actually using 4GB of memory on x86? I suspect (or hope) that people who are going to be doing those sorts of things will be using x86_64 and ia64 hardware. Christian's problem, aiui, is simply that the kernel sees 3.5GB instead of 4GB. I'm not sure whether this is by design, or is a bug, but I'd much rather see that fixed instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
2.6.12 in volatile?
Hi, So, was there any decision whether to provide 2.6.8+security in volatile, or just backport linux-2.6 (2.6.12)? I need to do a 2.6.12 backport, so if people are wanting 2.6.12 for volatile, I'll do that; however, if people want 2.6.8+security in volatile, I'll just put 2.6.12 in p.d.o/~dilinger, and make it known via apt-get.org. I've had reports of breakage with 2.6.12 and sarge which I believe are related to udev, so we might need to keep that updated as well. There is also some breakage with powerpc and older versions of kernel-package; we'd need to determine what's necessary for that (my tests on i386 w/ 2.6.12-1 went just fine w/ the kernel-package that's in sarge). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315968: kernel: usb-storage not working, system freeze
reopen 315968 tags 315968 + sarge thanks I assume you meant to CC [EMAIL PROTECTED] :) On Tue, Aug 09, 2005 at 03:30:59PM +0900, Horms wrote: reopen 315968 thanks This bug is still valid for 2.6.8, so lets leave it here for now. At the very least we can use it to coodinate known problems in 2.6.8 -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322086: ALSA support for ali5451 is sill broken
For future reference, the original bug is #303311. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321964: linux-2.6: package that depends on all -headers for $arch
On Mon, Aug 08, 2005 at 03:52:33PM +0200, Max Vozeler wrote: Package: linux-2.6 Version: 2.6.12-1 Severity: wishlist There used to exist packages that depend on all -headers packages for a particular arch (eg. kernel-headers-2.6.11-1-i386). This is very useful for build-depends when autobuilding external module packages. Such packages seem to no longer exist with the new kernel packaging - please consider to re-add something like it. Now that waldi has gencontrol.py creating dummy packages and rules for the various linux-image and linux-header packages, we can throw the all-headers package back in. There was some issue of what it should actually be called, however.. Calling it linux-headers-2.6.12-1-i386 doesn't work too well for all archs, since we end up w/ linux-headers-2.6.12-1-powerpc, which conflicts w/ the name of a flavour. Suggestions? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6_2.6.12-2_i386.changes REJECTED
On Tue, 2005-08-09 at 10:34 +0900, Horms wrote: On Mon, Aug 08, 2005 at 01:18:20PM -0700, Debian Installer wrote: Rejected: kernel-image-2.6-k7-smp_2.6.12-2_i386.deb: old version (101) in unstable = new version (2.6.12-2) targeted at unstable. Rejected: kernel-image-2.6-k7-smp_2.6.12-2_i386.deb: old version (101) in testing = new version (2.6.12-2) targeted at unstable. Rejected: kernel-image-2.6-k7-smp_2.6.12-2_i386.deb: old version (101) in stable = new version (2.6.12-2) targeted at unstable. Rejected: kernel-image-2.6-686-smp_2.6.12-2_i386.deb: old version (101) in unstable = new version (2.6.12-2) targeted at unstable. Rejected: kernel-image-2.6-686-smp_2.6.12-2_i386.deb: old version (101) in testing = new version (2.6.12-2) targeted at unstable. Rejected: kernel-image-2.6-686-smp_2.6.12-2_i386.deb: old version (101) in stable = new version (2.6.12-2) targeted at unstable. Rejected: kernel-image-2.6-386_2.6.12-2_i386.deb: old version (101) in unstable = new version (2.6.12-2) targeted at unstable. Rejected: kernel-image-2.6-386_2.6.12-2_i386.deb: old version (101) in testing = new version (2.6.12-2) targeted at unstable. Rejected: kernel-image-2.6-386_2.6.12-2_i386.deb: old version (101) in stable = new version (2.6.12-2) targeted at unstable. Rejected: kernel-image-2.6-k7_2.6.12-2_i386.deb: old version (101) in unstable = new version (2.6.12-2) targeted at unstable. Rejected: kernel-image-2.6-k7_2.6.12-2_i386.deb: old version (101) in testing = new version (2.6.12-2) targeted at unstable. Rejected: kernel-image-2.6-k7_2.6.12-2_i386.deb: old version (101) in stable = new version (2.6.12-2) targeted at unstable. Rejected: kernel-image-2.6-686_2.6.12-2_i386.deb: old version (101) in unstable = new version (2.6.12-2) targeted at unstable. Rejected: kernel-image-2.6-686_2.6.12-2_i386.deb: old version (101) in testing = new version (2.6.12-2) targeted at unstable. Rejected: kernel-image-2.6-686_2.6.12-2_i386.deb: old version (101) in stable = new version (2.6.12-2) targeted at unstable. I guess we need an epoch Give the man an epoch! 2.6.12-2 is re-tagged in svn, w/ some epoch spiffiness that waldi did; only the transition packages (kernel-image-*) got epoch'd. We're both building test packages.. Hopefully this should appease katie. -- Andres Salomon [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: linux-2.6 - subarch and patches
On Wed, 03 Aug 2005 19:55:12 +0200, Bastian Blank wrote: Hi folks linux-2.6 currently supports something called subarch. It should be used for incompatible patches. This is needed for m68k and I think mips. Problems with this - mostly unimplemented, - namingschema differs from anything else: linux-image-$subarch-2.6-$flavour. Proposal: Replace with patch definitions. I'm in the Christoph school of thought; I'd rather see archs get their patches upstream. I'm willing to tolerate subarchs (and get them working if no one else does) after a rather long argument w/ Sven. If you want to implement your proposal in a branch and get it working 100%, we can replace the subarch stuff w/ it. I would recommend doing it sooner rather than later, however; if I get around to doing the subarch stuff, and it works, I won't be overly excited about dealing w/ more package renaming. I must admit that I do prefer your proposal's naming convention for header packages, however. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sarge kernels and Volatile
On Tue, 2005-08-02 at 18:10 -0400, Michael Stone wrote: On Tue, Aug 02, 2005 at 03:43:42PM -0400, Andres Salomon wrote: until fairly recently; we've gotten conflicting answers ranging from We should provide kernel updates and the security team will use them verbatim generally the security team at least glances at what's released in a dsa. to Don't even bother providing an update, you're just wasting your time. I have no idea who said that. There were a range of answers from all sorts of folks; RMs, QA people, etc. No two were alike. problems and build (and work) on all 11 archs. We need to know just how much leeway we have with our update; can we include an ABINAME bump? We've done it before when absolutely necessary. I'd expect that to be a last resort, because it'll definately screw people who expect apt-get to magically upgrade them. We've gone over this with joeyh, he thinks it's ok to do. I do believe it's absolutely necessary. Can we include other important fixes? Not in a security update, unless it's security-critical. You can argue with the stable release manager over additional changes to a package in sarge-proposed-updates. Ok, thanks. of security fixes that don't break the ABI? Will you leave it up to our judgement as to what security fixes to include, or will you have to ok each and every patch? Expect it to be reviewed, but as long as you don't make any mistakes your judgement should be fine. :) Then the process will probably be to release a new kernel-source-2.6.8 (and possibly kernel-image-2.6.8-i386), get it ok'd by the security team, and then do rebuilds of the rest of the kernel-image packages. Ditto for 2.4.27. As for taking responsibility for the security updates, I believe Horms is more than willing He's the one who told me nobody was coordinating kernel security updates... Yes, because 2 months ago, that was the case. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sarge kernels and Volatile
On Tue, 2005-08-02 at 13:54 -0400, Michael Stone wrote: On Tue, Aug 02, 2005 at 12:07:50PM +0900, Horms wrote: Thanks, I wasn't aware of that. However it seems that working with the security team on this is difficult - lack of response being a primary issue. What response do you want? I sent a message 2 months ago asking how kernel updates were being coordinated and you replied that they weren't. Are you asking me or Horms? *I* was looking for a response from Joey regarding my plan for updating 2.6.8. As for the coordination of kernel updates, we (the kernel team) were unsure of how that was being handled until fairly recently; we've gotten conflicting answers ranging from We should provide kernel updates and the security team will use them verbatim to Don't even bother providing an update, you're just wasting your time. I was hoping Joey would answer my response to let me know if our plan was ok or not, so we could go ahead with it. In the meantime, Horms is keeping an updated kernel-source-2.6.8 in our SVN repo. I can't speak for anyone else @security.d.o, but for myself I'm looking to see the debian kernel maintainers come to a conclusion. This group maintainer shit doesn't work if nobody actually wants to take responsibility for the package. Bottom line--I'm waiting for the package maintainer (debian-kernel) to present packages that fix the problems and build (and work) on all 11 archs. And we're waiting for a response from the security team about whether or not we should go through the pain of presenting packages that fix the problems and build (and work) on all 11 archs. We need to know just how much leeway we have with our update; can we include an ABINAME bump? Can we include other important fixes? Or are we restricted to a subset of security fixes that don't break the ABI? Will you leave it up to our judgement as to what security fixes to include, or will you have to ok each and every patch? If the latter is the case, we'll have to do this in two steps; first, getting you an updated kernel-source-2.6.8 package, and after that's been ok'd, building packages for all 11 archs. As for taking responsibility for the security updates, I believe Horms is more than willing (but I'm certainly not speaking for him. Horms?) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sarge kernels and Volatile
On Mon, 01 Aug 2005 18:40:26 +0900, Horms wrote: On Mon, Aug 01, 2005 at 09:28:37AM +0200, Andreas Barth wrote: * Horms ([EMAIL PROTECTED]) [050801 08:23]: I am wondering if others thing that volatile is a good place for us to make uploads of updated 2.6.8 and 2.4.27 kerels for Sarge? This would allow us to remove these kernels from unstable/testing and still provide maintenence releases for users. Well, my basic approach to that is that nobody of the volatile team can really do security stuff (or otherwise debugging) for the kernels. So, if the kernel team is able and willing to do that, we could go that way. But anything that is in volatile needs to be security-supported till the distribution is archived (and the security support won't be done by the security-team). What I am really looking for is a way to allow the kernel-team (me?) to provide updates for sarge. Primarily security updates, but there are other important fixes too. The security team hasn't doene kernel updates for a long time now, I guess they are busy with other things. So I think it is valuable for the kernel team to provide updates. Also, you might consider if the current approach to rebuild the kernels is the best one (but that's of course up to you as long as you do the work :). I am not sure what you are getting at there. The current build process is a mess. We are tying to sort that out with single-source, which is what you can see for 2.6.12. If we can get this working, and convince ourselves that moving sarge from 2.6.8 to 2.6.12 is possible, then yes, we should do that. But for now, I'm really looking for a way to do maintenance on 2.4.27 and 2.6.8. -- Horms I should probably point out this: http://lists.debian.org/debian-release/2005/07/msg00083.html Joey responded (privately) asking for an outline of the plan. My response was: We will update 2.4.27 and 2.6.8 for various security fixes (and only security fixes). The netfilter frag queue security fix requires an ABINAME bump, so the kernel packages will all be renamed from (for example) kernel-image-2.6.8-2-686 to kernel-image-2.6.8-3-686. They will be uploaded to stable-proposed-updates. This will happen for kernel-source-$VERSION, the various architecture kernel packages (ie, kernel-image-2.6.8-i386), and kernel-latest packages. Once they are uploaded, joeyh will take over, updating d-i as necessary. He doesn't plan to redo the d-i boot stuff (aiui), so d-i will boot the old 3.1r0 kernels, while it will install the 3.1r1 kernels (it would be better to talk to him to clarify this, however). Horms has been working on security fix kernels, with the intention of doing a non-ABI changing kernel update, and has been trying to get ahold of you; I'm not sure the status of this atm. However, depending on what you'd prefer to see, we can roll the ABI change in there as well, and just do one security update. The source package names will not be changing; only the binary package names. kernel-image-2.6.8-i386 will remain the source package name; however, the following binary packages that're generated from that will change: kernel-headers-2.6.8-2- kernel-headers-2.6.8-3 kernel-headers-2.6.8-2-386- kernel-headers-2.6.8-3-386 kernel-headers-2.6.8-2-686- kernel-headers-2.6.8-3-686 kernel-headers-2.6.8-2-686-smp- kernel-headers-2.6.8-3-686-smp kernel-headers-2.6.8-2-k7 - kernel-headers-2.6.8-3-k7 kernel-headers-2.6.8-2-k7-smp - kernel-headers-2.6.8-3-k7-smp kernel-image-2.6.8-2-386 - kernel-image-2.6.8-3-386 kernel-image-2.6.8-2-686 - kernel-image-2.6.8-3-686 kernel-image-2.6.8-2-686-smp - kernel-image-2.6.8-3-686-smp kernel-image-2.6.8-2-k7 - kernel-image-2.6.8-3-k7 kernel-image-2.6.8-2-k7-smp - kernel-image-2.6.8-3-k7-smp There are, as you can imagine, many more for each different architecture (and for 2.4.27). Do you need a full list of these? I never received a response to that mail, however. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6_2.6.12-1_i386.changes is NEW
On Sun, 24 Jul 2005 11:51:31 -0400, Nathanael Nerode wrote: - readdition of tg3 driver, as firmware license has been fixed It's distributable, but only in non-free. No source code for the firmware program. Sorry. :-P Ask debian-legal if you have further questions about that. Yep, I'm well aware of that; but we're not stripping firmware yet, so there's no need to remove tg3 yet. If anyone's interested, I've got a patched version of the tg3 in Debian's linux-source-2.6.12 package which does firmware loading (it builds), *and* a package ready for non-free containing the firmware. (Well, it's ready except that it would need some sort of Depends: appropriate-kernel-version) Since I don't actually have a tigon 3, I need someone else to test it for me, of course. Files at http://home.twcny.rr.com/nerode/neroden/debian/ . If you're not interested in that, I suppose I could arrange for the driver to build out-of-tree. I would *like* to get the firmware loading upstream, but they have some... interesting requirements before they'll accept it, so we'll see when that happens. :-P Getting it upstream would be the ideal situation; otherwise, we'll just have the complete driver in non-free. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
goals for 2.6.12-2 (and beyond)
linux-2.6_2.6.12-1 just hit incoming, woo! My definite goals for 2.6.12-2 are: - differentiate between @longclass@ and @class@, as Frederik pointed out that the @class@ in 2.6.12-1 was making the synopsis line too long. This is already checked into svn; it's up to arch people to update their desc.$flavour files, now. - add the ability to have flavours of the same name, across different arches. mips/mipsel will be the test case for this. Thiemo, care to commit some mips/mipsel stuff to the arch directory, so we can start playing with it? It doesn't matter if it breaks stuff initially, we can fix it. :) - make depends/suggests dynamic for flavours, as several architectures have flavours that require different bootloaders. - clean up my substitute() shell code - make linux-headers-2.6.12-1 Architecture: all, with the associated cleanups involved in that. The more we can remove from headers-install.in, the better, imo. - merge kernel-latest-2.6-$arch into the linux-2.6 package. It shouldn't be difficult, but will require some additional targets in debian/rules (oh, how i long for cdbs(2) here, to automatically take care of this stuff for me). My potential goals (ie, most likely for -3) are: - re-add qla2xxx drivers. QLogic's lawyers are supposed to call me today, to discuss further minor language changes in their license; assuming all goes well, and their turnaround time is quick, hopefully the firmware for this driver will become redistributable before 2.6.12-2 is uploaded. If that happens, we can readd the driver. - get at least 5 archs successfully building; probably i386, plus some combination of the archs that're already in 2.6.12-1 (powerpc, ia64, sparc, alpha, s390). The more the merrier, of course.. When's amd64 going to start being autobuilt, anyways? - add k8 images to the i386 images, after flavours are allowed to have the same name. Of course, this assumes the toolchain will allow cross-compilation... - if we have an architecture attempting to use subarches, get that working. This will probably require (aside from various fixes all over the place) looking at the patches mechanism, making it work more in line with what we've got wrt series.. - get all the missing archs included that're currently missing; that is, mips, mipsel, hppa, arm, m68k. And, once all of that is done: - start using initramfs instead of an initrd. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
