Processing of kernel-source-2.6.10_2.6.10-3_i386.changes
kernel-source-2.6.10_2.6.10-3_i386.changes uploaded successfully to localhost along with the files: kernel-source-2.6.10_2.6.10-3.dsc kernel-source-2.6.10_2.6.10-3.diff.gz kernel-patch-debian-2.6.10_2.6.10-3_all.deb kernel-source-2.6.10_2.6.10-3_all.deb kernel-tree-2.6.10_2.6.10-3_all.deb kernel-doc-2.6.10_2.6.10-3_all.deb Greetings, Your Debian queue daemon
Bug#288062: marked as done (Dead link to patches)
Your message dated Sun, 09 Jan 2005 01:17:37 -0500
with message-id [EMAIL PROTECTED]
and subject line Bug#288062: fixed in kernel-source-2.6.10 2.6.10-3
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--
Received: (at submit) by bugs.debian.org; 1 Jan 2005 04:59:51 +
From [EMAIL PROTECTED] Fri Dec 31 20:59:51 2004
Return-path: [EMAIL PROTECTED]
Received: from relay4.usu.ru [194.226.235.39]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1CkbMk-0002Z2-00; Fri, 31 Dec 2004 20:59:50 -0800
Received: from usu2.usu.ru (usu2.usu.ru [194.226.237.16])
by relay4.usu.ru (8.13.1/8.13.1/Debian-15) with ESMTP id j014xsTq022215
for [EMAIL PROTECTED]; Sat, 1 Jan 2005 09:59:56 +0500
Received: from localhost.usu2.usu.ru (localhost.usu2.usu.ru [127.0.0.1])
by usu2.usu.ru (Postfix) with ESMTP id 44005A7F74
for [EMAIL PROTECTED]; Sat, 1 Jan 2005 09:59:40 +0500 (YEKT)
Received: from ums.usu.ru (ums.usu.ru [194.226.236.116])
by usu2.usu.ru (Postfix) with ESMTP id F2C01A7F72
for [EMAIL PROTECTED]; Sat, 1 Jan 2005 09:59:39 +0500 (YEKT)
Received: from dialin.dialog.usu.ru (dsa.physics.usu.ru
[:::194.226.236.126])
(AUTH: PLAIN patrakov, SSL: TLSv1/SSLv3,128bits,RC4-MD5)
by ums.usu.ru with esmtp; Sat, 01 Jan 2005 09:59:38 +0500
id 803A.41D62E3B.54C4
From: Alexander E. Patrakov [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Dead link to patches
Date: Sat, 1 Jan 2005 10:00:48 +0500
User-Agent: KMail/1.7.1
MIME-Version: 1.0
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: [EMAIL PROTECTED]
X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.16; AVE: 6.29.0.5;
VDF: 6.29.0.44; host: usu2.usu.ru)
X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0124], KAS/Release
X-Spamtest-Info: Pass through
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE
autolearn=no version=2.60-bugs.debian.org_2004_03_25
X-Spam-Level:
Package: kernel
Version: 2.6.9-1
In /usr/share/doc/kernel-image-2.6.9-1-686/README.Debian.1st.gz, there is a
line:
The patches can be found
at http://svn.debian.org/viewcvs/kernel/tags/kernel/source/${version}.
This link is dead, please replace it with
http://svn.debian.org/wsvn/kernel/tags/kernel/source/
--
Alexander E. Patrakov
---
Received: (at 288062-close) by bugs.debian.org; 9 Jan 2005 06:21:38 +
From [EMAIL PROTECTED] Sat Jan 08 22:21:38 2005
Return-path: [EMAIL PROTECTED]
Received: from newraff.debian.org [208.185.25.31] (mail)
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1CnWSI-00041n-00; Sat, 08 Jan 2005 22:21:38 -0800
Received: from katie by newraff.debian.org with local (Exim 3.35 1 (Debian))
id 1CnWOP-ld-00; Sun, 09 Jan 2005 01:17:37 -0500
From: Andres Salomon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
X-Katie: $Revision: 1.54 $
Subject: Bug#288062: fixed in kernel-source-2.6.10 2.6.10-3
Message-Id: [EMAIL PROTECTED]
Sender: Archive Administrator [EMAIL PROTECTED]
Date: Sun, 09 Jan 2005 01:17:37 -0500
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2005_01_02
X-Spam-Level:
Source: kernel-source-2.6.10
Source-Version: 2.6.10-3
We believe that the bug you reported is fixed in the latest version of
kernel-source-2.6.10, which is due to be installed in the Debian FTP archive:
kernel-doc-2.6.10_2.6.10-3_all.deb
to pool/main/k/kernel-source-2.6.10/kernel-doc-2.6.10_2.6.10-3_all.deb
kernel-patch-debian-2.6.10_2.6.10-3_all.deb
to
pool/main/k/kernel-source-2.6.10/kernel-patch-debian-2.6.10_2.6.10-3_all.deb
kernel-source-2.6.10_2.6.10-3.diff.gz
to pool/main/k/kernel-source-2.6.10/kernel-source-2.6.10_2.6.10-3.diff.gz
kernel-source-2.6.10_2.6.10-3.dsc
to pool/main/k/kernel-source-2.6.10/kernel-source-2.6.10_2.6.10-3.dsc
kernel-source-2.6.10_2.6.10-3_all.deb
to pool/main/k/kernel-source-2.6.10/kernel-source-2.6.10_2.6.10-3_all.deb
kernel-tree-2.6.10_2.6.10-3_all.deb
to pool/main/k/kernel-source-2.6.10/kernel-tree-2.6.10_2.6.10-3_all.deb
A summary of the changes between
kernel-source-2.6.10_2.6.10-3_i386.changes ACCEPTED
Accepted: kernel-doc-2.6.10_2.6.10-3_all.deb to pool/main/k/kernel-source-2.6.10/kernel-doc-2.6.10_2.6.10-3_all.deb kernel-patch-debian-2.6.10_2.6.10-3_all.deb to pool/main/k/kernel-source-2.6.10/kernel-patch-debian-2.6.10_2.6.10-3_all.deb kernel-source-2.6.10_2.6.10-3.diff.gz to pool/main/k/kernel-source-2.6.10/kernel-source-2.6.10_2.6.10-3.diff.gz kernel-source-2.6.10_2.6.10-3.dsc to pool/main/k/kernel-source-2.6.10/kernel-source-2.6.10_2.6.10-3.dsc kernel-source-2.6.10_2.6.10-3_all.deb to pool/main/k/kernel-source-2.6.10/kernel-source-2.6.10_2.6.10-3_all.deb kernel-tree-2.6.10_2.6.10-3_all.deb to pool/main/k/kernel-source-2.6.10/kernel-tree-2.6.10_2.6.10-3_all.deb Announcing to debian-devel-changes@lists.debian.org Closing bugs: 288062 Thank you for your contribution to Debian.
2.6.10
Alright, I've uploaded 2.6.10 source and i386 packages. They can be obtained here: http://www.acm.rpi.edu/~dilinger/kernel-source-2.6.10/ http://www.acm.rpi.edu/~dilinger/kernel-image-2.6.10-i386/ Looks like I *just* missed some NEW processing, too. Oh well..
Processing of kernel-image-2.6.10-i386_2.6.10-3_i386.changes
kernel-image-2.6.10-i386_2.6.10-3_i386.changes uploaded successfully to localhost along with the files: kernel-image-2.6.10-i386_2.6.10-3.dsc kernel-image-2.6.10-i386_2.6.10-3.tar.gz kernel-headers-2.6.10-1_2.6.10-3_i386.deb kernel-headers-2.6.10-1-686-smp_2.6.10-3_i386.deb kernel-image-2.6.10-1-686-smp_2.6.10-3_i386.deb kernel-headers-2.6.10-1-386_2.6.10-3_i386.deb kernel-image-2.6.10-1-386_2.6.10-3_i386.deb kernel-headers-2.6.10-1-k7_2.6.10-3_i386.deb kernel-image-2.6.10-1-k7_2.6.10-3_i386.deb kernel-headers-2.6.10-1-686_2.6.10-3_i386.deb kernel-image-2.6.10-1-686_2.6.10-3_i386.deb kernel-headers-2.6.10-1-k7-smp_2.6.10-3_i386.deb kernel-image-2.6.10-1-k7-smp_2.6.10-3_i386.deb Greetings, Your Debian queue daemon
kernel-image-2.6.10-i386_2.6.10-3_i386.changes is NEW
(new) kernel-headers-2.6.10-1-386_2.6.10-3_i386.deb optional devel Linux kernel headers 2.6.10 on 386 This package provides kernel header files for version 2.6.10 on 386, for sites that want the latest kernel headers. Please read /usr/share/doc/kernel-headers-2.6.10-1/debian.README.gz for details (new) kernel-headers-2.6.10-1-686-smp_2.6.10-3_i386.deb optional devel Linux kernel headers 2.6.10 on PPro/Celeron/PII/PIII/P4 SMP This package provides kernel header files for version 2.6.10 on Pentium Pro/Celeron/Pentium II/Pentium III/Pentium 4 with SMP support, for sites that want the latest kernel headers. SMP (symmetric multi-processing) is needed if you have multiple processors. Please read /usr/share/doc/kernel-headers-2.6.10-1/debian.README.gz for details (new) kernel-headers-2.6.10-1-686_2.6.10-3_i386.deb optional devel Linux kernel headers 2.6.10 on PPro/Celeron/PII/PIII/P4 This package provides kernel header files for version 2.6.10 on Pentium Pro/Celeron/Pentium II/Pentium III/Pentium 4, for sites that want the latest kernel headers. Please read /usr/share/doc/kernel-headers-2.6.10-1/debian.README.gz for details (new) kernel-headers-2.6.10-1-k7-smp_2.6.10-3_i386.deb optional devel Linux kernel headers 2.6.10 on AMD K7 SMP This package provides kernel header files for version 2.6.10 on AMD Duron/Athlon with SMP support, for sites that want the latest kernel headers. SMP (symmetric multi-processing) is needed if you have multiple processors. Please read /usr/share/doc/kernel-headers-2.6.10-1/debian.README.gz for details (new) kernel-headers-2.6.10-1-k7_2.6.10-3_i386.deb optional devel Linux kernel headers 2.6.10 on AMD K7 This package provides kernel header files for version 2.6.10 on AMD Duron/Athlon, for sites that want the latest kernel headers. Please read /usr/share/doc/kernel-headers-2.6.10-1/debian.README.gz for details (new) kernel-headers-2.6.10-1_2.6.10-3_i386.deb optional devel Header files related to Linux kernel version 2.6.10 This package provides kernel header files for version 2.6.10, for sites that want the latest kernel headers. Please read /usr/share/doc/kernel-headers-2.6.10-1/debian.README.gz for details (new) kernel-image-2.6.10-1-386_2.6.10-3_i386.deb optional base Linux kernel image for version 2.6.10 on 386. This package contains the Linux kernel image for version 2.6.10 on 386, the corresponding System.map file, and the modules built by the packager. It also contains scripts that try to ensure that the system is not left in a unbootable state after an update. . If you wish to update a bootdisk, or to use a bootloader to make installing and using the image easier, we suggest you install the latest fdutils (for formatting a floppy to be used as boot disk), and LILO, for a powerful bootloader. Of course, both these are optional. . Kernel image packages are generally produced using kernel-package, and it is suggested that you install that package if you wish to create a custom kernel from the sources. (new) kernel-image-2.6.10-1-686-smp_2.6.10-3_i386.deb optional base Linux kernel image for version 2.6.10 on PPro/Celeron/PII/PIII/P4 SMP. This package contains the Linux kernel image for version 2.6.10 on Pentium Pro/Celeron/Pentium II/Pentium III/Pentium 4 with SMP support, the corresponding System.map file, and the modules built by the packager. SMP (symmetric multi-processing) is needed if you have multiple processors. It also contains scripts that try to ensure that the system is not left in a unbootable state after an update. . If you wish to update a bootdisk, or to use a bootloader to make installing and using the image easier, we suggest you install the latest fdutils (for formatting a floppy to be used as boot disk), and LILO, for a powerful bootloader. Of course, both these are optional. . Kernel image packages are generally produced using kernel-package, and it is suggested that you install that package if you wish to create a custom kernel from the sources. (new) kernel-image-2.6.10-1-686_2.6.10-3_i386.deb optional base Linux kernel image for version 2.6.10 on PPro/Celeron/PII/PIII/P4. This package contains the Linux kernel image for version 2.6.10 on Pentium Pro/Celeron/Pentium II/Pentium III/Pentium 4, the corresponding System.map file, and the modules built by the packager. It also contains scripts that try to ensure that the system is not left in a unbootable state after an update. . If you wish to update a bootdisk, or to use a bootloader to make installing and using the image easier, we suggest you install the latest fdutils (for formatting a floppy to be used as boot disk), and LILO, for a powerful bootloader. Of course, both these are optional. . Kernel image packages are generally produced using kernel-package, and it is suggested that you install that package if you wish to create a custom kernel from the sources. (new) kernel-image-2.6.10-1-k7-smp_2.6.10-3_i386.deb optional base Linux
Bug#120116: Hey, It's me, StephanZEP72534 from AOL
Check here if your message above does not load. No man or woman who tries to pursue an ideal in his or her own way is without enemies. -Daisy Bates (1863-1951) Ahir Does Joe hate laughing over there? aventurine About life breadman Those janitors aren't missing sleeping right now. Baluga Half the work that is done in this world is to make things appear what they are not. Elias Root Beadle anoli Did Anthony miss running? Caulerpaceae It is not enough to do your best; you must know what to do, and THEN do your best. W. Edwards Deming catenarian Those bus drivers aren't missing praying on the street just now. acheiria
Processing of kernel-patch-powerpc-2.6.8_2.6.8-9_powerpc.changes
kernel-patch-powerpc-2.6.8_2.6.8-9_powerpc.changes uploaded successfully to localhost along with the files: kernel-patch-powerpc-2.6.8_2.6.8-9.dsc kernel-patch-powerpc-2.6.8_2.6.8-9.tar.gz kernel-headers-2.6.8_2.6.8-9_powerpc.deb kernel-image-2.6.8-power3_2.6.8-9_powerpc.deb kernel-build-2.6.8-power3_2.6.8-9_powerpc.deb kernel-image-2.6.8-power3-smp_2.6.8-9_powerpc.deb kernel-build-2.6.8-power3-smp_2.6.8-9_powerpc.deb kernel-image-2.6.8-power4_2.6.8-9_powerpc.deb kernel-build-2.6.8-power4_2.6.8-9_powerpc.deb kernel-image-2.6.8-power4-smp_2.6.8-9_powerpc.deb kernel-build-2.6.8-power4-smp_2.6.8-9_powerpc.deb kernel-image-2.6.8-powerpc_2.6.8-9_powerpc.deb kernel-build-2.6.8-powerpc_2.6.8-9_powerpc.deb kernel-image-2.6.8-powerpc-smp_2.6.8-9_powerpc.deb kernel-build-2.6.8-powerpc-smp_2.6.8-9_powerpc.deb Greetings, Your Debian queue daemon
Bug#287933: marked as done (kernel-image-2.6.8-powerpc: [prep] upping the network interface (de4x5DecChip 21140 based) freezes the kernel.)
Your message dated Sun, 09 Jan 2005 08:02:24 -0500 with message-id [EMAIL PROTECTED] and subject line Bug#287933: fixed in kernel-patch-powerpc-2.6.8 2.6.8-9 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 31 Dec 2004 00:00:28 + From [EMAIL PROTECTED] Thu Dec 30 16:00:28 2004 Return-path: [EMAIL PROTECTED] Received: from smtp10.wanadoo.fr [193.252.22.21] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1CkADT-0006xD-00; Thu, 30 Dec 2004 16:00:28 -0800 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1002.wanadoo.fr (SMTP Server) with SMTP id 0B0A82400095; Fri, 31 Dec 2004 00:59:57 +0100 (CET) Received: from pegasos (AMontpellier-205-2-3-151.w193-253.abo.wanadoo.fr [193.253.222.151]) by mwinf1002.wanadoo.fr (SMTP Server) with ESMTP id E4132240008D; Fri, 31 Dec 2004 00:59:56 +0100 (CET) Received: from luther by pegasos with local (Exim 4.34) id 1CkAJn-0004xi-NI; Fri, 31 Dec 2004 01:06:59 +0100 Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Sven Luther [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Subject: kernel-image-2.6.8-powerpc: [prep] upping the network interface (de4x5DecChip 21140 based) freezes the kernel. X-Mailer: reportbug 3.4 Date: Fri, 31 Dec 2004 01:06:59 +0100 Message-Id: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2004_03_25 X-Spam-Level: Package: kernel-image-2.6.8-powerpc Severity: important Tags: upstream As the subject says, the motorola powerstack (utah motherboard) has an onboard decchip 21140 (pci-id 1011:0009), and modprobing the de4x5 module works fine, but as soon as we access the interface, it freezes the kernel. It was reported that the same happens with an intel based network card. A 2.4.12 suse kernel install currently present on the machine doesn't exhibit this problem. Friendly, Sven Luther -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.4.27-powerpc Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) --- Received: (at 287933-close) by bugs.debian.org; 9 Jan 2005 13:08:23 + From [EMAIL PROTECTED] Sun Jan 09 05:08:23 2005 Return-path: [EMAIL PROTECTED] Received: from newraff.debian.org [208.185.25.31] (mail) by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1Cncnv-0004Kh-00; Sun, 09 Jan 2005 05:08:23 -0800 Received: from katie by newraff.debian.org with local (Exim 3.35 1 (Debian)) id 1Cnci8-00012r-00; Sun, 09 Jan 2005 08:02:24 -0500 From: Sven Luther [EMAIL PROTECTED] To: [EMAIL PROTECTED] X-Katie: $Revision: 1.54 $ Subject: Bug#287933: fixed in kernel-patch-powerpc-2.6.8 2.6.8-9 Message-Id: [EMAIL PROTECTED] Sender: Archive Administrator [EMAIL PROTECTED] Date: Sun, 09 Jan 2005 08:02:24 -0500 Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: Source: kernel-patch-powerpc-2.6.8 Source-Version: 2.6.8-9 We believe that the bug you reported is fixed in the latest version of kernel-patch-powerpc-2.6.8, which is due to be installed in the Debian FTP archive: kernel-build-2.6.8-power3-smp_2.6.8-9_powerpc.deb to pool/main/k/kernel-patch-powerpc-2.6.8/kernel-build-2.6.8-power3-smp_2.6.8-9_powerpc.deb kernel-build-2.6.8-power3_2.6.8-9_powerpc.deb to pool/main/k/kernel-patch-powerpc-2.6.8/kernel-build-2.6.8-power3_2.6.8-9_powerpc.deb kernel-build-2.6.8-power4-smp_2.6.8-9_powerpc.deb to pool/main/k/kernel-patch-powerpc-2.6.8/kernel-build-2.6.8-power4-smp_2.6.8-9_powerpc.deb kernel-build-2.6.8-power4_2.6.8-9_powerpc.deb to pool/main/k/kernel-patch-powerpc-2.6.8/kernel-build-2.6.8-power4_2.6.8-9_powerpc.deb kernel-build-2.6.8-powerpc-smp_2.6.8-9_powerpc.deb to pool/main/k/kernel-patch-powerpc-2.6.8/kernel-build-2.6.8-powerpc-smp_2.6.8-9_powerpc.deb kernel-build-2.6.8-powerpc_2.6.8-9_powerpc.deb to
kernel-patch-powerpc-2.6.8_2.6.8-9_powerpc.changes ACCEPTED
Accepted: kernel-build-2.6.8-power3-smp_2.6.8-9_powerpc.deb to pool/main/k/kernel-patch-powerpc-2.6.8/kernel-build-2.6.8-power3-smp_2.6.8-9_powerpc.deb kernel-build-2.6.8-power3_2.6.8-9_powerpc.deb to pool/main/k/kernel-patch-powerpc-2.6.8/kernel-build-2.6.8-power3_2.6.8-9_powerpc.deb kernel-build-2.6.8-power4-smp_2.6.8-9_powerpc.deb to pool/main/k/kernel-patch-powerpc-2.6.8/kernel-build-2.6.8-power4-smp_2.6.8-9_powerpc.deb kernel-build-2.6.8-power4_2.6.8-9_powerpc.deb to pool/main/k/kernel-patch-powerpc-2.6.8/kernel-build-2.6.8-power4_2.6.8-9_powerpc.deb kernel-build-2.6.8-powerpc-smp_2.6.8-9_powerpc.deb to pool/main/k/kernel-patch-powerpc-2.6.8/kernel-build-2.6.8-powerpc-smp_2.6.8-9_powerpc.deb kernel-build-2.6.8-powerpc_2.6.8-9_powerpc.deb to pool/main/k/kernel-patch-powerpc-2.6.8/kernel-build-2.6.8-powerpc_2.6.8-9_powerpc.deb kernel-headers-2.6.8_2.6.8-9_powerpc.deb to pool/main/k/kernel-patch-powerpc-2.6.8/kernel-headers-2.6.8_2.6.8-9_powerpc.deb kernel-image-2.6.8-power3-smp_2.6.8-9_powerpc.deb to pool/main/k/kernel-patch-powerpc-2.6.8/kernel-image-2.6.8-power3-smp_2.6.8-9_powerpc.deb kernel-image-2.6.8-power3_2.6.8-9_powerpc.deb to pool/main/k/kernel-patch-powerpc-2.6.8/kernel-image-2.6.8-power3_2.6.8-9_powerpc.deb kernel-image-2.6.8-power4-smp_2.6.8-9_powerpc.deb to pool/main/k/kernel-patch-powerpc-2.6.8/kernel-image-2.6.8-power4-smp_2.6.8-9_powerpc.deb kernel-image-2.6.8-power4_2.6.8-9_powerpc.deb to pool/main/k/kernel-patch-powerpc-2.6.8/kernel-image-2.6.8-power4_2.6.8-9_powerpc.deb kernel-image-2.6.8-powerpc-smp_2.6.8-9_powerpc.deb to pool/main/k/kernel-patch-powerpc-2.6.8/kernel-image-2.6.8-powerpc-smp_2.6.8-9_powerpc.deb kernel-image-2.6.8-powerpc_2.6.8-9_powerpc.deb to pool/main/k/kernel-patch-powerpc-2.6.8/kernel-image-2.6.8-powerpc_2.6.8-9_powerpc.deb kernel-patch-powerpc-2.6.8_2.6.8-9.dsc to pool/main/k/kernel-patch-powerpc-2.6.8/kernel-patch-powerpc-2.6.8_2.6.8-9.dsc kernel-patch-powerpc-2.6.8_2.6.8-9.tar.gz to pool/main/k/kernel-patch-powerpc-2.6.8/kernel-patch-powerpc-2.6.8_2.6.8-9.tar.gz Announcing to debian-devel-changes@lists.debian.org Closing bugs: 287933 Thank you for your contribution to Debian.
Bug#281905: #281905 please enable CONFIG_EFI_PARTITION; it's needed for 2TiB
Christoph Hellwig wrote: Best thing for 2TB disks is to use LVM anyway At least as far as d-i is concerned (AFAICT), you have to put LVM on top of an existing partition table; you can't just use the full /dev/sda or whatever. (The command-line lets you get around this). However, even if you do use the command line to get around d-i limitations, its still not safe to have /boot on LVM (at least according to all the documentation I've seen). I believe the only way to use d-i on machines with only 2TiB disks is to rebuild the kernel to enable EFI GPT. If EFI breaks iPods, could we maybe have an 'enable_efi' kernel command-line option to enable the support? That way, everyone could be happy.
Bug#281905: #281905 please enable CONFIG_EFI_PARTITION; it's needed for 2TiB
On Sun, Jan 09, 2005 at 08:49:54AM -0500, Anthony DeRobertis wrote: Christoph Hellwig wrote: Best thing for 2TB disks is to use LVM anyway At least as far as d-i is concerned (AFAICT), you have to put LVM on top of an existing partition table; you can't just use the full /dev/sda or whatever. (The command-line lets you get around this). Yikes. The a stupid and quite serious bug in d-i. However, even if you do use the command line to get around d-i limitations, its still not safe to have /boot on LVM (at least according to all the documentation I've seen). with lilo it's safe if the LV is created with the continuous flag, for grub I'm not sure whether it has LVM support these days, I implemented support for LVM1 ~5 years ago but it got lost (and I don't have the patch anyore either) I believe the only way to use d-i on machines with only 2TiB disks is to rebuild the kernel to enable EFI GPT. Or any other of the partition formats that work. E.g. all the SGI Altix systems with 2TB volumes (which is probably all of them) use IRIX disk labels.
Re: Bug#281905: #281905 please enable CONFIG_EFI_PARTITION; it's needed for 2TiB
On Sun, Jan 09, 2005 at 02:53:17PM +0100, Christoph Hellwig wrote: At least as far as d-i is concerned (AFAICT), you have to put LVM on top of an existing partition table; you can't just use the full /dev/sda or whatever. (The command-line lets you get around this). Yikes. The a stupid and quite serious bug in d-i. No it is not, it is unspecified if this will work. Bastian -- But Captain -- the engines can't take this much longer! signature.asc Description: Digital signature
Re: Bug#281905: #281905 please enable CONFIG_EFI_PARTITION; it's needed for 2TiB
On Sun, Jan 09, 2005 at 03:24:26PM +0100, Bastian Blank wrote: On Sun, Jan 09, 2005 at 02:53:17PM +0100, Christoph Hellwig wrote: At least as far as d-i is concerned (AFAICT), you have to put LVM on top of an existing partition table; you can't just use the full /dev/sda or whatever. (The command-line lets you get around this). Yikes. The a stupid and quite serious bug in d-i. No it is not, it is unspecified if this will work. Huh? LVM on blockdevices work. Partitions are in no way different from regular block devices from the kernel POV.
Re: Bug#284116: kernel-image-* should include vmlinux
On Tue, 14 Dec 2004 17:37:41 +0100, Juan Cespedes [EMAIL PROTECTED] said: On Tue, Dec 14, 2004 at 08:03:15AM -0800, Manoj Srivastava wrote: Being able to inspect the kernel variables and the kernel content with: gdb /boot/vmlinux /proc/kcore I disagree. People who want the bare vmlinux can use the configuration option install_vmlinux to get the debugging symbols they need I would like to be able to have a copy of the vmlinux used to generate the kernel in kernel-image-* packages. Maybe it will overbloat the package, but we could add it to anothe package or at least leave it at some URL... I don't want to debug the kernel just for fun, but to be able to know what is going on when some weird things happen. How is this any different from asking for debugging information in all the packages all the time? There is a mechanism for a user to get the debug symbols on a recompile, which is not very dofferent from any other binary package in Debian. I could recompile my own kernel to create my vmlinux, but unless I use exactly the same enviroment (gcc, etc), the resulting vmlinux will not match the kernels shipped with Debian, and that's what I need. The same argument holds for any other binary package as well, I do not see why kernel images should be treated differently. I don't know what is the best solution for this, but I would really like to have access to the vmlinux used to generate our kernels... Right. However, many users do not want to further bloat kernel packages, so we have conflicting desires. Just like other packages, it is easy enough to recreate the kernel image package with debugging symbols built in, and that should be all that is required. But unlike other packages, it is not easy to compile other kernel and just run it... in some situations, stopping a machine to try a new kernel is not acceptable. There are production machines that are restrictred, yes. I don't allow gcc and gdb on my server boxes, which makes debugging hard. However, this is a local policy decision, and not a global invariant; this should not be used to impose one set of preferences on everyone else. manoj -- Be careful! UGLY strikes 9 out of 10! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Bug#284116: kernel-image-* should include vmlinux
On Wed, 5 Jan 2005 11:13:06 +0100, Juan Cespedes [EMAIL PROTECTED] said: On Tue, Dec 14, 2004 at 05:37:41PM +0100, Juan Cespedes wrote: On Tue, Dec 14, 2004 at 08:03:15AM -0800, Manoj Srivastava wrote: I disagree. People who want the bare vmlinux can use the configuration option install_vmlinux to get the debugging symbols they need I could recompile my own kernel to create my vmlinux, but unless I use exactly the same enviroment (gcc, etc), the resulting vmlinux will not match the kernels shipped with Debian, and that's what I need. I don't know what is the best solution for this, but I would really like to have access to the vmlinux used to generate our kernels... Is anyone willing to give me an answer for this? Should I just reopen the bug report until sonething is done? I think this has been answered; and I do not think this is a bug in kernel-package. (Abstract: I need access to the vmlinux used to generate Debian shipped kernels; I am not asking for inclusion of vmlinux in the packages, but for having them available somewhere (other package? FTP site? I don't mind!). Now this is for the kernel team to decide. manoj -- I want to read my new poem about pork brains and outer space ... Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Classification scheme for 2.6 kernel patches
Hi, A few months ago, I asked on this list for more informative description of patches enabling non-kernel hackers to choose individual patchsets for their local kernels. Unfortunately, that question was denied pretty fast. Looks like you guys don't have time to write more extensive docs. cleanup: Cosmetic change bugfix: Fixes a bug that might result in errant behavior crashfix: Fixes a bug that might result in a kernel crash oopsfix: Fixes a bug that might result in a kernel oops build: Fixes a build time issue feature: Adds a new feature maybe-security: Fixes an issue that might pose a security problem security: Fixes a sure security problem license: Patch accompanying driver removal due to license issues documentation: Documentation patch only patchfix: fixes a bug introduced by some other patch Architecture-specific tags do not seem to be necessary as architecture specific patches have the architecture in their file name. To locate possible problems with the classification, I have tried to roughly classify the patches from current 2.6.10 svn: x86-i486_emu.dpatch feature tty-locking-fixes9.dpatch bugfix sparc64-hme-lockup.dpatch bugfix sparc32-initrd-memcpy.dpatchbugfix smbfs-overflow-fixes.dpatch maybe-security smbfs-overflow-fixes-2.dpatch maybe-security sec_brk-locked.dpatch security remove-references-to-removed-drivers.dpatch license powerpc-serial.dpatch bugfix powerpc-pegasos-via82cxxx.dpatchbugfix powerpc-pegasos-2.dpatchfeature powerpc-g4-l2-flush-errata.dpatch bugfix modular-vesafb.dpatch feature modular-vesafb-2.dpatch feature modular-ide.dpatch bugfix modular-ide-pnp.dpatch feature modular-ide-2.dpatchfeature marvell-pegasos.dpatch feature ia64-irq-affinity-upfix.dpatch build ia64-generic-no-smp.dpatch build ia64-generic-no-smp-1-to-2.dpatch build ia64-bte_error-missing-include.dpatch build fs-asfs.dpatch feature fix-mxser-compile.dpatchbuild drm-locking-fixes.dpatchcrashfix drivers-scsi_changer.dpatch feature drivers-net-tg3-readd.dpatchlicense drivers-net-8139too-locking.dpatch crashfix drivers-input-psaux-hacks.dpatchfeature drivers-ide-dma-blacklist-toshiba.dpatchbugfix drivers-ide-__devinit.dpatchcleanup doc-post_halloween.dpatch documentation alsa-module-load-fix.dpatch crashfix 032-do_brk_security_fixes.dpatchsecurity 031-sg_scsi_ioctl_int_overflows.dpatch security 030-moxa_user_copy_checking.dpatch security 029-random_poolsize_overflow.dpatch security 028-do_brk_security_fixes.dpatchsecurity 027-track_dummy_capability-2.dpatch cleanup 026-nfs_o_direct_error.dpatch maybe-security 025-track_dummy_capability.dpatch maybe-security 024-nfs_incorrect_df_output.dpatch bugfix 023-nfs_dentry_refcount.dpatch bugfix 022-sunrpc_xdr_flush_pages.dpatch bugfix 021-sunrpc_check_before_kill.dpatch bugfix 020-clear_cyrix_mii_ecx_reg.dpatch bugfix 019-conntrack_tcp_RST_handling.dpatch bugfix 018-ipt_recent_proc_remove.dpatch bugfix 017-conntrack_sctp_sysctl.dpatchbugfix 016-cs461x_gameport.dpatch feature 015-vmscan_total_scanned.dpatch bugfix 014-acpi_video_dev_slab_corruption.dpatch maybe-security 013-conntrack_standalone_sysctl.dpatch bugfix 012-conntrack_standalone_proc_removal.dpatchbugfix 011-parport_pc_module_parm_mixing.dpatchcleanup 010-sparc64_macro_pmd_offset.dpatch cleanup 009-ipt_ecn_corrupt_chksum.dpatch bugfix 008-sock_without_ipv6.dpatchbuild 007-pci_ide_no_reserve.dpatch bugfix 006-zatm_cast_fix_fix.dpatchbuild 005-sparc64_no_i_sock-2.dpatch patchfix 004-sparc64_no_i_sock.dpatchbuild 003-libata_alpha_build_fix.dpatch build 002-pio_err_handling.dpatch bugfix 001-acpi_ibm_exit.dpatchcleanup One possible source of problems is that some patches, for example the patchfix patches, depend on some other patches. In those case, that dependency needs to be documented more clearly. Additionally, maybe the bugfix category needs to be split into more categories, we have too
Re: Classification scheme for 2.6 kernel patches
Marc Haber wrote: Hi, A few months ago, I asked on this list for more informative description of patches enabling non-kernel hackers to choose individual patchsets for their local kernels. Unfortunately, that question was denied pretty fast. Looks like you guys don't have time to write more extensive docs. [snip] I would like to solicit your comments about this concept. I think the effort to do so is better invested elsewhere. As a general rule, the kernel team strives to keep the debian-specific patches to a minimum. For people without in-depth kernel knowledge it's probably best to take the full set of patches and add their own (feature- ?) patches on top. Thiemo
Bug#264339: another confirmation of this report
I am also seeing this on pinhead, an IBM Thinkpad T20, when trying to upgrade to kernel-image-2.6.8-2-686 (version 2.6.8-11). I'm using encrypted swap with the cryptsetup package. The kernel package installation attempt looks like this: [EMAIL PROTECTED] dkg]$ sudo apt-get install kernel-image-2.6.8-2-686 Reading Package Lists... Done Building Dependency Tree... Done kernel-image-2.6.8-2-686 is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. Need to get 0B of archives. After unpacking 0B of additional disk space will be used. Setting up kernel-image-2.6.8-2-686 (2.6.8-11) ... Unknown DM device 254:0 Failed to create initrd image. dpkg: error processing kernel-image-2.6.8-2-686 (--configure): subprocess post-installation script returned error exit status 9 Errors were encountered while processing: kernel-image-2.6.8-2-686 E: Sub-process /usr/bin/dpkg returned an error code (1) [EMAIL PROTECTED] dkg]$ if i swapoff that encrypted device, the installation still doesn't work: [EMAIL PROTECTED] dkg]$ sudo swapoff /dev/mapper/cryptswap [EMAIL PROTECTED] dkg]$ sudo apt-get install kernel-image-2.6.8-2-686 Reading Package Lists... Done Building Dependency Tree... Done kernel-image-2.6.8-2-686 is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. Need to get 0B of archives. After unpacking 0B of additional disk space will be used. Setting up kernel-image-2.6.8-2-686 (2.6.8-11) ... Unknown DM device 254:0 Failed to create initrd image. dpkg: error processing kernel-image-2.6.8-2-686 (--configure): subprocess post-installation script returned error exit status 9 Errors were encountered while processing: kernel-image-2.6.8-2-686 E: Sub-process /usr/bin/dpkg returned an error code (1) [EMAIL PROTECTED] dkg]$ but if i actually tell the device mapper to unmap the encrypted partition, the installation proceeds as expected: [EMAIL PROTECTED] dkg]$ sudo /sbin/cryptsetup remove cryptswap [EMAIL PROTECTED] dkg]$ sudo apt-get install kernel-image-2.6.8-2-686 Reading Package Lists... Done Building Dependency Tree... Done kernel-image-2.6.8-2-686 is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. Need to get 0B of archives. After unpacking 0B of additional disk space will be used. Setting up kernel-image-2.6.8-2-686 (2.6.8-11) ... Searching for GRUB installation directory ... found: /boot/grub . Testing for an existing GRUB menu.list file... found: /boot/grub/menu.lst . Searching for splash image... none found, skipping... Found kernel: /vmlinuz-2.6.8-2-686 Found kernel: /vmlinuz-2.6.8-1-686 Found kernel: /vmlinuz-2.4.27-1-686 Found kernel: /vmlinuz-2.4.26-1-686 Found kernel: /memtest86+.bin Updating /boot/grub/menu.lst ... done [EMAIL PROTECTED] dkg]$ i'm happy to supply any additional information about the system if it would help; let me know what's needed. --dkg
Re: r2230 - in trunk/kernel/source/kernel-source-2.6.10-2.6.10/debian: . patches patches/series
+ static int __init init_ext3_fs(void)
+ {
+ int err = init_ext3_xattr();
++
++/* fix for oops */
++printk(KERN_ERR [%d] init_ext3_fs(), err = %d\n, __LINE__, err);
urgg, this is not a fix but a hack. Should look more like:
/* ugly hack to work around compiler bug */
#ifdef __alpha__
printk(KERN_DEBUG [%d] init_ext3_fs(), err = %d\n, __LINE__, err);
#endif
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 07:40:06PM +0100, Thiemo Seufer wrote: I think the effort to do so is better invested elsewhere. As a general rule, the kernel team strives to keep the debian-specific patches to a minimum. For people without in-depth kernel knowledge it's probably best to take the full set of patches and add their own (feature- ?) patches on top. Agreed. The package is not a repository for cherrypicking patches but intended to used as a whole thing.
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 07:40:06PM +0100, Thiemo Seufer wrote: I think the effort to do so is better invested elsewhere. As a general rule, the kernel team strives to keep the debian-specific patches to a minimum. For people without in-depth kernel knowledge it's probably best to take the full set of patches and add their own (feature- ?) patches on top. Actually, the kernel of my dreams is more near to the vanilla kernel.org kernel, so I'd like to be able to throw out patches that you need to apply because of your _much_ broader user base. otoh, I would like to run a 2.6.10 kernel _now_ and cannot take the distribution kernel because it is still stuck in NEW. It is adviseable to take a snapshot from the Debian kernel svn? And, without trolling, I'd like to build my local kernels from sources that haven't had drivers removed because of non-free licenses. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 08:25:33PM +0100, Christoph Hellwig wrote: Agreed. The package is not a repository for cherrypicking patches but intended to used as a whole thing. I am pretty disappointed about that attitude towards your users. What exactly is the problem with a little more docs to _allow_ cherrypicking? Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 08:33:51PM +0100, Marc Haber wrote: Actually, the kernel of my dreams is more near to the vanilla kernel.org kernel, so I'd like to be able to throw out patches that you need to apply because of your _much_ broader user base. otoh, I would like to run a 2.6.10 kernel _now_ and cannot take the distribution kernel because it is still stuck in NEW. It is adviseable to take a snapshot from the Debian kernel svn? And, without trolling, I'd like to build my local kernels from sources that haven't had drivers removed because of non-free licenses. I think only one of my machines is running a Debian-built kernel. Debian is much more forgiving of using a stock kernel than some other distributions. -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 07:36:47PM +, Matthew Wilcox wrote: On Sun, Jan 09, 2005 at 08:33:51PM +0100, Marc Haber wrote: Actually, the kernel of my dreams is more near to the vanilla kernel.org kernel, so I'd like to be able to throw out patches that you need to apply because of your _much_ broader user base. otoh, I would like to run a 2.6.10 kernel _now_ and cannot take the distribution kernel because it is still stuck in NEW. It is adviseable to take a snapshot from the Debian kernel svn? And, without trolling, I'd like to build my local kernels from sources that haven't had drivers removed because of non-free licenses. I think only one of my machines is running a Debian-built kernel. Debian is much more forgiving of using a stock kernel than some other distributions. It definetely is, and it is exceptionally good in allowing usage of infrastructure for local builds and installation as well. kernel-package is one of the big advantages that has driven me to Debian years ago. Using infrastructure that makes individual patch files is a big step forward as well as this enables people to individually choose their patch sets. The progress is impressive. What we need now are better docs, and a few minor tweaks in the tools. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
Re: Classification scheme for 2.6 kernel patches
Marc Haber wrote: On Sun, Jan 09, 2005 at 07:40:06PM +0100, Thiemo Seufer wrote: I think the effort to do so is better invested elsewhere. As a general rule, the kernel team strives to keep the debian-specific patches to a minimum. For people without in-depth kernel knowledge it's probably best to take the full set of patches and add their own (feature- ?) patches on top. Actually, the kernel of my dreams is more near to the vanilla kernel.org kernel, so I'd like to be able to throw out patches that you need to apply because of your _much_ broader user base. Well, then you need detailed knowledge about those patches in any case. (If you know you don't use that code, why bother? The patch won't make a difference for you.) otoh, I would like to run a 2.6.10 kernel _now_ and cannot take the distribution kernel because it is still stuck in NEW. http://www.acm.rpi.edu/~dilinger/ It is adviseable to take a snapshot from the Debian kernel svn? You can use the appopriate SVN tag as well if you like. And, without trolling, I'd like to build my local kernels from sources that haven't had drivers removed because of non-free licenses. Disable the purge script in the kernel-source source package. Thiemo
Re: Classification scheme for 2.6 kernel patches
Marc Haber wrote: On Sun, Jan 09, 2005 at 08:25:33PM +0100, Christoph Hellwig wrote: Agreed. The package is not a repository for cherrypicking patches but intended to used as a whole thing. I am pretty disappointed about that attitude towards your users. What exactly is the problem with a little more docs to _allow_ cherrypicking? It generates work. The time is better used for pushing those patches upstream. Cherrypicking makes little sense, because there are only cherries. :-) Thiemo
kernel-patch-powerpc-2.6.9_2.6.9-2_powerpc.changes UNACCEPT
Rejected: Rejected: kernel-image-power3-smp_2.6.9-2_powerpc.deb: old version (100) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-patch-powerpc-2.6.9_2.6.9-2_all.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-patch-powerpc-2.6.9_2.6.9-2.dsc: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-build-2.6.9-powerpc-smp_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-build-2.6.9-power3-smp_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-build-2.6.9-power3_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-power3_2.6.9-2_powerpc.deb: old version (100) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-2.6.9-powerpc_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-2.6.9-power3-smp_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-powerpc_2.6.9-2_powerpc.deb: old version (100) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-2.6.9-power3_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-power4-smp_2.6.9-2_powerpc.deb: old version (100) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-build-2.6.9-powerpc_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-2.6.9-power4_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-2.6.9-powerpc-smp_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-power4_2.6.9-2_powerpc.deb: old version (100) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-build-2.6.9-power4_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-build-2.6.9-power4-smp_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-2.6.9-power4-smp_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-powerpc-smp_2.6.9-2_powerpc.deb: old version (100) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-headers-2.6.9_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. === Despite being ACCEPTed, this package failed the database sanity checks at the time of install. This should only happen rarely and in corner-cases (a binary upload of a package which has since been melanie'd for example), so no code to do the necessary unaccept actions has been written. These actions (e.g. bug reopening, announcement rescinding, etc.) will have to be done by hand. Also, the files have been left in the accepted directory; please deal with them as well.
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 08:52:59PM +0100, Thiemo Seufer wrote: Cherrypicking makes little sense, because there are only cherries. :-) For my systems, I care about security holes being fixed, but I do not care about some obscure video hardware, or additional features. So Cherry is relative. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
Re: Classification scheme for 2.6 kernel patches
On Sun, 09 Jan 2005 20:41:41 +0100, Marc Haber wrote: On Sun, Jan 09, 2005 at 08:25:33PM +0100, Christoph Hellwig wrote: Agreed. The package is not a repository for cherrypicking patches but intended to used as a whole thing. I am pretty disappointed about that attitude towards your users. What exactly is the problem with a little more docs to _allow_ cherrypicking? Greetings Marc A large problem with this is that patches in our -source packages assume a certain order. A patch may depend upon another patch; removing one breaks the other. We have this problem when cherry-picking changes from bitkeeper; I'd imagine it gets even worse when you attempt to pick changes from -source packages.
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 03:56:48PM -0500, Andres Salomon wrote: On Sun, 09 Jan 2005 20:41:41 +0100, Marc Haber wrote: On Sun, Jan 09, 2005 at 08:25:33PM +0100, Christoph Hellwig wrote: Agreed. The package is not a repository for cherrypicking patches but intended to used as a whole thing. I am pretty disappointed about that attitude towards your users. What exactly is the problem with a little more docs to _allow_ cherrypicking? Greetings Marc A large problem with this is that patches in our -source packages assume a certain order. A patch may depend upon another patch; removing one breaks the other. We have this problem when cherry-picking changes from bitkeeper; I'd imagine it gets even worse when you attempt to pick changes from -source packages. Choosing a working patchset would be the responsibility of the picking user, no work on your side involved. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
Re: r2230 - in trunk/kernel/source/kernel-source-2.6.10-2.6.10/debian: . patches patches/series
* Christoph Hellwig wrote:
+ static int __init init_ext3_fs(void)
+ {
+ int err = init_ext3_xattr();
++
++ /* fix for oops */
++ printk(KERN_ERR [%d] init_ext3_fs(), err = %d\n, __LINE__, err);
urgg, this is not a fix but a hack. Should look more like:
/* ugly hack to work around compiler bug */
#ifdef __alpha__
printk(KERN_DEBUG [%d] init_ext3_fs(), err = %d\n, __LINE__, err);
#endif
Indeed... updated for 2.6.8 and 2.6.10, thanks.
Norbert
Re: Classification scheme for 2.6 kernel patches
On Sun, 09 Jan 2005 19:01:38 +0100, Marc Haber wrote: Hi, A few months ago, I asked on this list for more informative description of patches enabling non-kernel hackers to choose individual patchsets for their local kernels. Unfortunately, that question was denied pretty fast. Looks like you guys don't have time to write more extensive docs. cleanup: Cosmetic change Shouldn't be in Debian kernels. bugfix: Fixes a bug that might result in errant behavior This applies to pretty much every patch. Even feature additions are usually fixing bugs of the type machine XYZ doesn't boot! or I can't use my network card with your kernel crashfix: Fixes a bug that might result in a kernel crash oopsfix: Fixes a bug that might result in a kernel oops build: Fixes a build time issue Not worth classifying the differences, imo. Something that might crash one machine might oops on another; it depends on hardware, what the kernel config is, etc. Build problems are the most clear-cut on this list, but I can't imagine why you wouldn't want to include them. There's also warning build fixes, which might be necessary (if the code in question causes an oops/crash), or might simply be to shut the compiler up. feature: Adds a new feature Aside from non-x86 stuff, we try to avoid these. Some archs need them for basic hardware; in which case, they could easily be considered a bugfix. The general rule is, if it's not needed to boot/install, it should be in a separate kernel-patch package. maybe-security: Fixes an issue that might pose a security problem Pretty much any bugfix is possibly a security hole that no one's figured out how to exploit yet. This is just another name for bugfix. security: Fixes a sure security problem We already try to use this one. license: Patch accompanying driver removal due to license issues I believe we have exactly 1 patch (tg3-readd) that would be classified as this. That patch needs to go away, as well, as it's a hassle to maintain. documentation: Documentation patch only I would think this would be easy enough to determine simply by looking at the patch? We don't really have too many of these to begin with. patchfix: fixes a bug introduced by some other patch When you end up with a large number of patches, this becomes quite an annoyance. Architecture-specific tags do not seem to be necessary as architecture specific patches have the architecture in their file name. To locate possible problems with the classification, I have tried to roughly classify the patches from current 2.6.10 svn: x86-i486_emu.dpatch feature tty-locking-fixes9.dpatch bugfix sparc64-hme-lockup.dpatch bugfix sparc32-initrd-memcpy.dpatch bugfix smbfs-overflow-fixes.dpatch maybe-security smbfs-overflow-fixes-2.dpatch maybe-security sec_brk-locked.dpatch security remove-references-to-removed-drivers.dpatch license powerpc-serial.dpatch bugfix powerpc-pegasos-via82cxxx.dpatch bugfix powerpc-pegasos-2.dpatch feature powerpc-g4-l2-flush-errata.dpatch bugfix modular-vesafb.dpatch feature modular-vesafb-2.dpatch feature modular-ide.dpatchbugfix modular-ide-pnp.dpatchfeature modular-ide-2.dpatch feature marvell-pegasos.dpatchfeature ia64-irq-affinity-upfix.dpatchbuild ia64-generic-no-smp.dpatchbuild ia64-generic-no-smp-1-to-2.dpatch build ia64-bte_error-missing-include.dpatch build fs-asfs.dpatchfeature fix-mxser-compile.dpatch build drm-locking-fixes.dpatch crashfix drivers-scsi_changer.dpatch feature drivers-net-tg3-readd.dpatch license drivers-net-8139too-locking.dpatchcrashfix drivers-input-psaux-hacks.dpatch feature drivers-ide-dma-blacklist-toshiba.dpatch bugfix drivers-ide-__devinit.dpatch cleanup doc-post_halloween.dpatch documentation alsa-module-load-fix.dpatch crashfix 032-do_brk_security_fixes.dpatch security 031-sg_scsi_ioctl_int_overflows.dpatchsecurity 030-moxa_user_copy_checking.dpatchsecurity 029-random_poolsize_overflow.dpatch security 028-do_brk_security_fixes.dpatch security 027-track_dummy_capability-2.dpatch cleanup This actually fixes 025. It could be considered security, or cleanup, or patchfix. Kind of hard to classify it with one word. 026-nfs_o_direct_error.dpatch
Bug#288272: Very slow on Toshiba Satellite Pro 4360
I'm seeing the same problem on my Toshiba Satellite Pro 4360. Switching to the other kernel I have available (2.4.18) speeds it back up.
Re: r2215 - in trunk/kernel/source/kernel-source-2.6.10-2.6.10/debian/patches: . series
* Christoph Hellwig wrote: +- smbfs-overflow-fixes.dpatch ++ smbfs-overflow-fixes-2.dpatch The new patch doesn't apply: -- 2.6.10-3 fully applied. smbfs-overflow-fixes.dpatch OK (-) smbfs-overflow-fixes-2.dpatch OK (+) 1 out of 2 hunks FAILED -- saving rejects to file drivers/ide/pci/generic.c.rej modular-ide.dpatch FAIL (-) make: *** [binary-indep] Error 1 Norbert
Bug#289610: kernel-source-2.6.10: console screen blank when vesafb compiled statically
Package: kernel-source-2.6.10 Version: 2.6.10-3 Severity: important Compiling the kernel with the debianized /drivers/video/vesafb.c statically results in a blank screen at bootup. Replacing with the vanilla vesafb.c works. I patched with the bootsplash-3.1.4-2.6.10.diff from bootsplash.de before compiling. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-20050109 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages kernel-source-2.6.10 depends on: ii binutils 2.15-5 The GNU assembler, linker and bina ii bzip2 1.0.2-3high-quality block-sorting file co ii coreutils [fileutils] 5.2.1-2The GNU core utilities -- no debconf information
Re: r2215 - in trunk/kernel/source/kernel-source-2.6.10-2.6.10/debian/patches: . series
* Norbert Tretkowski wrote: * Christoph Hellwig wrote: +- smbfs-overflow-fixes.dpatch ++ smbfs-overflow-fixes-2.dpatch The new patch doesn't apply: -- 2.6.10-3 fully applied. smbfs-overflow-fixes.dpatch OK (-) smbfs-overflow-fixes-2.dpatch OK (+) 1 out of 2 hunks FAILED -- saving rejects to file drivers/ide/pci/generic.c.rej modular-ide.dpatch FAIL (-) make: *** [binary-indep] Error 1 D'uh... too late already... problem is in modular-ide.dpatch of course. Norbert
kernel-image-2.6.10-i386_2.6.10-3_i386.changes ACCEPTED
Accepted: kernel-headers-2.6.10-1-386_2.6.10-3_i386.deb to pool/main/k/kernel-image-2.6.10-i386/kernel-headers-2.6.10-1-386_2.6.10-3_i386.deb kernel-headers-2.6.10-1-686-smp_2.6.10-3_i386.deb to pool/main/k/kernel-image-2.6.10-i386/kernel-headers-2.6.10-1-686-smp_2.6.10-3_i386.deb kernel-headers-2.6.10-1-686_2.6.10-3_i386.deb to pool/main/k/kernel-image-2.6.10-i386/kernel-headers-2.6.10-1-686_2.6.10-3_i386.deb kernel-headers-2.6.10-1-k7-smp_2.6.10-3_i386.deb to pool/main/k/kernel-image-2.6.10-i386/kernel-headers-2.6.10-1-k7-smp_2.6.10-3_i386.deb kernel-headers-2.6.10-1-k7_2.6.10-3_i386.deb to pool/main/k/kernel-image-2.6.10-i386/kernel-headers-2.6.10-1-k7_2.6.10-3_i386.deb kernel-headers-2.6.10-1_2.6.10-3_i386.deb to pool/main/k/kernel-image-2.6.10-i386/kernel-headers-2.6.10-1_2.6.10-3_i386.deb kernel-image-2.6.10-1-386_2.6.10-3_i386.deb to pool/main/k/kernel-image-2.6.10-i386/kernel-image-2.6.10-1-386_2.6.10-3_i386.deb kernel-image-2.6.10-1-686-smp_2.6.10-3_i386.deb to pool/main/k/kernel-image-2.6.10-i386/kernel-image-2.6.10-1-686-smp_2.6.10-3_i386.deb kernel-image-2.6.10-1-686_2.6.10-3_i386.deb to pool/main/k/kernel-image-2.6.10-i386/kernel-image-2.6.10-1-686_2.6.10-3_i386.deb kernel-image-2.6.10-1-k7-smp_2.6.10-3_i386.deb to pool/main/k/kernel-image-2.6.10-i386/kernel-image-2.6.10-1-k7-smp_2.6.10-3_i386.deb kernel-image-2.6.10-1-k7_2.6.10-3_i386.deb to pool/main/k/kernel-image-2.6.10-i386/kernel-image-2.6.10-1-k7_2.6.10-3_i386.deb kernel-image-2.6.10-i386_2.6.10-3.dsc to pool/main/k/kernel-image-2.6.10-i386/kernel-image-2.6.10-i386_2.6.10-3.dsc kernel-image-2.6.10-i386_2.6.10-3.tar.gz to pool/main/k/kernel-image-2.6.10-i386/kernel-image-2.6.10-i386_2.6.10-3.tar.gz Announcing to debian-devel-changes@lists.debian.org Thank you for your contribution to Debian.
Re: Status of Kernel 2.4.28 packages?
Horms wrote: Debian isn't lowering priority on Linux 2.4 work but individual people are. I am one of the people who do work on 2.4 for debian, I won't raise the hands of others. Personally my focus is 2.4.27, because that is what will go into sarge and right now I don't have the time to do 2.4.27 and 2.4.28. And to be honest I think that any surplus time would be best spent working on 2.6 as that is a mountain of work. The reason kernel-source-2.4.28 is unfinished is because I'm waiting for Herbert Xu to release an IPsec patch for 2.4.28. Once that happens we can see about getting it in the archive and tested. Hope this status update quells any other concerns.. -- Joshua Kwan signature.asc Description: OpenPGP digital signature
