Re: uncoordinated upload
* Frederik Schueler wrote: Do we have the resources to check the next upload for all architectures within a day or two? No. My Alpha needs 18 hours for building all three flavours which are available for alpha. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: uncoordinated upload
On Sun, Apr 23, 2006 at 02:27:22AM +0200, Frederik Schueler wrote: - for other changes, we need to make sure they don't break the ABI as happend with 2.6.16-7 when we disabled SECCOMP, and don't introduce build failures as 2.6.16.6 did on alpha. This needs built snapshots and automatic ABI checks. I suspect one day is not enough for every arch maintainer to check the changes and possibly veto the upload. What is a decent compromise here? Two days? Is this possible at all, considering we do not have more than one active developer for most architectures? Do we have the resources to check the next upload for all architectures within a day or two? If someone take i386, I should be able to do another two or three smaller arches on one of the openpower machines. But only if the compiler is buildable cleanly. - do external modules built against a previous version still work This is part of the ABI check. - do external modules still build That is why I think, we should control which binary modules packages get build and we can shedule rebuilds via our autobuilds without problems. - Arch maintainer should review patches in the -stable queue. The patch which broke alpha was posted as part of the regular -stable update and noone objected. In fact, I don't found anything about it until now on linux-kernel. Bastian -- Peace was the way. -- Kirk, The City on the Edge of Forever, stardate unknown signature.asc Description: Digital signature
Re: uncoordinated upload
On Sun, Apr 23, 2006 at 10:34:06AM +0200, Norbert Tretkowski wrote: No. My Alpha needs 18 hours for building all three flavours which are available for alpha. Which sort of machine? What happens if you use ccache? I currently build s390, powerpc and i386 in 3 hours. Bastian -- You! What PLANET is this! -- McCoy, The City on the Edge of Forever, stardate 3134.0 signature.asc Description: Digital signature
Re: uncoordinated upload
* Bastian Blank wrote: On Sun, Apr 23, 2006 at 10:34:06AM +0200, Norbert Tretkowski wrote: No. My Alpha needs 18 hours for building all three flavours which are available for alpha. Which sort of machine? EV56, 433 MHz, 192 MB RAM. What happens if you use ccache? It faster? I haven't tried it recently. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: uncoordinated upload
On Sun, Apr 23, 2006 at 12:26:46AM +0200, Bastian Blank wrote: 2.6.16.10 is scheduled for tomorrow. More than one upload per day is not good for the buildd network. I am more concerend about the installer... the first m68k upload came only with -7, since then there has never been enough time for the installer to process the m68k images: linux-2.6_2.6.16-7_m68k.changes is NEW linux-2.6_2.6.16-8_m68k.changes is NEW linux-2.6_2.6.16-9_m68k.changes is NEW Doesn't it take like a week to get this resolved? Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364429: initramfs-tools: fails to boot with EVMS root
Package: initramfs-tools Version: 0.59b Severity: important Since I upgraded initramfs-tools from 0.53c - 0.59b (testing machine), new initramfs-es refuse to boot my EVMS root. The boot log is a little long to paste, but a summary follows: [boot] Loading, please wait... Begin: Loading essential drivers... [unix] Done. Begin: Running /scripts/init-premount ... [load sata, nic, etc.] Done. Begin: Mounting root file system... ... Begin: Running /scripts/local-top ... [load dm, md] Error returned from evms_open_engine(): No such file or directory mknod: sda: File exists mknod: sda1: File exists [repeat for all other drives and partitions] [start md0 and md1] Done. Begin: Waiting for root file system... ... At this point, it hangs forever. I'm actually not 100% sure what the EVMS error means, but AFAIK it can be related to a missing /var/lock. I can't, however, find anything in the initramfs-tools changelogs about that. Any ideas? -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15.3 Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Versions of packages initramfs-tools depends on: ii busybox 1:1.01-4 Tiny utilities for small and embed ii cpio 2.6-11 GNU cpio -- a program to manage ar ii klibc-utils 1.2.4-1small statically-linked utilities ii module-init-tools 3.2.2-2tools for managing Linux kernel mo ii udev 0.089-1/dev/ and hotplug management daemo initramfs-tools recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358617: linux-image-2.6.16-1-686: please enable CONFIG_IPW2200_MONITOR=y
I'm with Noèl on this one. Monitor mode should be enabled ASAP. I'm even getting firmware errors even not being able to enable monitor mode so I see no point on having it enabled. Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, rápido, fiable.
Bug#364437: bttv: Overlayed video and vbi causing oops + lockup.
Package: linux-2.6 Severity: critical Justification: breaks the whole system Hopefully my classification justification is correct, otherwise I have to apologize. When I'm using xawtv in overlay mode and at the same time, nxtvepg is capturing vbi data, I can easily cause the console and syslog to be spammed with error messages like the following: Apr 23 04:27:14 abrasax kernel: bttv0: OCERR @ 1a44301c,bits: HSYNC OFLOW OCERR* Apr 23 04:27:20 abrasax last message repeated 156 times Apr 23 04:27:20 abrasax kernel: bttv0: OCERR @ 1a44301c,bits: HSYNC OFLOW FBUS OCERR* Apr 23 04:27:20 abrasax kernel: bttv0: OCERR @ 1a44301c,bits: HSYNC OFLOW OCERR* Apr 23 04:27:24 abrasax last message repeated 101 times Apr 23 04:27:24 abrasax nxtvepg[6584]: pid 6584: terminated by signal 15 Apr 23 04:27:24 abrasax nxtvepg[6584]: fd 8: closing connection Apr 23 04:27:24 abrasax nxtvepg[6584]: pid 6584: shutting down Apr 23 04:27:24 abrasax kernel: bttv0: OCERR @ 1a44301c,bits: HSYNC OFLOW OCERR* Apr 23 04:27:25 abrasax last message repeated 13 times How to reproduce: - Start nxtvepg and let acquisition start. I'm currently using the package with the vbi workaround for bug 362153 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=362153) but the same bug occured with 2.6.15 and before (with every 2.6 kernel I can remember, but I've been using grabdisplay mode for a while, which doesn't trigger it) - start xawtv, (or probably any other tv application that is able to display overlayed tv) in overlay mode! - Switch xawtv to fullscreen - Move the mouse and at the same time press 'f' to leave fullscreen mode The screen resolution won't be changed, the tv image stands still or gets garbled, and the console and syslog gets spammed with the OCERR @ messages. User interaction is still possible and turning off acquisition in nxtvepg frees xawtv from its misery. (i.e. it runs again, screen resolution is switched and the error messages stop). Kernel log continued: Apr 23 04:27:25 abrasax kernel: bttv0: timeout: drop=3 irq=46161/46161, risc=00c9510c, bits: HSYNC OFLOW Apr 23 04:27:25 abrasax kernel: bttv0: reset, reinitialize The reset, reinitialize does not occur, before the acquisition is stopped. Then eventually (in this example, almost immediately, but mostly some time later) an oops occurs. It's sometimes possible to save buffers and kill some applications but eventually the system will completely hang. Continued log: Apr 23 04:27:31 abrasax nxtvepg[6708]: pid 6708: started listening on local socket Apr 23 04:27:31 abrasax nxtvepg[6708]: fd 8: new connection from localhost via named socket Apr 23 04:27:52 abrasax kernel: Unable to handle kernel paging request at virtual address 602c4d7d Apr 23 04:27:52 abrasax kernel: printing eip: Apr 23 04:27:52 abrasax kernel: b014171b Apr 23 04:27:52 abrasax kernel: *pde = Apr 23 04:27:52 abrasax kernel: Oops: 0002 [#1] Apr 23 04:27:52 abrasax kernel: Modules linked in: radeon drm binfmt_misc rpcsec_gss_krb5 auth_rpcgss nfs nfsd exportfs lockd nfs_acl sunrpc autofs4 ipv6 dm_mod sha1 des nls_iso8859_15 8139cp sg sr_mod tuner tvaudio tsdev 8139too mii snd_ens1371 gameport snd_rawmidi snd_seq_device snd_ac97_codec snd_ac97_bus psmouse snd_pcm_oss pcspkr serio_raw floppy bttv video_buf firmware_class compat_ioctl32 i2c_algo_bit v4l2_common btcx_risc ir_common snd_mixer_oss tveeprom videodev snd_pcm snd_timer rtc aic7xxx scsi_transport_spi scsi_mod snd soundcore snd_page_alloc shpchp pci_hotplug amd_k7_agp ide_cd agpgart cdrom ohci_hcd i2c_amd756 i2c_core usbcore ext3 jbd mbcache ide_disk amd74xx generic ide_core evdev mousedev Apr 23 04:27:52 abrasax kernel: CPU:0 Apr 23 04:27:52 abrasax kernel: EIP:0060:[shmem_unlink+17/124]Not tainted VLI Apr 23 04:27:52 abrasax kernel: EFLAGS: 00210a17 (2.6.16-1-k7 #2) Apr 23 04:27:52 abrasax kernel: EIP is at shmem_unlink+0x11/0x7c Apr 23 04:27:52 abrasax kernel: eax: b0141c39 ebx: ecx: b0183144 edx: caf27dd4 Apr 23 04:27:52 abrasax kernel: esi: c9ef217c edi: caf27dd4 ebp: cb101000 esp: c0d8bf2c Apr 23 04:27:52 abrasax kernel: ds: 007b es: 007b ss: 0068 Apr 23 04:27:52 abrasax kernel: Process FvwmThumbnail (pid: 4909, threadinfo=c0d8a000 task=c0d41ab0) Apr 23 04:27:52 abrasax kernel: Stack: 0 c9ef217c caf27dd4 b01516e5 c9ef217c caf27dd4 Apr 23 04:27:52 abrasax kernel:caf27dd4 b284d238 caf27dd4 b01531f4 c9ef217c caf27dd4 bc0ff8d4 cbfe38a0 Apr 23 04:27:52 abrasax kernel:8ba40bd5 000d cb10100d 0010 0007 c0d8bfbc Apr 23 04:27:52 abrasax kernel: Call Trace: Apr 23 04:27:53 abrasax kernel: [vfs_unlink+168/211] vfs_unlink+0xa8/0xd3 Apr 23 04:27:53 abrasax kernel: [do_unlinkat+145/249] do_unlinkat+0x91/0xf9 Apr 23 04:27:53 abrasax kernel: [sysenter_past_esp+84/117] sysenter_past_esp+0x54/0x75 Apr 23 04:27:53 abrasax kernel: Code: 01 08 4c 27 b0 ff 07 53 57 e8 48 80 01 00 58
Bug#364429: marked as done (initramfs-tools: fails to boot with EVMS root)
Your message dated Sun, 23 Apr 2006 15:26:36 +0200 with message-id [EMAIL PROTECTED] and subject line initramfs-tools: fails to boot with EVMS root 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: initramfs-tools Version: 0.59b Severity: important Since I upgraded initramfs-tools from 0.53c - 0.59b (testing machine), new initramfs-es refuse to boot my EVMS root. The boot log is a little long to paste, but a summary follows: [boot] Loading, please wait... Begin: Loading essential drivers... [unix] Done. Begin: Running /scripts/init-premount ... [load sata, nic, etc.] Done. Begin: Mounting root file system... ... Begin: Running /scripts/local-top ... [load dm, md] Error returned from evms_open_engine(): No such file or directory mknod: sda: File exists mknod: sda1: File exists [repeat for all other drives and partitions] [start md0 and md1] Done. Begin: Waiting for root file system... ... At this point, it hangs forever. I'm actually not 100% sure what the EVMS error means, but AFAIK it can be related to a missing /var/lock. I can't, however, find anything in the initramfs-tools changelogs about that. Any ideas? -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15.3 Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Versions of packages initramfs-tools depends on: ii busybox 1:1.01-4 Tiny utilities for small and embed ii cpio 2.6-11 GNU cpio -- a program to manage ar ii klibc-utils 1.2.4-1small statically-linked utilities ii module-init-tools 3.2.2-2tools for managing Linux kernel mo ii udev 0.089-1/dev/ and hotplug management daemo initramfs-tools recommends no packages. -- no debconf information ---End Message--- ---BeginMessage--- On Sun, Apr 23, 2006 at 02:08:31PM +0200, Steinar H. Gunderson wrote: Since I upgraded initramfs-tools from 0.53c - 0.59b (testing machine), new initramfs-es refuse to boot my EVMS root. The boot log is a little long to paste, but a summary follows: Nevermind, I regenerated the initramfs, and this time it went smooth. Some transient problem with /lib/evms/* not being copied, it seems... /* Steinar */ -- Homepage: http://www.sesse.net/ ---End Message---
kernel-image-2.4.27-s390 and ndiswrapper-modules-i386 need update in unstable
Hi Bastian, kernel team, Both kernel-image-2.4.27-s390 and ndiswrapper-modules-i386 (for the latter, Andres has indicated to me the kernel team can decide about it) have had a security upload, but are yet still missing in proposed updates. They both didn't get an upload yet since sarge was released in unstable, and being kernel-related packages, are definitely outdated. The security upload had an ABI change, and unlike regular security uploads, those combined with package name changes are not (yet) supported. Quite a borderline case, and the outdateness of the unstable packages needs to be dealt with one way or the other anyway, so: What do with those two packages? Can I remove them? Will you update them? If you want either or both removed, please file a bug on ftp.debian.org requesting so, or alternatively update the package(s) one of these days. Of course, if they are removed, they can always later be reintroduced. Thanks in advance, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
problem loading gamecon module
Hi, Since I migrate to Debian I can't use my joysticks anymore, because when I type: # /sbin/modprobe gamecon map=0,1,0,1,1,1 # jstest /dev/input/js0 My system freezes. The same happen with: # /sbin/insmod /lib/modules/2.6.15-1-486/kernel/drivers/input/joystick/gamecon.ko gamecon map=0,1,0,1,1,1 My system is Debian testing, kernel: 2.6.15-1-486 CPU: AMD Sempron(tm) 2800+ SNES Joystick at parallel port Any ideas? Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: your mail
Processing commands for [EMAIL PROTECTED]: retitle 361674 please do not use mdrun at all Bug#361674: problems with using mdrun /dev Changed Bug title. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361674: please do not use mdrun at all
mdrun does not respect the device minor numbers at all... this can totally mess up the ordering of md devices and screw with static mounts (note that while mounting by label/uuid is preferable it isn't always available -- for example XFS external log partitions cannot be specified by label or uuid). see bug#354705 -- mdrun is set to be deprecated. it would eliminate a lot of linux-raid bug reports if initramfs-tools would set up only the root raid, using something like i've suggested (and tested) for yaird in bug#351183: mdadm -Ac partitions /dev/md$N --uuid $UUID there is further discussion of initramfs in modern mdadm packages (i.e. 2.4.1) in README.initramfs... for example you may wish to add --auto=part to that command as well. thanks -dean -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: severity of 364437 is important
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.19 # hardware/driver-specific severity 364437 important Bug#364437: bttv: Overlayed video and vbi causing oops + lockup. Severity set to `important'. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#364482: mtouchusb.txt.gz: add introduction
Processing commands for [EMAIL PROTECTED]: reassign 364482 linux-2.6 Bug#364482: mtouchusb.txt.gz: add introduction Warning: Unknown package 'linux-doc-2.6.12' Bug reassigned from package `linux-doc-2.6.12' to `linux-2.6'. -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364338: 2.4.1
from glibc: * Bumped the minimum kernel to 2.4.1 instead of 2.4.0 as there are some important new features in this version. Thanks to Petr Salinger for noticing me. So it needs to use LD_ASSUME_KERNEL=2.4.1. -- see shy jo signature.asc Description: Digital signature
Bug#363997: #363997: linux-2.6: Some Toshiba laptops no longer reboot correctly
tag 363997 upstream merge 363997 360336 thanks Latest from upstream is that the patch I linked to in [1] will be included in 2.6.10, so I suggest just waiting for that. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363997;msg=5 pgpInu0p5G758.pgp Description: PGP signature
Processed: #363997: linux-2.6: Some Toshiba laptops no longer reboot correctly
Processing commands for [EMAIL PROTECTED]: tag 363997 upstream Bug#363997: linux-2.6: Some Toshiba laptops no longer reboot correctly There were no tags set. Tags added: upstream merge 363997 360336 Bug#360336: linux-2.6: Allows processor to overheat on Toshiba Satellite A40 Bug#363997: linux-2.6: Some Toshiba laptops no longer reboot correctly Merged 360336 363997. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: severity of 318326 is important
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.16 severity 318326 important Bug#318326: initrd-tools: System with 3ware 9500 fails to boot after clean Sarge install Severity set to `important'. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processing of initrd-tools_0.1.84.1_i386.changes
initrd-tools_0.1.84.1_i386.changes uploaded successfully to localhost along with the files: initrd-tools_0.1.84.1.dsc initrd-tools_0.1.84.1.tar.gz initrd-tools_0.1.84.1_all.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
initrd-tools_0.1.84.1_i386.changes ACCEPTED
Accepted: initrd-tools_0.1.84.1.dsc to pool/main/i/initrd-tools/initrd-tools_0.1.84.1.dsc initrd-tools_0.1.84.1.tar.gz to pool/main/i/initrd-tools/initrd-tools_0.1.84.1.tar.gz initrd-tools_0.1.84.1_all.deb to pool/main/i/initrd-tools/initrd-tools_0.1.84.1_all.deb Announcing to debian-devel-changes@lists.debian.org Setting bugs to severity fixed: 364338 Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Fixed in NMU of initrd-tools 0.1.84.1
tag 364338 + fixed quit This message was generated automatically in response to a non-maintainer upload. The .changes file follows. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 23 Apr 2006 18:59:54 -0400 Source: initrd-tools Binary: initrd-tools Architecture: source all Version: 0.1.84.1 Distribution: unstable Urgency: high Maintainer: Debian kernel team debian-kernel@lists.debian.org Changed-By: Joey Hess [EMAIL PROTECTED] Description: initrd-tools - tools to create initrd image for prepackaged Linux kernel Closes: 364338 Changes: initrd-tools (0.1.84.1) unstable; urgency=high . * NMU * Use LD_ASSUME_KERNEL=2.4.1 since glibc has been changed to refuse to work with kernel 2.4(.0). Closes: #364338 Files: bf01a0f4bac1b25166371503f8aa9022 714 utils optional initrd-tools_0.1.84.1.dsc 144e8b8549552ebad257a7b2ed90ace4 29229 utils optional initrd-tools_0.1.84.1.tar.gz 4ce523eb96a32cb6502f7abf2257d5f4 32130 utils optional initrd-tools_0.1.84.1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFETBdf2tp5zXiKP0wRAgPEAJ9+KC8z/QgZm5GH1dskZ4dboq9MKQCfYMT+ ccllWcR2/GVPYh57u/PL/WE= =AYlR -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301063: marked as done (kernel-source-2.6.10: emu10k driver broken in version 6 of this package)
Your message dated Sun, 23 Apr 2006 16:42:53 -0700 (PDT) with message-id [EMAIL PROTECTED] and subject line Bug#301063: kernel-source-2.6.10: emu10k driver broken in version 6 of this package 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: kernel-source-2.6.10 Version: 2.6.10-6 Severity: normal After untarring 2.6.10-6 and recompiling (w/o changing my configuration), snd no longer works. Downgrading to my previous kernel (compiled from 2.6.10-5) fixes the problem. I see the following error message on startup: Mar 23 10:16:59 cavy kernel: snd_hwdep: Unknown symbol snd_info_free_entry Mar 23 10:16:59 cavy kernel: snd_hwdep: Unknown symbol snd_unregister_oss_device Mar 23 10:16:59 cavy kernel: snd_hwdep: Unknown symbol snd_register_oss_device Mar 23 10:16:59 cavy kernel: snd_hwdep: Unknown symbol snd_ctl_register_ioctl Mar 23 10:16:59 cavy kernel: snd_hwdep: Unknown symbol snd_card_file_add Mar 23 10:16:59 cavy kernel: snd_hwdep: Unknown symbol snd_iprintf Mar 23 10:16:59 cavy kernel: snd_hwdep: Unknown symbol snd_unregister_device Mar 23 10:16:59 cavy kernel: snd_hwdep: Unknown symbol snd_device_new Mar 23 10:16:59 cavy kernel: snd_hwdep: Unknown symbol snd_ctl_unregister_ioctl Mar 23 10:16:59 cavy kernel: snd_hwdep: Unknown symbol snd_card_file_remove Mar 23 10:16:59 cavy kernel: snd_hwdep: Unknown symbol snd_info_unregister Mar 23 10:16:59 cavy kernel: snd_hwdep: Unknown symbol snd_register_device Mar 23 10:16:59 cavy kernel: snd_timer: Unknown symbol snd_info_register Mar 23 10:16:59 cavy kernel: snd_timer: Unknown symbol snd_info_create_module_entry Mar 23 10:16:59 cavy kernel: snd_timer: Unknown symbol snd_info_free_entry Mar 23 10:16:59 cavy kernel: snd_timer: Unknown symbol snd_iprintf Mar 23 10:16:59 cavy kernel: snd_timer: Unknown symbol snd_ecards_limit Mar 23 10:16:59 cavy kernel: snd_timer: Unknown symbol snd_oss_info_register Mar 23 10:16:59 cavy kernel: snd_timer: Unknown symbol snd_unregister_device Mar 23 10:16:59 cavy kernel: snd_timer: Unknown symbol snd_device_new Mar 23 10:16:59 cavy kernel: snd_timer: Unknown symbol snd_kmalloc_strdup Mar 23 10:16:59 cavy kernel: snd_timer: Unknown symbol snd_info_unregister Mar 23 10:16:59 cavy kernel: snd_timer: Unknown symbol snd_register_device Mar 23 10:16:59 cavy kernel: snd_timer: Unknown symbol snd_info_register Mar 23 10:16:59 cavy kernel: snd_timer: Unknown symbol snd_info_create_module_entry Mar 23 10:16:59 cavy kernel: snd_timer: Unknown symbol snd_info_free_entry Mar 23 10:16:59 cavy kernel: snd_timer: Unknown symbol snd_iprintf Mar 23 10:16:59 cavy kernel: snd_timer: Unknown symbol snd_ecards_limit Mar 23 10:16:59 cavy kernel: snd_timer: Unknown symbol snd_oss_info_register Mar 23 10:16:59 cavy kernel: snd_timer: Unknown symbol snd_unregister_device Mar 23 10:16:59 cavy kernel: snd_timer: Unknown symbol snd_device_new Mar 23 10:16:59 cavy kernel: snd_timer: Unknown symbol snd_kmalloc_strdup Mar 23 10:16:59 cavy kernel: snd_timer: Unknown symbol snd_info_unregister Mar 23 10:16:59 cavy kernel: snd_timer: Unknown symbol snd_register_device Mar 23 10:16:59 cavy kernel: snd_pcm: Unknown symbol snd_info_register Mar 23 10:16:59 cavy kernel: snd_pcm: Unknown symbol snd_info_create_module_entry Mar 23 10:16:59 cavy kernel: snd_pcm: Unknown symbol snd_timer_notify Mar 23 10:16:59 cavy kernel: snd_pcm: Unknown symbol snd_timer_interrupt Mar 23 10:16:59 cavy kernel: snd_pcm: Unknown symbol snd_info_free_entry Mar 23 10:16:59 cavy kernel: snd_pcm: Unknown symbol snd_info_get_str Mar 23 10:16:59 cavy kernel: snd_pcm: Unknown symbol snd_ctl_register_ioctl Mar 23 10:16:59 cavy kernel: snd_pcm: Unknown symbol snd_card_file_add Mar 23 10:16:59 cavy kernel: snd_pcm: Unknown symbol snd_iprintf Mar 23 10:16:59 cavy kernel: snd_pcm: Unknown symbol snd_major Mar 23 10:16:59 cavy kernel: snd_pcm: Unknown symbol snd_unregister_device Mar 23 10:16:59 cavy kernel: snd_pcm: Unknown symbol snd_timer_new Mar 23 10:16:59 cavy kernel: snd_pcm: Unknown symbol snd_device_new Mar 23 10:16:59 cavy kernel: snd_pcm: Unknown symbol snd_ctl_unregister_ioctl Mar 23 10:16:59 cavy kernel: snd_pcm: Unknown symbol snd_info_create_card_entry Mar 23 10:16:59 cavy kernel: snd_pcm: Unknown symbol snd_power_wait Mar 23 10:16:59 cavy kernel: snd_pcm: Unknown symbol snd_device_free Mar 23 10:16:59 cavy kernel: snd_pcm: Unknown symbol snd_card_file_remove Mar 23 10:16:59 cavy kernel: snd_pcm: Unknown symbol snd_info_unregister Mar 23 10:16:59 cavy kernel: snd_pcm: Unknown symbol snd_device_register Mar
Processed: Fixed in NMU of initrd-tools 0.1.84.1
Processing commands for [EMAIL PROTECTED]: tag 364338 + fixed Bug#364338: LD_ASSUME_KERNEL is broken Tags were: d-i Tags added: fixed quit Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364516: this bug..
Hi Ted.. to summarize what needs doing for this bug, /usr/share/initrd-tools/scripts/e2fsprogs currently contains LD_ASSUME_KERNEL=2.4. This needs to change to LD_ASSUME_KERNEL=2.4.1 -- see shy jo signature.asc Description: Digital signature
Processed: reassign 364516 to e2fsprogs
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.16 reassign 364516 e2fsprogs Bug#364516: LD_ASSUME_KERNEL is broken Bug reassigned from package `initrd-tools' to `e2fsprogs'. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: uncoordinated upload
* Norbert Tretkowski wrote: * Bastian Blank wrote: Norbert Tretkowski wrote: I can't remember notices before 2.6.16-8 and 2.6.16-9 were uploaded. There was. Where? Bastian? I'm still interested where the uploads of 2.6.16-8 and 2.6.16-9 have been announced. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
