Re: which kernel version for etch?
On Wed, 10 May 2006, Bastian Blank wrote: Just provide them and either they want them (at least for s390, I do) or they don't. For the out-of-tree modules, we will see it in the next days, if it works. I think this should be done in at most 4 days. If it does not work, we have to take down the law and build them ourself. Sorry, I kept mentioning that I'm working on the out-of-tree module stuff, but lately I'm completely swamped with sparc and other issues, so it wasn't going anywhere. I have some preliminary draft of the policy and the foundation of a sample module package in the people/jurij directory in svn. If it's of any use, feel free to adopt it, otherwise just go ahead with your plans (and I'll try to document everything afterwards ;-). Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#363235: backports 2.6.15 avoid OOPS with kernel-image-2.6.8-3-686
after trying new RAM and different swap partitions on different disks, i installed kernel 2.6.15 from backports.org. the machine has now been up for 8 days with no problems. this suggests to me that there is a problem in Debian's stable 2.6 kernel which has been fixed between 2.6.8-3 and 2.6.15. if anyone wants me to try something to attempt to debug further, please drop me a mail. thanks, d -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
On Tue, 9 May 2006, Frederik Schueler wrote: Considering the current upstream 2.6 development model on one side, and Adrian Bunks intention to maintain 2.6.16.x for the next 2-3 years on the other side - backporting drivers and other updates like the 2.4 line is handled -, makes the 2.6.16.x line an ideal candidate for the purpose of a release kernel for Etch. The choice looks easy then :-). One major issue is currently open for 2.6.16: ppc/PrEP support. Finding a solution for this is a show-stopper, if we want to go the 2.6.16.x path. The second show-stopper is (IMHO) the missing sparc niagara support, which was added in 2.6.17-rc. I guess it should not be too hard to backport. I believe that Fabio did patch in the Niagara support into the Ubuntu kernels even before 2.6.17-rc appeared, so we probably can just leech the patches from there. I'll discuss it with him. There is another sparc consideration in play. For a while we've had problems with SMP kernels, which would randomly crash under high load. As this was affecting buildds, it was one of the main reasons for not qualifying sparc as a release arch. Currently the buildds are running 2.6.17-rc1, and James Troup mentioned that he didn't see them crash for a while now with this kernel. If 2.6.17-rc1 indeed turns out to be stable and 2.6.16.x will not (it hasn't been tested yet), that would be one of the strong reasons to prefer 2.6.17 on sparc. At the moment we do not have enough information though. Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#354378: nforce2 ide controller doesn't work properly
Processing commands for [EMAIL PROTECTED]: > package linux-image-2.6.15-1-686 Ignoring bugs not assigned to: linux-image-2.6.15-1-686 > close 354378 Bug#354378: linux-image-2.6.15-1-686: nforce2 ide controller doesn't work properly 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug closed, send any further explanations to Emil Nowak <[EMAIL PROTECTED]> > 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#354378: nforce2 ide controller doesn't work properly
package linux-image-2.6.15-1-686 close 354378 thanks It was related to yiard which generated my initrd. Of course yarids ramdisk don't support hardware upgrades, and so my controller wasn't working then. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
On Wed, May 10, 2006 at 11:36:06PM +0200, Sven Luther wrote: > On Wed, May 10, 2006 at 09:35:56PM +0200, Frederik Schueler wrote: > > Hello Sven, > > > > On Wed, May 10, 2006 at 11:02:29AM +0200, Sven Luther wrote: > > > I am little interested in > > > going this way, if it means another flamewar between me and the d-i team, > > > with > > > everyone else watching silently. > > > > > > Andreas Barth, you claimed that you could see strong reason not to go this > > > way, please could you comment on them now in this thread. > > > > Please let's keep this problem you and some other developers have with > > each other out of here. IMHO it has reached a point where only personal > > mediation could help, and every additional word lost on it here or on > > IRC will just make it worse. > > Huh ? What has this to do with this ? Andreas told us on irc that he knew of > several serious reasons why we should not merge the .udebs into the linux-2.6 > package. I am just asking that he don't keep those reasons secret, but tell > them to us here. > > Is that also too much to ask ? > > > Sven: I would like you to not partecipate in any discussion concerning > > d-i or kernel udebs - at least as long as you use that very contribution > > to raise this issue again and again. > > Well, i am seriously interested in knowing what reservations Andreas had, that > he mentioned on irc, and have asked him now a couple of times to state them. I > believe that this information he has and seems unwilling to share for some > obscure reason, do indeed belong to this thread. Oh well, it seems after all, Andreas Barth had no reservations, but only some second hand objections from the d-i team. Andreas, why didn't you say so the first time then ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
On Wed, May 10, 2006 at 09:35:56PM +0200, Frederik Schueler wrote: > Hello Sven, > > On Wed, May 10, 2006 at 11:02:29AM +0200, Sven Luther wrote: > > I am little interested in > > going this way, if it means another flamewar between me and the d-i team, > > with > > everyone else watching silently. > > > > Andreas Barth, you claimed that you could see strong reason not to go this > > way, please could you comment on them now in this thread. > > Please let's keep this problem you and some other developers have with > each other out of here. IMHO it has reached a point where only personal > mediation could help, and every additional word lost on it here or on > IRC will just make it worse. Huh ? What has this to do with this ? Andreas told us on irc that he knew of several serious reasons why we should not merge the .udebs into the linux-2.6 package. I am just asking that he don't keep those reasons secret, but tell them to us here. Is that also too much to ask ? > Sven: I would like you to not partecipate in any discussion concerning > d-i or kernel udebs - at least as long as you use that very contribution > to raise this issue again and again. Well, i am seriously interested in knowing what reservations Andreas had, that he mentioned on irc, and have asked him now a couple of times to state them. I believe that this information he has and seems unwilling to share for some obscure reason, do indeed belong to this thread. As for d-i. Well, the d-i team doesn't exist for me anymore, so i am going to ignore them for any discussion or flame or whatever. Andreas is not part of the d-i team though, and he said he had reservation about the plan to merge the .udebs, and ... Well, i am repeating myself. As for mediation, i believe there is no mediation possible. I asked the DPL to mediate on this, and the result was a joke. I mean, go read it on debian-boot if you are interested, but i will no more lose time with those people. > Your opinion is highly welcome otherwise, of course. Cool. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#358288: Loading speedstep-centrino instead of acpi-cpufreq also solves the bug for me
Just wanted to tell you...:-) /me will no more try to understand what's happening in the upstream kernel maintenance, which could explain such changesanyway, basta...:-) I'll have mor ebattery power in ym trip to Debconf..:) -- signature.asc Description: Digital signature
linux-2.6_2.6.16-13_powerpc.changes is NEW
kernel-image-2.6-power3-smp_2.6.16-13_powerpc.deb to pool/main/l/linux-2.6/kernel-image-2.6-power3-smp_2.6.16-13_powerpc.deb kernel-image-2.6-power3_2.6.16-13_powerpc.deb to pool/main/l/linux-2.6/kernel-image-2.6-power3_2.6.16-13_powerpc.deb kernel-image-2.6-power4-smp_2.6.16-13_powerpc.deb to pool/main/l/linux-2.6/kernel-image-2.6-power4-smp_2.6.16-13_powerpc.deb kernel-image-2.6-power4_2.6.16-13_powerpc.deb to pool/main/l/linux-2.6/kernel-image-2.6-power4_2.6.16-13_powerpc.deb kernel-image-2.6-powerpc-smp_2.6.16-13_powerpc.deb to pool/main/l/linux-2.6/kernel-image-2.6-powerpc-smp_2.6.16-13_powerpc.deb kernel-image-2.6-powerpc_2.6.16-13_powerpc.deb to pool/main/l/linux-2.6/kernel-image-2.6-powerpc_2.6.16-13_powerpc.deb kernel-image-power3-smp_2.6.16-13_powerpc.deb to pool/main/l/linux-2.6/kernel-image-power3-smp_2.6.16-13_powerpc.deb kernel-image-power3_2.6.16-13_powerpc.deb to pool/main/l/linux-2.6/kernel-image-power3_2.6.16-13_powerpc.deb kernel-image-power4-smp_2.6.16-13_powerpc.deb to pool/main/l/linux-2.6/kernel-image-power4-smp_2.6.16-13_powerpc.deb kernel-image-power4_2.6.16-13_powerpc.deb to pool/main/l/linux-2.6/kernel-image-power4_2.6.16-13_powerpc.deb kernel-image-powerpc-smp_2.6.16-13_powerpc.deb to pool/main/l/linux-2.6/kernel-image-powerpc-smp_2.6.16-13_powerpc.deb kernel-image-powerpc_2.6.16-13_powerpc.deb to pool/main/l/linux-2.6/kernel-image-powerpc_2.6.16-13_powerpc.deb linux-2.6_2.6.16-13.diff.gz to pool/main/l/linux-2.6/linux-2.6_2.6.16-13.diff.gz linux-2.6_2.6.16-13.dsc to pool/main/l/linux-2.6/linux-2.6_2.6.16-13.dsc linux-doc-2.6.16_2.6.16-13_all.deb to pool/main/l/linux-2.6/linux-doc-2.6.16_2.6.16-13_all.deb linux-headers-2.6-powerpc-miboot_2.6.16-13_powerpc.deb to pool/main/l/linux-2.6/linux-headers-2.6-powerpc-miboot_2.6.16-13_powerpc.deb linux-headers-2.6-powerpc-smp_2.6.16-13_powerpc.deb to pool/main/l/linux-2.6/linux-headers-2.6-powerpc-smp_2.6.16-13_powerpc.deb linux-headers-2.6-powerpc64_2.6.16-13_powerpc.deb to pool/main/l/linux-2.6/linux-headers-2.6-powerpc64_2.6.16-13_powerpc.deb linux-headers-2.6-powerpc_2.6.16-13_powerpc.deb to pool/main/l/linux-2.6/linux-headers-2.6-powerpc_2.6.16-13_powerpc.deb linux-headers-2.6-vserver-powerpc64_2.6.16-13_powerpc.deb to pool/main/l/linux-2.6/linux-headers-2.6-vserver-powerpc64_2.6.16-13_powerpc.deb linux-headers-2.6-vserver-powerpc_2.6.16-13_powerpc.deb to pool/main/l/linux-2.6/linux-headers-2.6-vserver-powerpc_2.6.16-13_powerpc.deb (new) linux-headers-2.6.16-2-all-powerpc_2.6.16-13_powerpc.deb optional devel All header files for Linux kernel 2.6.16 This package depends against all architecture-specific kernel header files for Linux kernel version 2.6.16, generally used for building out-of-tree kernel modules. (new) linux-headers-2.6.16-2-all_2.6.16-13_powerpc.deb optional devel All header files for Linux kernel 2.6.16 This package depends against all architecture-specific kernel header files for Linux kernel version 2.6.16, generally used for building out-of-tree kernel modules. (new) linux-headers-2.6.16-2-powerpc-miboot_2.6.16-13_powerpc.deb optional devel Header files for Linux kernel 2.6.16 on powerpc-miboot-class machines This package provides the architecture-specific kernel header files for Linux kernel 2.6.16 on powerpc-miboot-class machines, generally used for building out-of-tree kernel modules. These files are going to be installed into /usr/src/linux-headers-2.6.16-2-powerpc-miboot, and can be used for building modules that load into the kernel provided by the linux-image-2.6.16-2-powerpc-miboot package. . This packages is produced using an updated kernel packaging system and replaces older kernel-headers packages (new) linux-headers-2.6.16-2-powerpc-smp_2.6.16-13_powerpc.deb optional devel Header files for Linux kernel 2.6.16 on powerpc-smp-class machines This package provides the architecture-specific kernel header files for Linux kernel 2.6.16 on powerpc-smp-class machines, generally used for building out-of-tree kernel modules. These files are going to be installed into /usr/src/linux-headers-2.6.16-2-powerpc-smp, and can be used for building modules that load into the kernel provided by the linux-image-2.6.16-2-powerpc-smp package. . This packages is produced using an updated kernel packaging system and replaces older kernel-headers packages (new) linux-headers-2.6.16-2-powerpc64_2.6.16-13_powerpc.deb optional devel Header files for Linux kernel 2.6.16 on powerpc64-class machines This package provides the architecture-specific kernel header files for Linux kernel 2.6.16 on powerpc64-class machines, generally used for building out-of-tree kernel modules. These files are going to be installed into /usr/src/linux-headers-2.6.16-2-powerpc64, and can be used for building modules that load into the kernel provided by the linux-image-2.6.16-2-powerpc64 package. . This packages is produced using an updated kernel packaging system and replaces o
Re: Arch specific kernel building
Never mind, I found the answers at: http://svn.debian.org/wsvn/kernel/dists/sid/linux-2.6/debian/README.build ;) Pepijn Oomen wrote: My question: how are the architecture specific packages (linux-image-2.6.16-1-nslu2/linux-headers-2.6.16-1-nslu2) build? Or more generic: how can I determine which patches are actually applied to generate arch specific kernel packages? -- Pepijn Oomen http://piprograms.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Arch specific kernel building
Hi all, I am currently working on the IXP425 kernel modules for the arm/nslu2 specific port of debian and ran into the following: The linux-source-2.6.16 package is arch independent and thus does not contain arch specific patches. However, the linux-headers-2.6.16-1-nslu2 package does contain eg. net/maclist.h which is the result of two arch specific patches from the linux-patch-debian-2.6.16 package. My question: how are the architecture specific packages (linux-image-2.6.16-1-nslu2/linux-headers-2.6.16-1-nslu2) build? Or more generic: how can I determine which patches are actually applied to generate arch specific kernel packages? TIA, -- Pepijn Oomen http://piprograms.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of linux-2.6_2.6.16-13_powerpc.changes
linux-2.6_2.6.16-13_powerpc.changes uploaded successfully to localhost along with the files: linux-2.6_2.6.16-13.dsc linux-2.6_2.6.16-13.diff.gz linux-doc-2.6.16_2.6.16-13_all.deb linux-manual-2.6.16_2.6.16-13_all.deb linux-patch-debian-2.6.16_2.6.16-13_all.deb linux-source-2.6.16_2.6.16-13_all.deb linux-tree-2.6.16_2.6.16-13_all.deb linux-support-2.6.16-2_2.6.16-13_all.deb linux-headers-2.6.16-2-all_2.6.16-13_powerpc.deb linux-headers-2.6.16-2-all-powerpc_2.6.16-13_powerpc.deb linux-headers-2.6.16-2_2.6.16-13_powerpc.deb linux-image-2.6.16-2-powerpc_2.6.16-13_powerpc.deb linux-headers-2.6.16-2-powerpc_2.6.16-13_powerpc.deb linux-image-powerpc_2.6.16-13_powerpc.deb linux-image-2.6-powerpc_2.6.16-13_powerpc.deb linux-headers-2.6-powerpc_2.6.16-13_powerpc.deb linux-image-2.6.16-2-powerpc-smp_2.6.16-13_powerpc.deb linux-headers-2.6.16-2-powerpc-smp_2.6.16-13_powerpc.deb linux-image-powerpc-smp_2.6.16-13_powerpc.deb linux-image-2.6-powerpc-smp_2.6.16-13_powerpc.deb linux-headers-2.6-powerpc-smp_2.6.16-13_powerpc.deb linux-image-2.6.16-2-powerpc-miboot_2.6.16-13_powerpc.deb linux-headers-2.6.16-2-powerpc-miboot_2.6.16-13_powerpc.deb linux-image-powerpc-miboot_2.6.16-13_powerpc.deb linux-image-2.6-powerpc-miboot_2.6.16-13_powerpc.deb linux-headers-2.6-powerpc-miboot_2.6.16-13_powerpc.deb linux-image-2.6.16-2-powerpc64_2.6.16-13_powerpc.deb linux-headers-2.6.16-2-powerpc64_2.6.16-13_powerpc.deb linux-image-powerpc64_2.6.16-13_powerpc.deb linux-image-2.6-powerpc64_2.6.16-13_powerpc.deb linux-headers-2.6-powerpc64_2.6.16-13_powerpc.deb linux-headers-2.6.16-2-vserver_2.6.16-13_powerpc.deb linux-image-2.6.16-2-vserver-powerpc_2.6.16-13_powerpc.deb linux-headers-2.6.16-2-vserver-powerpc_2.6.16-13_powerpc.deb linux-image-vserver-powerpc_2.6.16-13_powerpc.deb linux-image-2.6-vserver-powerpc_2.6.16-13_powerpc.deb linux-headers-2.6-vserver-powerpc_2.6.16-13_powerpc.deb linux-image-2.6.16-2-vserver-powerpc64_2.6.16-13_powerpc.deb linux-headers-2.6.16-2-vserver-powerpc64_2.6.16-13_powerpc.deb linux-image-vserver-powerpc64_2.6.16-13_powerpc.deb linux-image-2.6-vserver-powerpc64_2.6.16-13_powerpc.deb linux-headers-2.6-vserver-powerpc64_2.6.16-13_powerpc.deb kernel-image-powerpc_2.6.16-13_powerpc.deb kernel-image-2.6-powerpc_2.6.16-13_powerpc.deb kernel-image-powerpc-smp_2.6.16-13_powerpc.deb kernel-image-2.6-powerpc-smp_2.6.16-13_powerpc.deb kernel-image-power3_2.6.16-13_powerpc.deb kernel-image-2.6-power3_2.6.16-13_powerpc.deb kernel-image-power3-smp_2.6.16-13_powerpc.deb kernel-image-2.6-power3-smp_2.6.16-13_powerpc.deb kernel-image-power4_2.6.16-13_powerpc.deb kernel-image-2.6-power4_2.6.16-13_powerpc.deb kernel-image-power4-smp_2.6.16-13_powerpc.deb kernel-image-2.6-power4-smp_2.6.16-13_powerpc.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
Hello Sven, On Wed, May 10, 2006 at 11:02:29AM +0200, Sven Luther wrote: > I am little interested in > going this way, if it means another flamewar between me and the d-i team, with > everyone else watching silently. > > Andreas Barth, you claimed that you could see strong reason not to go this > way, please could you comment on them now in this thread. Please let's keep this problem you and some other developers have with each other out of here. IMHO it has reached a point where only personal mediation could help, and every additional word lost on it here or on IRC will just make it worse. Sven: I would like you to not partecipate in any discussion concerning d-i or kernel udebs - at least as long as you use that very contribution to raise this issue again and again. Your opinion is highly welcome otherwise, of course. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Bug#366730: linux-source-2.6.16: bogus scsi timeouts with qla1280 driver
Package: linux-source-2.6.16 Version: 2.6.16-12 Severity: normal Tags: patch I have been aggravated by tape problems since upgrading to 2.6 on my Alphaserver using the qla1280 driver with ISP1020/1040 support enabled. It appears on inspection that the problem lies with the qla1280 driver itself, which enforces a 30-second timeout on all (?) SCSI operations it issues. The result is that operations on my TZ89 DLT4 tape drive which take longer than that to complete (for example, "mt eod" or "mt fsf" in particular) abort and force a device reset. The attached kludgy patch demonstrates the fix I am using, namely to increase the timeout to 900 seconds. This is fine because my hardware is all solid and I'm not worried at the moment about a disk going bad and hanging my system for 15 minutes while the I/O times out... :-) Probably the timeout could be reduced to perhaps 5 minutes, but I am erring on the side of longer since these errant "errors" really screw up my backups and restores. I have posted to linux-scsi on this but haven't gotten much of a response. I'll report this there too but figured it would be better to have more eyes on the problem. Thanks, Scott Bailey [EMAIL PROTECTED] --- drivers/scsi/qla1280.c 2006-03-20 00:53:29.0 -0500 +++ drivers/scsi/qla1280.c 2006-05-10 10:02:39.0 -0400 @@ -17,9 +17,11 @@ * General Public License for more details. * **/ -#define QLA1280_VERSION "3.26" +#define QLA1280_VERSION "3.26.rsb" /* Revision History: +Rev 3.26.rsb, May 10, 2006 R. Scott Bailey + - Increase timeouts (?) from 30 to 900 sec for tape support Rev 3.26, January 16, 2006 Jes Sorensen - Ditch all < 2.6 support Rev 3.25.1, February 10, 2005 Christoph Hellwig @@ -2886,7 +2888,7 @@ memset(((char *)pkt + 8), 0, (REQUEST_ENTRY_SIZE - 8)); /* Set ISP command timeout. */ - pkt->timeout = cpu_to_le16(30); + pkt->timeout = cpu_to_le16(900); /* was 30 - RSB */ /* Set device target ID and LUN */ pkt->lun = SCSI_LUN_32(cmd); @@ -3185,7 +3187,7 @@ memset(((char *)pkt + 8), 0, (REQUEST_ENTRY_SIZE - 8)); /* Set ISP command timeout. */ - pkt->timeout = cpu_to_le16(30); + pkt->timeout = cpu_to_le16(900); /* was 30 - RSB */ /* Set device target ID and LUN */ pkt->lun = SCSI_LUN_32(cmd); -- System Information: Debian Release: testing/unstable Architecture: alpha Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-scsi.12 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages linux-source-2.6.16 depends on: ii binutils 2.16.1cvs20060413-1 The GNU assembler, linker and bina ii bzip21.0.3-2 high-quality block-sorting file co Versions of packages linux-source-2.6.16 recommends: ii gcc 4:4.0.2-2 The GNU C compiler ii libc6.1-dev [libc6-dev] 2.3.6-7GNU C Library: Development Librari ii make 3.81-1 The GNU version of the "make" util -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#364761: problem loading gamecon module
Fixed in linux-image-2.6.16-1-486 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: klibc m68k state
* Stephen R Marenka <[EMAIL PROTECTED]> [2006-05-10 09:30]: > It builds initrd's for the latest kernels just fine, which means they > can at least now be installed on systems with running kernels < 2.6. > Yeah! Unfortunately, my hardware doesn't work with 2.6 yet, so I'll > have to leave that test for someone else. But m68k isn't actually using the initramfs that is generated? If so, you can simply turn off initrd/initramfs on m68 -- see mips for an example. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: klibc m68k state
On Wed, May 10, 2006 at 09:30:08AM -0500, Stephen R Marenka wrote: > > i'm eager to hear of one of the aboves tests. > (sid-di)[EMAIL PROTECTED]:~# /usr/lib/klibc/bin/fstype < /dev/sda1 > stdin: error 4294966272 > (sid-di)[EMAIL PROTECTED]:~# /usr/lib/klibc/bin/fstype < /dev/sda9 > stdin: error 4294966272 > It builds initrd's for the latest kernels just fine, which means they > can at least now be installed on systems with running kernels < 2.6. > Yeah! Unfortunately, my hardware doesn't work with 2.6 yet, so I'll > have to leave that test for someone else. You could copy that over to spice or vivaldi. Both are running 2.6. -- Ciao...//Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] gpg pubkey: http://www.juergensmann.de/ij/public_key.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: klibc m68k state
retitle 334917 klibc barfs on m68k syscall interface thanks On Wed, May 10, 2006 at 09:30:08AM -0500, Stephen R Marenka wrote: > > thanks to cts klibc got more build fixes and 1.3.19 should > > just build fine on m68k. > > Successful build. cool, good news. > > On Fri, 05 May 2006, maximilian attems wrote: > > > > > you need build-dep linux-headers-2.6.16-1 for m68k. > > > hope to get some feedback if it's working, a good first test is the fstype > > > binary: /usr/lib/klibc/bin/fstype < /dev/sda1 > > > an even cooler test would be an initramfs-tools boot which uses run-init. > > > > i'm eager to hear of one of the aboves tests. > > (sid-di)[EMAIL PROTECTED]:~# /usr/lib/klibc/bin/fstype < /dev/sda1 > stdin: error 4294966272 > > (sid-di)[EMAIL PROTECTED]:~# /usr/lib/klibc/bin/fstype < /dev/sda9 > stdin: error 4294966272 hmm i need an strace of aboves error, also an access to an m68k porter box to try to get the syscall interface right would be cool. > It builds initrd's for the latest kernels just fine, which means they > can at least now be installed on systems with running kernels < 2.6. > Yeah! Unfortunately, my hardware doesn't work with 2.6 yet, so I'll > have to leave that test for someone else. nice indeed, but won't boot with aboves error yet ;) thanks for feedback + regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: klibc m68k state
On Mon, May 08, 2006 at 07:01:26PM +0200, maximilian attems wrote: > thanks to cts klibc got more build fixes and 1.3.19 should > just build fine on m68k. Successful build. > On Fri, 05 May 2006, maximilian attems wrote: > > > you need build-dep linux-headers-2.6.16-1 for m68k. > > hope to get some feedback if it's working, a good first test is the fstype > > binary: /usr/lib/klibc/bin/fstype < /dev/sda1 > > an even cooler test would be an initramfs-tools boot which uses run-init. > > i'm eager to hear of one of the aboves tests. (sid-di)[EMAIL PROTECTED]:~# /usr/lib/klibc/bin/fstype < /dev/sda1 stdin: error 4294966272 (sid-di)[EMAIL PROTECTED]:~# /usr/lib/klibc/bin/fstype < /dev/sda9 stdin: error 4294966272 It builds initrd's for the latest kernels just fine, which means they can at least now be installed on systems with running kernels < 2.6. Yeah! Unfortunately, my hardware doesn't work with 2.6 yet, so I'll have to leave that test for someone else. Thanks, Stephen -- Stephen R. Marenka If life's not fun, you're not doing it right! <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#361197: linux-image-2.6.16-1-686: Please report upstream and let it fix
Package: linux-image-2.6.16-1-686 Version: 2.6.16-12 Followup-For: Bug #361197 I've no sound, too. It is very boring ;( __ ACPI: PCI Interrupt :00:08.0[A] -> Link [LNKC] -> GSI 5 (level, low) -> IRQ 5 never read ISV3 and ISV4 from AC'97 ACPI: PCI interrupt for device :00:08.0 disabled CS4281: probe of :00:08.0 failed with error -5 __ :00:08.0 Multimedia audio controller: Cirrus Logic Crystal CS4281 PCI Audio (rev 01) Subsystem: Toshiba America Info Systems: Unknown device ff00 Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR-
Bug#287954: Additional information
I'm surprised that this report is still alive. This is the output from lspci: :00:00.0 Host bridge: Transmeta Corporation LongRun Northbridge :00:00.1 RAM memory: Transmeta Corporation SDRAM controller :00:00.2 RAM memory: Transmeta Corporation BIOS scratchpad :00:02.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08) :00:03.0 CardBus bridge: Texas Instruments PCI1420 :00:03.1 CardBus bridge: Texas Instruments PCI1420 :00:04.0 Multimedia audio controller: ALi Corporation M5451 PCI AC-Link Controller Audio Device (rev 01) :00:05.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M (rev 64) :00:06.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08) :00:07.0 ISA bridge: ALi Corporation M1533 PCI to ISA Bridge [Aladdin IV] :00:10.0 IDE interface: ALi Corporation M5229 IDE (rev c3) :00:11.0 Bridge: ALi Corporation M7101 Power Management Controller [PMU] :00:14.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) And this one is with -n: :00:00.0 0600: 1279:0395 :00:00.1 0500: 1279:0396 :00:00.2 0500: 1279:0397 :00:02.0 0200: 8086:1229 (rev 08) :00:03.0 0607: 104c:ac51 :00:03.1 0607: 104c:ac51 :00:04.0 0401: 10b9:5451 (rev 01) :00:05.0 0300: 1002:4c52 (rev 64) :00:06.0 0200: 8086:1229 (rev 08) :00:07.0 0601: 10b9:1533 :00:10.0 0101: 10b9:5229 (rev c3) :00:11.0 0680: 10b9:7101 :00:14.0 0c03: 10b9:5237 (rev 03) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#366680: linux-image: snd_intel8x0 module randomly fails to initialize sound hardware
Processing commands for [EMAIL PROTECTED]: > reassign 366680 linux-2.6 Bug#366680: linux-image: snd_intel8x0 module randomly fails to initialize sound hardware Warning: Unknown package 'linux-image' Bug reassigned from package `linux-image' 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#366680: linux-image: snd_intel8x0 module randomly fails to initialize sound hardware
Package: linux-image Version: /linux-2.6.16.1 Severity: normal Normally, I would not report this kind of problem using the BTS - audio problems are common enough, and not what I consider critical problems - but this one has persisted through a long series of kernel changes, all the way from the early ones in the 2.4 series until now (2.6.16.1). After this long, it's earned the status of Bug Emeritus, and I figure you folks deserve a chance at shooting it down. :) Over the last two years, I've experimented with a number of possible solutions to this problem, including trying to tweak the code in snd_intel8x0.c (unfortunately, it seems that my C-fu is not quite up to kernel hacking.) I'm hoping that you can offer some suggestions; you're also welcome to ask me to test out any patches or experimental code you'd care to try. The problem is that when I boot this laptop (Acer 2012, see included 'lspci' report), the sound hardware often fails to initialize and reports the following error: `` codec_ready: codec is not ready [0x870] '' and, of course, ALSA follows that up with a 'no soundcards found' error. '/var/log/kern.log' has the following to say at those times: `` Apr 22 19:40:53 Fenrir kernel: ACPI: PCI Interrupt :00:1f.5[B] -> GSI 17 (level, low) -> IRQ 21 Apr 22 19:40:53 Fenrir kernel: PCI: Setting latency timer of device :00:1f.5 to 64 Apr 22 19:40:53 Fenrir kernel: codec_ready: codec is not ready [0x870] Apr 22 19:40:53 Fenrir kernel: ACPI: PCI interrupt for device :00:1f.5 disabled Apr 22 19:40:53 Fenrir kernel: Intel ICH: probe of :00:1f.5 failed with error -5 '' and `` Apr 22 07:40:59 Fenrir kernel: Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04 08:57:20 2006 UTC). Apr 22 07:40:59 Fenrir kernel: ALSA device list: Apr 22 07:40:59 Fenrir kernel: No soundcards found. '' The frequency of how often this happens varies: sometimes, it's every single boot until I remove the laptop battery; at other times, it's only about one boot out of every five. It seems to be related to IRQ problems (booting the laptop without its battery, and inserting it after the boot, results in the problem nearly disappearing - it only happens in ~1 of every 20 boots.) I've tried setting the module options - `` options snd-intel8x0 buggy_irq=1 buggy_semaphore=1 '' but this does not help. Also, once the hardware has failed to be detected, nothing will fix the problem other than rebooting - unloading and reloading all the relevant modules has no effect. Any help at this point would be greatly appreciated. lspci output: ''' :00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02) :00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02) :00:00.3 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02) :00:01.0 PCI bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to AGP Controller (rev 02) :00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03) :00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 03) :00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 03) :00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 03) :00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 83) :00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 03) :00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 03) :00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 03) :00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03) :00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 03) :01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] :02:00.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link) :02:01.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02) :02:02.0 Network controller: Intel Corporation PRO/Wireless 2200BG (rev 05) :02:04.0 CardBus bridge: ENE Technology Inc CB1410 Cardbus Controller (rev 01) :03:00.0 USB Controller: NEC Corporation USB (rev 43) :03:00.1 USB Controller: NEC Corporation USB (rev 43) ''' Sincerely, Ben Okopnik, Editor-in-Chief, Linux Gazette -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.1 Locale: LA
Re: which kernel version for etch?
On Wed, May 10, 2006 at 10:15:45AM +0200, Bastian Blank wrote: > On Wed, May 10, 2006 at 07:46:12AM +0200, Sven Luther wrote: > > > - branch the current linux-2.6 package into a new source package, say > > > linux-2.6.16, tracking 2.6.16.x releases > > Sounds the right thing to do for me. We keep linux-2.6 as trunk package, and > > can branch off any number of kernel we want to have around long term, and > > mark > > it as linux-2.6.. Problem is with the metapackages, where will they come > > from ? Bastian, can you comment on this ? > > Currently they are built from linux-2.6. This needs to be changed for > such a package. And after that, they need to be reintroduced through > t-p-u. Well, this means thought that they will no more be built with linux-2.6, right ? Why do you need to involve t-p-u, the current version in testing points to the linux-2.6 2.6.16- which is compatible with the new packages. We just upload linux-2.6.16 to unstable and linux-2.6 without the metapackages, and they should migrate to testing normally or with an RM hint at the right moment, no ? > > I hearthily vote for this, and my effort to produce the .udebs from the > > common > > kernel and get a solution for the out-of-tree modules where designed to > > allow > > this easily enough, even in case of abi-changes. Support for those ideas > > have > > been tentative at best, especially in the light of the extreme flamming i > > got > > from the d-i folk about this. > > Just provide them and either they want them (at least for s390, I do) > or they don't. Ok. This means that at least 2 architectures, powerpc and s390, are interested in this. Thanks for your support in this, i will see what we can do, probably in a branch for now until the situation is proven. I am little interested in going this way, if it means another flamewar between me and the d-i team, with everyone else watching silently. Andreas Barth, you claimed that you could see strong reason not to go this way, please could you comment on them now in this thread. > For the out-of-tree modules, we will see it in the next days, if it > works. I think this should be done in at most 4 days. If it does not > work, we have to take down the law and build them ourself. Documentation is needed here also. > > We would also need to get some policy fixed about what happens to user > > self-compiled modules in that case. > > Either the ABI is compatible or not. A, sure, that is hardly the problem, what we need is some documentation, which will inform the user of what he is supposed to do in case of ABI changes. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366620: initramfs-tools: 2.6.16-1-powerpc fails to mount rootfs, 2.6.15-1-powerpc works
On Wed, May 10, 2006 at 07:48:42AM +0200, Sven Luther wrote: > On Wed, May 10, 2006 at 12:55:39AM +0200, maximilian attems wrote: > > tags 366620 moreinfo > > stop > > > > On Tue, May 09, 2006 at 11:54:24PM +0200, Hans Ekbrand wrote: > > > Package: initramfs-tools > > > Version: 0.60 > > > Severity: important > > > > > > > > > This might be a bug in the kernel or udev or something else, but > > > failure to mount root fs smells like an initrd problem to me. > > > > > > Bootloader: quik, with ramdisk_size 8192 (even tested 16384, with no luck) > > > Rootfs: ext2 on ide > > > Module for the harddisk: > > > lsmod says "ide_disk" on 2.6.15, but the > > > module is called ide-disk.ko and that module is present in booth the > > > working initrd.img (2.6.15-1-powerpc) and the non-working > > > (2.6.16-1-powerpc). ext2.ko also present in the initrd in booth > > > initrds. > > > > > > Debuging is problematic on this box since I don't have a working > > > serial console, nor can I interact with the bootloader via the > > > keyboard, so If a kernel+initrd doesn't work, I have to boot from the > > > woody installation floppy-disks and rescue from a shell in the > > > installation program. > > > > you didn't tell the error message? hda: Quantum Fireball_tm1700A, ATA Disk drive hda: Enabling MultiWord DMA 2 ide0 at 0xc2016000-0x2016007,0xc2016160 on ir1q 13 mice: NET: IP route TCP TCP TCP: TCP TCP NET: NET: VFS: Cannot open root device "hda5" or unknown-block(0,0) Please append a correct "root=" boot option Kernel panic - not syncing: VFS Unable to mount root fs on unknown-block(0,0) (0) Rebooting in 180 seconds... I miss the partition enumeration, it seems like the kernel does not see the partitions on the harddisk. > > what mkvmlinuz version are you using? > > This is probably (not 100% sure though) an old-world powermac, probably booted > by quik or bootx. In both cases, mkvmlinuz is not used, or at least its > scripts are silently skipped. Sorry for leaving out cpuinfo! You are correct Sven, it's an old-world powermac (performa 5400) $ cat /proc/cpuinfo processor : 0 cpu : 603ev clock : 160MHz revision: 2.1 (pvr 0007 0201) bogomips: 105.98 machine : Power Macintosh motherboard : AAPL,e407 MacRISC detected as : 35 (Alchemy) pmac flags : memory : 24MB pmac-generation : OldWorld $ -- Hans Ekbrand (http://sociologi.cjb.net) <[EMAIL PROTECTED]> GnuPG key: 1024D/7050614E Fingerprint: 1408 C8D5 1E7D 4C9C C27E 014F 7C2C 872A 7050 614E Learn about secure email at http://www.gnupg.org signature.asc Description: Digital signature
Re: which kernel version for etch?
On Wed, May 10, 2006 at 12:41:05PM +0200, Andreas Barth wrote: > * Sven Luther ([EMAIL PROTECTED]) [060510 12:25]: > > I will not be at debconf, so i will not be able to participate in this > > discussion. > > That's a pity. Sure, but i can't let my wife alone with my newly bron daugther, so ... I am sure that you at least can understand such personal life conditions. > > > > 2) Any discussion about this issue done during the sarge time can be > > > > thrown > > > > in the trashcan. Remember the mess that was the kernel packages in > > > > sarge, > > > > and compare it to the current situation. > > > > > > I didn't claim that Sarge and Etch are the same. However, one should and > > > could do the following: Which issues are problematic within Sarge? Could > > > that happen in Etch again? If the answer is no, I'm happy. If not, one > > > could try to fix it in time. > > > > Seems good. I listed a few points in the past, do you want that i repeat > > them, > > or will you find them in the archive by yourself. > > Hm, best if you could send me a private mail listing these points (or > just containing pointers), so I can make sure they're picked up. Ok, altough, i don't clearly understand the need for a private mail ? Don't you believe a discussion on the list would be a good idea ? For this same reason, please posts your objections to the .udebs-in-di and don't leave us in the dark. > > i think that we are already in the situation where the > > corresponding teams have failed. > > Perhaps I'm a bit more tolerant in that then you, but I agree that we > might come to a point where this is the case, and in that case, I'll > make sure the release team calls for a solution. Well, we are two month and a bit before the freeze, and there is some serious work still needed. If it is not now the moment to give impulse, it will be too late for etch, until the release schedule is already programmed for slipping. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
* Sven Luther ([EMAIL PROTECTED]) [060510 12:25]: > On Wed, May 10, 2006 at 12:02:48PM +0200, Andreas Barth wrote: > > * Sven Luther ([EMAIL PROTECTED]) [060510 11:31]: > > > 1) Frans is hardly competent enough to give advice for this. He is > > > biased by > > > his personal feud over this with me, and i believe has not a good enough > > > oversight of the problems involved to give a good technical advice. > > > This is my > > > opinion, though, so feel free to ignore it. > > > > We need to discuss how to update the kernel for the next stable point > > release. There is a stable release management BoF during Debconf, I'll > > try to discuss it there. Of course, anyone can come to that BoF, and I'd > > welcome anyone who helps us to resolve issues. (And this discussion > > needs to happen anyways, independend of Etch.) > > I will not be at debconf, so i will not be able to participate in this > discussion. That's a pity. > > > 2) Any discussion about this issue done during the sarge time can be > > > thrown > > > in the trashcan. Remember the mess that was the kernel packages in > > > sarge, > > > and compare it to the current situation. > > > > I didn't claim that Sarge and Etch are the same. However, one should and > > could do the following: Which issues are problematic within Sarge? Could > > that happen in Etch again? If the answer is no, I'm happy. If not, one > > could try to fix it in time. > > Seems good. I listed a few points in the past, do you want that i repeat them, > or will you find them in the archive by yourself. Hm, best if you could send me a private mail listing these points (or just containing pointers), so I can make sure they're picked up. > i think that we are already in the situation where the > corresponding teams have failed. Perhaps I'm a bit more tolerant in that then you, but I agree that we might come to a point where this is the case, and in that case, I'll make sure the release team calls for a solution. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
On Wed, May 10, 2006 at 12:02:48PM +0200, Andreas Barth wrote: > * Sven Luther ([EMAIL PROTECTED]) [060510 11:31]: > > 1) Frans is hardly competent enough to give advice for this. He is biased > > by > > his personal feud over this with me, and i believe has not a good enough > > oversight of the problems involved to give a good technical advice. This > > is my > > opinion, though, so feel free to ignore it. > > We need to discuss how to update the kernel for the next stable point > release. There is a stable release management BoF during Debconf, I'll > try to discuss it there. Of course, anyone can come to that BoF, and I'd > welcome anyone who helps us to resolve issues. (And this discussion > needs to happen anyways, independend of Etch.) I will not be at debconf, so i will not be able to participate in this discussion. > > 2) Any discussion about this issue done during the sarge time can be > > thrown > > in the trashcan. Remember the mess that was the kernel packages in sarge, > > and compare it to the current situation. > > I didn't claim that Sarge and Etch are the same. However, one should and > could do the following: Which issues are problematic within Sarge? Could > that happen in Etch again? If the answer is no, I'm happy. If not, one > could try to fix it in time. Seems good. I listed a few points in the past, do you want that i repeat them, or will you find them in the archive by yourself. > > 4) Back in the sarge time, a full d-i rebuild meant over a month of work. > > We > > have solved all the issues we had with this on the kernel side, and the > > delay is now caused by a lack of organisation on the d-i side, and their > > refusal to address the issue. > > I'm going to discuss that with the d-i people. Hey, we could even do an > ad-hoc BoF on kernel&d-i. :) I doubt that it will do any good, given the d-i past positions on this, but we will see. As said, i will not be there. I don't believe the current d-i team has the mental flexibility enough to not see any progress on this as anything but a lose of face, and they will strongly oppose this for that reason. > > I believe it is the RMs place to have enough vision to find the best > > technical > > solution, and to make sure they happen, even if a few try to block it > > because > > they are afraid of change. > > I think the RMs should only address issues if the maintainers / teams / > whoever fail to address them by themself. So for now, I'm not going to > force anybody to something. But I definitly will discuss issues with > different people during debconf. Well, given that the right time to address these issues where in october, or at least after the 2.6.14 release, that there where repeated calls for a discussion about this, which only ended in a a bashing fest, and that we are now in may, i think that we are already in the situation where the corresponding teams have failed. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
On Wed, May 10, 2006 at 07:46:12AM +0200, Sven Luther wrote: > > - branch the current linux-2.6 package into a new source package, say > > linux-2.6.16, tracking 2.6.16.x releases > Sounds the right thing to do for me. We keep linux-2.6 as trunk package, and > can branch off any number of kernel we want to have around long term, and mark > it as linux-2.6.. Problem is with the metapackages, where will they come > from ? Bastian, can you comment on this ? Currently they are built from linux-2.6. This needs to be changed for such a package. And after that, they need to be reintroduced through t-p-u. > I hearthily vote for this, and my effort to produce the .udebs from the common > kernel and get a solution for the out-of-tree modules where designed to allow > this easily enough, even in case of abi-changes. Support for those ideas have > been tentative at best, especially in the light of the extreme flamming i got > from the d-i folk about this. Just provide them and either they want them (at least for s390, I do) or they don't. For the out-of-tree modules, we will see it in the next days, if it works. I think this should be done in at most 4 days. If it does not work, we have to take down the law and build them ourself. > We would also need to get some policy fixed about what happens to user > self-compiled modules in that case. Either the ABI is compatible or not. Bastian -- You! What PLANET is this! -- McCoy, "The City on the Edge of Forever", stardate 3134.0 signature.asc Description: Digital signature
Re: which kernel version for etch?
* Sven Luther ([EMAIL PROTECTED]) [060510 11:06]: > Andreas Barth, you claimed that you could see strong reason not to go this > way, please could you comment on them now in this thread. I think that discussion how to handle udebs should be done inbetween kernel and boot team, and the right mail address for the boot team people is [EMAIL PROTECTED] I don't like to be a human forwarder of infos. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
On Wed, May 10, 2006 at 11:16:31AM +0200, Andreas Barth wrote: > * Frederik Schueler ([EMAIL PROTECTED]) [060509 23:47]: > > Second, if we go this path and do an Etch release with 2.6.16.x, > > I would like to NOT stick forever with that very version we will have in > > testing at the day the freeze happens, but keep updating the kernel > > images and the installer for every point release to a reasonably newer > > 2.6.16.x upstream release. > > We need to discuss how to do it sanely for the installer; I'll discuss > that with Frans anyways during debconf for Sarge, and what we learn from > that for Etch. Otherwise, this is ok from the stable release management > point of view. Andreas, Well, there are a few points to see here : 1) Frans is hardly competent enough to give advice for this. He is biased by his personal feud over this with me, and i believe has not a good enough oversight of the problems involved to give a good technical advice. This is my opinion, though, so feel free to ignore it. 2) Any discussion about this issue done during the sarge time can be thrown in the trashcan. Remember the mess that was the kernel packages in sarge, and compare it to the current situation. 3) We are able to do kernel uploads, rebuilt for all arches in a matter of days (same day for most major arches usually). The upload of 2.6.14-1 and later first time upgrades has shown that. 4) Back in the sarge time, a full d-i rebuild meant over a month of work. We have solved all the issues we had with this on the kernel side, and the delay is now caused by a lack of organisation on the d-i side, and their refusal to address the issue. 5) We shipped sarge d-i with a known remote security hole, let's try to avoid such issues if possible. We still have time to make it work. If we solve the issue of the out-of-tree modules, and get the d-i kernel .udebs situation in grip, then there is no reason at all we should be able to do even abi-breaking upgrades in a matter of days. This means some change in the infrastructure of netbooting and businesscard .udebs, but if there is a will to solve this as it should, we could do this before the etch freeze. I believe it is the RMs place to have enough vision to find the best technical solution, and to make sure they happen, even if a few try to block it because they are afraid of change. So keep in mind of what would be best for etch once released, and let's try to make it happen. (BTW, the mediation attempt between me and the d-i team failed, i am disapointed on how the DPL handled this, and his lack of impartiality, so any d-i side of the thing will not be handled by me, unless it is forked and maintained in a more free way). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
On Wed, May 10, 2006 at 11:21:27AM +0200, Andreas Barth wrote: > * Sven Luther ([EMAIL PROTECTED]) [060510 11:06]: > > Andreas Barth, you claimed that you could see strong reason not to go this > > way, please could you comment on them now in this thread. > > I think that discussion how to handle udebs should be done inbetween > kernel and boot team, and the right mail address for the boot team > people is [EMAIL PROTECTED] I don't like to be a human > forwarder of infos. Debian-boot has said they want nothing to do with me, and the DPL mediation process failed. The d-i team is not competent enough, lacks the vision or will necessary to see what is best for etch, and have thus forfeited their part in this discussion, as far as i am concerned. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
* Frederik Schueler ([EMAIL PROTECTED]) [060509 23:47]: > Second, if we go this path and do an Etch release with 2.6.16.x, > I would like to NOT stick forever with that very version we will have in > testing at the day the freeze happens, but keep updating the kernel > images and the installer for every point release to a reasonably newer > 2.6.16.x upstream release. We need to discuss how to do it sanely for the installer; I'll discuss that with Frans anyways during debconf for Sarge, and what we learn from that for Etch. Otherwise, this is ok from the stable release management point of view. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
On Wed, May 10, 2006 at 11:21:27AM +0200, Andreas Barth wrote: > * Sven Luther ([EMAIL PROTECTED]) [060510 11:06]: > > Andreas Barth, you claimed that you could see strong reason not to go this > > way, please could you comment on them now in this thread. > > I think that discussion how to handle udebs should be done inbetween > kernel and boot team, and the right mail address for the boot team > people is [EMAIL PROTECTED] I don't like to be a human > forwarder of infos. Or more to the point, please list those reasons and CC debian-boot. Claiming on irc that you see such reason and refusing to give them here is very suspisious about the validity of those reasons. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
* Andreas Barth ([EMAIL PROTECTED]) [060510 11:17]: > * Frederik Schueler ([EMAIL PROTECTED]) [060509 23:47]: > > Second, if we go this path and do an Etch release with 2.6.16.x, > > I would like to NOT stick forever with that very version we will have in > > testing at the day the freeze happens, but keep updating the kernel > > images and the installer for every point release to a reasonably newer > > 2.6.16.x upstream release. > > We need to discuss how to do it sanely for the installer; I'll discuss > that with Frans anyways during debconf for Sarge, and what we learn from > that for Etch. Otherwise, this is ok from the stable release management > point of view. Ah, and of course: If a kernel update breaks out-of-the-tree modules, we need some way to handle that. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
* Sven Luther ([EMAIL PROTECTED]) [060510 11:33]: > On Wed, May 10, 2006 at 11:21:27AM +0200, Andreas Barth wrote: > > * Sven Luther ([EMAIL PROTECTED]) [060510 11:06]: > > > Andreas Barth, you claimed that you could see strong reason not to go this > > > way, please could you comment on them now in this thread. > > > > I think that discussion how to handle udebs should be done inbetween > > kernel and boot team, and the right mail address for the boot team > > people is [EMAIL PROTECTED] I don't like to be a human > > forwarder of infos. > > Debian-boot has said they want nothing to do with me Well, in that case, perhaps someone else from the kernel team should try to speak with them. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
* Sven Luther ([EMAIL PROTECTED]) [060510 11:31]: > 1) Frans is hardly competent enough to give advice for this. He is biased by > his personal feud over this with me, and i believe has not a good enough > oversight of the problems involved to give a good technical advice. This is > my > opinion, though, so feel free to ignore it. We need to discuss how to update the kernel for the next stable point release. There is a stable release management BoF during Debconf, I'll try to discuss it there. Of course, anyone can come to that BoF, and I'd welcome anyone who helps us to resolve issues. (And this discussion needs to happen anyways, independend of Etch.) > 2) Any discussion about this issue done during the sarge time can be thrown > in the trashcan. Remember the mess that was the kernel packages in sarge, > and compare it to the current situation. I didn't claim that Sarge and Etch are the same. However, one should and could do the following: Which issues are problematic within Sarge? Could that happen in Etch again? If the answer is no, I'm happy. If not, one could try to fix it in time. > 4) Back in the sarge time, a full d-i rebuild meant over a month of work. We > have solved all the issues we had with this on the kernel side, and the > delay is now caused by a lack of organisation on the d-i side, and their > refusal to address the issue. I'm going to discuss that with the d-i people. Hey, we could even do an ad-hoc BoF on kernel&d-i. :) > I believe it is the RMs place to have enough vision to find the best technical > solution, and to make sure they happen, even if a few try to block it because > they are afraid of change. I think the RMs should only address issues if the maintainers / teams / whoever fail to address them by themself. So for now, I'm not going to force anybody to something. But I definitly will discuss issues with different people during debconf. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
