Bug#258204: kernel-image-2.6.7-1-686: swsusp is missing
On Thu, Jul 08, 2004 at 09:15:15AM +0200, Wesley W. Terpstra wrote: > Package: kernel-image-2.6.7-1-686 > Version: 2.6.7-1 > Severity: normal > > Hi, I am running kernel-image-2.6.7-1-686 and using software suspend. > Unfortunately, the 'swsusp' module is missing and /proc/acpi/sleep does > nothing anymore. With kernel-image-2.6.6-1-686 I had no problems. > > Also, I have no interest in swsusp.sf.net since their scripts break swsusp > on my machine. The kernel version of swsusp in 2.6.6 was perfectly > sufficient for my needs. > > Please turn it back on. > Please see the thread at http://lists.debian.org/debian-kernel/2004/06/msg00461.html
Bug#258343: kernel-image-2.6.7-1-k7: Please re-enable software susped
On Fri, 09 Jul 2004 02:25:02 +0300, Lior Kaplan wrote: > Package: kernel-image-2.6.7-1-k7 > Version: 2.6.7-1 > Severity: wishlist > > I don't see we shouldn't the kernel=image have the swsusp module? > Upstream does not support modular swsusp. The swsusp module patch that we were previously using is no longer maintained, and upstream apparently has no interest in including it (so I'm told by the author of the patch). So, we're forced to either turn it on for everyone, or turn it off for everyone. I'm not entirely sure of its stability, so for now it's turned off.
Re: 2.4 kernels
On Thu, Jul 08, 2004 at 01:07:17PM +0200, Martin Michlmayr wrote: >> ssh people.debian.org:~herbert/cvs/ I don't know which modifications >> wli has made already since Herbert uploaded his sources. On Fri, Jul 09, 2004 at 10:34:27AM +0900, Horms wrote: > Thanks, I have that now. > I will assume wli hasn't made any changes unless I hear otherwise. On Thu, Jul 08, 2004 at 01:07:17PM +0200, Martin Michlmayr wrote: >> Sounds like a plan. On Fri, Jul 09, 2004 at 10:34:27AM +0900, Horms wrote: > Ok, I will use the same layout as for 2.6. I've not done anything to 2.4 worth saving. -- wli
Re: 2.4 kernels
On Thu, Jul 08, 2004 at 01:07:17PM +0200, Martin Michlmayr wrote: > * Horms <[EMAIL PROTECTED]> [2004-07-08 16:57]: > > 1) Where is the CVS tree? > > ssh people.debian.org:~herbert/cvs/ I don't know which modifications > wli has made already since Herbert uploaded his sources. Thanks, I have that now. I will assume wli hasn't made any changes unless I hear otherwise. > > 2) Should this move to SVN. I am happy to help with that. > > Sounds like a plan. Ok, I will use the same layout as for 2.6. -- Horms
Re: status of 2.6.7 ?
[I am not subscribed to debian-kernel.] On Wed, Jun 30, 2004 at 09:06:39PM +0200, Sven Luther wrote: > On Wed, Jun 30, 2004 at 04:57:12PM +, Andreas Metzler wrote: > > * XFree starts treating /dev/psaux and /dev/input/mice equally if both > > are listed, i.e. it will work if _either_ of them are accessible > > instead of insiting on the primary one. > > A huge XFree86 Change probably, i don't know that code so well, so am > CCing debian-x for advice. No, just a bit of (attempted) cleverness in the generated XF86Config-4 files. Here's the logic from the dexconf command. The "cleverness" is documented at line 400. 344 ### MOUSE / INPUTDEVICE 345 346 DO_EMULATE3BUTTONS= 347 DO_ZAXISMAPPING= 348 349 if [ "$FORMAT" = "3" ]; then 350fetch shared/xfree86v3/config/inputdevice/mouse/port 351MOUSE_PORT="$RET" 352fetch shared/xfree86v3/config/inputdevice/mouse/protocol 353MOUSE_PROTOCOL="$RET" 354fetch shared/xfree86v3/config/inputdevice/mouse/emulate3buttons 355if [ "$RET" = "true" ]; then 356 DO_EMULATE3BUTTONS=true 357fi 358fetch shared/xfree86v3/config/inputdevice/mouse/zaxismapping 359if [ "$RET" = "true" ]; then 360 DO_ZAXISMAPPING=true 361fi 362printf "Section \"Pointer\"\n" > "$DEXCONFTMPDIR/InputDeviceMouse" 363printf "\tDevice\t\t\"$MOUSE_PORT\"\n" >> "$DEXCONFTMPDIR/InputDeviceMouse" 364printf "\tProtocol\t\"$MOUSE_PROTOCOL\"\n" >> "$DEXCONFTMPDIR/InputDeviceMouse" 365if [ -n "$DO_EMULATE3BUTTONS" ]; then 366 printf "\tEmulate3Buttons\n" >> "$DEXCONFTMPDIR/InputDeviceMouse" 367fi 368if [ -n "$DO_ZAXISMAPPING" ]; then 369 printf "\tZAxisMapping\t4 5\n" >> "$DEXCONFTMPDIR/InputDeviceMouse" 370fi 371printf "EndSection\n" >> "$DEXCONFTMPDIR/InputDeviceMouse" 372 else # $FORMAT == 4 373fetch xserver-xfree86/config/inputdevice/mouse/port 374MOUSE_PORT="$RET" 375fetch xserver-xfree86/config/inputdevice/mouse/protocol 376MOUSE_PROTOCOL="$RET" 377fetch xserver-xfree86/config/inputdevice/mouse/emulate3buttons 378if [ "$RET" = "true" ]; then 379 DO_EMULATE3BUTTONS=true 380fi 381fetch xserver-xfree86/config/inputdevice/mouse/zaxismapping 382if [ "$RET" = "true" ]; then 383 DO_ZAXISMAPPING=true 384fi 385 386printf "Section \"InputDevice\"\n" > "$DEXCONFTMPDIR/InputDeviceMouse" 387printf "\tIdentifier\t\"Configured Mouse\"\n" >> "$DEXCONFTMPDIR/InputDeviceMouse" 388printf "\tDriver\t\t\"mouse\"\n" >> "$DEXCONFTMPDIR/InputDeviceMouse" 389printf "\tOption\t\t\"CorePointer\"\n" >> "$DEXCONFTMPDIR/InputDeviceMouse" 390printf "\tOption\t\t\"Device\"\t\t\"$MOUSE_PORT\"\n" >> "$DEXCONFTMPDIR/InputDeviceMouse" 391printf "\tOption\t\t\"Protocol\"\t\t\"$MOUSE_PROTOCOL\"\n" >> "$DEXCONFTMPDIR/InputDeviceMouse" 392if [ -n "$DO_EMULATE3BUTTONS" ]; then 393 printf "\tOption\t\t\"Emulate3Buttons\"\t\"true\"\n" >> "$DEXCONFTMPDIR/InputDeviceMouse" 394fi 395if [ -n "$DO_ZAXISMAPPING" ]; then 396 printf "\tOption\t\t\"ZAxisMapping\"\t\t\"4 5\"\n" >> "$DEXCONFTMPDIR/InputDeviceMouse" 397fi 398printf "EndSection\n" >> "$DEXCONFTMPDIR/InputDeviceMouse" 399 400# Only write this stanza -- designed for USB pointers -- if the Configured 401# Mouse isn't USB. This isn't a problem even on systems without 402# CONFIG_INPUT_MOUSEDEV, because this is not the core pointer, and failure to 403# open it is not harmful. 404# 405# Also don't write this stanza if the Configured Mouse is the GPM repeater. 406# We have no way of knowing what device GPM is repeating for, and it might be 407# a USB mouse. 408if [ "$MOUSE_PORT" != "/dev/input/mice" -a "$MOUSE_PORT" != "/dev/gpmdata" ]; then 409 printf "\nSection \"InputDevice\"\n" >> "$DEXCONFTMPDIR/InputDeviceMouse" 410 printf "\tIdentifier\t\"Generic Mouse\"\n" >> "$DEXCONFTMPDIR/InputDeviceMouse" 411 printf "\tDriver\t\t\"mouse\"\n" >> "$DEXCONFTMPDIR/InputDeviceMouse" 412 printf "\tOption\t\t\"SendCoreEvents\"\t\"true\"\n" >> "$DEXCONFTMPDIR/InputDeviceMouse" 413 printf "\tOption\t\t\"Device\"\t\t\"/dev/input/mice\"\n" >> "$DEXCONFTMPDIR/InputDeviceMouse" 414 printf "\tOption\t\t\"Protocol\"\t\t\"ImPS/2\"\n" >> "$DEXCONFTMPDIR/InputDeviceMouse" 415 if [ -n "$DO_EMULATE3BUTTONS" ]; then 416printf "\tOption\t\t\"Emulate3Buttons\"\t\"true\"\n" >> "$DEXCONFTMPDIR/InputDeviceMouse" 417 fi 418 if [ -n "$DO_ZAXISMAPPING" ]; then 419printf "\tOption\t\t\"ZAxisMapping\"\t\t\"4 5\"\n" >> "$DEXCONFTMPDIR/InputDeviceMouse" 420 fi 421 printf "EndSection\n" >> "$DEXCONFTMPDIR/InputDeviceMouse" 422fi 423 fi -- G. Branden Robinson
Bug#258343: kernel-image-2.6.7-1-k7: Please re-enable software susped
Package: kernel-image-2.6.7-1-k7 Version: 2.6.7-1 Severity: wishlist I don't see we shouldn't the kernel=image have the swsusp module? -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.7-1-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 Versions of packages kernel-image-2.6.7-1-k7 depends on: ii coreutils [fileutils] 5.0.91-2 The GNU core utilities ii fileutils 5.0.91-2 The GNU file management utilities ii initrd-tools 0.1.71 tools to create initrd image for p ii module-init-tools 3.1-pre4-1 tools for managing Linux kernel mo -- no debconf information
Bug#257865: initrd-tools: assembles raid using mdadm with devfs device names even when there's no devfs
severity 257865 minor thanks * Andreas Kroschel <[EMAIL PROTECTED]> [2004-07-06 14:05]: > instead of /dev/md0, even when there is no devfs installed. This renders > a system without devfs unbootable, if / is on a raid and the raid > modules are loaded from the initrd. initrd-tools is made to work with Debian kernels which have a specific configuration. In this case, Debian kernels have devfs built-in and there are no intentions of supporting something else. Apparently, lvm won't work at all without devfs. So either use a Debian kernel and initrd-tools will work for you, or don't use an initrd at all when you use custom kernels. -- Martin Michlmayr [EMAIL PROTECTED]
Processed: Re: initrd-tools: assembles raid using mdadm with devfs device names even when there's no devfs
Processing commands for [EMAIL PROTECTED]: > severity 257865 minor Bug#257865: initrd-tools: assembles raid using mdadm with devfs device names even when there's no devfs Severity set to `minor'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#258282: Additional info forgotten in the initial report.
I have also tried every 2.6.6-1 kernel. They work just fine without any black magic. [EMAIL PROTECTED]:greg]$ lsmod | grep snd_ens1371 snd_ens137124544 3 snd_rawmidi24928 1 snd_ens1371 snd_pcm96996 2 snd_ens1371,snd_pcm_oss snd_ac97_codec 64452 1 snd_ens1371 snd55140 10 snd_ens1371,snd_rawmidi,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_ac97_codec gameport4736 1 snd_ens1371 [EMAIL PROTECTED]:greg]$ Other info, as needed/requested. -- [EMAIL PROTECTED] REMEMBER ED CURRY! http://www.iwethey.org/ed_curry Novell's Directory Services is a competitive product to Microsoft's Active Directory in much the same way that the Saturn V is a competitive product to those dinky little model rockets that kids light off down at the playfield. -- Thane Walkup signature.asc Description: This is a digitally signed message part
Bug#258282: kernel-image-2.6.7-1-k7: ALSA Driver snd_ens1371 causes oops with pci.agent and modprobe
Package: kernel-image-2.6.7-1-k7 Version: 2.6.7-1 Severity: important The oops occurs on every up x86 kernel available to me. -386, -686, -k7. I had this issue with kernel-image-2.6.5-*. I fixed that one by compiling ALSA into the kernel. following is the hand typed in oops: -- System Information: Debian Release: testing/unstable APT prefers experimental APT policy: (990, 'experimental'), (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.6-1-k7 Locale: LANG=en_US, LC_CTYPE=en_US Versions of packages kernel-image-2.6.7-1-k7 depends on: ii coreutils [fileutils] 5.0.91-2 The GNU core utilities ii fileutils 5.0.91-2 The GNU file management utilities ii initrd-tools 0.1.71 tools to create initrd image for p ii module-init-tools 3.1-pre5-1 tools for managing Linux kernel mo -- no debconf information -- oops info [snip] aic7xxx alread loaded unable to handle kernel paging request at virtual address f8cc2698 printing eip: c01a051b *pde = 01d03067 *pte = Oops: 0002 [#1] PREEMPT Modules linked in: snd_ens1371 snd_rawmidi snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_timer snd_ac97_codec snd soundcore gameport joydev usbhid uhci-hcd usbcore pci_hotplug via_agp agpgart pcspkr tsdev mousedev psmouse floppy parport_pc parport evdev capability commoncap ide_cd cdrom aic7xxx e100 mii sg st scsi_mod rtc vfat xfs jfs udf isofs ext2 ext3 jbd mbcache reiserfs ide_disk ide_generic via82cxxx pdc202xx_old ide_core unix font vesafb cfbcopyarea cfbimgblt cfbfillrect CPU:0 EIP:0060:[] not tainted EFLAGS: 00010292 (2.6.7-1-k7) eax: c02ea140ebx: f8c5a07cecx: f8cc2698edx: f8c5a098 esi: ffeaedi: c02ea148ebp: f8c5a064esp: f724df24 ds: 007bws: 007bss: 0068 Process modprobe (pid: 1736, threadinfo = f724c000 task = c1f7b130) STACK: c02ea148 f8c5a07c f8c5a70c ffea c01a05b8 f8c5a07c f8c5a70c c02ea0ed f8c5a07c c02ea0e0 c01ee920 f8c5a07c f8c56fee f8c5a040 f8c5a0d8 c02b2b80 c01eee1f f8c5a064 001c f8c496cc f8c45c69 f8c47976 CALL TRACE: [] kobject_register+0x28/0x60 [] bus_add_driver+0x50/0x60 [] driver_register+0x2f/0x40 [] pci_register_driver+0c5c/0x90 [] alsa_card_ens137x_init+0xf/0x1d [snd_ens1371] [] sys_init_module+0xff/0x210 [] syscall_call+0x7/0xb CODE: 89 11 89 4a 04 8b 43 28 8b 30 8d 4e 89 c8 ba ff 00 00 ./pci.agent: Line 156: 1736 Segmentation fault $MODPROBE $MODULE > /dev/null 2>&1 snd-ens1371: can't be located Missing kernel or user-mode driver snd-ens1371 e100 already loaded eepro100.c: blah blah blah [snip]
kernel-image-2.6.7-i386_2.6.7-2_i386.changes ACCEPTED
Accepted: kernel-headers-2.6-386_2.6.7-2_i386.deb to pool/main/k/kernel-image-2.6.7-i386/kernel-headers-2.6-386_2.6.7-2_i386.deb kernel-headers-2.6-686-smp_2.6.7-2_i386.deb to pool/main/k/kernel-image-2.6.7-i386/kernel-headers-2.6-686-smp_2.6.7-2_i386.deb kernel-headers-2.6-686_2.6.7-2_i386.deb to pool/main/k/kernel-image-2.6.7-i386/kernel-headers-2.6-686_2.6.7-2_i386.deb kernel-headers-2.6-k7-smp_2.6.7-2_i386.deb to pool/main/k/kernel-image-2.6.7-i386/kernel-headers-2.6-k7-smp_2.6.7-2_i386.deb kernel-headers-2.6-k7_2.6.7-2_i386.deb to pool/main/k/kernel-image-2.6.7-i386/kernel-headers-2.6-k7_2.6.7-2_i386.deb kernel-headers-2.6.7-1-386_2.6.7-2_i386.deb to pool/main/k/kernel-image-2.6.7-i386/kernel-headers-2.6.7-1-386_2.6.7-2_i386.deb kernel-headers-2.6.7-1-686-smp_2.6.7-2_i386.deb to pool/main/k/kernel-image-2.6.7-i386/kernel-headers-2.6.7-1-686-smp_2.6.7-2_i386.deb kernel-headers-2.6.7-1-686_2.6.7-2_i386.deb to pool/main/k/kernel-image-2.6.7-i386/kernel-headers-2.6.7-1-686_2.6.7-2_i386.deb kernel-headers-2.6.7-1-k7-smp_2.6.7-2_i386.deb to pool/main/k/kernel-image-2.6.7-i386/kernel-headers-2.6.7-1-k7-smp_2.6.7-2_i386.deb kernel-headers-2.6.7-1-k7_2.6.7-2_i386.deb to pool/main/k/kernel-image-2.6.7-i386/kernel-headers-2.6.7-1-k7_2.6.7-2_i386.deb kernel-headers-2.6.7-1_2.6.7-2_i386.deb to pool/main/k/kernel-image-2.6.7-i386/kernel-headers-2.6.7-1_2.6.7-2_i386.deb kernel-image-2.6-386_2.6.7-2_i386.deb to pool/main/k/kernel-image-2.6.7-i386/kernel-image-2.6-386_2.6.7-2_i386.deb kernel-image-2.6-686-smp_2.6.7-2_i386.deb to pool/main/k/kernel-image-2.6.7-i386/kernel-image-2.6-686-smp_2.6.7-2_i386.deb kernel-image-2.6-686_2.6.7-2_i386.deb to pool/main/k/kernel-image-2.6.7-i386/kernel-image-2.6-686_2.6.7-2_i386.deb kernel-image-2.6-k7-smp_2.6.7-2_i386.deb to pool/main/k/kernel-image-2.6.7-i386/kernel-image-2.6-k7-smp_2.6.7-2_i386.deb kernel-image-2.6-k7_2.6.7-2_i386.deb to pool/main/k/kernel-image-2.6.7-i386/kernel-image-2.6-k7_2.6.7-2_i386.deb kernel-image-2.6.7-1-386_2.6.7-2_i386.deb to pool/main/k/kernel-image-2.6.7-i386/kernel-image-2.6.7-1-386_2.6.7-2_i386.deb kernel-image-2.6.7-1-686-smp_2.6.7-2_i386.deb to pool/main/k/kernel-image-2.6.7-i386/kernel-image-2.6.7-1-686-smp_2.6.7-2_i386.deb kernel-image-2.6.7-1-686_2.6.7-2_i386.deb to pool/main/k/kernel-image-2.6.7-i386/kernel-image-2.6.7-1-686_2.6.7-2_i386.deb kernel-image-2.6.7-1-k7-smp_2.6.7-2_i386.deb to pool/main/k/kernel-image-2.6.7-i386/kernel-image-2.6.7-1-k7-smp_2.6.7-2_i386.deb kernel-image-2.6.7-1-k7_2.6.7-2_i386.deb to pool/main/k/kernel-image-2.6.7-i386/kernel-image-2.6.7-1-k7_2.6.7-2_i386.deb kernel-image-2.6.7-i386_2.6.7-2.dsc to pool/main/k/kernel-image-2.6.7-i386/kernel-image-2.6.7-i386_2.6.7-2.dsc kernel-image-2.6.7-i386_2.6.7-2.tar.gz to pool/main/k/kernel-image-2.6.7-i386/kernel-image-2.6.7-i386_2.6.7-2.tar.gz Announcing to debian-devel-changes@lists.debian.org Thank you for your contribution to Debian.
Processing of kernel-image-2.6.7-i386_2.6.7-2_i386.changes
kernel-image-2.6.7-i386_2.6.7-2_i386.changes uploaded successfully to localhost along with the files: kernel-image-2.6.7-i386_2.6.7-2.dsc kernel-image-2.6.7-i386_2.6.7-2.tar.gz kernel-headers-2.6.7-1_2.6.7-2_i386.deb kernel-headers-2.6-386_2.6.7-2_i386.deb kernel-image-2.6-386_2.6.7-2_i386.deb kernel-headers-2.6.7-1-386_2.6.7-2_i386.deb kernel-image-2.6.7-1-386_2.6.7-2_i386.deb kernel-headers-2.6-686_2.6.7-2_i386.deb kernel-image-2.6-686_2.6.7-2_i386.deb kernel-headers-2.6.7-1-686_2.6.7-2_i386.deb kernel-image-2.6.7-1-686_2.6.7-2_i386.deb kernel-headers-2.6-686-smp_2.6.7-2_i386.deb kernel-image-2.6-686-smp_2.6.7-2_i386.deb kernel-headers-2.6.7-1-686-smp_2.6.7-2_i386.deb kernel-image-2.6.7-1-686-smp_2.6.7-2_i386.deb kernel-headers-2.6-k7_2.6.7-2_i386.deb kernel-image-2.6-k7_2.6.7-2_i386.deb kernel-headers-2.6.7-1-k7_2.6.7-2_i386.deb kernel-image-2.6.7-1-k7_2.6.7-2_i386.deb kernel-headers-2.6-k7-smp_2.6.7-2_i386.deb kernel-image-2.6-k7-smp_2.6.7-2_i386.deb kernel-headers-2.6.7-1-k7-smp_2.6.7-2_i386.deb kernel-image-2.6.7-1-k7-smp_2.6.7-2_i386.deb Greetings, Your Debian queue daemon
Bug#258043: kernel-patch-debian-2.6.7: doesn't list which patches are incorporated: kernel-patch-debian-2.6.7, kernel-image-2.6.7: doesn't list which patches are incorporated
On 2004-07-07 Christoph Hellwig <[EMAIL PROTECTED]> wrote: > On Wed, Jul 07, 2004 at 12:29:44PM +0200, Kilian Krause wrote: > > The description from kernel-patch-debian and kernel-image does not > > list which patches are contained in the Debian diff. That way it's > > pretty hard to evaluate which benefits are already provided by using the > > debian kernel package compared to going vanilla (and patching in what > > you need apart from vanilla). > Currently README.Debian in kernel-source has an incomplete list. I > talked to Jens about this and we can't see anything in Policy mandating > that at all, so we plan to remove that aswell. With the .dpatch > ification you can easily check in the source for yourself, all the > .dpatches have proper descriptions. [...] If you are using dpatch there is a simple, automatic solution. Check the contents of patch-stamp after dpatch has run. - It contains the list of applied patches and there respective "#DP: ..."-descriptions. Ship it in the debs and Kilian's wish is implemented. cu andreas
Bug#258251: initrd-tools cannot be installed during the base system install.
* Felix SPORTELLI <[EMAIL PROTECTED]> [2004-07-08 15:54]: > There is a critical bug on the sarge installation of the daily build of > sarge version 8/7/2004. > In fact the package cannot be installed while the installation of the > base system. What was the exact error message? Did you have your root partition on LVM or RAID? -- Martin Michlmayr [EMAIL PROTECTED]
Bug#258251: initrd-tools cannot be installed during the base system install.
reassign 258251 debian-installer thanks On Thu, Jul 08, 2004 at 03:54:15PM +0200, Felix SPORTELLI wrote: > Package: initrd-tools > Version: 0.1.70 > Severity: grave > > Hello, > There is a critical bug on the sarge installation of the daily build of > sarge version 8/7/2004. > In fact the package cannot be installed while the installation of the > base system. Care to provide more info about this ? You probably mean the dpkg error about this and the missing cramfs and dash dependencies ? The current diagnostic seems to be a version skew in tasksel package you see previously, or at least that is what joeyh said, i have some doubts about this myself though, but joeyh has more experience about those things than me. In any case, it is not an initrd-tools bug, but a debian-installer one, thus reassigning. Friendly, Sven Luther
Processed: reassigning to debian-installer
Processing commands for [EMAIL PROTECTED]: > reassign 258251 debian-installer Bug#258251: initrd-tools cannot be installed during the base system install. Bug reassigned from package `initrd-tools' to `debian-installer'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#258251: initrd-tools cannot be installed during the base system install.
Package: initrd-tools Version: 0.1.70 Severity: grave Hello, There is a critical bug on the sarge installation of the daily build of sarge version 8/7/2004. In fact the package cannot be installed while the installation of the base system. -- *---* |Félix Sportelli (alias neo)[EMAIL PROTECTED] | |25 rue des chevreaux http://fsportelli.org | |91250 Saint Germain lès Corbeil| |FP: 645B A7EC E026 1CF0 90D4 E385 601F E6DA 58EC 668A | *---*
Re: broadcom BCM5700 2.6 kernel (tg3 module)
Hi, I happened to see the same. Quick (and anemic) workaround is to use pci=noacpi boot parameter. This helps---probably. Explanation? Hmmm, seems to be kinda IRQ-related problem. Unfortunately have no resources to investigate. This problem (and better solution!) is certainly worth to propagate. Rgrds, andresm
Re: PReP support for mkvmlinuz & kernel-image 2.6
Damn,
forgot to attach the files, here they are.
Friendly,
Sven Luther
#!/bin/sh
# usage information
usage() {
echo 'usage:'
echo ' -o - path to output file for compressed kernel image'
echo ' -a - PowerPC sub-architecture'
echo ' -k - path to kernel image file in ELF format'
echo ' -s - path to System.map file'
echo ' -i - path to initrd image file in uncompressed format'
echo ' -d - path to directory with additional object files'
echo ' -r - kernel release number'
echo ' -z - assume the initrd image file is already compressed'
echo ' -q - quiet operation (do not indicate progress)'
echo ' -v - verbose operation (print commands)'
exit 0
}
# echo a shell command if desired, and execute it
do_cmd() {
test -z "$verbose" || echo $@; eval $@
return
}
# parse command line
while getopts o:k:s:i:d:r:a:zqv option; do
case "$option" in
o) output=$OPTARG ;;
k) kernel=$OPTARG ;;
s) sysmap=$OPTARG ;;
i) initrd=$OPTARG ;;
d) objdir=$OPTARG ;;
r) release=$OPTARG ;;
a) arch=$OPTARG ;;
z) compressed="Yes" ;;
q) quiet="Yes" ;;
v) verbose="Yes" ;;
*) usage; exit 0 ;;
esac
done
# use non-option arguments as release version and kernel image file if needed
shift $((OPTIND-1))
if test -z "$release" -a -n "$1"; then
release=$1
fi
if test -z "$kernel" -a -n "$2"; then
kernel=$2
fi
# if no sub-architecture was specified, read it from /proc
if test -z "$arch"; then
case $(grep ^machine /proc/cpuinfo) in
*PReP*) arch=prep ;;
*CHRP*) arch=chrp ;;
*Amiga) arch=amiga ;;
*iSeries) arch=iseries ;;
*)
case $(grep ^pmac-generation /proc/cpuinfo) in
*NewWorld) arch=newworld ;;
*OldWorld) arch=coff ;;
esac
;;
esac
fi
test -n "$quiet" || echo === Building for sub-architecture $arch.
# if no kernel was specified, try to find one
if test -z "$kernel"; then
# guess the location of a kernel
if kernel=/boot/vmlinux-$release; test -n "$release" -a -r $kernel; then
:
elif kernel=/vmlinux; test -r $kernel; then
:
elif kernel=/boot/vmlinux; test -r $kernel; then
:
elif kernel=/boot/vmlinux-$(uname -r); test -r $kernel; then
:
else
kernel=""
fi
# we couldn't find a kernel, and therefore give up
if test -z "$kernel"; then
echo Could not find a kernel image file, please specify one.
exit 1
fi
# sanitize the location of the kernel
kernel=$(readlink -f $kernel)
fi
test -n "$quiet" || echo === Using kernel image file $kernel.
# if no initrd was specified, try to find one that goes with the kernel
if test -z "$initrd"; then
# guess the location of an initrd, but don't try too hard
if initrd=${kernel/vmlinux/initrd.img}; test -r $initrd; then
:
else
initrd=""
fi
# sanitize the location of the initrd
if test -n "$initrd"; then
initrd=$(readlink -f $initrd)
fi
fi
test -n "$quiet" -a -n "$initrd" || echo === Using initrd image file $initrd.
# if no release was specified, extract it from the kernel image name
if test -z "$release"; then
release=$(echo $kernel | sed s/.*vmlinux-//)
if echo $release | grep -q '2\.[46]\.[0-9]*'; then
:
else
release=""
fi
fi
test -n "$quiet" || echo === Release version seems to be $release.
# if no object file directory was specified, try to find one
if test -z "$objdir"; then
# try a default location first, then use the current directory
if objdir=/usr/lib/kernel-image-$release; test -d $objdir; then
:
else
objdir=$PWD
fi
fi
test -n "$quiet" || echo === Using object files from $objdir.
# if no output file was specified, source the configuration file
if test -z "$output" -a -r /etc/mkvmlinuz/output; then
. /etc/mkvmlinuz/output
fi
# we absolutely need an output file, and won't attempt guesses
if test -z "$output"; then
echo Please specify an output file.
exit 1
fi
test -n "$quiet" || echo === Building a bootable compressed kernel image in
$output.
# create a work directory
work=$(mktemp -d)
test -n "$quiet" || echo === Doing build in $work.
# utilities
ADDNOTE=$objdir/utils/addnote
HACKOFF=$objdir/utils/hack-coff
MKNOTE=$objdir/utils/mknote
MKPREP=$objdir/utils/mkprep
MKBUGBOOT=$objdir/utils/mkbugboot
LD=ld
OBJCOPY=objcopy
GZIP="--force --best"
# libraries and common object files
libs=$objdir/lib
of_objs=$objdir/obj/openfirmware
simple_objs=$objdir/obj/simple
OBJS="$of_objs/start.o $of_objs/misc.o $of_objs/common.o $of_objs/${arch}main.o"
SIMPLE_OBJS="$simple_objs/head.o $simple_objs/relocate.o $simple_objs/legacy.o
$simple_objs/misc.o $simple_objs/misc-prep.o $simple_objs/mpc10x_memory.o"
case $arch in
prep)
dummy=$objdir/obj/simple/dummy.o
Re: PReP support for mkvmlinuz & kernel-image 2.6
Ok, i had the oportunity to try this out with real packages now, and noticed some stuff needed fixing, which i did. Here is the new mkvmlinuz attached. Still the powerpc kernels i built behave strangely, and don't generate the initrd, which probably means i should not reboot until this is fixed. The kernel-package initrd scripts behave strangely, and produce this kind of stuff : $ more /var/lib/dpkg/info/kernel-image-2.6.7-powerpc.postinst #!/bin/sh set -e # Automatically added by dh_installmodules if [ "$1" = "configure" ] && [ -x /sbin/update-modules ]; then update-modules >/dev/null fi # End automatically added section Which i think is utterly broken. Jens, any idea on what is going on ? Or you Manoj ? Also, Jens, what is your plan for the release of these packages ? Friendly, Sven Luther
Re: 2.4 kernels
* Horms <[EMAIL PROTECTED]> [2004-07-08 16:57]: > 1) Where is the CVS tree? ssh people.debian.org:~herbert/cvs/ I don't know which modifications wli has made already since Herbert uploaded his sources. > 2) Should this move to SVN. I am happy to help with that. Sounds like a plan. -- Martin Michlmayr [EMAIL PROTECTED]
Bug#258043: kernel-patch-debian-2.6.7: doesn't list which patches are incorporated: kernel-patch-debian-2.6.7, kernel-image-2.6.7: doesn't list which patches are incorporated
On Thu, Jul 08, 2004 at 09:43:48AM +0200, Kilian Krause wrote: > So, do i see right that neither of VServer and SKAS (the UML patch) are > in the debian-kernel? You're absolutely right. And you can be sure they won't get into the Debian packtkit as long as I'm part of the kernel team..
Bug#249564: mkinitrd should not fail when modules are missing
Herbert Xu wrote: Does this patch help? Yes it works. Sorry for having no time to check it earlier. Thanks, Torsten
Bug#258043: kernel-patch-debian-2.6.7: doesn't list which patches are incorporated: kernel-patch-debian-2.6.7, kernel-image-2.6.7: doesn't list which patches are incorporated
On Thu, Jul 08, 2004 at 09:43:48AM +0200, Kilian Krause wrote: > Hi Sven, > > > Ah, what is your problem with : > > > > > > http://svn.debian.org/viewcvs/kernel/kernel/2.6/source/trunk/kernel-source-2.6.7-2.6.7/debian/patches > > > > Well, probably the tagged version thereof. > > About none. That's somewhat close to the list i'd like the link being in > the description. ;) > It's a little hard reading the description by the SVN commit message, Well, you could link to the actual file or something such. > but it's a good start to know where to look further (or maybe be > convinced and just go ahead and install). From that listing it's however > a bit tough to tell if all those are individual patches or if that was Well, if you browse a bit, you can see all the patches, and browse their content. > just split from a grand patch to the actual files it touches. > So, do i see right that neither of VServer and SKAS (the UML patch) are > in the debian-kernel? I will let others comment on that. Friendly, Sven Luther
Bug#258043: kernel-patch-debian-2.6.7: doesn't list which patches are incorporated: kernel-patch-debian-2.6.7, kernel-image-2.6.7: doesn't list which patches are incorporated
On Thu, Jul 08, 2004 at 08:58:44AM +0200, Kilian Krause wrote: > Hi Sven, > > > > /usr/src/kernel-patches/all/2.6.7/debian/patch-2.6.7-1.bz2 > > > /usr/src/kernel-patches/all/2.6.7/debian/patch-2.6.7-2.bz2 > > > > For this kind of stuff, it is better to work on the source package of > > kernel-source. > > > > try apt-get source kernel-source-2.6.7 and experiment with it. > > my point is: when installing a system and thus adding a new kernel, why > would i want to install a kernel with patches and settings i don't know? Because it is the debian kernel, and you trust the debian-kernel maintainers to know what is best for you. If this is not the case, then you are big enough to look at the source package, are you not ? Or even at the kernel-source subversion repo if the package is too big for you. Alternatively, the kernel-patch package should provide the patches in split format, as well as the different patchsets. This is not done yet though, and would need kernel-package support. > So all i ask for is a policy-refence for the internal kernel-package > policy about: > - which patches are in (more than just the vanilla kernel) > - which hardware is supported > - which features are compiled in (like networking etc.) Sure, but adding this in the package description is overkill, and maybe even difficult to automate. > If that can be put on some web page for me to look at, that'd just be > terrific. Ah, what is your problem with : http://svn.debian.org/viewcvs/kernel/kernel/2.6/source/trunk/kernel-source-2.6.7-2.6.7/debian/patches Well, probably the tagged version thereof. > I *DO* understand that putting that into the description is not what you > guys want, so ok. Even a pointer to the SVN repository of kernel-source > would be ok, if that does list what i search for. > This all shall take place *before* moving some 300 MB (binary images, > sources, vanilla sources, crawling patch websites etc.) around the net > until finally finding the kernel-image i really do want to install (and > reading sources and docs and searching bits and pieces in README and > TODO files for like 3-4h until i find all info i need to know what went > into kernel-source). Like said, if you think you are big enough to know better than the debian-kernel team, you are also big enough to find out the info you want all by yourself. And in any case, just downloading the kernel-patch-debian package should in the future give you all the info you want. Friendly, Sven Luther
Bug#258043: kernel-patch-debian-2.6.7: doesn't list which patches are incorporated: kernel-patch-debian-2.6.7, kernel-image-2.6.7: doesn't list which patches are incorporated
Hi Sven, > > /usr/src/kernel-patches/all/2.6.7/debian/patch-2.6.7-1.bz2 > > /usr/src/kernel-patches/all/2.6.7/debian/patch-2.6.7-2.bz2 > > For this kind of stuff, it is better to work on the source package of > kernel-source. > > try apt-get source kernel-source-2.6.7 and experiment with it. my point is: when installing a system and thus adding a new kernel, why would i want to install a kernel with patches and settings i don't know? So all i ask for is a policy-refence for the internal kernel-package policy about: - which patches are in (more than just the vanilla kernel) - which hardware is supported - which features are compiled in (like networking etc.) If that can be put on some web page for me to look at, that'd just be terrific. I *DO* understand that putting that into the description is not what you guys want, so ok. Even a pointer to the SVN repository of kernel-source would be ok, if that does list what i search for. This all shall take place *before* moving some 300 MB (binary images, sources, vanilla sources, crawling patch websites etc.) around the net until finally finding the kernel-image i really do want to install (and reading sources and docs and searching bits and pieces in README and TODO files for like 3-4h until i find all info i need to know what went into kernel-source). Maybe with 2.6 there's few patches needed. Maybe however you use a -mm kernel or one of the other near-vanilla-upstream for they have an advantage you think is making them superior. Now all that i want to be able to is inform myself, which piece of software am i getting as kernel-image. Unfortunatelly "KERNEL" is defined in a little fuzzy way around the Linux comunity (like the RH NPTL-enabled kernels are also a distro-kernel). I hope I could make my point clear. It's not about that I question you do a great job with the kernel-images. Just I want to know if the additional patches are for: - just making it compile - adding features that weren't in (like IPsec for 2.4, Vserver, UML with SKAS patch, O(1) for 2.4 kernels etc.) - reducing warnings that are kind of annoying - making install target the Debian-way For some reason I do believe that it's somewhere between #1 and #2. So now which patches went in that are not just eyecandy, but real new features? Is that asking too much, to be allowed to know what you get before you "apt-get install kernel-image-2.6.7-1-k7&&reboot" and find out the hard way? -- Best regards, Kilian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#258043: kernel-patch-debian-2.6.7: doesn't list which patches are incorporated: kernel-patch-debian-2.6.7, kernel-image-2.6.7: doesn't list which patches are incorporated
Hi Sven, > Ah, what is your problem with : > > > http://svn.debian.org/viewcvs/kernel/kernel/2.6/source/trunk/kernel-source-2.6.7-2.6.7/debian/patches > > Well, probably the tagged version thereof. About none. That's somewhat close to the list i'd like the link being in the description. ;) It's a little hard reading the description by the SVN commit message, but it's a good start to know where to look further (or maybe be convinced and just go ahead and install). From that listing it's however a bit tough to tell if all those are individual patches or if that was just split from a grand patch to the actual files it touches. So, do i see right that neither of VServer and SKAS (the UML patch) are in the debian-kernel? > And in any case, just downloading the kernel-patch-debian package should > in the future give you all the info you want. sounds good. ;) -- Best regards, Kilian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#257504: marked as done (User can chown/chmod files in /proc)
Your message dated Thu, 08 Jul 2004 03:47:41 -0400 with message-id <[EMAIL PROTECTED]> and subject line Bug#257504: fixed in kernel-source-2.6.7 2.6.7-3 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 3 Jul 2004 21:50:49 + >From [EMAIL PROTECTED] Sat Jul 03 14:50:49 2004 Return-path: <[EMAIL PROTECTED]> Received: from home.nightdaughter.de [194.95.224.141] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1BgsPI-0002mj-00; Sat, 03 Jul 2004 14:50:49 -0700 Received: from hydra.joerghoh.de (hydra.joerghoh.de [192.168.0.14]) by home.nightdaughter.de (Postfix) with SMTP id 47C2F170029 for <[EMAIL PROTECTED]>; Sat, 3 Jul 2004 23:50:46 +0200 (CEST) Received: by hydra.joerghoh.de (sSMTP sendmail emulation); Sat, 3 Jul 2004 23:50:47 +0200 From: "Joerg Hoh" <[EMAIL PROTECTED]> Date: Sat, 3 Jul 2004 23:50:47 +0200 To: [EMAIL PROTECTED] Subject: User can chown/chmod files in /proc Message-ID: <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.6i Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2004_03_25 X-Spam-Level: Package: kernel-source-2.6.7 Version: 2.6.7 A user with a local account can change the owner and the permissions of files in /proc. Affected is at least kernel 2.6.7, but possibly all 2.6.x kernels. hydra proc $ cd /proc hydra proc $ ls -la config.gz -r--r--r-- 1 root root 6354 3. Jul 23:25 config.gz hydra proc $ chown joerg config.gz hydra proc $ ls -la config.gz -r--r--r-- 1 joerg root 6354 3. Jul 23:25 config.gz hydra proc $ chown root config.gz hydra proc $ ls -la config.gz -r--r--r-- 1 root root 6354 3. Jul 23:26 config.gz hydra proc $ chmod o+x config.gz hydra proc $ ls -la config.gz -r--r--r-x 1 root root 6354 3. Jul 23:46 config.gz hydra proc $ SuSE mentioned this bug in http://article.gmane.org/gmane.comp.security.bugtraq/12316, so there should be a patch around. Jörg -- Fachbegriffe der Informatik (Nr 369): Ursache - Ursächlich war, dass Windows nicht neu gestartet wurde. Michael Scheer --- Received: (at 257504-close) by bugs.debian.org; 8 Jul 2004 07:49:31 + >From [EMAIL PROTECTED] Thu Jul 08 00:49:31 2004 Return-path: <[EMAIL PROTECTED]> Received: from newraff.debian.org [208.185.25.31] (mail) by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1BiTes-0004en-00; Thu, 08 Jul 2004 00:49:30 -0700 Received: from katie by newraff.debian.org with local (Exim 3.35 1 (Debian)) id 1BiTd7-00075w-00; Thu, 08 Jul 2004 03:47:41 -0400 From: Sven Luther <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] X-Katie: $Revision: 1.51 $ Subject: Bug#257504: fixed in kernel-source-2.6.7 2.6.7-3 Message-Id: <[EMAIL PROTECTED]> Sender: Archive Administrator <[EMAIL PROTECTED]> Date: Thu, 08 Jul 2004 03:47:41 -0400 Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER autolearn=no version=2.60-bugs.debian.org_2004_03_25 X-Spam-Level: X-CrossAssassin-Score: 2 Source: kernel-source-2.6.7 Source-Version: 2.6.7-3 We believe that the bug you reported is fixed in the latest version of kernel-source-2.6.7, which is due to be installed in the Debian FTP archive: kernel-doc-2.6.7_2.6.7-3_all.deb to pool/main/k/kernel-source-2.6.7/kernel-doc-2.6.7_2.6.7-3_all.deb kernel-patch-debian-2.6.7_2.6.7-3_all.deb to pool/main/k/kernel-source-2.6.7/kernel-patch-debian-2.6.7_2.6.7-3_all.deb kernel-source-2.6.7_2.6.7-3.diff.gz to pool/main/k/kernel-source-2.6.7/kernel-source-2.6.7_2.6.7-3.diff.gz kernel-source-2.6.7_2.6.7-3.dsc to pool/main/k/kernel-source-2.6.7/kernel-source-2.6.7_2.6.7-3.dsc kernel-source-2.6.7_2.6.7-3_all.deb to pool/main/k/kernel-source-2.6.7/kernel-source-2.6.7_2.6.7-3_all.deb kernel-tree-2.6.7_2.6.7-3_all.deb to pool/main/k/kernel-source-2.6.7/kernel-tree-2.6.7_2.6.7-3_all.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If yo
kernel-source-2.6.7_2.6.7-3_powerpc.changes ACCEPTED
Accepted: kernel-doc-2.6.7_2.6.7-3_all.deb to pool/main/k/kernel-source-2.6.7/kernel-doc-2.6.7_2.6.7-3_all.deb kernel-patch-debian-2.6.7_2.6.7-3_all.deb to pool/main/k/kernel-source-2.6.7/kernel-patch-debian-2.6.7_2.6.7-3_all.deb kernel-source-2.6.7_2.6.7-3.diff.gz to pool/main/k/kernel-source-2.6.7/kernel-source-2.6.7_2.6.7-3.diff.gz kernel-source-2.6.7_2.6.7-3.dsc to pool/main/k/kernel-source-2.6.7/kernel-source-2.6.7_2.6.7-3.dsc kernel-source-2.6.7_2.6.7-3_all.deb to pool/main/k/kernel-source-2.6.7/kernel-source-2.6.7_2.6.7-3_all.deb kernel-tree-2.6.7_2.6.7-3_all.deb to pool/main/k/kernel-source-2.6.7/kernel-tree-2.6.7_2.6.7-3_all.deb Announcing to debian-devel-changes@lists.debian.org Closing bugs: 256064 257504 Thank you for your contribution to Debian.
Re: 2.4 kernels
On Thu, Jul 08, 2004 at 08:38:46AM +0200, Sven Luther wrote: > On Thu, Jul 08, 2004 at 12:56:35PM +0900, Horms wrote: > > On Wed, Jul 07, 2004 at 06:29:41PM -0700, William Lee Irwin III wrote: > > > On Wed, Jul 07, 2004 at 03:29:48AM -0700, William Lee Irwin III wrote: > > > >> Basically, update cvs to the current 2.4 in order to get security fixes > > > >> from newer mainline 2.4, and send out packages. > > > > > > On Thu, Jul 08, 2004 at 10:22:54AM +0900, Horms wrote: > > > > I am more than happy to help with this. > > > > By merging in the latest mainline I am assuming that > > > > you mean 2.4.27-rc3 or something like that? > > > > All the security fixes that _I_ am aware of are fixed > > > > as of 2.4.27-rc2. > > > > > > That sounds good to me. > > > > Excellent. Do I need to do anything special to get CVS access? > > Err, you probably mean SVN access here. I thought so too. But the 2.4 section of the SVN tree seems bare. Obviously I am missing something. > > My debian username is horms if that helps. > > I need to add you to the alioth project, i guess. ... Done. > > Do you have any question about the organisation of it all ? If so, > then please ask either here or on the #debian-kernel irc channel. Will do. -- Horms
Re: 2.4 kernels
On Thu, Jul 08, 2004 at 09:50:51AM +0200, Martin Michlmayr wrote: > * William Lee Irwin III <[EMAIL PROTECTED]> [2004-07-07 18:29]: > > > you mean 2.4.27-rc3 or something like that? > > > All the security fixes that _I_ am aware of are fixed > > > as of 2.4.27-rc2. > > > > That sounds good to me. > > No, it would be much better to do an update of 2.4.26 now with those > security patches applied. We can do 2.4.27 later. Ok, that sounds fine to me. I already have patches for all of the CAN entries that were sent out in another post. -- Horms
Re: 2.4 kernels
On Thu, Jul 08, 2004 at 12:56:34PM +0900, Horms wrote: > On Wed, Jul 07, 2004 at 06:29:41PM -0700, William Lee Irwin III wrote: > > On Wed, Jul 07, 2004 at 03:29:48AM -0700, William Lee Irwin III wrote: > > >> Basically, update cvs to the current 2.4 in order to get security fixes > > >> from newer mainline 2.4, and send out packages. > > > > On Thu, Jul 08, 2004 at 10:22:54AM +0900, Horms wrote: > > > I am more than happy to help with this. > > > By merging in the latest mainline I am assuming that > > > you mean 2.4.27-rc3 or something like that? > > > All the security fixes that _I_ am aware of are fixed > > > as of 2.4.27-rc2. > > > > That sounds good to me. > > Excellent. Do I need to do anything special to get CVS access? > My debian username is horms if that helps. Two questions. 1) Where is the CVS tree? 2) Should this move to SVN. I am happy to help with that. -- Horms
bug 257120
Hi guys, I did quite a bit of work on this bug, but i had stop there since it is an upstream bug and i houneslty i don't know how to go further. Please can you kindly take care, as debian kernel maintainers, take care of it. Fabio -- fajita: step one Whatever the problem, step one is always to look in the error log. fajita: step two When in danger or in doubt, step two is to scream and shout.
Processing of kernel-source-2.6.7_2.6.7-3_powerpc.changes
kernel-source-2.6.7_2.6.7-3_powerpc.changes uploaded successfully to localhost along with the files: kernel-source-2.6.7_2.6.7-3.dsc kernel-source-2.6.7_2.6.7-3.diff.gz kernel-patch-debian-2.6.7_2.6.7-3_all.deb kernel-tree-2.6.7_2.6.7-3_all.deb kernel-source-2.6.7_2.6.7-3_all.deb kernel-doc-2.6.7_2.6.7-3_all.deb Greetings, Your Debian queue daemon
Re: 2.4 kernels
* William Lee Irwin III <[EMAIL PROTECTED]> [2004-07-07 18:29]: > > you mean 2.4.27-rc3 or something like that? > > All the security fixes that _I_ am aware of are fixed > > as of 2.4.27-rc2. > > That sounds good to me. No, it would be much better to do an update of 2.4.26 now with those security patches applied. We can do 2.4.27 later. -- Martin Michlmayr [EMAIL PROTECTED]
Incomplete upload found in Debian upload queue
Probably you are the uploader of the following file(s) in the Debian upload queue directory: kernel-source-2.6.7_2.6.7-3.diff.gz kernel-source-2.6.7_2.6.7-3.dsc kernel-source-2.6.7_2.6.7-3_all.deb This looks like an upload, but a .changes file is missing, so the job cannot be processed. If no .changes file arrives within 23:27:08, the files will be deleted. If you didn't upload those files, please just ignore this message. Greetings, Your Debian queue daemon
Bug#258204: kernel-image-2.6.7-1-686: swsusp is missing
Package: kernel-image-2.6.7-1-686 Version: 2.6.7-1 Severity: normal Hi, I am running kernel-image-2.6.7-1-686 and using software suspend. Unfortunately, the 'swsusp' module is missing and /proc/acpi/sleep does nothing anymore. With kernel-image-2.6.6-1-686 I had no problems. Also, I have no interest in swsusp.sf.net since their scripts break swsusp on my machine. The kernel version of swsusp in 2.6.6 was perfectly sufficient for my needs. Please turn it back on. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.7-1-686 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 Versions of packages kernel-image-2.6.7-1-686 depends on: ii coreutils [fileutils]5.0.91-2The GNU core utilities ii initrd-tools 0.1.70 tools to create initrd image for p ii module-init-tools3.0-pre10-4 tools for managing Linux kernel mo -- no debconf information
Bug#258043: kernel-patch-debian-2.6.7: doesn't list which patches are incorporated: kernel-patch-debian-2.6.7, kernel-image-2.6.7: doesn't list which patches are incorporated
On Wed, Jul 07, 2004 at 03:00:11PM +0200, Kilian Krause wrote: > Hi Christoph, > > Am Mi, den 07.07.2004 schrieb Christoph Hellwig um 14:58: > > On Wed, Jul 07, 2004 at 02:22:38PM +0200, Kilian Krause wrote: > > > well, installing a kernel first to see if i like its patches is not very > > > compfortable. So i was actually referring to the description of > > > "apt-cache show kernel-patch-debian-2.6.7 kernel-image-2.6.7-1-k7" which > > > does not list anything at all. I see that maintaining a list is > > > problematic, so maybe a pointer to the SVN/CVS URL would be helping. > > > Just some place i can check the list *BEFORE* downloading some 30MB off > > > the net (which i then remove after having read README.Debian). > > > > Ok, that's fine with me. I'll try to find a reasoanable way to > > implement that. > > Good ;) > > > > It was meant as a means to debug. Like i have a problem and i want to > > > find out which patch breaks (for vanilla kernel works fine), then > > > removing a certain patch and trying might make sense. It was not meant > > > for you to support Q&A for that, just a better way to build unsupported > > > personal kernel-images or report bugs after proving more details. If > > > that's not needed, ok fine. ;) > > > > just uncomment one of more patches from the 00list-$VERSION file. I'll > > try to find a proper place to document this. > > > You mean any of these two? > /usr/src/kernel-patches/all/2.6.7/debian/patch-2.6.7-1.bz2 > /usr/src/kernel-patches/all/2.6.7/debian/patch-2.6.7-2.bz2 For this kind of stuff, it is better to work on the source package of kernel-source. try apt-get source kernel-source-2.6.7 and experiment with it. Friendly, Sven Luther
Re: 2.4 kernels
On Thu, Jul 08, 2004 at 12:56:35PM +0900, Horms wrote: > On Wed, Jul 07, 2004 at 06:29:41PM -0700, William Lee Irwin III wrote: > > On Wed, Jul 07, 2004 at 03:29:48AM -0700, William Lee Irwin III wrote: > > >> Basically, update cvs to the current 2.4 in order to get security fixes > > >> from newer mainline 2.4, and send out packages. > > > > On Thu, Jul 08, 2004 at 10:22:54AM +0900, Horms wrote: > > > I am more than happy to help with this. > > > By merging in the latest mainline I am assuming that > > > you mean 2.4.27-rc3 or something like that? > > > All the security fixes that _I_ am aware of are fixed > > > as of 2.4.27-rc2. > > > > That sounds good to me. > > Excellent. Do I need to do anything special to get CVS access? Err, you probably mean SVN access here. > My debian username is horms if that helps. I need to add you to the alioth project, i guess. ... Done. Do you have any question about the organisation of it all ? If so, then please ask either here or on the #debian-kernel irc channel. Friendly, Sven Luther
Re: preparations for 2.6.7-3
On Thu, Jul 08, 2004 at 02:17:08AM -0400, Andres Salomon wrote: > On Thu, 2004-07-08 at 07:56 +0200, Sven Luther wrote: > [...] > > > > I wonder though, i thought you where not a DD, and so couldn't upload, > > is this correct ? > > That's correct; I had a sponsor ready to do the upload, though. Ah, ok. Sine i added you ad -guest to the alioth project, and you were not around, i decided to do it myself, which was not a smart move in the end. Friendly, Sven Luther
Re: kernel-patch-amd64
On Thu, Jul 08, 2004 at 02:34:55PM +0900, Horms wrote: > On Wed, Jul 07, 2004 at 09:46:15PM +0200, Sven Luther wrote: > > On Wed, Jul 07, 2004 at 02:05:37PM -0500, Troy Benjegerdes wrote: > > > On Sat, Jul 03, 2004 at 10:48:10PM +0200, Sven Luther wrote: > > > > On Sat, Jul 03, 2004 at 07:40:49PM +0200, Christoph Hellwig wrote: > > > > > On Fri, Jul 02, 2004 at 03:32:55PM +0200, Goswin von Brederlow wrote: > > > > > > Its also quite off the mark for amd64. The last kerel version had a > > > > > > 0 Byte > > > > > > patch for amd64 and only the current one has some patches in there > > > > > > to > > > > > > fix recent bugs. > > > > > > > > > > So what exact problems does the patch you propose solve? Which > > > > > systems > > > > > don't boot/corrupt data/start nuclear wars without it? Do you > > > > > understand what exactly the patch does? > > > > > > > > Well, Christoph, i have trouble understanding all this religiuous anti > > > > patch problem. As in the case of the Marvell driver, what is the problem > > > > in having the patch as is available to debian/unstable users, _WHILE_ we > > > > are working on cleaning the situation ? Also, again if the last kernel > > > > version (2.6.6) had a obyte patch, and the current one (2.6.7) has only > > > > bug fixes, it is more than probable that those patches will also be > > > > submitted upstream pretty soon. > > > > > > If someone (in this case Christoph and Viro) isn't around continually > > > trying to get people to submit upstream, the users lose out because the > > > patch(es) never get submitted and rot. Or it just keeps getting bigger and > > > bigger and never gets reviewed. > > > > I doubt this applies in this case though. > > > > > In the amd64 case, I haven't seen anyone point out what kernel.org 2.6.7 > > > is > > > missing that the big amd64 patch misses. > > > > Probably 2.6.8 development branch fixes and backports ? > > I believe that statement is a strong argument for splitting > up the patches, so their purpose can more easily be determined. > Though in this cause they likely would not need to be pushed upstream. Sure, but i believe that at this point getting the various other kernel port patch maintainers into the debian-kernel team is more important a goal, and it is not by yelling on them that this will happen. Friendly, Sven Luther
Re: preparations for 2.6.7-3
On Thu, 2004-07-08 at 07:56 +0200, Sven Luther wrote: [...] > > I wonder though, i thought you where not a DD, and so couldn't upload, > is this correct ? That's correct; I had a sponsor ready to do the upload, though. -- Andres Salomon <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: preparations for 2.6.7-3
On Wed, Jul 07, 2004 at 03:46:55PM -0400, Andres Salomon wrote: > On Wed, 2004-07-07 at 12:24, Sven Luther wrote: > > On Tue, Jul 06, 2004 at 04:33:09PM -0400, Andres Salomon wrote: > > > I would like to get kernel-source-2.6.7-3 out tomorrow, if possible. > > > Does anyone have anything pressing that needs to go in before -3 is > > > released? I've spoken to luther (who wanted me to wait until tomorrow), > > > hch, and wli; they're all fine w/ tomorrow (early morning, before > > > dinstall). I built kernel-source and kernel-image -i386 packages > > > yesterday, so I don't forsee any problems tomorrow. > > > > > > Jens? Anyone else? > > > > Ok, i am building and preparing to upload the kernel-source-2.6.7-3 > > package. If anyone still has an objection, please speak now. > > > > Friendly, > > > > Sven Luther > > > Cool. I had a busy night/morning, so I didn't get the chance to make > dinstall. Well, i failed to upload it in a way dinstall would accept, oh well. I wonder though, i thought you where not a DD, and so couldn't upload, is this correct ? Friendly, Sven Luther
Re: kernel-patch-amd64
On Wed, Jul 07, 2004 at 03:20:35PM -0500, Troy Benjegerdes wrote: > > Who took that decision ? And even then, how would it be all that > > different from the many alternative trees out there, like the -mm one > > Christoph refered to me recently. > > > > Nothing is stoping us from presenting usefull stuff to our unstable > > users while we are still working on it, is this not how free software > > works ? > > This may be okay for unstable, but I would love it if the next stable > release of debian shipped a 'pristine' (except for non-distributable > firmware) kernel.org kernel for ppc, x86, and amd64. Other arches will > probably need some patch. I understand you would love it, but is this reasonable ? The upstream release schedules and the debian one may or might not coincide, making your above mentioned goal an unreachable one, and during both the freeze and the stable lifetime, the package is due to diverge again, as at least security fixes are backported. > Do we have a mechanism for dropping patches as we move from > unstable->testing->stable ? Or a way to mark a package as "unstable > only" ? We simply do upload a package dropping some patches. It would be easy enough to drop patches from the kernel-source package with just removing them from the 00list file. But again, what if we are freezing and then releasing at a time before let's say 2.6.12 is released, and many of our 2.6.11 patches are already in the 2.6.12 development tree ? Again, i believe adhering too strictly to the dogma of shipping only pristine sources will hurt us more than it will help us. It is a worthy goal, but we have to step back into reality, and adapt to the different situation at hand. As long as the patches are of upstream quality, and are going submitted upstream, it matters not if they are already in the upstream tree or not. > > > 2) Getting the patch upstream allows upstream kernel hackers to review > > > it. This is of real interest to our users, since we ensure that they > > > will have a verified and accepted (read: supported) kernel. > > > > Except that it doesn't always work, often the upstream kernel hackers > > don't even care to read the patch and you wait forever for comments. > > Sometimes, but I think we now have a better chance if we keep Viro, HCH, > Benh, etc involved. Yep, i agree. Indeed, i hope that we are as near as upstream as possible, but let's stay flexible and realistic too. > If there is a specific patch that's submitted to kernel.org, and we get > no response, by all means, include it in the debian package, but if we > have a good reason to have it, and can make good technical points, we > can include it.. but it's got to be discussed first. Yep, as opposed to someone taking the decision alone without bothering to mention this to the team. > I looked over the amd64 patch, and it's all arch-specific code.. so I > don't have a real problem with it, assumeing the changes are slated to > show up in 2.6.8. So, why is everyone making an huge drama over it ? Instead of letting the amd64 guy into the team and into the kernel subversion repo, and working with him, instead of being agressive as the first response where ? It is preferable to the goal above to work with people, and bring the different arch patch maintainer into the fold of the debian-kernel team, than having them angry with us because we disconsider them, and them working their own stuff out of the team, and given the way debian works, there is nothing that we can do if they chose to do so. Friendly, Sven Luther > > -- > -- > Troy Benjegerdes'da hozer'[EMAIL PROTECTED] > > Somone asked my why I work on this free (http://www.fsf.org/philosophy/) > software stuff and not get a real job. Charles Shultz had the best answer: > > "Why do musicians compose symphonies and poets write poems? They do it > because life wouldn't have any meaning for them if they didn't. That's why > I draw cartoons. It's my life." -- Charles Shultz
Re: kernel-patch-amd64
On Wed, Jul 07, 2004 at 09:46:15PM +0200, Sven Luther wrote: > On Wed, Jul 07, 2004 at 02:05:37PM -0500, Troy Benjegerdes wrote: > > On Sat, Jul 03, 2004 at 10:48:10PM +0200, Sven Luther wrote: > > > On Sat, Jul 03, 2004 at 07:40:49PM +0200, Christoph Hellwig wrote: > > > > On Fri, Jul 02, 2004 at 03:32:55PM +0200, Goswin von Brederlow wrote: > > > > > Its also quite off the mark for amd64. The last kerel version had a 0 > > > > > Byte > > > > > patch for amd64 and only the current one has some patches in there to > > > > > fix recent bugs. > > > > > > > > So what exact problems does the patch you propose solve? Which systems > > > > don't boot/corrupt data/start nuclear wars without it? Do you > > > > understand what exactly the patch does? > > > > > > Well, Christoph, i have trouble understanding all this religiuous anti > > > patch problem. As in the case of the Marvell driver, what is the problem > > > in having the patch as is available to debian/unstable users, _WHILE_ we > > > are working on cleaning the situation ? Also, again if the last kernel > > > version (2.6.6) had a obyte patch, and the current one (2.6.7) has only > > > bug fixes, it is more than probable that those patches will also be > > > submitted upstream pretty soon. > > > > If someone (in this case Christoph and Viro) isn't around continually > > trying to get people to submit upstream, the users lose out because the > > patch(es) never get submitted and rot. Or it just keeps getting bigger and > > bigger and never gets reviewed. > > I doubt this applies in this case though. > > > In the amd64 case, I haven't seen anyone point out what kernel.org 2.6.7 is > > missing that the big amd64 patch misses. > > Probably 2.6.8 development branch fixes and backports ? I believe that statement is a strong argument for splitting up the patches, so their purpose can more easily be determined. Though in this cause they likely would not need to be pushed upstream. -- Horms
Re: 2.4 kernels
On Thu, Jul 08, 2004 at 10:22:54AM +0900, Horms wrote: > On Wed, Jul 07, 2004 at 03:29:48AM -0700, William Lee Irwin III wrote: > > On Wed, Jul 07, 2004 at 11:44:06AM +0900, Horms wrote: > > > What needs to be done? > > > > Basically, update cvs to the current 2.4 in order to get security fixes > > from newer mainline 2.4, and send out packages. > > I am more than happy to help with this. > By merging in the latest mainline I am assuming that > you mean 2.4.27-rc3 or something like that? > > All the security fixes that _I_ am aware of are fixed > as of 2.4.27-rc2. Sorry, that should be 2.4.27-rc3, CAN-2004-0497, the sys_chown() fix was inculded in that rc. -- Horms
