Bug#436723: Playing sound hands on powerbook3,5 with 2.6.21-2 kernel
Dave Vasilevsky has tracked down the commit that introduced the bug and some information about how it occurs http://article.gmane.org/gmane.linux.kernel/576080 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: K8 Kernel Image
Jim Crilly schrieb: On 09/02/07 04:59:02AM +0200, Sascha Conradi wrote: Hi, In debian there are several kernel images, 486,686,K7,AMD64 and so on... But what about K8 ? I think that a K8 image will give more optimization on 32bit systems when run on an K8 like cpu, doesn't it? Unless I'm really confused K8 is AMD64. Jim. No no!!! The AMD64 is a 64bit image!!! so you need the 64bit libs and by the way the old sempron without 64bit extension is allso K8 So this is not usable for some users with only 32bit cpu. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reducing number of i386 linux images
On Wed, Aug 22, 2007 at 11:40:59AM -0600, dann frazier wrote: Dropping 686-bigmem --- - 686-bigmem dies - 686 flavour acquires PAE support Please reread what I wrote: Rename 686-bigmem to 686-pae. Bastian -- A Vulcan can no sooner be disloyal than he can exist without breathing. -- Kirk, The Menagerie, stardate 3012.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reducing number of i386 linux images
On Wed, Aug 22, 2007 at 11:10:39PM -0600, dann frazier wrote: I hope it will be based on benchmarks Yes. It is based on the lack of benchmarks. I did not find anything that showed that the k7-optimization provides any not only theoretical difference. I see no reason to drop any flavours if there maybe a significant performance benefit for a significant part of our userbase[1]. Until someone shows significant performance benefits, I don't see why we should waste cpu and space to ship it. I know that gcc have different cost tables for generic i686 and k7. The same is true for k8 and em64t, but upstream said that distributors should not use it as it does not provide any benefit. Also noone else ships explicit k7. fwiw, a coworker is looking into the availability of a benchmark that should be good for comparing pae/non-pae. Someone said, mysql may be a usefull target. Can use much memory. Bastian -- Vulcans never bluff. -- Spock, The Doomsday Machine, stardate 4202.1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424605: marked as done (FTBFS with GCC 4.2: section type conflict)
Your message dated Sun, 2 Sep 2007 14:03:27 +0200 with message-id [EMAIL PROTECTED] and subject line gcc bug 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) ---BeginMessage--- Package: linux-2.6 Version: 2.6.20-3 Usertags: ftbfs-gcc-4.2 Your package fails to build with GCC 4.2 that was released a few days ago. There is a gcc-4.2 package in experimental and I guess it will show up in unstable soon. There are other, similar problems. I've started sending patches upstream. Automatic build of linux-2.6_2.6.20-3 on coconut0 by sbuild/ia64 0.49 ... CC arch/ia64/kernel/unaligned.o CC arch/ia64/kernel/unwind.o CC arch/ia64/kernel/mca.o arch/ia64/kernel/mca.c:275: error: __ksymtab_ia64_mlogbuf_finish causes a section type conflict make[5]: *** [arch/ia64/kernel/mca.o] Error 1 make[4]: *** [arch/ia64/kernel] Error 2 make[4]: Leaving directory `/build/tbm/linux-2.6-2.6.20/debian/build/build-ia64-none-itanium' -- Martin Michlmayr http://www.cyrius.com/ ---End Message--- ---BeginMessage--- This was actually a GCC bug that has been fixed. -- Martin Michlmayr http://www.cyrius.com/ ---End Message---
Bug#440529: linux-image-2.6.22-1-686: I/O errors for some USB masse storage
Package: linux-image-2.6.22-1-686 Version: 2.6.22-3 Severity: important After upgrade, I cannot use the USB mode of my nikon camera anymore (it used to work a couple of months ago). The first time it stopped working I was in 2.6.18. Upgrading to 2.6.22 didn't solve anything. Below is what I get from dmesg (essentially, I/O errors after the media is recognised). It is a camera with an SD card. I don't think the SD is faulty since it works perfectly on my other linux PC running mandriva, and on windows too. Btw, if I turn my camera to PTP mode, then it also works on this debian machine (with gtkam). But USB mode is much more handy for me and doesn't work anymore ! Important remark: my usb pendrives (1go and 2go) still work fine. dmesg output: usb 2-2: new full speed USB device using uhci_hcd and address 3 usb 2-2: configuration #1 chosen from 1 choice scsi7 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 3 usb-storage: waiting for device to settle before scanning usb-storage: device scan complete scsi 7:0:0:0: Direct-Access NIKOND50 1.00 PQ: 0 ANSI: 2 sd 7:0:0:0: [sda] 4019201 512-byte hardware sectors (2058 MB) sd 7:0:0:0: [sda] Write Protect is off sd 7:0:0:0: [sda] Mode Sense: 0f 00 00 00 sd 7:0:0:0: [sda] Assuming drive cache: write through sd 7:0:0:0: [sda] 4019201 512-byte hardware sectors (2058 MB) sd 7:0:0:0: [sda] Write Protect is off sd 7:0:0:0: [sda] Mode Sense: 0f 00 00 00 sd 7:0:0:0: [sda] Assuming drive cache: write through sda: sda1 sd 7:0:0:0: [sda] Attached SCSI removable disk end_request: I/O error, dev sda, sector 4019200 printk: 613 messages suppressed. Buffer I/O error on device sda, logical block 4019200 end_request: I/O error, dev sda, sector 4019200 Buffer I/O error on device sda, logical block 4019200 end_request: I/O error, dev sda, sector 4019200 Buffer I/O error on device sda, logical block 4019200 end_request: I/O error, dev sda, sector 4019200 Buffer I/O error on device sda, logical block 4019200 end_request: I/O error, dev sda, sector 4019200 Buffer I/O error on device sda, logical block 4019200 end_request: I/O error, dev sda, sector 4019200 Buffer I/O error on device sda, logical block 4019200 end_request: I/O error, dev sda, sector 4019200 Buffer I/O error on device sda, logical block 4019200 end_request: I/O error, dev sda, sector 40 Buffer I/O error on device sda, logical block 40 end_request: I/O error, dev sda, sector 41 Buffer I/O error on device sda, logical block 41 Buffer I/O error on device sda, logical block 42 end_request: I/O error, dev sda, sector 40 etc -- Package-specific info: ** Version: Linux version 2.6.22-1-686 (Debian 2.6.22-3) ([EMAIL PROTECTED]) (gcc version 4.1.3 20070718 (prerelease) (Debian 4.1.2-14)) #1 SMP Sun Jul 29 14:37:42 UTC 2007 ** Tainted: PFSRMB ** Kernel log: end_request: I/O error, dev sda, sector 243 end_request: I/O error, dev sda, sector 244 end_request: I/O error, dev sda, sector 243 end_request: I/O error, dev sda, sector 244 end_request: I/O error, dev sda, sector 243 end_request: I/O error, dev sda, sector 244 end_request: I/O error, dev sda, sector 243 end_request: I/O error, dev sda, sector 244 end_request: I/O error, dev sda, sector 243 end_request: I/O error, dev sda, sector 244 end_request: I/O error, dev sda, sector 243 end_request: I/O error, dev sda, sector 244 end_request: I/O error, dev sda, sector 243 end_request: I/O error, dev sda, sector 243 end_request: I/O error, dev sda, sector 244 end_request: I/O error, dev sda, sector 243 end_request: I/O error, dev sda, sector 244 end_request: I/O error, dev sda, sector 243 end_request: I/O error, dev sda, sector 244 end_request: I/O error, dev sda, sector 243 end_request: I/O error, dev sda, sector 244 end_request: I/O error, dev sda, sector 243 end_request: I/O error, dev sda, sector 244 end_request: I/O error, dev sda, sector 243 end_request: I/O error, dev sda, sector 244 end_request: I/O error, dev sda, sector 243 end_request: I/O error, dev sda, sector 244 end_request: I/O error, dev sda, sector 243 end_request: I/O error, dev sda, sector 244 end_request: I/O error, dev sda, sector 243 end_request: I/O error, dev sda, sector 244 end_request: I/O error, dev sda, sector 243 end_request: I/O error, dev sda, sector 243 end_request: I/O error, dev sda, sector 244 end_request: I/O error, dev sda, sector 243 end_request: I/O error, dev sda, sector 244 end_request: I/O error, dev sda, sector 243 end_request: I/O error, dev sda, sector 244 end_request: I/O error, dev sda, sector 243 end_request: I/O error, dev sda, sector 244 end_request: I/O error, dev sda, sector 243 end_request: I/O error, dev sda, sector 244 end_request: I/O error, dev sda, sector 243 end_request: I/O error, dev sda, sector 244 end_request: I/O error, dev sda, sector 251 end_request: I/O error, dev sda, sector 252 end_request: I/O error, dev sda, sector 243 end_request: I/O error, dev sda, sector 243 end_request: I/O error, dev sda,
Bug#440536: initramfs-tools: runaway modprobe loop: net-pf-1 and char-major-5-1
Package: initramfs-tools Version: 0.85h Severity: critical Justification: breaks the whole system Running kernel 2.6.16 on stable, root/boot on raid 1 on scsi devices, rest of system is lvm on raid 1 on same scsi devices. Upgrading from initrd-tools to initramfs-tools results in the error message: runaway modprobe loop on boot, and then hangs (hence critical). The looping messages are modprobe for: net-pf-1 char-major-5-1 I used modules=list and put the same list of modules in the initramfs config file as are in my initrd config file. When I unpack the cpio archive I see that initramfs added the module unix to the list, which of course is alised to net-pf-1. Also, I have no idea what char-major-5-1 is. -- Package-specific info: -- /proc/cmdline BOOT_IMAGE=Linux ro root=901 hdc=ide-cd -- /proc/filesystems ext3 ext2 cramfs iso9660 romfs udf xfs vfat -- lsmod Module Size Used by nvidia 4549332 16 dv1394 19020 0 video1394 17996 0 raw139425836 0 lirc_serial12800 0 bttv 160820 0 video_buf 20868 1 bttv btcx_risc 5128 1 bttv ir_common 9732 1 bttv lirc_i2c9348 2 lirc_dev 13940 2 lirc_serial,lirc_i2c snd_usb_audio 68800 0 snd_usb_lib14976 1 snd_usb_audio pwc86912 0 compat_ioctl32 1792 2 bttv,pwc ip_nat_irc 2944 0 ip_conntrack_irc7024 1 ip_nat_irc ip_nat_ftp 3584 0 ip_conntrack_ftp7536 1 ip_nat_ftp snd_emu10k1_synth 7296 0 snd_emux_synth 31744 1 snd_emu10k1_synth snd_seq_virmidi 7296 1 snd_emux_synth snd_seq_midi_emul 6272 1 snd_emux_synth snd_emu10k199108 1 snd_emu10k1_synth msp340028448 0 saa712711156 0 saa711513456 0 tda988715376 0 tuner 45612 0 v4l2_common 8064 4 bttv,pwc,msp3400,tuner snd_seq_dummy 4100 0 snd_seq_oss29568 0 snd_seq_midi8736 0 snd_seq_midi_event 7424 3 snd_seq_virmidi,snd_seq_oss,snd_seq_midi snd_seq47440 9 snd_emux_synth,snd_seq_virmidi,snd_seq_midi_emul,snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event snd_rawmidi23456 4 snd_usb_lib,snd_seq_virmidi,snd_emu10k1,snd_seq_midi snd_intel8x0 29084 0 snd_ac97_codec 81068 2 snd_emu10k1,snd_intel8x0 snd_ac97_bus2688 1 snd_ac97_codec snd_pcm_oss44704 0 snd_mixer_oss 16384 1 snd_pcm_oss snd_pcm74756 5 snd_usb_audio,snd_emu10k1,snd_intel8x0,snd_ac97_codec,snd_pcm_oss snd_seq_device 8972 8 snd_emu10k1_synth,snd_emux_synth,snd_emu10k1,snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq,snd_rawmidi ivtv 166544 1 snd_util_mem4864 2 snd_emux_synth,snd_emu10k1 firmware_class 10240 2 bttv,ivtv snd_timer 22020 3 snd_emu10k1,snd_seq,snd_pcm snd_hwdep 9348 3 snd_usb_audio,snd_emux_synth,snd_emu10k1 i2c_algo_bit8712 2 bttv,ivtv snd48228 15 snd_usb_audio,snd_emux_synth,snd_seq_virmidi,snd_emu10k1,snd_seq_oss,snd_seq,snd_rawmidi,snd_intel8x0,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_device,snd_timer,snd_hwdep v4l1_compat12676 1 ivtv tveeprom 14224 2 bttv,ivtv ehci_hcd 36488 0 i2c_core 20224 11 nvidia,bttv,lirc_i2c,msp3400,saa7127,saa7115,tda9887,tuner,ivtv,i2c_algo_bit,tveeprom soundcore 9696 1 snd e1000 93876 0 ohci1394 30768 2 dv1394,video1394 snd_page_alloc 10376 3 snd_emu10k1,snd_intel8x0,snd_pcm uhci_hcd 27532 0 ieee1394 286904 4 dv1394,video1394,raw1394,ohci1394 videodev9344 3 bttv,pwc,ivtv bcm5700 132908 0 ide_cd 36128 0 usbcore 119172 6 snd_usb_audio,snd_usb_lib,pwc,ehci_hcd,uhci_hcd ide_scsi 16388 0 sg 28572 0 sr_mod 14884 0 sd_mod 14592 19 raid5 21888 0 xor14728 1 raid5 raid1 19712 3 aic79xx 198104 12 scsi_transport_spi 21376 1 aic79xx vfat 12672 0 fat47132 1 vfat -- kernel-img.conf # Kernel Image management overrides # See kernel-img.conf(5) for details do_symlinks = No -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (700, 'stable'), (600, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages initramfs-tools
Bug#357982: marked as done (AHCI / Intel ICH6: lost interrupt)
Your message dated Sun, 2 Sep 2007 17:35:28 +0200 with message-id [EMAIL PROTECTED] and subject line closing old bugs: AHCI hangs on some Dell. 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) ---BeginMessage--- Package: linux-image-2.6.15-1-686-smp Version: 2.6.15-7bpo1 Severity: normal Yo! I'm experiencing hangs at boot with 'hda: lost interrupt' every few seconds being the last signs of life as soon as the ahci module is loaded (not sure about the exact boot sequence, but I think udev loads these drivers.) Deleting ahci.ko from disk causes the system to work, no idea which disk driver (just ide-generic?) The system is a DELL Latitude D810 Notebook. Using non-smp kernels or various boot flags (apm=off, noapic, ide=nodma) didn't change anything. PCI config below. (NOTE: I must admit that I don't have too much time to further diagnose the problem - I'm hoping that somebody else has the same problem. Also, I'm installing sarge + this kernel from backports.org via fai, so you may want to close the report quickly lest anybody suspects you of providing support for unofficial versions ;-) OTOH if somebody has an idea that this or that could just fix it, I'll gladly try to run kernel images. cheers -- vbi # lspci -v :00:00.0 Host bridge: Intel Corp. Mobile Memory Controller Hub (rev 03) Subsystem: Dell: Unknown device 0186 Flags: bus master, fast devsel, latency 0 Capabilities: [e0] #09 [2109] :00:01.0 PCI bridge: Intel Corp. Mobile Memory Controller Hub PCI Express Port (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: d000-dfff Memory behind bridge: dfd0-dfef Prefetchable memory behind bridge: d000-d7ff Capabilities: [88] #0d [] Capabilities: [80] Power Management version 2 Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [a0] #10 [0141] :00:1c.0 PCI bridge: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 Memory behind bridge: dfc0-dfcf Capabilities: [40] #10 [0141] Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [90] #0d [] Capabilities: [a0] Power Management version 2 :00:1d.0 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03) (prog-if 00 [UHCI]) Subsystem: Dell: Unknown device 0186 Flags: bus master, medium devsel, latency 0, IRQ 11 I/O ports at bf80 [size=32] :00:1d.1 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03) (prog-if 00 [UHCI]) Subsystem: Dell: Unknown device 0186 Flags: bus master, medium devsel, latency 0, IRQ 10 I/O ports at bf60 [size=32] :00:1d.2 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) (prog-if 00 [UHCI]) Subsystem: Dell: Unknown device 0186 Flags: bus master, medium devsel, latency 0, IRQ 9 I/O ports at bf40 [size=32] :00:1d.3 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03) (prog-if 00 [UHCI]) Subsystem: Dell: Unknown device 0186 Flags: bus master, medium devsel, latency 0, IRQ 5 I/O ports at bf20 [size=32] :00:1d.7 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03) (prog-if 20 [EHCI]) Subsystem: Dell: Unknown device 0186 Flags: bus master, medium devsel, latency 0, IRQ 11 Memory at ffa80800 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] #0a [20a0] :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev d3) (prog-if 01 [Subtractive decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=04, sec-latency=32 I/O behind bridge: 2000-2fff Memory behind bridge: dfb0-dfbf Prefetchable memory behind bridge: 5000-51f0 Capabilities: [50] #0d [] :00:1e.2 Multimedia audio controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97
sparc and testing migration
Hi, as you all are probably aware, we currently have some quite bad issues with the sparc buildds for some times, especially http://bugs.debian.org/433187 unkillable processes on the buildds. More and more packages which are ready for testing migration otherwise can't go in because of out-of-date-packages on sparc (including missing binNMUs). In past, we have decided on a case-by-case-basis to ignore such issues, or even force packages in which break other packages only on sparc. As the situation is now, we decided to make our lives easier, and always allow such packages to migrate to testing by hand if the only issue is on sparc, and the package transition is otherwise useful (i.e. fixing RC bugs, finishing a transition etc). This is not equivalent (yet) to ignore sparc in testing migration by scripts, but also not a healty sign for this architecture. I hope that the mentioned RC bug can be fixed soon - if so, we're happy to stop ignoring issues on sparc (or rather: we probably will find us in the situation that such cases cease to exist). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
linux-2.6_2.6.18.dfsg.1-13etch2_ia64.changes ACCEPTED
Accepted: linux-2.6_2.6.18.dfsg.1-13etch2.diff.gz to pool/main/l/linux-2.6/linux-2.6_2.6.18.dfsg.1-13etch2.diff.gz linux-2.6_2.6.18.dfsg.1-13etch2.dsc to pool/main/l/linux-2.6/linux-2.6_2.6.18.dfsg.1-13etch2.dsc linux-doc-2.6.18_2.6.18.dfsg.1-13etch2_all.deb to pool/main/l/linux-2.6/linux-doc-2.6.18_2.6.18.dfsg.1-13etch2_all.deb linux-headers-2.6.18-5-all-ia64_2.6.18.dfsg.1-13etch2_ia64.deb to pool/main/l/linux-2.6/linux-headers-2.6.18-5-all-ia64_2.6.18.dfsg.1-13etch2_ia64.deb linux-headers-2.6.18-5-all_2.6.18.dfsg.1-13etch2_ia64.deb to pool/main/l/linux-2.6/linux-headers-2.6.18-5-all_2.6.18.dfsg.1-13etch2_ia64.deb linux-headers-2.6.18-5-itanium_2.6.18.dfsg.1-13etch2_ia64.deb to pool/main/l/linux-2.6/linux-headers-2.6.18-5-itanium_2.6.18.dfsg.1-13etch2_ia64.deb linux-headers-2.6.18-5-mckinley_2.6.18.dfsg.1-13etch2_ia64.deb to pool/main/l/linux-2.6/linux-headers-2.6.18-5-mckinley_2.6.18.dfsg.1-13etch2_ia64.deb linux-headers-2.6.18-5_2.6.18.dfsg.1-13etch2_ia64.deb to pool/main/l/linux-2.6/linux-headers-2.6.18-5_2.6.18.dfsg.1-13etch2_ia64.deb linux-image-2.6.18-5-itanium_2.6.18.dfsg.1-13etch2_ia64.deb to pool/main/l/linux-2.6/linux-image-2.6.18-5-itanium_2.6.18.dfsg.1-13etch2_ia64.deb linux-image-2.6.18-5-mckinley_2.6.18.dfsg.1-13etch2_ia64.deb to pool/main/l/linux-2.6/linux-image-2.6.18-5-mckinley_2.6.18.dfsg.1-13etch2_ia64.deb linux-manual-2.6.18_2.6.18.dfsg.1-13etch2_all.deb to pool/main/l/linux-2.6/linux-manual-2.6.18_2.6.18.dfsg.1-13etch2_all.deb linux-patch-debian-2.6.18_2.6.18.dfsg.1-13etch2_all.deb to pool/main/l/linux-2.6/linux-patch-debian-2.6.18_2.6.18.dfsg.1-13etch2_all.deb linux-source-2.6.18_2.6.18.dfsg.1-13etch2_all.deb to pool/main/l/linux-2.6/linux-source-2.6.18_2.6.18.dfsg.1-13etch2_all.deb linux-support-2.6.18-5_2.6.18.dfsg.1-13etch2_all.deb to pool/main/l/linux-2.6/linux-support-2.6.18-5_2.6.18.dfsg.1-13etch2_all.deb linux-tree-2.6.18_2.6.18.dfsg.1-13etch2_all.deb to pool/main/l/linux-2.6/linux-tree-2.6.18_2.6.18.dfsg.1-13etch2_all.deb Override entries for your package: linux-2.6_2.6.18.dfsg.1-13etch2.dsc - optional devel linux-doc-2.6.18_2.6.18.dfsg.1-13etch2_all.deb - optional doc linux-headers-2.6.18-5-all-ia64_2.6.18.dfsg.1-13etch2_ia64.deb - optional devel linux-headers-2.6.18-5-all_2.6.18.dfsg.1-13etch2_ia64.deb - optional devel linux-headers-2.6.18-5-itanium_2.6.18.dfsg.1-13etch2_ia64.deb - optional devel linux-headers-2.6.18-5-mckinley_2.6.18.dfsg.1-13etch2_ia64.deb - optional devel linux-headers-2.6.18-5_2.6.18.dfsg.1-13etch2_ia64.deb - optional devel linux-image-2.6.18-5-itanium_2.6.18.dfsg.1-13etch2_ia64.deb - optional admin linux-image-2.6.18-5-mckinley_2.6.18.dfsg.1-13etch2_ia64.deb - optional admin linux-manual-2.6.18_2.6.18.dfsg.1-13etch2_all.deb - optional doc linux-patch-debian-2.6.18_2.6.18.dfsg.1-13etch2_all.deb - optional devel linux-source-2.6.18_2.6.18.dfsg.1-13etch2_all.deb - optional devel linux-support-2.6.18-5_2.6.18.dfsg.1-13etch2_all.deb - optional devel linux-tree-2.6.18_2.6.18.dfsg.1-13etch2_all.deb - optional devel Announcing to [EMAIL PROTECTED] Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
linux-2.6_2.6.18.dfsg.1-13etch2_sparc.changes ACCEPTED
Accepted: linux-headers-2.6.18-5-all-sparc_2.6.18.dfsg.1-13etch2_sparc.deb to pool/main/l/linux-2.6/linux-headers-2.6.18-5-all-sparc_2.6.18.dfsg.1-13etch2_sparc.deb linux-headers-2.6.18-5-all_2.6.18.dfsg.1-13etch2_sparc.deb to pool/main/l/linux-2.6/linux-headers-2.6.18-5-all_2.6.18.dfsg.1-13etch2_sparc.deb linux-headers-2.6.18-5-sparc32_2.6.18.dfsg.1-13etch2_sparc.deb to pool/main/l/linux-2.6/linux-headers-2.6.18-5-sparc32_2.6.18.dfsg.1-13etch2_sparc.deb linux-headers-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13etch2_sparc.deb to pool/main/l/linux-2.6/linux-headers-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13etch2_sparc.deb linux-headers-2.6.18-5-sparc64_2.6.18.dfsg.1-13etch2_sparc.deb to pool/main/l/linux-2.6/linux-headers-2.6.18-5-sparc64_2.6.18.dfsg.1-13etch2_sparc.deb linux-headers-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13etch2_sparc.deb to pool/main/l/linux-2.6/linux-headers-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13etch2_sparc.deb linux-headers-2.6.18-5-vserver_2.6.18.dfsg.1-13etch2_sparc.deb to pool/main/l/linux-2.6/linux-headers-2.6.18-5-vserver_2.6.18.dfsg.1-13etch2_sparc.deb linux-headers-2.6.18-5_2.6.18.dfsg.1-13etch2_sparc.deb to pool/main/l/linux-2.6/linux-headers-2.6.18-5_2.6.18.dfsg.1-13etch2_sparc.deb linux-image-2.6.18-5-sparc32_2.6.18.dfsg.1-13etch2_sparc.deb to pool/main/l/linux-2.6/linux-image-2.6.18-5-sparc32_2.6.18.dfsg.1-13etch2_sparc.deb linux-image-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13etch2_sparc.deb to pool/main/l/linux-2.6/linux-image-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13etch2_sparc.deb linux-image-2.6.18-5-sparc64_2.6.18.dfsg.1-13etch2_sparc.deb to pool/main/l/linux-2.6/linux-image-2.6.18-5-sparc64_2.6.18.dfsg.1-13etch2_sparc.deb linux-image-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13etch2_sparc.deb to pool/main/l/linux-2.6/linux-image-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13etch2_sparc.deb Override entries for your package: linux-headers-2.6.18-5-all-sparc_2.6.18.dfsg.1-13etch2_sparc.deb - optional devel linux-headers-2.6.18-5-all_2.6.18.dfsg.1-13etch2_sparc.deb - optional devel linux-headers-2.6.18-5-sparc32_2.6.18.dfsg.1-13etch2_sparc.deb - optional devel linux-headers-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13etch2_sparc.deb - optional devel linux-headers-2.6.18-5-sparc64_2.6.18.dfsg.1-13etch2_sparc.deb - optional devel linux-headers-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13etch2_sparc.deb - optional devel linux-headers-2.6.18-5-vserver_2.6.18.dfsg.1-13etch2_sparc.deb - optional devel linux-headers-2.6.18-5_2.6.18.dfsg.1-13etch2_sparc.deb - optional devel linux-image-2.6.18-5-sparc32_2.6.18.dfsg.1-13etch2_sparc.deb - optional admin linux-image-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13etch2_sparc.deb - optional admin linux-image-2.6.18-5-sparc64_2.6.18.dfsg.1-13etch2_sparc.deb - optional admin linux-image-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13etch2_sparc.deb - optional admin Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
modules should provide some meta package
Hi,
the official kernel modules do not provide a meta package. Eg. the
unionfs-modules-{2.6.18-5|2.6}-686 should provide unionfs-modules. Without
that meta package it is hardly possible to make a package dependency on that
module.
At the moment you have to list all the architectures with its flavors as
dependencies.
Eg:
Depends: unionfs-modules
instead of
Depends: unionfs-modules-2.6-468 | unionfs-modules-2.6-686 ...
Bye Michael
--
Don't cry because it is over, smile because it happened.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: modules should provide some meta package
On Sun, Sep 02, 2007 at 10:38:54PM +0200, Michael Walle wrote:
the official kernel modules do not provide a meta package. Eg. the
unionfs-modules-{2.6.18-5|2.6}-686 should provide unionfs-modules. Without
that meta package it is hardly possible to make a package dependency on that
module.
At the moment you have to list all the architectures with its flavors as
dependencies.
Eg:
Depends: unionfs-modules
instead of
Depends: unionfs-modules-2.6-468 | unionfs-modules-2.6-686 ...
You shouldn't be setting Package dependencies on kernel interfaces anyway,
because users can and do install kernels (and kernel modules) without using
the Debian packages, and because a dependency on a kernel interface doesn't
guarantee that the interface in question is available at package runtime.
--
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/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
i386 biarch support for lenny
The i386 biarch toolchain is built as biarch toolchain; the value of this is currently doubtful, because you only can use it in an i386 chroot on a machine running a 64bit kernel in the host system. With newer compiler versions apparently more hacks are needed to even build the biarch GCC, it currently ftbfs on a 32bit kernel (snapshot) on i386 and powerpc (afaik all our powerpc and i386 buildds run 32bit kernels). Do we still want to support the i386 biarch toolchain? If yes, the minimum support for that would be an amd64 kernel for the i386 architecture which is used on the buildds. Please could the kernel team first check the possibility of such an kernel? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: i386 biarch support for lenny
On Sun, Sep 02, 2007 at 11:11:37PM +0200, Matthias Klose wrote: Please could the kernel team first check the possibility of such an kernel? | linux-image-2.6.18-5-amd64 | 2.6.18.dfsg.1-13 |stable | amd64, i386 Available in etch and newer. Bastian -- The more complex the mind, the greater the need for the simplicity of play. -- Kirk, Shore Leave, stardate 3025.8 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: i386 biarch support for lenny
Bastian Blank writes: On Sun, Sep 02, 2007 at 11:11:37PM +0200, Matthias Klose wrote: Please could the kernel team first check the possibility of such an kernel? | linux-image-2.6.18-5-amd64 | 2.6.18.dfsg.1-13 |stable | amd64, i386 Available in etch and newer. nice, are all the i386 buildds runnig this kernel? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: K8 Kernel Image
On 2007-09-02, Sascha Conradi [EMAIL PROTECTED] wrote: The AMD64 is a 64bit image!!! so you need the 64bit libs and by the way the old sempron without 64bit extension is allso K8 So this is not usable for some users with only 32bit cpu. All 32 bit semprons are K7, not K8. All 64 bit AMD CPUs are = K8. -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362851: linux-2.6: sis ide controller 5513 detects and uses wrong udma modes
maximilian attems [EMAIL PROTECTED] wrote: tags 362851 moreinfo stop could you please retest against etch kernel? The issue is still present with both etch and sid kernels, however maybe it's already fixed upstream in 2.6.23-rc1 by commit 49521f97ccd3c2bf6e71a91cea8fe65d170fa4fb : ide: add short cables support This patch allows users to override both host and device side cable detection with ideX=ata66 kernel parameter. Thanks to this it should be now possible to use UDMA 2 modes on systems (laptops mainly) which use short 40-pin cable instead of 80-pin one. I have not tested yet a 2.6.23 kernel, but I hope to find the time to do that soon. Cheers, -- Giuseppe D'Angelo signature.asc Description: This is a digitally signed message part.
Re: K8 Kernel Image
On 09/03/07 02:41:29AM +0200, Sascha Conradi wrote: Robert Edmonds schrieb: On 2007-09-02, Sascha Conradi [EMAIL PROTECTED] wrote: The AMD64 is a 64bit image!!! so you need the 64bit libs and by the way the old sempron without 64bit extension is allso K8 So this is not usable for some users with only 32bit cpu. All 32 bit semprons are K7, not K8. All 64 bit AMD CPUs are = K8. Excuse me, but thats not right.. The Sempron was sell in three diferent versions of design and features. Sempron in K7 design, Sempron in K8 design but without the 64bit extensions. - Paris/Paris-128 (Revision CG), - Georgetown/Georgetown-128 (Revision D0),64bit is possible but it isn't often activated Sempron in K8 design with 64bit extensions. - Palermo (Revision E3), from this time it was called Sempron64 and it's a full featured K8/AMD64 So there exists some K8 Sempron CPUs without 64Bit. By the way, some time ago i was using a little Sempron in my notebook. And of course it was a K8, but no 64bit! Assuming that they do indeed call those chips K8s, what would be gained by having anther kernel flavor for them instead of running the k7 or 686 builds already available? Jim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
