2.6.15 was released upstream ...
Hi ... As you may have noticed, 2.6.15 was released upstream this night, and i did prepare debian source packages at : http://people.debian.org/~luther/2.6.15 Which i am building now and which should be uploadable at around noon, provided someone with a fast box doesn't beat me to it. They will still need NEW processing, which is why i am CCing ftp-masters, since it would be nice if these packages could be NEW processed before dinstall today. There apparently wasn't any kconfig change since -rc7, so this should build straightforwardly for all arches that built previously, which are everyone except m68k which will be readied post 2.6.15, as usual. I have removed the experimental entries, readded the 2.6.14-[4-7] entries, and the changelog now looks as below, i hope this is ok. Ok, thanks everyone again for having made things ready during the -rc phase, and especially to Frederik Schüler for having lead the effort this time. Friendly, Sven Luther linux-2.6 (2.6.15-1) unstable; urgency=low [ Sven Luther ] * New upstream release. [ Bastian Blank ] * [s390] Update configs. [ Kyle McMartin ] * [hppa] Snag latest hppa.diff from cvs.parisc-linux.org. * [hppa] Update configs for 2.6.15. * [hppa] Change parisc kernel names to something less ambiguous. [ Sven Luther ] * [powerpc] Now use ARCH=powerpc for 64bit powerpc flavours, 32bit still stays with ARCH=ppc for now. * [powerpc] Readded PReP Motorola PowerStack II Utah IDE interrupt (Closes: #345424) * [powerpc] Fixed apus patch. * Added make-kpkg --arch option support to gencontrol.py. * Added debian/bin/kconfig.ml to process config file snipplet, so we can preserve the pre 2.6.15 ordering of config file snipplets. Upto 2.6.15 the kernel Kconfig magic apparently kept the later occuring config options, but it seems that this is no more the case. Instead of catting the config files together, not use the kconfig.ml script to read in the files from more generic to more specific, and keep only the more specific. [ dann frazier ] * [ia64] Update ia64 configs [ maximilian attems ] * Drop modular-ide.patch, nacked by ide upstream. Prevents udev to load ide-generic and those successfull boots with initramfs-tools. * Disable CONFIG_USB_BANDWIDTH, causes major trouble for alsa usb cards. [ Norbert Tretkowski ] * [alpha] Removed conflict with initramfs-tools, thanks vorlon for finding the klibc bug! [ Jonas Smedegaard ] * Adjust short description of transitional package kernel-image-2.6- 486 to mention 2.6 (not 2.6.12). * Clean duplicate Kconfig options. [ Frederik Schüler ] * Add updated version of drivers-scsi-megaraid_splitup.patch. * Deactivate CONFIG_IDE_TASK_IOCTL on alpha and ia64 and make it a global option. * Make CONFIG_VIDEO_SAA7134 a global option. * New option CONFIG_CC_OPTIMIZE_FOR_SIZE set per-arch. * Rename i386 368 flavour to 486. * Add myself to uploaders. * Readdition of qla2xxx drivers, as firmware license has been fixed. * Make CONFIG_PACKET, PACKET_MM and UNIX builtin on all architectures: statically linked has better performance then modules due to TLB issue. * clean up debian-patches dir: remove all obsolete patches: - alpha-compile-fix.patch: obsolete - amd64-int3-fix.patch: fixed since 2.6.12 - net-ipconntrack-nat-fix.patch: merged upstream after 2.6.14 release - net-nf_queue-oops.patch: merged upstream after 2.6.14 release - qla2xxx-removed.patch: obsolete * Drop M386 support remains from the i386 386 flavour: built with M486 from now on. [ Martin Michlmayr ] * [arm] Don't define compiler since GCC 4.x is the default now anyway. * [arm] Add descriptions for class and longclass. * [arm] Compile CONFIG_BLK_DEV_SL82C105 support into the kernel on Footbridge. * [arm] Compile ext3 support into the kernel on Footbridge. * [arm] Turn on CONFIG_SERIAL_8250 support on Footbridge. [ Jurij Smakov ] * [sparc] Correct the patch for the atyfb framebuffer driver (sparc64-atyfb-xl-gr.patch) to finally fix the console and X image defects on Blade 100/150. The new patch is named sparc64-atyfb-xl-gr-final.patch to avoid the confusion. Thanks to Luis F. Ortiz for fixing the patch and Luigi Gangitano for testing it out. * Drop tty-locking-fixes9.patch, which was preventing the oops during shutdown on some sparc machines with serial console. Proper fix has been incorporated upstream. [ Simon Horman ] * Enable MKISS globally (closes: #340215) * Add recommends libc6-i686 to 686 and k7 image packages (closes: #278729) * Enable OBSOLETE_OSS_USB_DRIVER and USB_AUDIO as alsa snd-usb-audio still isn't quite there. I expect this to be re-disabled at some stage, possibly soon if it proves to be a source of bugs. (closes: #340388) -- Sven Luther [EMAIL PROTECTED] Tue, 3 Jan 2006 06:48:07 + -- To UNSUBSCRIBE, email to [EMAIL
Re: 2.6.15 was released upstream ...
Forgot to CC ftp-masters, ... i hope the address is correct and it reaches them :) On Tue, Jan 03, 2006 at 09:07:09AM +0100, sven wrote: Hi ... As you may have noticed, 2.6.15 was released upstream this night, and i did prepare debian source packages at : http://people.debian.org/~luther/2.6.15 Which i am building now and which should be uploadable at around noon, provided someone with a fast box doesn't beat me to it. They will still need NEW processing, which is why i am CCing ftp-masters, since it would be nice if these packages could be NEW processed before dinstall today. There apparently wasn't any kconfig change since -rc7, so this should build straightforwardly for all arches that built previously, which are everyone except m68k which will be readied post 2.6.15, as usual. I have removed the experimental entries, readded the 2.6.14-[4-7] entries, and the changelog now looks as below, i hope this is ok. Ok, thanks everyone again for having made things ready during the -rc phase, and especially to Frederik Schüler for having lead the effort this time. Friendly, Sven Luther linux-2.6 (2.6.15-1) unstable; urgency=low [ Sven Luther ] * New upstream release. [ Bastian Blank ] * [s390] Update configs. [ Kyle McMartin ] * [hppa] Snag latest hppa.diff from cvs.parisc-linux.org. * [hppa] Update configs for 2.6.15. * [hppa] Change parisc kernel names to something less ambiguous. [ Sven Luther ] * [powerpc] Now use ARCH=powerpc for 64bit powerpc flavours, 32bit still stays with ARCH=ppc for now. * [powerpc] Readded PReP Motorola PowerStack II Utah IDE interrupt (Closes: #345424) * [powerpc] Fixed apus patch. * Added make-kpkg --arch option support to gencontrol.py. * Added debian/bin/kconfig.ml to process config file snipplet, so we can preserve the pre 2.6.15 ordering of config file snipplets. Upto 2.6.15 the kernel Kconfig magic apparently kept the later occuring config options, but it seems that this is no more the case. Instead of catting the config files together, not use the kconfig.ml script to read in the files from more generic to more specific, and keep only the more specific. [ dann frazier ] * [ia64] Update ia64 configs [ maximilian attems ] * Drop modular-ide.patch, nacked by ide upstream. Prevents udev to load ide-generic and those successfull boots with initramfs-tools. * Disable CONFIG_USB_BANDWIDTH, causes major trouble for alsa usb cards. [ Norbert Tretkowski ] * [alpha] Removed conflict with initramfs-tools, thanks vorlon for finding the klibc bug! [ Jonas Smedegaard ] * Adjust short description of transitional package kernel-image-2.6- 486 to mention 2.6 (not 2.6.12). * Clean duplicate Kconfig options. [ Frederik Schüler ] * Add updated version of drivers-scsi-megaraid_splitup.patch. * Deactivate CONFIG_IDE_TASK_IOCTL on alpha and ia64 and make it a global option. * Make CONFIG_VIDEO_SAA7134 a global option. * New option CONFIG_CC_OPTIMIZE_FOR_SIZE set per-arch. * Rename i386 368 flavour to 486. * Add myself to uploaders. * Readdition of qla2xxx drivers, as firmware license has been fixed. * Make CONFIG_PACKET, PACKET_MM and UNIX builtin on all architectures: statically linked has better performance then modules due to TLB issue. * clean up debian-patches dir: remove all obsolete patches: - alpha-compile-fix.patch: obsolete - amd64-int3-fix.patch: fixed since 2.6.12 - net-ipconntrack-nat-fix.patch: merged upstream after 2.6.14 release - net-nf_queue-oops.patch: merged upstream after 2.6.14 release - qla2xxx-removed.patch: obsolete * Drop M386 support remains from the i386 386 flavour: built with M486 from now on. [ Martin Michlmayr ] * [arm] Don't define compiler since GCC 4.x is the default now anyway. * [arm] Add descriptions for class and longclass. * [arm] Compile CONFIG_BLK_DEV_SL82C105 support into the kernel on Footbridge. * [arm] Compile ext3 support into the kernel on Footbridge. * [arm] Turn on CONFIG_SERIAL_8250 support on Footbridge. [ Jurij Smakov ] * [sparc] Correct the patch for the atyfb framebuffer driver (sparc64-atyfb-xl-gr.patch) to finally fix the console and X image defects on Blade 100/150. The new patch is named sparc64-atyfb-xl-gr-final.patch to avoid the confusion. Thanks to Luis F. Ortiz for fixing the patch and Luigi Gangitano for testing it out. * Drop tty-locking-fixes9.patch, which was preventing the oops during shutdown on some sparc machines with serial console. Proper fix has been incorporated upstream. [ Simon Horman ] * Enable MKISS globally (closes: #340215) * Add recommends libc6-i686 to 686 and k7 image packages (closes: #278729) * Enable OBSOLETE_OSS_USB_DRIVER and USB_AUDIO as alsa snd-usb-audio
Bug#100421: Don't show up at work tomorrow, pat
Hey pat, Want to generate 1.5 - 3.5k easily from the comfort of your own home with minimal effort? CaII me at : 800*645*2308 Payments are made daily. Regards, [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321409: hda: dma_timer_expiry: dma status == 0x21
03.01.2006 08:58 you wrote: In that case, it's the IDE chipset. I have replaced the hard drive, and the problem is the same. I do not have any problems when running Windows. A hard disk scan reveals no errors. I have openend the bug again. If you are sure the Bug is IDE-Kernel related please use the latest unstable kernel (best wait for 2.6.15). Then give us more information, in detail give: lscpi lspci -n dmesg lsmod And maybe interrupts. The hda: dma messages unfortunately don't help, because they are just hardware-error messages passed through the ide subsystem. thank you for your help Markus Raab -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321409: hda: dma_timer_expiry: dma status == 0x21
Markus Raab wrote: I have openend the bug again. Thanks. If you are sure the Bug is IDE-Kernel related please use the latest unstable kernel (best wait for 2.6.15). Then give us more information, in detail give: lscpi lspci -n dmesg lsmod And maybe interrupts. The hda: dma messages unfortunately don't help, because they are just hardware-error messages passed through the ide subsystem. OK, I've attached the requested information. I still have 2.6.14-2, though, I can resubmit when .15 arrives. Best regards, Henrik Linux version 2.6.14-2-686-smp (Debian 2.6.14-7) ([EMAIL PROTECTED]) (gcc version 4.0.3 20051201 (prerelease) (Debian 4.0.2-5)) #1 SMP Wed Dec 28 18:47:53 UTC 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 0010 - 4feaa000 (usable) BIOS-e820: 4feaa000 - 5000 (reserved) BIOS-e820: fec1 - fec2 (reserved) BIOS-e820: feda - fee0 (reserved) BIOS-e820: ffb0 - 0001 (reserved) 382MB HIGHMEM available. 896MB LOWMEM available. On node 0 totalpages: 327338 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 225280 pages, LIFO batch:31 HighMem zone: 97962 pages, LIFO batch:31 DMI 2.3 present. ACPI: RSDP (v000 DELL ) @ 0x000fdf00 ACPI: RSDT (v001 DELLCPi R 0x27d4070e ASL 0x0061) @ 0x4fef ACPI: FADT (v001 DELLCPi R 0x27d4070e ASL 0x0061) @ 0x4fef0400 ACPI: DSDT (v001 INT430 SYSFexxx 0x1001 MSFT 0x010e) @ 0x ACPI: PM-Timer IO Port: 0x808 Allocating PCI resources starting at 6000 (gap: 5000:aec1) Built 1 zonelists Kernel command line: root=/dev/hda3 ro Local APIC disabled by BIOS -- you can enable it with lapic mapped APIC to d000 (01a42000) Initializing CPU#0 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 1399.266 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1292776k/1309352k available (1960k kernel code, 15416k reserved, 541k data, 212k init, 391848k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 2799.09 BogoMIPS (lpj=1399548) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 CPU: After generic identify, caps: a7e9f9bf 0180 CPU: After vendor identify, caps: a7e9f9bf 0180 CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 1024K CPU: After all inits, caps: a7e9f9bf 0040 0180 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. mtrr: v2.0 (20020519) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. ACPI: setting ELCR to 0200 (from 0800) CPU0: Intel(R) Pentium(R) M processor 1400MHz stepping 05 SMP motherboard not detected. Local APIC not detected. Using dummy APIC emulation. Brought up 1 CPUs checking if image is initramfs... it is softlockup thread 0 started up. Freeing initrd memory: 1068k freed NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xfc96e, last bus=1 PCI: Using configuration type 1 ACPI: Subsystem revision 20050902 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) ACPI: Assume root bridge [\_SB_.PCI0] bus is 0 Boot video device is :00:02.0 PCI quirk: region 0800-087f claimed by ICH4 ACPI/GPIO/TCO PCI quirk: region 0880-08bf claimed by ICH4 GPIO PCI: Ignoring BAR0-3 of IDE controller :00:1f.1 PCI: Transparent bridge - :00:1e.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 9 10 *11) ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7) *11 ACPI: PCI Interrupt Link [LNKC] (IRQs 9 10 *11) ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 9 10 *11) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIE._PRT] Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 13 devices PnPBIOS: Disabled by ACPI PNP PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try pci=routeirq. If it helps, post a report pnp: 00:01: ioport range 0x4d0-0x4d1 has been reserved pnp: 00:01: ioport range 0x800-0x805 could not be reserved pnp: 00:01: ioport range 0x808-0x80f could not be reserved pnp: 00:02: ioport range 0xf400-0xf4fe
Bug#345725: via ide dma not enabled
On Tue, Jan 03, 2006 at 08:23:32PM +0800, zzz haha wrote: This is probably the now infamous ide-generic bug. what version of yaird or initramfs-tools did you try ? yaird ver. 0.0.12-3. but my self-compiled kernel does not use initrd. ah, so the bug is your own fault :) Please try the upcoming 2.6.15 kernels which will be uploaded hopefully today. i will when it's available thru apt-get. Tomorrow hoepfully. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345725: via ide dma not enabled
yaird ver. 0.0.12-3. but my self-compiled kernel does not use initrd. ah, so the bug is your own fault :) ? my own kernel (no initrd) has dma enabled. the debian default one cannot let me enable dma. you mean that this version of yaird has error? to be safer, i compiled the relevant ide driver directly into the kernel. and i notice that the debian default kernel compiled the driver as module. but as viewed from lsmod, i think i've the relevant driver loaded.
Bug#345725: via ide dma not enabled
On Tue, Jan 03, 2006 at 08:53:40PM +0800, zzz haha wrote: yaird ver. 0.0.12-3. but my self-compiled kernel does not use initrd. ah, so the bug is your own fault :) ? my own kernel (no initrd) has dma enabled. the debian default one cannot let me enable dma. The debian default one is an initrd kernel, and this seems to be a bug in the interaction of the via ide driver and ide-generic. you mean that this version of yaird has error? Not sure, it should fix this issue, but if you still see it, then the fix is bogus. can you check if ide-generic is loaded before or after via-ide. And indeed, please file a bug against yaird about this, jonas and erik would like to know about this. to be safer, i compiled the relevant ide driver directly into the kernel. and i notice that the debian default kernel compiled the driver as module. but as viewed from lsmod, i think i've the relevant driver loaded. Indeed. The problem is ide-generic. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345725: via ide dma not enabled
On Tue, Jan 03, 2006 at 08:53:40PM +0800, zzz haha wrote: yaird ver. 0.0.12-3. but my self-compiled kernel does not use initrd. ah, so the bug is your own fault :) ? my own kernel (no initrd) has dma enabled. the debian default one cannot let me enable dma. you mean that this version of yaird has error? to be safer, i compiled the relevant ide driver directly into the kernel. and i notice that the debian default kernel compiled the driver as module. but as viewed from lsmod, i think i've the relevant driver loaded. try initramfs-tools - curious if there your dma is on? -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345725: via ide dma not enabled
On Tue, Jan 03, 2006 at 02:29:29PM +0100, Maximilian Attems wrote: On Tue, Jan 03, 2006 at 08:53:40PM +0800, zzz haha wrote: yaird ver. 0.0.12-3. but my self-compiled kernel does not use initrd. ah, so the bug is your own fault :) ? my own kernel (no initrd) has dma enabled. the debian default one cannot let me enable dma. you mean that this version of yaird has error? to be safer, i compiled the relevant ide driver directly into the kernel. and i notice that the debian default kernel compiled the driver as module. but as viewed from lsmod, i think i've the relevant driver loaded. try initramfs-tools - curious if there your dma is on? It should have been fixed both way. Still i believe this is a kernel bug. Normally, you should be able to drive that controller with only the via-dide driver, and not even try to load ide-generic as it seems to be done here. What does initramfs-tools try to do about this ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processing of linux-2.6_2.6.15-1_i386.changes
linux-2.6_2.6.15-1_i386.changes uploaded successfully to localhost along with the files: linux-2.6_2.6.15-1.dsc linux-2.6_2.6.15.orig.tar.gz linux-2.6_2.6.15-1.diff.gz linux-manual-2.6.15_2.6.15-1_all.deb linux-patch-debian-2.6.15_2.6.15-1_all.deb linux-source-2.6.15_2.6.15-1_all.deb linux-tree-2.6.15_2.6.15-1_all.deb linux-headers-2.6.15_2.6.15-1_i386.deb linux-headers-2.6.15-1_2.6.15-1_i386.deb linux-headers-2.6.15-1-486_2.6.15-1_i386.deb linux-image-2.6.15-1-486_2.6.15-1_i386.deb linux-image-486_2.6.15-1_i386.deb linux-image-2.6-486_2.6.15-1_i386.deb linux-headers-2.6-486_2.6.15-1_i386.deb linux-headers-2.6.15-1-686_2.6.15-1_i386.deb linux-image-2.6.15-1-686_2.6.15-1_i386.deb linux-image-686_2.6.15-1_i386.deb linux-image-2.6-686_2.6.15-1_i386.deb linux-headers-2.6-686_2.6.15-1_i386.deb linux-headers-2.6.15-1-686-smp_2.6.15-1_i386.deb linux-image-2.6.15-1-686-smp_2.6.15-1_i386.deb linux-image-686-smp_2.6.15-1_i386.deb linux-image-2.6-686-smp_2.6.15-1_i386.deb linux-headers-2.6-686-smp_2.6.15-1_i386.deb linux-headers-2.6.15-1-k7_2.6.15-1_i386.deb linux-image-2.6.15-1-k7_2.6.15-1_i386.deb linux-image-k7_2.6.15-1_i386.deb linux-image-2.6-k7_2.6.15-1_i386.deb linux-headers-2.6-k7_2.6.15-1_i386.deb linux-headers-2.6.15-1-k7-smp_2.6.15-1_i386.deb linux-image-2.6.15-1-k7-smp_2.6.15-1_i386.deb linux-image-k7-smp_2.6.15-1_i386.deb linux-image-2.6-k7-smp_2.6.15-1_i386.deb linux-headers-2.6-k7-smp_2.6.15-1_i386.deb kernel-image-2.6-486_2.6.15-1_i386.deb kernel-image-2.6-686_2.6.15-1_i386.deb kernel-image-2.6-686-smp_2.6.15-1_i386.deb kernel-image-2.6-k7_2.6.15-1_i386.deb kernel-image-2.6-k7-smp_2.6.15-1_i386.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343092: This bug should be fixed with both 2.6.14-7 and upcoming 2.6.15-1, ...
Hi Jean-Marc, Can you please confirm that this issue should be closed, so that we can close the bug report ? Jurij said the bug was fixed in k-p 10.018, and both 2.6.14-7 and 2.6.15-1 where built with a more recent version of it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
remaining linux-2.6 RC bugs ...
Hi, ... I have been looking at the remaining linux-2.6 RC bug, in the wake of the 2.6.15 release. There are 7 RC bugs remaining now : #337493: linux-2.6 2.6.14 should not move to testing unexpectedly. #343260: Grub: After installing linux-image-2.6.14-2-k7 grub had wrong entries #343443: linux-image-2.6.14-2-k7: Doesn't boot: /sys/block/hde/dev not found #343686: debsums: checksums mismatch + bug #343048 again #344515: kernel module ip2100 crashes when loading firmware on amd64-system #343092: linux-image configuration fails #343934: kernel-2.6: FTBFS on mips/experimental Of these, #337493 ius artificial and can be closed anytime, #343260 is a kernel-package/grub bug, #343443 and #343092 are the same yaird bug, #343686 is a kernel-package issue, and #343934 is ths's fault. Of these only #344515 is remotely a kernel issue, and it is probably due to the ip2100 (non-free?) firmware being 32bit only or whatever, and affects only amd64. There will probably be a slew of new bugs for 2.6.15, but provided the above are moved to the right packages, and their maintainers take things in hand, there is not anything especially worrysome remaining. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: remaining linux-2.6 RC bugs ...
severity 343934 important retitle 343934 please support mips thanks * Sven Luther [EMAIL PROTECTED] [2006-01-03 15:24]: #343934: kernel-2.6: FTBFS on mips/experimental Of these, #337493 ius artificial and can be closed anytime, #343260 is a kernel-package/grub bug, #343443 and #343092 are the same yaird bug, #343686 is a kernel-package issue, and #343934 is ths's fault. This is not RC anyway given that it has never built on mips. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: remaining linux-2.6 RC bugs ...
On Tue, Jan 03, 2006 at 03:31:16PM +0100, Martin Michlmayr wrote: severity 343934 important retitle 343934 please support mips thanks * Sven Luther [EMAIL PROTECTED] [2006-01-03 15:24]: #343934: kernel-2.6: FTBFS on mips/experimental Of these, #337493 ius artificial and can be closed anytime, #343260 is a kernel-package/grub bug, #343443 and #343092 are the same yaird bug, #343686 is a kernel-package issue, and #343934 is ths's fault. This is not RC anyway given that it has never built on mips. the fact that the mips/mipsel guys do their own thing in their own way is i believe etch-RC though, and need to be solved in the next 6 month. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345797: linux-2.6: patch for powerbook fn-key
Package: linux-2.6 Severity: wishlist The fn-key on apple powerbook g4 doesnt work from scratch on linux 2.6. There is a patch at: https://hansmi.home.forkbomb.ch/public/usbhid-hook-try6.diff Which enables the fn-key. It sends directly the right events from the keyboard (for example PageUp from Fn+Up). It would be great to have it included in debian kernels. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343092: linux-image configuration fails
reopen 343092 reassign 343092 grub stop grub needs to be debconfied to allow latest linux-images to install. at least update-grub needs to write to stderr. better control would use the debconf ENV var to check context. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329284: linux-2.6: Failed to bring up eth1.
please try against lastest 2.6.14 in unstable, tomorrow 2.6.15 should be available. is the bug still reproducible? -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311412: Bug #311412: still present in later kernels ?
Hello, Can you please check if 2.6.12 (etch), 2.6.14 (sid) or 2.6.15 (sid tomorrow evening) fix this bug (radeon oops on system halt), since there where numerous radeonfb changes since the 2.6.11 kernel this was against and i have no such problem on my powerbook which uses a similar radeon chip i think. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317581: kernel-image-2.6.11-1-k7: kernel oops while reading udf disk
On Sat, Jul 09, 2005 at 11:20:02PM +0200, Adam Szojda wrote: Kernel oops while reading UDF formated DVD+RW disk. Tested on two disks: one formated and burned with InCD on Windows and the other with linux udftools... Both mounted standard way: mount -t udf /dev/hdc /tmp/1 pktcdvd module wasn't loaded. After oops drive is busy - cannot umount and drive led is on. Could you please retest this with a current linux image? 2.6.15 will enter unstable tomorrow. If this still isn't fixed, it'd be worthwhile to poke upstream (http://bugzilla.kernel.org/) Thanks for your time and work, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317798: kernel-image-2.6.11-1-686-smp: nfs locking can cause a process to hang forever
On Mon, Jul 11, 2005 at 03:09:04PM -0400, Marc Horowitz wrote: maximilian attems [EMAIL PROTECTED] writes: On Mon, 11 Jul 2005, Marc Horowitz wrote: can you try out if newer 2.6.12 fixed that nfs issue? http://charm.itp.tuwien.ac.at/~mattems/ from the client side, but i guess you better update your server side. I can't update the server side trivially, since it's a production fileserver. from nfs(5): soft If an NFS file operation has a major timeout then report an I/O error to the calling program. The default is to continue retrying NFS file operations indefinitely. So this seems to be a case of feature, not bug. It'd be great if you could test this with a soft-mount too. Regards, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317798: kernel-image-2.6.11-1-686-smp: nfs locking can cause a process to hang forever
David Schmitt [EMAIL PROTECTED] writes: from nfs(5): soft If an NFS file operation has a major timeout then report an I/O error to the calling program. The default is to continue retrying NFS file operations indefinitely. So this seems to be a case of feature, not bug. It'd be great if you could test this with a soft-mount too. I set the mount on the client to soft, but the hang isn't happening with a hard mount right now. If I see the problem again, I'll experiment some more and report back. Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344205: linux-source-2.6.14: drivers/net/wireless/airo.c fails to compile
reassign 344205 linux-source-2.6.15 thanks Roland Mas, 2005-12-20 22:19:44 +0100 : Trying to build my kernel from the linux-source-2.6.14 package (and no external patches), I get an error in drivers/net/wireless/airo.c. Same happens with linux-source-2.6.15_2.6.15-1, so I'm reassigning. I'm tempted to upgrade to important, too. Debian kernel images (at least up to 2.6.14) don't provide Longrun power management on my Crusoe laptop. So I'm stuck with 2.6.12 (the last version that I managed to build), which makes the boot process horribly long (udev takes almost two minutes to do its job before the computer can do anything useful). Roland. -- Roland Mas 'And what would humans be without love?' RARE, said Death. -- in Sourcery (Terry Pratchett) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote: N-117 = Mon 30 Jul 06: freeze essential toolchain, kernels Why do you put the kernel together with the essential toolchain freeze, it should be together with the rest of base, i believe. N-110 = Mon 7 Aug 06: freeze base, non-essential toolchain (including e.g. cdbs) N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. So, we will be asking the question about the upgradability of the kernel later during this release process, and i believe that it is not something which should be ignored. Already you are considering upgrading the sarge kernel which has some trouble booting on a rather non-negligible quantity of hardware, so having a two version outdated kernel at release time is not nice. Already it should be possible, provided the d-i guys get their act together, to have a new d-i .udeb sets within 48 hours or less of a new upstream kernel release, altough the image build may take longer, and we hope to get the external modules and patches streamlined by then. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323136: acknowledged by developer (Re: Bug#323136: linux-2.6: patch from 2.6.13)
I'm unable to test the fix... But it should be fine. Thanks. Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report #323136: linux-kernel-2.6.12-k7: module dc395x causes kernel panic, which was filed against the linux-2.6 package. It has been closed by one of the developers, namely David Schmitt [EMAIL PROTECTED]. Their explanation is attached below. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact the developer, by replying to this email. Debian bug tracking system administrator (administrator, Debian Bugs database) Received: (at 323136-done) by bugs.debian.org; 3 Jan 2006 20:31:39 + From [EMAIL PROTECTED] Tue Jan 03 12:31:39 2006 Return-path: [EMAIL PROTECTED] Received: from [217.19.46.22] (helo=rerun.lefant.net) by spohr.debian.org with esmtp (Exim 4.50) id 1Etsol-0004Y1-B1 for [EMAIL PROTECTED]; Tue, 03 Jan 2006 12:31:39 -0800 Received: from david by rerun.lefant.net with local (Exim 4.50) id 1Etsok-0006wh-5F for [EMAIL PROTECTED]; Tue, 03 Jan 2006 21:31:38 +0100 Date: Tue, 3 Jan 2006 21:31:38 +0100 From: David Schmitt [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Bug#323136: linux-2.6: patch from 2.6.13 Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: [EMAIL PROTECTED] Organization: EDV-BeratungService -- http://www.edv-bus.at User-Agent: Mutt/1.5.9i X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER autolearn=no version=2.60-bugs.debian.org_2005_01_02 Version: 2.6.14-2 On Sat, Nov 12, 2005 at 11:05:15AM +0200, Lior Kaplan wrote: Jurij Smakov wrote: Could you give 2.6.14-2 (currently in unstable) a try? All the fixes mentioned in the bug trail should be included in it. I don't have the hardware any more, but I'll try to figure out how to test this. Since you haven't answered in a long time, I assume that either your problem was fixed or you arn't able to test it anymore. Anyways, since all patches were applied I close the bug. Regards, David -- Lior Kaplan [EMAIL PROTECTED] http://www.Guides.co.il Debian GNU/Linux unstable (SID) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
Hi, thanks for your mail. I just want to point out that we published the timeline already back in October, but of course, that shouldn't refrain us from changing it if this is necessary. :) [re-arranged the quote] * Sven Luther ([EMAIL PROTECTED]) [060103 22:03]: On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote: N-117 = Mon 30 Jul 06: freeze essential toolchain, kernels N-110 = Mon 7 Aug 06: freeze base, non-essential toolchain (including e.g. cdbs) Why do you put the kernel together with the essential toolchain freeze, it should be together with the rest of base, i believe. Hm, I'm quite sure we had some good reason for this; however, I cannot really remember why we put the kernel to the essential tool chain. On the other hand side, the difference is only one week - and if nothing is broken by that, we can freeze the kernel at N-110 also. N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. Well, if we want to release with a newer kernel, we need to make sure d-i doesn't stumble over it. Experience tells us that there are enough last-minutes changes to the installer that we cannot avoid to better not change the kernel; if the installer team (i.e. Joey Hess or Frans Pop) tell us otherwise, we can of course adjust our plannings. However, there will be a minimum periode where we just need to freeze everything to get enough testing to the proposed release. Also, the kernel will be outdated sooner or later anyways - so, if after one year the kernel is 12 or 14 months old is not too much a difference. So, we will be asking the question about the upgradability of the kernel later during this release process, and i believe that it is not something which should be ignored. Well, we as release team first believe what is told us by the relevant maintainers. Our current status is that kernel upgrades late in the release process (especially after the d-i RC) are rather painfull. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On 1/3/06, Sven Luther [EMAIL PROTECTED] wrote: Why do you put the kernel together with the essential toolchain freeze, it should be together with the rest of base, i believe. [...] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. So, we will be asking the question about the upgradability of the kernel later during this release process, and i believe that it is not something which should be ignored. Already you are considering upgrading the sarge kernel which has some trouble booting on a rather non-negligible quantity of hardware, so having a two version outdated kernel at release time is not nice. I really don't think that having a four months out-dated kernel is that bad. What is really important is to have stable kernels. Past experience with the modified 2.6 release policy has shown that some 2.6 kernels are pretty stable and some others are quite crappy. So, I'd say it's better to give some time to be sure that the kernel that is shipping with Debian's stable distribution is really a stable kernel, and not a crappy one. I don't think you can tell the difference before this version of the kernel reaches a big number of people, and therefore, it does need time (frozen, in testing). However, if while preparing the release, the frozen kernel would show up as being a crappy one, the release managers might allow for a new kernel to enter testing. But this is only a hypothetical case, and I expect it would be carefully evaluated before it actually happened. -- Besos, Marga
Re: bits from the release team
On Tue, Jan 03, 2006 at 10:02:05PM +0100, Sven Luther wrote: On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote: N-117 = Mon 30 Jul 06: freeze essential toolchain, kernels Why do you put the kernel together with the essential toolchain freeze, it should be together with the rest of base, i believe. the kernel is an essential piece of our release, makes sense to have it in tune with everchanging userspace interfaces (alsa, udev to name a few). N-110 = Mon 7 Aug 06: freeze base, non-essential toolchain (including e.g. cdbs) N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. we had the chance for sarge, but we weren't ready. for etch we will work for our best to be ready. please don't rush out such mails without consensual position. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333831: Combination of irqpoll and routeirq doesn't fix reboots entirely
On Sun, Nov 13, 2005 at 03:50:31PM +, Simon Waters wrote: Seems this combination makes reboots less likely/predictable, but it is yet to finish an entire CD. Hi Simon! Could you please retest this with a current linux image? 2.6.15 will enter unstable tomorrow. If this still isn't fixed, it'd be worthwhile to poke upstream (http://bugzilla.kernel.org/) and point them to the logs here. Please include the output of lsmod lspci lspci -n dmesg Thanks for your time and work, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, Jan 03, 2006 at 10:31:38PM +0100, Andreas Barth wrote: Hi, thanks for your mail. I just want to point out that we published the timeline already back in October, but of course, that shouldn't refrain us from changing it if this is necessary. :) Yeah, i was already chidded (?) that my mail was too inflamatory, this was not the intention, altough i wrote it such to get some reaction upto a point :) [re-arranged the quote] * Sven Luther ([EMAIL PROTECTED]) [060103 22:03]: On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote: N-117 = Mon 30 Jul 06: freeze essential toolchain, kernels N-110 = Mon 7 Aug 06: freeze base, non-essential toolchain (including e.g. cdbs) Why do you put the kernel together with the essential toolchain freeze, it should be together with the rest of base, i believe. Hm, I'm quite sure we had some good reason for this; however, I cannot really remember why we put the kernel to the essential tool chain. On :) the other hand side, the difference is only one week - and if nothing is broken by that, we can freeze the kernel at N-110 also. i think comparing the kernel with the toolchain is overkill, if nothing else a last minute change in the toolchain will need a kernel recompile anyway maybe. I do confess that i read June 30 at first, and this seemed much less acceptable to me. N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. Well, if we want to release with a newer kernel, we need to make sure d-i doesn't stumble over it. Experience tells us that there are enough What experience ? There is no way of common measure between todays situation and what happened in the pre-sarge timeframe, and we (i, but some of the kernel team at least agreed with that) fully expect to get things working out nicely well before the release date, so that there would be a much reduced impact from the kernel upload on the d-i build schedule. Remember i proposed the common infrastructure already in marsh/april last year, but was voted done for the sarge release on it (with some no-kind words even). The main issue will be one of testing the kernel and d-i built with it, but there should be no technical hurdles which would cause month-long delays. last-minutes changes to the installer that we cannot avoid to better not change the kernel; if the installer team (i.e. Joey Hess or Frans Pop) tell us otherwise, we can of course adjust our plannings. However, there will be a minimum periode where we just need to freeze everything to get enough testing to the proposed release. Indeed. The d-i team usually says no outright to any kind of proposal of this kind, so it is up to the kernel team to come up with an implementation which convinces them :) The release team deserves to be informed about the possibility though. Also, the kernel will be outdated sooner or later anyways - so, if after one year the kernel is 12 or 14 months old is not too much a difference. Hehe, me runs sid kernels installed almost as is on all my sarge systems indeed, just with rebuild yaird and mininmally backported udev. But still, it is an image issue, and i believe the kernel team would be more happy if the obsolet the day it comes out stigma debian has had in the past doesn't touch us. Also, you will pay in maintenance cost for those few month difference during all the etch livetime, guess who will be ending doing this work ? So, we will be asking the question about the upgradability of the kernel later during this release process, and i believe that it is not something which should be ignored. Well, we as release team first believe what is told us by the relevant maintainers. Our current status is that kernel upgrades late in the release process (especially after the d-i RC) are rather painfull. Indeed, but you have only the sarge experience to go by, and taking the sarge experience on this is hardly fair to the huge amount the kernel team has devoted to streamline the process. Also, i don't really believe joeyh and fjp are really the relevant maintainers with regard to the debian kernel and its application, since they lack the vision of how things could go better, or more thruthfully, probably lack the time and motivation to think really about the issue, and why should they, it is the kernel team jobs :) d-i is only a part of the problem anyway, and i believe the less problematic. out-of-tree modules and third-party patches are a worse mess. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
(forgot to CC d-kernel on this) On Tuesday 03 January 2006 22:02, Sven Luther wrote: We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. 2.6.8 is not an optimal kernel, but largely due to timing (i.e. SATA just starting to get implemented). I remember we did consider using 2.6.10 instead of 2.6.8 and decided not to mainly because it was not really that much better than 2.6.8. As I remember it, this was a joint decision by the kernel team, release managers and the d-i developers. Not something that the kernel team were really pushing and was blocked by some assholes from the d-i team who did not want to cooperate. The first kernel after 2.6.8 that was a real improvement was 2.6.12 and that was released definitely too late for Sarge. Already it should be possible, provided the d-i guys get their act together, to have a new d-i .udeb sets within 48 hours or less of a new upstream kernel release, altough the image build may take longer, and we hope to get the external modules and patches streamlined by then. This is an extremely bad way to get friendly cooperation and discussion about changing anything. Producing new udebs for all architectures for d-i can be done quite fast, as evidenced by the recent uploads for 2.6.14, provided the porters taking care of the udebs for their architecture . I expect little problems or delay for 2.6.15. As I remember it, the update from 2.6.8 to 2.6.12 was done quite fast for i386. Yes, we did wait a while before updating to 2.6.14, but that was mainly because d-i itself first had to prepare its userland for the removal of devfs. So please, get off your hobbyhorse and stop pissing people off with unfounded statements. pgpqdiSs8RCu9.pgp Description: PGP signature
Re: bits from the release team
On Tue, Jan 03, 2006 at 10:32:12PM +0100, Maximilian Attems wrote: On Tue, Jan 03, 2006 at 10:02:05PM +0100, Sven Luther wrote: On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote: N-117 = Mon 30 Jul 06: freeze essential toolchain, kernels Why do you put the kernel together with the essential toolchain freeze, it should be together with the rest of base, i believe. the kernel is an essential piece of our release, makes sense to have it in tune with everchanging userspace interfaces (alsa, udev to name a few). Indeed, that is why it is part of base, but putting it in comparison with the toolchain (glibc, gcc, etc) is overkill. N-110 = Mon 7 Aug 06: freeze base, non-essential toolchain (including e.g. cdbs) N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. we had the chance for sarge, but we weren't ready. Due in big part to the messed up kernel situation we inherited from in sarge, remember i proposed delaying sarge to get the unified kernel infrastructure :) for etch we will work for our best to be ready. indeed. please don't rush out such mails without consensual position. like bow and smile and wait forever ? This is not i believe the debian way of handling things, and i am certainly not the only one taking this kind of approach, and much more involved and whatever DDs than me have done it like that, so ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, Jan 03, 2006 at 11:01:03PM +0100, Frans Pop wrote: (forgot to CC d-kernel on this) On Tuesday 03 January 2006 22:02, Sven Luther wrote: We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. 2.6.8 is not an optimal kernel, but largely due to timing (i.e. SATA just starting to get implemented). I remember we did consider using 2.6.10 instead of 2.6.8 and decided not to mainly because it was not really that much better than 2.6.8. As I remember it, this was a joint decision by the kernel team, release managers and the d-i developers. Not something that the kernel team were really pushing and was blocked by some assholes from the d-i team who did not want to cooperate. Well, i remember joeyh vetoing it because it would take at least a month to get the change done, and i believe we didn't really push for it because the infrastructure was a mess back then. This has changed. The one point that put me up, is that we should have gotten that security update in, but this was also vetoed for the same month-long delay in the kernel/d-i upgrade process. The kernel team has reduced that delay to less than 24hours now for the release arches, but there is still work to be done on the d-i side of it, and more specifically with the module .udebs, which could be uploaded quickly, but rely on the porters doing very unfriendly drudge work. My believe is that this kind of thing should be as much automated as possible, to let the few ressource we have be used where best it should, a little work at the start which will pay off forever after, this is what computers and programming is for, to make the task of the users and programmers easier, i think we all agree with that, or we would still be using boot-floppies :) The first kernel after 2.6.8 that was a real improvement was 2.6.12 and that was released definitely too late for Sarge. Agreed, the issue is the common infrastrucure, and the cost the previous situation has, and the repercusion of this cost on stable-security. Already it should be possible, provided the d-i guys get their act together, to have a new d-i .udeb sets within 48 hours or less of a new upstream kernel release, altough the image build may take longer, and we hope to get the external modules and patches streamlined by then. This is an extremely bad way to get friendly cooperation and discussion about changing anything. :) Well, we could have released 2.6.15 with .udeb modules included, which would have been less friendly even. Producing new udebs for all architectures for d-i can be done quite fast, It could, joeyh even told me it could be easily automated, and Kamion mentioned me he is already doing part of what is needed for that automation (namely building module .udebs without installing the kernel images), but upto now it is still a pain, and takes over a week or two to get done, this was the case for both 2.6.12, and 2.6.14, and why is that ? Because the porters are slackers is not really the right reply to this. as evidenced by the recent uploads for 2.6.14, provided the porters taking care of the udebs for their architecture . I expect little problems or delay for 2.6.15. Indeed, and this is the crux of the problem, you put all the responsability on the porters, while there is really no porter work needed at all. it is only the nature of the non-unified package that the mainstream arch gets build quickly, and the non-mainstream arches get bit-rotten until there is an urgency and the porters get kicked. This is the process problem we are facing, and i think we can solve in a way satisfactory to the d-i team. My plan is to come up with something for the 2.6.16 timeframe, which you can then review, and if it works out well, be used shortly afterward. Etch should release with 2.6.18 i believe, with the current timeframe, so we have two versions afterward to sort things out. As I remember it, the update from 2.6.8 to 2.6.12 was done quite fast for i386. And exactly this is the bug, and not the feature, it did happen quite fast for i386, but nobody cared about the other arches, like before the i386 kernel came out quite fast, but other arches came out with a more or less longer delay. Compare with same day upload on 9 of the 12 main debian arches ? Yes, we did wait a while before updating to 2.6.14, but that was mainly because d-i itself first had to prepare its userland for the removal of devfs. The 2.6.12 to 2.6.14 upgrade was indeed very very painful because of the devfs removal and thus initrd-tools replacement, i am well placed to know about that. So please, get off your hobbyhorse and stop pissing people off with unfounded statements. He, so, there is no problem, and the situation is perfect, and you prefer to hide and shoot the messenger :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with
Re: bits from the release team
On Tue, Jan 03, 2006 at 06:26:02PM -0300, Margarita Manterola wrote: On 1/3/06, Sven Luther [EMAIL PROTECTED] wrote: Why do you put the kernel together with the essential toolchain freeze, it should be together with the rest of base, i believe. [...] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. So, we will be asking the question about the upgradability of the kernel later during this release process, and i believe that it is not something which should be ignored. Already you are considering upgrading the sarge kernel which has some trouble booting on a rather non-negligible quantity of hardware, so having a two version outdated kernel at release time is not nice. I really don't think that having a four months out-dated kernel is that bad. What is really important is to have stable kernels. Past experience with the modified 2.6 release policy has shown that some 2.6 kernels are pretty stable and some others are quite crappy. Indeed, but that would be something the kernel team is best placed to decide, and if a given unstable kernel is crappy, we won't allow it in testing, its that simple. So, I'd say it's better to give some time to be sure that the kernel that is shipping with Debian's stable distribution is really a stable kernel, and not a crappy one. I don't think you can tell the difference before this version of the kernel reaches a big number of people, and therefore, it does need time (frozen, in testing). Indeed, unstable is such a place, but is 4 month too much of a time to find out, and would a month or two be enough, i do believe this. However, if while preparing the release, the frozen kernel would show up as being a crappy one, the release managers might allow for a new kernel to enter testing. But this is only a hypothetical case, and I expect it would be carefully evaluated before it actually happened. The crappy kernel would never enter testing in the first place, as testing has always been done on unstable. See 2.6.14 is out for over 2 month now, and it didn't reach testing, and never will now that 2.6.15 is out, because the devfs/initrd-tool situation, and this was the right thing to do. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tuesday 03 January 2006 23:01, Sven Luther wrote: Indeed. The d-i team usually says no outright to any kind of proposal of this kind, so it is up to the kernel team to come up with an implementation which convinces them :) Bullshit. We (d-i team, mainly Joey) gave very good reasons why we thought the proposal was not good and would result in more problems than it solved. That you choose to structurally ignore the opinions, comments and objections by others who are a lot more knowledgeable about the _other_ area in Debian impacted by the proposal is typical. Your half-baked proposals may look good from a kernel maintenance viewpoint, but in our opinion they have a negative impact on the d-i side of the equation. Rejecting a badly thought out proposal is _not_ the same as saying no outright. I'm not going to repeat the arguments here. They can be found in the archives. Your attitude does nothing to motivate me to work on this. pgp7K3qzGswtd.pgp Description: PGP signature
Bug#317581: kernel-image-2.6.11-1-k7: kernel oops while reading udf disk
On Tue, Jan 03, 2006 at 08:09:45PM +0100, David Schmitt wrote: Could you please retest this with a current linux image? I'm on self built kernel-image-2.6.14 and everything seems OK. (Same burner but different, freshly formated disc...) 2.6.15 will enter unstable tomorrow. Hmm... I wanted to wait a few days before upgrading to 2.6.15, it's a huge six-meg patch, but ok I'll test that package as soon as it will be available on ftp.pl.debian.org. A. -- Kobieta na Nowy Rok! http://link.interia.pl/f18ec -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321403: 8139too network driver won't work with my card (it did with 2.6.8)
Hi, 2006-01-03, k keltezéssel 22.16-kor Christian Aichinger ezt írta: could you try out that bios workaround: http://www.ussg.iu.edu/hypermail/linux/kernel/0403.1/1537.html did you have time to test it? Did it work out? To quote a former letter of mine: Forwarded message -- From: Csillag Kristof [EMAIL PROTECTED] To: maximilian attems [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: Bug#321403: 8139too network driver won't work with my card (it did with 2.6.8) Date: Tue, 23 Aug 2005 18:19:34 +0200 2005-08-21, v keltezéssel 12.12-kor maximilian attems ezt írta: urrgs, but that seem to match upstream bugs thread. could you try out that bios workaround: http://www.ussg.iu.edu/hypermail/linux/kernel/0403.1/1537.html That won't work, since there is no such setting in my bios. Kristof - According to the kernel.org bugtracker this problem seems to be related to a broken DSDT table supplied by the BIOS, and there doesn't seem to be a simple generic way to work around this in the Linux kernel. But then why do older kernel versions (up to 2.6.8) work ok? So I'm closing this bug now, if the problem persists and you think there's a way for Linux to detect the broken BIOS and work around it, feel free to reopen the bug. I am sad to hear it, but since I don't have enough time to dig into this right now, I have no other option but to accept this, and keep going on using the box with ACPI=off. Best wishes: Kristof Csillag -- Csillag Kristof [EMAIL PROTECTED] SZTAKI/DSD
Re: bits from the release team
On Tue, Jan 03, 2006 at 11:33:44PM +0100, Frans Pop wrote: On Tuesday 03 January 2006 23:01, Sven Luther wrote: Indeed. The d-i team usually says no outright to any kind of proposal of this kind, so it is up to the kernel team to come up with an implementation which convinces them :) Bullshit. We (d-i team, mainly Joey) gave very good reasons why we thought the proposal was not good and would result in more problems than it solved. You did indeed give good reasons why having the one .udeb per module plan i follhardly proposed would not work. The current proposal is about simply using the same .udeb organisation and move it inside the linux-2.6 common package, which is something that works out just fine for ubuntu even, but which the current linux-2.6 common package infrastructure could also handle. The only reason i saw against this was a mail from joeyh mentioning ease of moving modules around inside .udebs, and that this would be easier under the d-i umbrella than if it is inside the kernel, and naturally the old sarge-time brokeness in the archive infrastructure, which is presumably fixed by now, or should be fixed for etch. I believe that this is indeed an argument, but which is outweighted by the benefit especially on the port situation, i believe, and the reason i come back with this times after time :) That you choose to structurally ignore the opinions, comments and objections by others who are a lot more knowledgeable about the _other_ area in Debian impacted by the proposal is typical. Yeah, i am an idiot and you know best, especially when you fail to clearly understand what i propose and chose to reject it on the basis of what you think i propose, this is probably due in part to some lacking in my communication skills, but i guess you also don't make things easy. Your half-baked proposals may look good from a kernel maintenance viewpoint, but in our opinion they have a negative impact on the d-i side of the equation. And have you added stable-security into the equation ? Your choices of back in april are in part responsible for the abysmal situation in stable-security with regard to kernels during these past months. Don't look only to save a few hours of work during the moment, in order to lose huge amounts of times (and irremediable lose of face even) later on. Rejecting a badly thought out proposal is _not_ the same as saying no outright. Yeah, but you have kept saying to me : it is a stupid idea, don't even think about it, and then you speak about badly thought out proposal ? I'm not going to repeat the arguments here. They can be found in the archives. Indeed, apart from the fact that they are the arguments against the wrong proposal :) Your attitude does nothing to motivate me to work on this. Yep, but i don't ask you to work on this, while you ask me to not work on it and keep the status quo, which is broken. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
Sven Luther wrote: Indeed. The d-i team usually says no outright to any kind of proposal of this kind, so it is up to the kernel team to come up with an implementation which convinces them :) The release team deserves to be informed about the possibility though. Cite message-ids or irc logs please. Indeed, but you have only the sarge experience to go by, and taking the sarge experience on this is hardly fair to the huge amount the kernel team has devoted to streamline the process. Also, i don't really believe joeyh and fjp are really the relevant maintainers with regard to the debian kernel and its application, since they lack the vision of how things could go better, or more thruthfully, probably lack the time and motivation to think really about the issue, and why should they, it is the kernel team jobs :) Understanding how the above paragraph could be perceived as insulting is left as an exersise for the reader. -- see shy jo signature.asc Description: Digital signature
Re: bits from the release team
Sven Luther wrote: And have you added stable-security into the equation ? Your choices of back in april are in part responsible for the abysmal situation in stable-security with regard to kernels during these past months. Pedantically speaking, fjp made no d-i release decisions last April. If you would like to blame this pendant, you'll need to be a bit more specific. -- see shy jo signature.asc Description: Digital signature
Re: bits from the release team
On Tuesday 03 January 2006 23:52, Sven Luther wrote: The current proposal is about simply using the same .udeb organisation and move it inside the linux-2.6 common package, which is something that works out just fine for ubuntu even, but which the current linux-2.6 common package infrastructure could also handle. So, when can we expect a coherent, full proposal (with overview of benefits, possible pitfalls, things that need to be worked out further, and so on) on this in a dedicated mail on a new thread to the relevant mailing lists, so we can actually comment on it instead of only seeing a rough outline mentioned every so often as part of a flame? (Without the current method sucks comments please; saying I think the current situation could be improved by... is much more likely to get positive reactions.) The only reason i saw against this was a mail from joeyh mentioning ease of moving modules around inside .udebs, and that this would be easier under the d-i umbrella than if it is inside the kernel, and naturally the old sarge-time brokeness in the archive infrastructure, which is presumably fixed by now, or should be fixed for etch. You forget the argument that when kernel udebs are maintained within d-i, we will be much more likely to spot changes in them as a possible cause of breakage when installation-reports come in. pgpCp2aRNAJTL.pgp Description: PGP signature
Re: bits from the release team
On Tue, Jan 03, 2006 at 06:09:18PM -0500, Joey Hess wrote: Sven Luther wrote: And have you added stable-security into the equation ? Your choices of back in april are in part responsible for the abysmal situation in stable-security with regard to kernels during these past months. Pedantically speaking, fjp made no d-i release decisions last April. Nope, you did, and the Your above was meant to be the d-i team. I also remember you accusing of single-handledly delaying the sarge release by a week, which was not welcome after i invested almost a week fighthing with k-p to get the 2.4 ppc kernels in a decent shape for sarge, especially as i didn't really believe into 2.4 powerpc kernels at that time. Would i have told you at the start of that week what i would have tried to do, can you honestly you would have let me do it ? But anyway, let's agree to disagree or whatever, and stop hurting each other, there will be a proposal made in the 2.6.16 timeframe, and we can then speak again about this. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Wed, Jan 04, 2006 at 12:13:37AM +0100, Frans Pop wrote: On Tuesday 03 January 2006 23:52, Sven Luther wrote: The current proposal is about simply using the same .udeb organisation and move it inside the linux-2.6 common package, which is something that works out just fine for ubuntu even, but which the current linux-2.6 common package infrastructure could also handle. So, when can we expect a coherent, full proposal (with overview of benefits, possible pitfalls, things that need to be worked out further, and so on) on this in a dedicated mail on a new thread to the relevant mailing lists, so we can actually comment on it instead of only seeing a rough outline mentioned every so often as part of a flame? The linux-2.6 package will propose a solution which will produce the *EXACT SAME* set of .udebs as with the current kernel-wedge solution, and will be more easy to maintain in a more automated way, and integrated with the rest of the linux-2.6 kernel, so porters only need to do the work once in a single integrated way. (Without the current method sucks comments please; saying I think the current situation could be improved by... is much more likely to get positive reactions.) This is not my past experience though, and the current method sucks, this is a fact, i as powerpc porter of d-i have to live with, so why should i not be allowed to express my opinion about this ? The only reason i saw against this was a mail from joeyh mentioning ease of moving modules around inside .udebs, and that this would be easier under the d-i umbrella than if it is inside the kernel, and naturally the old sarge-time brokeness in the archive infrastructure, which is presumably fixed by now, or should be fixed for etch. You forget the argument that when kernel udebs are maintained within d-i, we will be much more likely to spot changes in them as a possible cause of breakage when installation-reports come in. well, if the only thing you are afraid about is documentation, we shall provide you with this information in a way most suitable. All this can and and will be easily automated and presented upon you on a platter, which is not the case with the current kernel-wedge situation, where the i386 .udebs and kernel-wedge are updated and the rest of the ports left out in the cold without any kind of info about possible breakage already fixed on i386, thanks you very much, so two weights two measures, right ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, Jan 03, 2006 at 06:04:39PM -0500, Joey Hess wrote: Sven Luther wrote: Indeed. The d-i team usually says no outright to any kind of proposal of this kind, so it is up to the kernel team to come up with an implementation which convinces them :) The release team deserves to be informed about the possibility though. Cite message-ids or irc logs please. Such hiding in the sand, ... well i don't keep irc logs, and you can go searching for those past email posts as well as i can. Indeed, but you have only the sarge experience to go by, and taking the sarge experience on this is hardly fair to the huge amount the kernel team has devoted to streamline the process. Also, i don't really believe joeyh and fjp are really the relevant maintainers with regard to the debian kernel and its application, since they lack the vision of how things could go better, or more thruthfully, probably lack the time and motivation to think really about the issue, and why should they, it is the kernel team jobs :) Understanding how the above paragraph could be perceived as insulting is left as an exersise for the reader. Yeah, and i have mails from you which where degrees of magnitude more insulting than those, and i have still not forgiven you about the way you hurt me in april. So tone done your arrogance a bit, please. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Jan 04, Adam Heath [EMAIL PROTECTED] wrote: Not to mention that 2.6.15 requires a newer udev. Who knows what other newer things newer kernels might require. OTOH, old kernel are buggy and out of date wrt modern hardware, and we lack the manpower to backport for years fixes and new features RHEL-style. Do you have a better solution? (Other than telling people just use Ubuntu, which is what I do.) -- ciao, Marco signature.asc Description: Digital signature
Re: bits from the release team
On Tue, 3 Jan 2006, Margarita Manterola wrote: On 1/3/06, Sven Luther [EMAIL PROTECTED] wrote: Why do you put the kernel together with the essential toolchain freeze, it should be together with the rest of base, i believe. [...] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. So, we will be asking the question about the upgradability of the kernel later during this release process, and i believe that it is not something which should be ignored. Already you are considering upgrading the sarge kernel which has some trouble booting on a rather non-negligible quantity of hardware, so having a two version outdated kernel at release time is not nice. I really don't think that having a four months out-dated kernel is that bad. What is really important is to have stable kernels. Past experience with the modified 2.6 release policy has shown that some 2.6 kernels are pretty stable and some others are quite crappy. Not to mention that 2.6.15 requires a newer udev. Who knows what other newer things newer kernels might require. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345374: linux-image-2.6.14-2-686: I too have this problem
Package: linux-image-2.6.14-2-686 Version: 2.6.14-7 Followup-For: Bug #345374 I have the same problem. When piix is loaded as a module, I am unable to mess with DMA settings. However, when I compile piix statically, I can set DMA without a hitch. This issue has been discussed on debian-user, and I believe it is a kernel bug, but I feel more comfortable reporting bugs here (and I don't know how to report a kernel bug). Here's the thread on debian-user: http://lists.debian.org/debian-user/2003/12/msg00024.html Cheers. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages linux-image-2.6.14-2-686 depends on: ii module-init-tools 3.2.2-1tools for managing Linux kernel mo ii yaird [linux-initramfs-tool] 0.0.12-3 Yet Another mkInitRD Versions of packages linux-image-2.6.14-2-686 recommends: pn libc6-i686none (no description available) -- debconf information: * linux-image-2.6.14-2-686/preinst/already-running-this-2.6.14-2-686: linux-image-2.6.14-2-686/preinst/lilo-has-ramdisk: linux-image-2.6.14-2-686/postinst/create-kimage-link-2.6.14-2-686: true linux-image-2.6.14-2-686/preinst/initrd-2.6.14-2-686: linux-image-2.6.14-2-686/preinst/bootloader-initrd-2.6.14-2-686: true linux-image-2.6.14-2-686/postinst/old-system-map-link-2.6.14-2-686: true linux-image-2.6.14-2-686/preinst/failed-to-move-modules-2.6.14-2-686: linux-image-2.6.14-2-686/postinst/depmod-error-initrd-2.6.14-2-686: false linux-image-2.6.14-2-686/postinst/old-dir-initrd-link-2.6.14-2-686: true linux-image-2.6.14-2-686/preinst/elilo-initrd-2.6.14-2-686: true linux-image-2.6.14-2-686/prerm/would-invalidate-boot-loader-2.6.14-2-686: true linux-image-2.6.14-2-686/preinst/overwriting-modules-2.6.14-2-686: true linux-image-2.6.14-2-686/preinst/abort-install-2.6.14-2-686: linux-image-2.6.14-2-686/postinst/kimage-is-a-directory: linux-image-2.6.14-2-686/preinst/lilo-initrd-2.6.14-2-686: true linux-image-2.6.14-2-686/prerm/removing-running-kernel-2.6.14-2-686: true linux-image-2.6.14-2-686/postinst/depmod-error-2.6.14-2-686: false linux-image-2.6.14-2-686/postinst/bootloader-test-error-2.6.14-2-686: linux-image-2.6.14-2-686/postinst/old-initrd-link-2.6.14-2-686: true linux-image-2.6.14-2-686/postinst/bootloader-error-2.6.14-2-686: linux-image-2.6.14-2-686/preinst/abort-overwrite-2.6.14-2-686: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 4 Jan 2006 00:24:04 +0100 Sven Luther [EMAIL PROTECTED] wrote: (Without the current method sucks comments please; saying I think the current situation could be improved by... is much more likely to get positive reactions.) This is not my past experience though, and the current method sucks, this is a fact, i as powerpc porter of d-i have to live with, so why should i not be allowed to express my opinion about this ? Because your ignorance of being rude will hurt the conversation - even if your arguments are sane. Go ahead and claim that I have no right to say so due to my having a record of being rude myself. Such reaction would only prove my point here. - Jonas P.S. Please do *not* cc me as I am subscribed to d-kernel! - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDuwm8n7DbMsAkQLgRAklqAJ9Tz82+Gw7DjDid2F2cncgsjh2kswCfcZYn J8jSPC7UpM3ut3Oo/5BXkK4= =seHD -END PGP SIGNATURE-
Re: bits from the release team
[EMAIL PROTECTED] (Marco d'Itri) writes: On Jan 04, Adam Heath [EMAIL PROTECTED] wrote: Not to mention that 2.6.15 requires a newer udev. Who knows what other newer things newer kernels might require. OTOH, old kernel are buggy and out of date wrt modern hardware, and we lack the manpower to backport for years fixes and new features RHEL-style. Do you have a better solution? Why don't we use RHEL's kernel, or collaborate with them to maintain a stable kernel tree, or something? -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, Jan 03, 2006 at 05:28:15PM -0600, Adam Heath wrote: Not to mention that 2.6.15 requires a newer udev. Who knows what other newer things newer kernels might require. Notice that Linus recently expressed on LKML that udev and other userland breakage on kernel upgrade is not to acceptable, so this would be a bug to be fixed. But yes, udev is the problematic case, altough i run 2.6.14 with sarge udev and it works. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, Jan 03, 2006 at 06:43:28PM -0500, Brian Nelson wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Jan 04, Adam Heath [EMAIL PROTECTED] wrote: Not to mention that 2.6.15 requires a newer udev. Who knows what other newer things newer kernels might require. OTOH, old kernel are buggy and out of date wrt modern hardware, and we lack the manpower to backport for years fixes and new features RHEL-style. Do you have a better solution? Why don't we use RHEL's kernel, or collaborate with them to maintain a stable kernel tree, or something? Why doesn't debian really collaborate with ubuntu on the kernels, which would be more natural. Debian use mostly the mainline upstream kernels, which is where everything goes back in anyway, so ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#281912: udev: Fails to re-created FireWire CDROM device node after reconnecting: Still Present in 2.6.10
Hi David! On Monday 02 January 2006 21:24, David Schmitt wrote: Dear Georg! Could you please retest with a current kernel (testing:2.6.12, unstable:2.6.14) and a current udev (= 0.076). Using initramfs-tools for creating the initrd is probably a good idea too. Unfortunately, I don't have the hardware available for testing anymore and thus can't tell whether the bug still exists in current kernels. I'm sorry. Nevertheless, thank you very much for spending time on this issue. Regards, Georg -- Georg Wittenburg http://page.mi.fu-berlin.de/~wittenbu/ pgpT1OhhP5tPI.pgp Description: PGP signature
Re: bits from the release team
On Wed, Jan 04, 2006 at 01:10:49AM +0100, Sven Luther wrote: But yes, udev is the problematic case, altough i run 2.6.14 with sarge udev and it works. AFAIK it should work with the default ruleset. It breaks only with certain custom rules due to a bug in the libsysfs version used by udev. So, if you did not create any udev rules yourself you should be fine. With old udev and new kernel my rules that map my USB disks to persistent names under /dev were definitely broken. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345374: linux-image-2.6.14-2-686: I too have this problem
On Tue, Jan 03, 2006 at 03:43:13PM -0800, Garrett P. McLean wrote: I have the same problem. When piix is loaded as a module, I am unable to mess with DMA settings. However, when I compile piix statically, I can set DMA without a hitch. This issue has been discussed on debian-user, and I believe it is a kernel bug, but I feel more comfortable reporting bugs here (and I don't know how to report a kernel bug). Here's the thread on debian-user: http://lists.debian.org/debian-user/2003/12/msg00024.html try to use initramfs-tools? dma should work out of the box. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: remaining linux-2.6 RC bugs ...
On Tue, Jan 03, 2006 at 04:17:20PM +0100, Sven Luther wrote: On Tue, Jan 03, 2006 at 03:31:16PM +0100, Martin Michlmayr wrote: severity 343934 important retitle 343934 please support mips thanks * Sven Luther [EMAIL PROTECTED] [2006-01-03 15:24]: #343934: kernel-2.6: FTBFS on mips/experimental Of these, #337493 ius artificial and can be closed anytime, #343260 is a kernel-package/grub bug, #343443 and #343092 are the same yaird bug, #343686 is a kernel-package issue, and #343934 is ths's fault. This is not RC anyway given that it has never built on mips. the fact that the mips/mipsel guys do their own thing in their own way is i believe etch-RC though, and need to be solved in the next 6 month. That's a decision that needs to be made together with the people who will be doing security support for the kernel in etch. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: bits from the release team
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/03/2006 10:13 PM, Sven Luther wrote: On Tue, Jan 03, 2006 at 06:43:28PM -0500, Brian Nelson wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Jan 04, Adam Heath [EMAIL PROTECTED] wrote: Not to mention that 2.6.15 requires a newer udev. Who knows what other newer things newer kernels might require. OTOH, old kernel are buggy and out of date wrt modern hardware, and we lack the manpower to backport for years fixes and new features RHEL-style. Do you have a better solution? Why don't we use RHEL's kernel, or collaborate with them to maintain a stable kernel tree, or something? Why doesn't debian really collaborate with ubuntu on the kernels, which would be more natural. Debian use mostly the mainline upstream kernels, which is where everything goes back in anyway, so ... Just my two cents... :) Sometime ago, Adrian Bunk [1]raise the question about a kernel stable tree in LKML, after a lot of discussion (and AFAIK no good resolution), a lot of ideas travel on the list (also in the midle of flamewar), ideas like try to not break the entire userland and let the distro take care of having a stable kernel. 1. http://lkml.org/lkml/2005/12/3/55 Perhaps the idea of maintain a kernel with other distros is not bad, if Ubuntu shows up as a candidate, I would like to add Progeny, Linspire, Xandros, DCC Alliance Fan Club and also other Debian Derivatives. I really don't know if it is possible to mix RH, Debian, SuSE, Slackware and other distros to maintain the same kernel, but certainly should be possible to get all Debian (and Debian based/derivative) playing together. :-) If you give it a quick look (and a quick try), we will have more users testing the same kernel, which means more feedback, we will have more developers working to get it stable and working to get it secure. Probably even upstream get benefits from this model and sounds like a very good way to work together, even to try to integrate outside patches and backporting things. =) Kind regards, - -- Felipe Augusto van de Wiel (faw) Debian. Freedom to code. Code to freedom! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFDuzGiCjAO0JDlykYRAsYxAKCYl+WPqiEWapKTK3Yee//o6Dn58wCfXPh5 JOZOVATPQIMWPgMnHzDuKrg= =qcxC -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: remaining linux-2.6 RC bugs ...
On Tue, 3 Jan 2006 15:24:53 +0100, Sven Luther [EMAIL PROTECTED] said: Of these, #337493 ius artificial and can be closed anytime, #343260 is a kernel-package/grub bug, Grub bug. #343686 is a kernel-package issue Umm, no. This is not a kernel-package issue. kernel-package does not create md5sum's, presumably the user used debsums or something to do so, and that is what needs to be fixed. manoj -- It's hard to get ivory in Africa, but in Alabama the Tuscaloosa. Groucho Marx Manoj Srivastava [EMAIL PROTECTED]http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, Jan 03, 2006 at 11:27:25PM +0100, Sven Luther wrote: On Tue, Jan 03, 2006 at 11:01:03PM +0100, Frans Pop wrote: (forgot to CC d-kernel on this) On Tuesday 03 January 2006 22:02, Sven Luther wrote: We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. 2.6.8 is not an optimal kernel, but largely due to timing (i.e. SATA just starting to get implemented). I remember we did consider using 2.6.10 instead of 2.6.8 and decided not to mainly because it was not really that much better than 2.6.8. As I remember it, this was a joint decision by the kernel team, release managers and the d-i developers. Not something that the kernel team were really pushing and was blocked by some assholes from the d-i team who did not want to cooperate. Well, i remember joeyh vetoing it because it would take at least a month to get the change done, and i believe we didn't really push for it because the infrastructure was a mess back then. This has changed. The one point that put me up, is that we should have gotten that security update in, but this was also vetoed for the same month-long delay in the kernel/d-i upgrade process. The kernel team has reduced that delay to less than 24hours now for the release arches, You have been harranguing the ftp team to approve new upstream kernels through the NEW queue before they've even been uploaded -- for an amazing false optimization that burns good will with your fellow developers. Even if udebs *were* being built from the same linux-2.6 source package, this doesn't address the real reason why it's important to freeze the kernel early: *the kernel is a core component of everyone's system and detecting regressions takes a long time*. Anything that requires a reboot cycle or an installation test in order for users to detect bugs is going to need a longer testing period than other packages; the only way to ensure this happens is by freezing it early, i.e., around the same time as the toolchain packages for which we have the same problem of figuring out whether a new version is better or worse. The underlying assumption in your plea for a shorter kernel freeze is newer is better. But people who accept this assumption unconditionally don't *run* Debian stable; so neither should we base our freeze timeline on an unconditional acceptance of it. Newer isn't necessarily better, but it is necessarily *different*, which is the enemy of stability. There is still room for targetted fixes to the kernel after the freeze date; backports of new drivers, or backports of specific bugfixes, are certainly fair game. Taking a new version of whatever upstream happens to have released would not be. My believe is that this kind of thing should be as much automated as possible, to let the few ressource we have be used where best it should, a little work at the start which will pay off forever after, this is what computers and programming is for, to make the task of the users and programmers easier, i think we all agree with that, or we would still be using boot-floppies :) I'm all in favor of streamlining the integration of new kernel versions into the installer, but I don't believe that the majority of the work involved falls into the automatable category. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#345592: linux-image-2.6.14-2-k7: pwc module doesn't work
Hi Sven, Sven Luther wrote: On Tue, Jan 03, 2006 at 01:04:39PM +1300, Srdjan wrote: Hi Sven, I'm not sure what is the pwc external driver package - I haven't installed anything apart from the kernel in case of 2.6.14-2 and additional modules for 2.6.14-1. Can you please tell me where do I find additional modules ? What is it exactly you installed as additional modules ? pwc-modules-2.6.14-1-k7 old-pwc module that I can use meanwhile? apt-cache search pwc :) Done that already. You mean pwc-source, right? Also, do we need to reassign this bug to someone else then? Indeed. you should clone it and assign it to your userland tool so it provide uncompression, and maybe to the pwc package so it will build against the newest API. So I should file bugs against xawtv, camstream and gtcam? Cheers, Srdjan Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Wed, Jan 04, 2006 at 12:23:31AM -0200, Felipe Augusto van de Wiel (faw) wrote: 1. http://lkml.org/lkml/2005/12/3/55 Perhaps the idea of maintain a kernel with other distros is not bad, if Ubuntu shows up as a candidate, I would like to add Progeny, Linspire, Xandros, DCC Alliance Fan Club and also other Debian Derivatives. I really don't know if it is possible to mix RH, Debian, SuSE, Slackware and other distros to maintain the same kernel, but certainly should be possible to get all Debian (and Debian based/derivative) playing together. :-) The biggest obstacle to this is that different distributions have different and contradictory requirements for what ships in the kernel. For Debian, the obvious requirement is that everything we ship in main meets the DFSG; this is a requirement that is not shared by Ubuntu, for instance, which means any collaboration on kernels between those two distros has to allow for different bits being stripped out at the time of source package generation. It would certainly be nice to see improvements in kernel collaboration, and I believe it is possible, we just have to be honest with ourselves about the difficulties involved. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#345592: linux-image-2.6.14-2-k7: pwc module doesn't work
On Wed, Jan 04, 2006 at 06:17:00PM +1300, Srdjan wrote: Sven Luther wrote: additional modules ? What is it exactly you installed as additional modules ? pwc-modules-2.6.14-1-k7 Yes, except you would need the newer version, 2.6.14-2-k7, and soon 2.6.15-1-k7. I believe the fact that these out-of-tree modules have not yet been rebuilt for the abi changed kernels be a RC bug against them, since it makes the package uninstallable and thus unusable, and worse will probably stop seemless upgrades. apt-cache search pwc :) Done that already. You mean pwc-source, right? Well, you can either build the pwc package from source (apt-get source -b pwc) and get the new version, or use the pwc-source package to build your own package, both should work, there is also a thingy called module assistant, but i never could make it work. So I should file bugs against xawtv, camstream and gtcam? Indeed, with severity wishlist. These and others probably, but someone probably needs to write a uncompression library which can then be used by those tools. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, Jan 03, 2006 at 10:34:43PM -0800, Steve Langasek wrote: On Wed, Jan 04, 2006 at 12:23:31AM -0200, Felipe Augusto van de Wiel (faw) wrote: 1. http://lkml.org/lkml/2005/12/3/55 Perhaps the idea of maintain a kernel with other distros is not bad, if Ubuntu shows up as a candidate, I would like to add Progeny, Linspire, Xandros, DCC Alliance Fan Club and also other Debian Derivatives. I really don't know if it is possible to mix RH, Debian, SuSE, Slackware and other distros to maintain the same kernel, but certainly should be possible to get all Debian (and Debian based/derivative) playing together. :-) The biggest obstacle to this is that different distributions have different and contradictory requirements for what ships in the kernel. For Debian, the obvious requirement is that everything we ship in main meets the DFSG; this is a requirement that is not shared by Ubuntu, for instance, which means any collaboration on kernels between those two distros has to allow for different bits being stripped out at the time of source package generation. It would certainly be nice to see improvements in kernel collaboration, and I believe it is possible, we just have to be honest with ourselves about the difficulties involved. Also, notice that cooperation with the ubuntu kernels was more marked when Fabionne was the ubuntu kernel maintainer, but now that he has passed the relay, i feel that it is less. We have proposed to them to use a common infrastrcuture with enabled/disabled patches for both, but the reply was mostly of the kind, yeah we would like to cooperate, and no actions followed. I believe it has also an influence on the place where the source package is ohold (alioth svn repo over whatever strange stuff ubuntu uses), and they said we should use their system. So, altough patches can occasionally be exchanged, i doubt that cooperation will go further for control-and-politics reason, and i believe it is maybe best so for both involved. There can be cooperation without sharing all the infrastructure and packaging. Other less high-profile daughter-distros are probably simply reusing the debian kernel, and this is probably the best way of doing this. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
* Sven Luther ([EMAIL PROTECTED]) [060103 23:02]: On Tue, Jan 03, 2006 at 10:31:38PM +0100, Andreas Barth wrote: the other hand side, the difference is only one week - and if nothing is broken by that, we can freeze the kernel at N-110 also. i think comparing the kernel with the toolchain is overkill, if nothing else a last minute change in the toolchain will need a kernel recompile anyway maybe. I do confess that i read June 30 at first, and this seemed much less acceptable to me. well, the kernel is definitly about the same level as the toolchain and standard/base - changes can have very easily impact on the installer, and it is not an option to remove the package if it is broken. N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. Well, if we want to release with a newer kernel, we need to make sure d-i doesn't stumble over it. Experience tells us that there are enough What experience ? I was speaking about the installer. And usually there are lots of last-minute changes that need to go in - not only new languages, but lots of other small minor, but still important bug fixes. Also, the kernel will be outdated sooner or later anyways - so, if after one year the kernel is 12 or 14 months old is not too much a difference. Hehe, me runs sid kernels installed almost as is on all my sarge systems indeed, just with rebuild yaird and mininmally backported udev. Well, but then an older kernel doesn't hurt you? :P Indeed, but you have only the sarge experience to go by, and taking the sarge experience on this is hardly fair to the huge amount the kernel team has devoted to streamline the process. Of course, we have seen that the kernel build process is way more mature now. Nobody doubts that. Also, i don't really believe joeyh and fjp are really the relevant maintainers with regard to the debian kernel and its application, since they lack the vision of how things could go better, or more thruthfully, probably lack the time and motivation to think really about the issue, and why should they, it is the kernel team jobs :) Well, they are definitly the relevant people for the installer. And, frankly speaking, at least I have good experience with both of them. d-i is only a part of the problem anyway, and i believe the less problematic. out-of-tree modules and third-party patches are a worse mess. Hm, which out-of-tree modules do you consider to be release critical, i.e. we cannot release without them? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
