Bug#507557: linux-image-2.6.26-1-r4k-ip22: hangs early at boot on Indigo2
Julien BLACHE wrote: Thiemo Seufer t...@networkno.de wrote: Hi, ok, do you have a chance to test something newer preferred git-current ? If you have a kernel I can try, sure. Building one is another story, this machine isn't exactly fast nor quiet, as you probably know... you could cross-build upstream kernels, e.g. with my cross-toolchain for lenny: http://people.debian.org/~ths/toolchain/ I wish you had it built for amd64 :) Use the crossbuild script in there to build your own. :-) Thiemo -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507557: linux-image-2.6.26-1-r4k-ip22: hangs early at boot on Indigo2
Julien BLACHE wrote: [EMAIL PROTECTED] (Thomas Bogendoerfer) wrote: Hi, ok, do you have a chance to test something newer preferred git-current ? If you have a kernel I can try, sure. Building one is another story, this machine isn't exactly fast nor quiet, as you probably know... you could cross-build upstream kernels, e.g. with my cross-toolchain for lenny: http://people.debian.org/~ths/toolchain/ Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484365: suggestion: switch to linux-libre in main
Alexandre Oliva wrote: Package: linux-2.6 Severity: normal In case you're not aware, the linux-libre project grew out of gNewSense's efforts to publish 100% Free Software extracts from the kernel distributed by kernel.org, later on picked up by BLAG and, more recently, by FSF Latin America. You might want to use it, instead of kernel.org's kernel, to get closer to compliance with your policy of shipping only Free Software in main. Whether you move the non-Free kernel you currently ship to non-free, or simply remove it, is something you should discuss and decide on your own, but I thought I'd remind you of both possibilities. What are the specific instances of non-free software you found in Debian's kernel? linux-libre is currently available at http://www.fsfla.org/~lxoliva/fsfla/linux-libre/ There's a README in there. We're considering creating a freed-ebian repository with linux-libre-based kernels for Debian GNU/Linux in there, but we hope that, knowing how seriously you take your social contract and the freedom of your users, I thought you might want to preempt that move. I didn't find documentation about what was actually removed. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466977: 2.6.24-1-sb1-bcm91250a mipsel hangs running init
Martin Michlmayr wrote: * Thiemo Seufer [EMAIL PROTECTED] [2008-03-03 15:18]: The appended patch works around the problem. I don't tag it as patch because its implications are not fully analyzed upstream. It works well on my bcm91250a system, though. Do you want me to put this into our kernel package, or should I wait for Ralf to comment on the patch? I would like to wait a bit (unless we miss an important debian kernel deadline). Any update on this? My patch improves things, but the latest kernel is still somewhat crashy on SWARM. It works on BigSur, though. I didn't get any upstream comments about my patch. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465278: Mouse doesn't work on iBook G4 after sleep in Sid
Gaudenz Steinlin wrote: On Fri, Mar 28, 2008 at 09:54:15AM +0100, Francesco Pedrini wrote: On Tuesday 25 March 2008, Denís Fernández Cabrera wrote: Hello, I dist-upgraded, last weekend, to the lastest version of Sid on the repositories for my iBook G4 (summer 2005). Generally, it works very well (it did fix several bugs that I was suffering till now), but I mouse support after suspension doesn't. After suspending the system (e.g. by closing the lid) it resumes correctly, but the mouse is useless. It won't move or receive any clicks, and restarting X doesn't help. I have to do a full system restart for the mouse to work again. I also see this occasionally. It does not happen on every suspend/resume cycle. But for me it's always enogh to just rmmod and modprobe appletouch. Just switch to a text console with ctrl-alt-f1, login as root and type rmmod appletouch ; modprobe appletouch. My machine is a powerbook5,8 and I'm using 2.6.25-rc7 (self compiled). I see the same on my iBook G4 with Debian's 2.6.24-4, however, re-loading appletouch does not work for me. Thiemo
Re: Enable some debug options
Bastian Blank wrote: Hi folks I'd like to enable some debug options for all images: - PRINTK_TIME Is this one useful for non-esoteric cases? - DEBUG_KERNEL - SCHED_DEBUG, not sure yet, its one by default - TIMER_STATS, needed for powertop, gives some usefull data even on non-x86 Bastian -- A little suffering is good for the soul. -- Kirk, The Corbomite Maneuver, stardate 1514.0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Changes for 2.6.25
Bastian Blank wrote: On Tue, Feb 26, 2008 at 03:18:23PM +0100, Aurelien Jarno wrote: - Drop ext2 built-in exception for arm and mips. Could we have a waver for the versatile flavour on armel until support is added to d-i? There are almost 2 months left. About mips/mipsel, I am not sure this is actually possible, as those platforms are not using initrd and thus won't be able to boot without ext2 support. They need to include all local filesystems then. I can't see why. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6_2.6.24~rc8-1~experimental.2~snapshot.10147 FTBFS on mips
Thiemo Seufer wrote:
Martin Michlmayr wrote:
* Florian Lohoff [EMAIL PROTECTED] [2008-01-21 15:00]:
linux-2.6 version linux-2.6_2.6.24~rc8-1~experimental.2~snapshot.10147
FTBFS on mips:
CC [M] drivers/net/niu.o
{standard input}: Assembler messages:
{standard input}:293: Error: Branch out of range
make[6]: *** [drivers/net/niu.o] Error 1
I believe this is actually a kernel bug. Looking at the preprocessed
source, I see that it contains some inline assembler:
__asm__ __volatile__(
.setmips3 \n
1:ll%0, %1 # set_bit \n
or %0, %2 \n
sc%0, %1 \n
beqz%0, 2f \n
.subsection 2 \n
2: b 1b \n
.previous \n
And the Branch out of range error is in that piece of code.
Ralf/Aurelien, can you please take a look.
This is caused by the subsection trick which breaks for large
sections. The problem is fixed in the latest www.linux-mips.org tree.
Apparently I misremembered, and the problem still exists.
Thiemo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6_2.6.24~rc8-1~experimental.2~snapshot.10147 FTBFS on mips
Martin Michlmayr wrote:
* Florian Lohoff [EMAIL PROTECTED] [2008-01-21 15:00]:
linux-2.6 version linux-2.6_2.6.24~rc8-1~experimental.2~snapshot.10147
FTBFS on mips:
CC [M] drivers/net/niu.o
{standard input}: Assembler messages:
{standard input}:293: Error: Branch out of range
make[6]: *** [drivers/net/niu.o] Error 1
I believe this is actually a kernel bug. Looking at the preprocessed
source, I see that it contains some inline assembler:
__asm__ __volatile__(
.setmips3 \n
1:ll%0, %1 # set_bit \n
or %0, %2 \n
sc%0, %1 \n
beqz%0, 2f \n
.subsection 2 \n
2: b 1b \n
.previous \n
And the Branch out of range error is in that piece of code.
Ralf/Aurelien, can you please take a look.
This is caused by the subsection trick which breaks for large
sections. The problem is fixed in the latest www.linux-mips.org tree.
Thiemo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451805: linux-image-2.6.22-3-r4k-ip22 dies early on boot / Starting ELF64 kernel
Florian Lohoff wrote: On Mon, Nov 26, 2007 at 12:21:49PM +, Thiemo Seufer wrote: With proper support in the installer, different images, and even further increased buildd time: Quite a lot. The point is that there are probably a lot ore IP22 old-r4k users than there are matla 4kc or 5kc users ;) And those have a kernel (but no d-i support) I plan to do Malta installer support. (This allows us to scrap the odd QEMU-specific kernel and use the Malta Emulation instead.) Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451805: linux-image-2.6.22-3-r4k-ip22 dies early on boot / Starting ELF64 kernel
Florian Lohoff wrote: On Fri, Nov 23, 2007 at 05:54:52PM +, Thiemo Seufer wrote: That's a decision Thiemo would have to make. Thiemo, why is our IP22 kernel 64 bit again? The idea is to provide 64-bit kernels where possible, so n32/n64 can work alongside o32. The errata Thomas ad-hoc found was for example that a double-word shift garbles an integer multiplication. This would cause an n32/n64 userspace also to break in colorful ways if not compiled with these workarounds. So running 64bit on these kind of machines might be too much hassle ... Unless we use the compiler options mentioned before, which is probably not sensible given the performance impcat for other machines. However, keeping the kernel for IP22 at 64 bit sounds valuable to me, as most machines can make use of it. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451805: linux-image-2.6.22-3-r4k-ip22 dies early on boot / Starting ELF64 kernel
Martin Michlmayr wrote: * Florian Lohoff [EMAIL PROTECTED] [2007-11-23 17:59]: SGI IP22 Indy r4k 100Mhz will not be able to boot unmodified 64bit kernels. There are 64bit erratas for R4000SC Revision 3.0 which prohibit running 64bit code without kernel and gcc modifications. The only solution will be to run a 32bit kernel. I compiled the debian source with debian config except with 32Bit and it works. That's a decision Thiemo would have to make. Thiemo, why is our IP22 kernel 64 bit again? The idea is to provide 64-bit kernels where possible, so n32/n64 can work alongside o32. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451805: linux-image-2.6.22-3-r4k-ip22 dies early on boot / Starting ELF64 kernel
Florian Lohoff wrote: On Sun, Nov 18, 2007 at 07:11:53PM +0100, Martin Michlmayr wrote: * Florian Lohoff [EMAIL PROTECTED] [2007-11-18 19:02]: Version: 2.6.22-6 the kernel linux-image-2.6.22-3-r4k-ip22_2.6.22-6_mips.deb dies early on an SGI IP22 (mips) with That's strange because I booted a kernel just fine when I added the patches to 2.6.22-6. I'll test the .deb tomorrow. Okay - Now we got it: SGI IP22 Indigo2 250Mhz fails because of wrong EISA IRQ numbering overwriting CPU interrupts discovered by Thomas Bogendoerfer. Additionally there is a broken MAP_BASE which causes modules to not work. -#define MAP_BASE 0xc000 +#define MAP_BASE 0xc000 Additionally the I2 fails to get the MAC Address from the PROM so we end with 00:00:00:00:00 ... SGI IP22 Indy r4k 100Mhz will not be able to boot unmodified 64bit kernels. There are 64bit erratas for R4000SC Revision 3.0 which prohibit running 64bit code without kernel and gcc modifications. The only solution will be to run a 32bit kernel. I compiled the debian source with debian config except with 32Bit and it works. Gcc 4.2 has -mfix-r4000 and -mfix-r4400 options which work around some of those errata. Maybe that's enough to make it work. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451805: linux-image-2.6.22-3-r4k-ip22 dies early on boot / Starting ELF64 kernel
Florian Lohoff wrote:
On Mon, Nov 19, 2007 at 12:14:09PM +0100, Martin Michlmayr wrote:
Can you build a kernel from linux-mips git and see if that works?
After trying to produce a new toolchain:
net/sched/em_meta.c: In function 'meta_int_loadavg_0':
net/sched/em_meta.c:127: error: PRINT_OPERAND, invalid operand for relocation
(const:DI (plus:DI (symbol_ref:DI (avenrun) [flags 0x40] var_decl
0x405a2960 avenrun)
(const_int 4 [0x4])))
net/sched/em_meta.c:127: internal compiler error: in print_operand_reloc, at
config/mips/mips.c:5579
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
{standard input}: Assembler messages:
{standard input}:0: Warning: end of file not at end of a line; newline
inserted
{standard input}:1875: Warning: missing .end at end of assembly
make[2]: *** [net/sched/em_meta.o] Error 1
make[1]: *** [net/sched] Error 2
make[1]: *** Waiting for unfinished jobs
Now also while cross-compiling ...
AFAIR this is a compiler bug which was fixed in the meanwhile. Maybe
http://people.debian.org/~ths/toolchain/ works better.
Thiemo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cannot install kernel headers package
Federico Giacomini wrote: Hello, I need to build the kernel-image and headers .deb packages for a embedded system equipped with Debian etch. As the embedded processor is not much powerful (P III) and is too busy with several other tasks, I have to compile the kernel source (vanilla 2.6.20 patched with RTAI) on a PC running Kubuntu feisty. I made the packages with the usual command: fakeroot make-kpkg --revision=0.1 --append-to-version=-rtai kernel_image kernel_headers The kernel .deb package could be successfully installed on the Debian system, but when I tried to install the kernel_headers package, the following error occurred: dpkg: dependency problems prevent configuration of linux-headers-2.6.20-rtai: linux-headers-2.6.20-rtai depends on libc6 (= 2.5-0ubuntu1); however: Version of libc6 on system is 2.3.6.ds1-13etch2. dpkg: error processing linux-headers-2.6.20-rtai (--install): dependency problems - leaving unconfigured Errors were encountered while processing: linux-headers-2.6.20-rtai My question is: how can I correctly make a cross-system (Ubuntu/Debian) kernel compilation/installation? Any help will be highly appreciated! Build inside an etch chroot. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445177: m68k: asm/cachectl.h ?
Package: linux-2.6 Version: - Tags: patch Hector Oron wrote: Hello, I am trying to build a gcc cross compiler package for i386-m68k but i get this error: ../../../src/libffi/src/m68k/ffi.c:13:26: error: asm/cachectl.h: No such file or directory Do you know where should be cachectl.h? As it is not in kernel headers. Or is it a bug on GCC code (ffi.c includes)? This is a bug in linux-2.6. m68k fails to export the header. The appended patch should fix this (untested). Thiemo diff --git a/include/asm-m68k/Kbuild b/include/asm-m68k/Kbuild index c68e168..a60c1db 100644 --- a/include/asm-m68k/Kbuild +++ b/include/asm-m68k/Kbuild @@ -1 +1,3 @@ include include/asm-generic/Kbuild.asm + +header-y += cachectl.h -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421377: linux-2.6: Please add the malta flavour on mips and mipsel
Martin Michlmayr wrote: * Aurelien Jarno [EMAIL PROTECTED] [2007-04-28 14:32]: Please find attached a patch to add a malta flavour to the linux-2.6 package on mips and mipsel. As the names says, it support the Malta board, which is a development board produced by MIPS, and which can run various CPU. QEMU also emulates such a board. Most of our mips kernels are 64 bit these days. Any good reason why this one isn't? Most CPUs used on Malta are 32bit. Qemu currently can't emulate MIPS64 Malta. Also, do we want this flavour for mipsel as well? Yes. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421377: linux-2.6: Please add the malta flavour on mips and mipsel
Martin Michlmayr wrote: * Thiemo Seufer [EMAIL PROTECTED] [2007-04-28 19:21]: IOW, both flavours for now, and when the Malta Qemu emulation stabilizes we can drop the Qemu-specific one. OK. What name do you want to use for this flavour? Just malta or xxx-malta and what's xxx? Hm, a tricky question since Malta supports many different CPUs. 4kc-malta would be the compatible denominator for the kernel config given, i.e. we don't support the old legacy core cards with MIPS IV CPUs, but any 4kc or newer CPU should work ok. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421377: linux-2.6: Please add the malta flavour on mips and mipsel
Martin Michlmayr wrote: * Aurelien Jarno [EMAIL PROTECTED] [2007-04-28 14:32]: Please find attached a patch to add a malta flavour to the linux-2.6 package on mips and mipsel. As the names says, it support the Malta board, which is a development board produced by MIPS, and which can run various CPU. QEMU also emulates such a board. I guess we could drop the qemu flavour and add this one instead. I'm a bit reluctant to add another flavour without removing one, although it's not such a big problem on mips/mipsel. Thiemo, what do you think? Aurelien, are there any advantages of the current qemu image over malta? I reagard the Qemu Malta support as work in progress. I know of some flaws which need fixing, and which appear not to be present in the generic Qemu MIPS emulation. IOW, both flavours for now, and when the Malta Qemu emulation stabilizes we can drop the Qemu-specific one. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.18-5 schedule
maximilian attems wrote: hello, the vserver guys have fixes for sparc and s390. i expect them to be applied soonest. so the schedule for 2.6.18-5 upload would be tomorrow. nobse please check if the patch from vorlon satitisfies. the ia64 build fix is acked by dannf. I plan to sneak in qemu configs for mips/mipsel this night if my testbuild succeeds. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing linux-2.6 2.6.18-1
Nathanael Nerode wrote: Steve Langasek wrote: If it is the consensus of the project that sourceless firmware doesn't belong in main, this is a conscious regression in DFSG-compliance relative to sarge. I don't think that's acceptable. We obviously do have the means to remove this particular subset of non-free firmware from main (technically imperfect though it may be), and of the firmware that was removed for sarge the only one that was important enough to get me glared at personally was qla2xxx -- so what are these other already-removed firmwares that are so important to have re-added now? (I did ask for a list, which no one has provided yet; I can't find the pruning script in the kernel team's svn repo, or I would look it up myself.) Here you go, Steve. drivers/media/video/dabfirmware.h drivers/net/acenic_firmware.h drivers/net/dgrs_firmware.c drivers/net/tokenring/smctr_firmware.h drivers/usb/misc/emi62_fw_m.h drivers/usb/misc/emi62_fw_s.h The above are all undistributable: smctr_firmware.h under a use-only license, the others because they are GPL without source or have no license at all. drivers/usb/serial/keyspan_mpr_fw.h drivers/usb/serial/keyspan_usa18x_fw.h drivers/usb/serial/keyspan_usa19_fw.h drivers/usb/serial/keyspan_usa19qi_fw.h drivers/usb/serial/keyspan_usa19qw_fw.h drivers/usb/serial/keyspan_usa19w_fw.h drivers/usb/serial/keyspan_usa28_fw.h drivers/usb/serial/keyspan_usa28xa_fw.h drivers/usb/serial/keyspan_usa28xb_fw.h drivers/usb/serial/keyspan_usa28x_fw.h drivers/usb/serial/keyspan_usa49w_fw.h drivers/usb/serial/keyspan_usa49wlc_fw.h These are all under a unique and annoying license: redistributable as part of a Linux or other Open Source operating system kernel Additional regressions relative to sarge: * tg3 was readded with the upstream firmware at some point after the release of sarge, despite the existing firmware loading patches, and is already in the 2.6.17 packages * The bnx2 driver was introduced upstream with sourceless, but distributable, firmware. * e100 and starfire acquired sourceless, undistributable firmware upstream between the sarge release and now (God only knows why) * New drivers were introduced upstream between the sarge release and now with the following sourceless, undistributable firmware: - drivers/net/cassini.h - drivers/scsi/ql1040_fw.h You might want to have a closer look at some of those, I know the qla1040/qla1280 is already supported in 2.4 and always had firmware. (It also needs to download firmware for most devices.) Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hopefully straight forward patch by a newbie. Any comments?
[EMAIL PROTECTED] wrote: I am clueless with kernel programming. Still, I have came up with the following - hopefully straight forward - patch. Any comments? The patch looks good to me, please send it to the upstream driver maintainer. I figure you want to have a look a http://www.kernelnewbies.org/ , it is a very good starting point for working on the Linux kernel. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366730: qla1280 bugfix in limbo?
Bailey, Scott wrote: Just tuning in briefly to report: 1. I have been running my 3-processor Alphaserver 4100 with Ian's patch http://bugzilla.kernel.org/show_bug.cgi?id=6275 for a little over a month now, first with 2.6.16 and now with 2.6.17, and it continues to work like a champ. I very much would like to see this fix incorporated into the Debian kernel or preferably upstream, since my DLT drive is pretty much useless without it. 2. Unfortunately, I see no sign that anybody has looked at the kernel bugzilla report above. Is there anything I can do to help move things along? Send the patch with description and Signed-Off-By: line to [EMAIL PROTECTED] Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6: includes nondistributable and non-free binary firmware
[EMAIL PROTECTED] wrote: On Thu, Aug 17, 2006 at 10:06:44PM +0200, maximilian attems wrote: enough time is lost with any of those dfsg firmware wankers, that do _zero_ work upstream or on the licensing front. I repeat my offer to patch any (well, almost any) of these drivers to use request_firmware(). I need a volunteer who has the affected hardware and is willing to test my changes. You may want to start with tg3, that's the place where the last attempt failed. The hardware should be prevalent enough to find testers. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Nathanael Nerode wrote: [snip] http://wiki.debian.org/KernelFirmwareLicensing is grossly out-of-date, but I will integrate the relevant information from that in the process. KernelFirmwareLicensing is supposed to track information about mis-licensed firmware. IIRC you mentioned to have found at least one such driver in the Debian kernel, if that's correct, please update the wiki with that information. Please don't use KernelFirmwareLicensing for correctly licensed firmware. Alternative option: the Wiki page could be revived and used to coordinate the process. Unfortunately it's quite out-of-date, and it's unwieldly. You can split a page in several ones, probably per driver directory. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther wrote: On Mon, Aug 07, 2006 at 04:53:51PM +0200, Marco d'Itri wrote: On Aug 07, Goswin von Brederlow [EMAIL PROTECTED] wrote: No, because those are not linked together with the GPLed code, but are a mere aggregation of works inside the same media, i.e. the binary file. Those non-free firmware will never run inside the same memory space as the kernel, and are offloaded to a peripheral processor, and the communication media between the kernel and this peripheral processor running said firmware is clearly defined, there is no doubt that those non-free firmware do not break the kernel GPL. They are linked in, they have symbols, the code directly references their address. Can you name one tool that will easily remove such No. They are a char array, it's data copied where the hardware wants it. It's not code called by other functions. Yeah, exact, its mips or arm machine code, uploaded to the embedded core in the chip used for the peripheral in question. Often it isn't, unless you want to call the content of a configuration register bank code. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing the next linux-2.6 2.6.17 upload: ABI bump?
Frederik Schueler wrote: Hello, we have several changes pending which require an ABI bump, or at least would cause the next upload to go through NEW: - xen images - merge of amd64 k8 and p4 flavours into one generic - smp-alternatives for amd64, dropping the UP flavours - change default compiler to gcc-4.1 for some architectures - Hopefully a SGI Origin kernel Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380531: linux-2.6: mips and mipsel personality(2) support is broken
tags +patch
thanks
This patch fixes sys_personality for the o32 emulation by
a) killing the sign extension bits
b) tighten the bitmask match for current-personality (like it is done
for x86_64)
Already submitted to [EMAIL PROTECTED]
Thiemo
Signed-off-by: Thiemo Seufer [EMAIL PROTECTED]
--- a/arch/mips/kernel/linux32.c
+++ b/arch/mips/kernel/linux32.c
@@ -1053,7 +1053,9 @@ asmlinkage long sys32_newuname(struct ne
asmlinkage int sys32_personality(unsigned long personality)
{
int ret;
- if (current-personality == PER_LINUX32 personality == PER_LINUX)
+ personality = 0x;
+ if (personality(current-personality) == PER_LINUX32
+ personality == PER_LINUX)
personality = PER_LINUX32;
ret = sys_personality(personality);
if (ret == PER_LINUX32)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Upcoming Release of Debian GNU/Linux 4.0
maximilian attems wrote: [snip] No, it is not. As you may have noticed, we had a release update a few days ago, telling people that we're currently planning to release with 2.6.17. Though we're aware that it might be needed to update the kernel in October, the current upstream release quality is not something we want to rely on. the last announcement by the release team was coordinated with d-kernel and said 2.6.17 or higher. also if you look at the mails of fjp and aba, they all state that the Sarge Debian kernel freeze was too long and if things get coordinated with d-i an newer kernel is fine. we are about to stabilize 2.6.17, although we won't backport 2.6.18 stuff, as from the timing 2.6.18 looks good. 2.6.18 has features for several archs ppc, amd64 (smp alternatives), sparc (sbus sysfs) plus big sata/acpi merge. AFAIU you on IRC we agreed to keep 2.6.17 with the necessary backports as a plan B release candidate. Did I misunderstand you, or did you change your mind? Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Upcoming Release of Debian GNU/Linux 4.0
Jason Self wrote: [snip] Please see http://lists.debian.org/debian-powerpc/2006/07/msg00188.html And, as Brian Durant pointed out, this isn't just about the iMac G5 but also the Power Mac G5 (PowerMac 9.1) as well. In fact, Debian chokes on most of Apple's newer PowerPC machines. I and many others had been looking to Etch as a solution, but it won't provide one with 2.6.17 and I'm not looking forward to the potential of waiting through the lifetime of another stable release before gaining support. It's important, IMHO, that 2.6.17 _not_ be selected as the default kernel but rather 2.6.18 (or later) for the reasons discussed on debian-powerpc... even if that means delaying the release of Etch. Backporting the necessary changes is certainly an option. I would think this is up to the powerpc Porters to handle. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366730: Issue with qla1280.c (Debian bug #366730)
Bailey, Scott wrote: Funny this should come up now, just after my last note. I found a patch that looks better than mine in the report filed at http://bugzilla.kernel.org/show_bug.cgi?id=6275 by Ian Dall. Alas, it was posted in March and hasn't seen any activity (including a response) since then. Does this patch work for you? Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scheduling 2.6.17-1
Jurij Smakov wrote: [snip] There are a couple of patches for 2.6.16 which I would love to see included. There is a D-cache memory corruption fix included in 2.6.17 (attached as sparc64-dcache.patch), which did not appear in a 2.6.16 point release as I hoped. As it also affect the mips arch, perhaps mips maintainer should also have a look at it. The mips kernel seems not to trigger the failure seen on sparc, but the current handling is arguably incorrect for mips as well. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scheduling 2.6.17-1
Jurij Smakov wrote: On Tue, 20 Jun 2006, Thiemo Seufer wrote: Jurij Smakov wrote: [snip] There are a couple of patches for 2.6.16 which I would love to see included. There is a D-cache memory corruption fix included in 2.6.17 (attached as sparc64-dcache.patch), which did not appear in a 2.6.16 point release as I hoped. As it also affect the mips arch, perhaps mips maintainer should also have a look at it. The mips kernel seems not to trigger the failure seen on sparc, but the current handling is arguably incorrect for mips as well. Thanks for looking at it, Thiemo. Since your message does not make it clear whether you want it or not :-), It should be ok, and is in 2.6.17 for mips, but I haven't tested it yet on the potentially affected system. :-) Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I was banned from #debian-kernel ? ...
Sven Luther wrote: Hi all, I would like to know why i was banned from #debian-kernel and by whom, By waldi, because your client disconnected/connected continuously for several hours. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
Sven Luther wrote: On Wed, May 17, 2006 at 11:57:51AM +0200, Martin Michlmayr wrote: * dann frazier [EMAIL PROTECTED] [2006-05-16 17:04]: I believe there's a rough consensus to not ship 2.4 in etch. Anyone object to a filing of bugs to remove these packages from etch? For mips/mipsel, there's at least one sub-arch that is not in 2.6 yet. It's getting close though, but in the meantime I'd like to keep 2.4. For arm, I've recently removed the last bits of 2.4 from d-i and I was going to request the removal after the next d-i beta. In general, imho 2.4 should be removed from d-i first for each arch, and then after the next beta the 2.4 kernel images can be removed. We can start with the removal of 2.4 from those architectures which no longer use 2.4 at all (e.g. powerpc). Notice that we are not asking removal from d-i, but from the archive completely. It will AFAICS break all remaining d-i with 2.4 because those try to install a 2.4 kernel from testing by default. Frans, Joey, what is your opinion about this? Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
Frans Pop wrote: [snip] IMO the question whether 2.4 should be removed now and if so for which architectures is something to be decided between the kernel team and porters. If a porter needs more time to switch to 2.6 for the installer, he should probably come up with a migration plan and timeline. Purely from a d-i release management point of view, it would be nice if the removal of 2.4 could be delayed until just after the next beta release. The release date for that depends on the progress of AMD64 archive migration (it is not yet installable from testing). Switching d-i reqires stable kernels for all subarchitectures, those are now mostly done for mips/mipsel. I hope we complete the move to 2.6 in 3-6 weeks. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman-reiser4
Domenico Andreoli wrote: hi Jack, On Mon, May 01, 2006 at 11:58:04PM -0700, [EMAIL PROTECTED] wrote: I'm interested in installing Debian on a reiser4 root partition Are you aware of any work on a partman-reiser4 udeb? no, sorry. debian linux kernel guys vetoed reiser4 in debian kernel long time ago. i don't even remember when it was, but Martin Michlmayr was already mentioning this on January 2005 [0]. probably this is the right time to ask them for an update on this story. to what is my current view of the reiser4 merge in the vanilla, i don't think it is around the corner. General Debian Kernel Team policy is to not include feature patches, unless they are already in the upstream kernel. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge upgrade - linux, grub conflict
Martin Schulze wrote: Bastian Blank wrote: On Tue, Apr 18, 2006 at 05:04:53PM +0200, maximilian attems wrote: waldi why not add your patch to update-grub to the next stable release? Please keep in mind that you can't rely on a current sarge installation when it is upgraded to etch, in other words, you can't depend on people keeping their sarge r0 up-to-date with newer revisions or security updates. Especially for offline installations that are only maintained via ready CD/DVD images this may be the case. But it is relatively simple to collect the necessary packages from rlatest into an upgrade directory. That's not completely hassle-free, but it's surely better than special upgrade-only packages. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#358625: debian-kernel-devel or debian-devel-kernel?
Sven Luther wrote: On Mon, Apr 17, 2006 at 11:30:46AM -0500, Cord Beermann wrote: Hallo! Du (Thiemo Seufer) hast geschrieben: what about that? debian-devel-kernel@ I would personally prefer debian-kernel-devel, but in the end of the day it is not that important. If you have any reasons to prefer debian-devel-kernel over debian-kernel-devel, go ahead with it. We are drowning in bug traffic on debian-kernel, so i'm pretty sure that the new list, whatever the name is, will be welcome :-). I would also prefer debian-kernel-devel, just because it sorts the mbox names nicely together. :-) :-) debian-kernel-maint? debian-kernel-bugs ? If this is to hold the bug reports, it is more logical. The debian-kernel is by definition a devel list, so having d-k-fdevel in addition will probabluy be confusing. The point is to *keep* d-k the bug report list instead of trying to re-route the bug reports for all kernels released ever. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-kernel-devel or debian-devel-kernel?
Jurij Smakov wrote: Hi, Cord Beerman wrote: what about that? debian-devel-kernel@ Cord I would personally prefer debian-kernel-devel, but in the end of the day it is not that important. If you have any reasons to prefer debian-devel-kernel over debian-kernel-devel, go ahead with it. We are drowning in bug traffic on debian-kernel, so i'm pretty sure that the new list, whatever the name is, will be welcome :-). I would also prefer debian-kernel-devel, just because it sorts the mbox names nicely together. :-) Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: note on 2.4 is deprecated
Manoj Srivastava wrote: On 13 Apr 2006, Bastian Blank wrote: On Thu, Apr 13, 2006 at 10:28:56AM -0500, Manoj Srivastava wrote: That is stretching it. The third component of a version is hardly a major revision. Why? Component in a version are major.minor.sub. Now, given that Linux 1.0 was ages ago, one could conced that the versioning is Epoch.Major.Minor Upstream declared 2.6 a constant for the time being, so the third component remains the only one to make a version distinction. But claiming that 2.5.16 is majorly different from 2.5.15 when it comews to support is a facile argument that most people are not gonna buy. We already saw that for 2.6.12 - .13. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351692: mips-tools doesn't build on powerpc and hppa
On Mon, Feb 06, 2006 at 10:18:41PM +0100, Aurelien Jarno wrote: Martin Michlmayr a écrit : Package: mips-tools Version: 2.4.27-11.040815-2 Severity: serious mips-tools doesn't build on powerpc and hppa; probably a bug in kernel-package or something -- needs more investigation. Yes, it is a bug in kernel-package, architecture.mk is not included. It is included in local-vars.mk, but it looks like this file is not included anymore. architecture.mk convert the architecture name in case the name in Debian and the name in the kernel tree is different, which is the case for powerpc (ppc), and hppa (parisc). JFTR, it is also the case for mipsel (mips). Thiemo
Re: Please Build 2.4.27-12 for Sid
Horms wrote: 2.4.27-12 has been released into sid, this is a call to rebuild for all the different architectures. So far it is only available for i386 (which I built). I'll get powerpc rolling, I had mistakenly thought it was removed from Sid. Perhaps it should be, we can address that another day. I'm happy to do some more builds, but doing all of them is a little daunting. Unfortunately I don't have time for mips/mipsel kernels the next days (and not even a way to test them). Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [D-I] Supporting 2.6.14 kernels in base-installer
Sven Luther wrote: [snip] The upside is that the initramfs created should be more or less identical for every system and is resilient against people moving the drive from one machine to the other, doing perfect copies (using ghost, dd, or whatnot), or using an already generated initramfs to recover broken systems on other machines. I'd argue for keeping that mode as default if possible because there isn't any benefit to the smaller initramfs in 95% of cases, and it increases the risk of a non-booting system. I wonder about one thing though, since this is basically a ramdisk, once the boot is over, what happens to the memory used to hold it ? It's freed on umount, AFAIK. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel-package uploaded to experimental, please use.
Horms wrote: On Thu, Oct 20, 2005 at 07:38:36AM +0200, Sven Luther wrote: On Thu, Oct 20, 2005 at 10:35:09AM +0900, Horms wrote: On Wed, Oct 19, 2005 at 01:04:01PM +0200, Sven Luther wrote: Hello, [snip] I'm pretty sure 2.4 currently FTBFS in sid. Looks like a tool chain change. I think this occurs on both i386 and powerpc. I haven't tried others, nor had time to nvestigate. It should not, we use gcc-3.3 there. Will test. It does seem to be using gcc-3.3, and it does seem to be breaking. FWIW, I didn't see breakage for 2.4 mips/mipsel, but OTOH that's still built with the previous binutils version. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333220: doesn't install: Internal Error: Could not find image (/boot/vmlinuz-2.4.27-xxs1500)
reassign 333220 kernel-package 9.008
severity 333220 important
tags 333220 patch
thanks
Martin Michlmayr wrote:
Package: kernel-image-2.4.27-xxs1500
Version: 2.4.27-11.040815-2
Severity: grave
kernel-image-2.4.27-xxs1500 doesn't install. It seems kernel-package
is confused as to the name of the kernel.
Setting up kernel-image-2.4.27-xxs1500 (2.4.27-11.040815-2) ...
Internal Error: Could not find image (/boot/vmlinuz-2.4.27-xxs1500)
dpkg: error processing kernel-image-2.4.27-xxs1500 (--install):
subprocess post-installation script returned error exit status 2
vs
-rw-r--r-- 1 root root 6963004 2005-10-07 23:53 vmlinux-2.4.27-xxs1500
This seems to be some deficiency in kernel-package.
/usr/share/kernel-package/rules defines for xxs1500
kimage := vmlinux.srec
...
kimagedest = $(INT_IMAGE_DESTDIR)/vmlinux-$(version)
and the same kimage value is put in the package postinst. But later
in the postinst
# Paranoid check to make sure that the correct value is put in there
if(! $kimage) { $kimage = vmlinuz; } # Hmm. empty
elsif ($kimage =~ m/^b?zImage$/o) { $kimage = vmlinuz; } # these produce
vmlinuz
elsif ($kimage =~ m/^[iI]mage$/o) { my $nop = $kimage; }
elsif ($kimage =~ m/^vmlinux$/o) { my $nop = $kimage; }
else { $kimage = vmlinuz; } # Default
the default of vmlinuz is chosen, which leads to the vmlinux/vmlinuz
mismatch noted above.
Thiemo
--- image.postinst.old 2005-10-11 03:04:09.0 +0200
+++ image.postinst 2005-10-11 03:07:05.0 +0200
@@ -233,6 +233,7 @@ if(! $kimage) { $kim
elsif ($kimage =~ m/^b?zImage$/o) { $kimage = vmlinuz; } # these produce
vmlinuz
elsif ($kimage =~ m/^[iI]mage$/o) { my $nop = $kimage; }
elsif ($kimage =~ m/^vmlinux$/o) { my $nop = $kimage; }
+elsif ($kimage =~ m/^vmlinux.srec$/o) { kimage = vmlinux; }
else { $kimage = vmlinuz; } # Default
$ENV{KERNEL_ARCH}=$kernel_arch if $kernel_arch;
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6_2.6.13-1_i386.changes ACCEPTED
Sven Luther wrote: On Fri, Oct 07, 2005 at 03:46:01PM -0700, Debian Installer wrote: Accepted: kernel-image-2.6-386_2.6.13-1_i386.deb to pool/main/l/linux-2.6/kernel-image-2.6-386_2.6.13-1_i386.deb kernel-image-2.6-686-smp_2.6.13-1_i386.deb to pool/main/l/linux-2.6/kernel-image-2.6-686-smp_2.6.13-1_i386.deb Nice, but it seems that experimental is not autobuilt, or at least the log don't show up in the usual place. I know there is some experimental autobuilder setup, but i don't know who handles it, and i also don't know if the logs are available at all. Any idea on this ? http://experimental.debian.net/ Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#330191: klibc: ftbfs [sparc] redefinition of 'struct __new_sigaction'
maximilian attems wrote: severity 330191 serious thanks On Mon, 26 Sep 2005, Blars Blarson wrote: klibc failed to build on a sparc buildd, duplicated on my sparc pbuilder. It also failed on some other buildds. thanks for your report and duplicating, will look into it. the mips and mipsel failures are expected as they are it's the only arch. which doesn't build out of the common kernel package. don't know why, all the infrastructure seems there? had hoped that oldenburg would sort that out. adding cc to debian-kernel to investigate the mips/mipsel failure: E: Couldn't find package linux-headers-2.6.12-1 The mips/mipsel packages are only in experimental ATM. I hope to prepare an unstable upload the next days. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12-7 upload ? How far away is 2.6.13-1 ?
Horms wrote: On Wed, Sep 21, 2005 at 07:55:23AM +0200, Sven Luther wrote: On Wed, Sep 21, 2005 at 02:50:27PM +0900, Horms wrote: I have made an i386 build of what is currently in SVN, its version is 2.6.12-6.hls.2005092100, but the version is the only thing I changed, just to distinguish it from the official upload. http://packages.vergenet.net/testing/linux-2.6/ So, you think it is ready for upload ? What about the patch you removed, can we release without it in a sane way ? Removing the patch that I removed should be quite ok, it seems to fix a problem that was introduced since 2.6.12. As for if it is ready for upload? I am not sure. You are the one propmoting uploading 2.6.12-7. I certainly think that the addition of the 2.6.13.1 and 2.6.13.2 patches that I added makes it more ready for upload. So if you though it was ready yesterday, then yes, its ready today. I'm doing a 2.6.12-7 build now. I'm happy to upload this if others are happy. But I am still not entierly sure why there is a push to get 2.6.12-7 ready, and thus I am not entirely sure what it should include. FWIW, I would like to see 2.6.12-7 as basis for the mips kernels in the next days. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12-7 upload ? How far away is 2.6.13-1 ?
Sven Luther wrote: On Wed, Sep 21, 2005 at 10:37:02AM +0200, Thiemo Seufer wrote: Horms wrote: On Wed, Sep 21, 2005 at 07:55:23AM +0200, Sven Luther wrote: On Wed, Sep 21, 2005 at 02:50:27PM +0900, Horms wrote: I have made an i386 build of what is currently in SVN, its version is 2.6.12-6.hls.2005092100, but the version is the only thing I changed, just to distinguish it from the official upload. http://packages.vergenet.net/testing/linux-2.6/ So, you think it is ready for upload ? What about the patch you removed, can we release without it in a sane way ? Removing the patch that I removed should be quite ok, it seems to fix a problem that was introduced since 2.6.12. As for if it is ready for upload? I am not sure. You are the one propmoting uploading 2.6.12-7. I certainly think that the addition of the 2.6.13.1 and 2.6.13.2 patches that I added makes it more ready for upload. So if you though it was ready yesterday, then yes, its ready today. I'm doing a 2.6.12-7 build now. I'm happy to upload this if others are happy. But I am still not entierly sure why there is a push to get 2.6.12-7 ready, and thus I am not entirely sure what it should include. FWIW, I would like to see 2.6.12-7 as basis for the mips kernels in the next days. We can do a 2.6.12-8 for it then, since i want to include the powerpc-small miboot kernel too. What is your take on that ? Can you come discuss your plans with us on #debian-kernel (oftc). You probably misunderstood, I just want a newer kernel-source package than the current one as a build dependency. We can discuss this and other things tomorrow in RL. :-) Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12-7 upload ? How far away is 2.6.13-1 ?
Horms wrote: [snip] As for if it is ready for upload? I am not sure. You are the one propmoting uploading 2.6.12-7. I certainly think that the addition of the 2.6.13.1 and 2.6.13.2 patches that I added makes it more ready for upload. So if you though it was ready yesterday, then yes, its ready today. I'm doing a 2.6.12-7 build now. I'm happy to upload this if others are happy. But I am still not entierly sure why there is a push to get 2.6.12-7 ready, and thus I am not entirely sure what it should include. FWIW, I would like to see 2.6.12-7 as basis for the mips kernels in the next days. I spoke a bit more to Sven about this on IRC, and it looks like we will go ahead with what we have. I have the binaries built (i386) and will upload once I get a final go-ahead from Sven. I even tested that they boot and am running one of them now :) Sorry, I am a bit confused, does this mean you want to see a 2.6.12-7 upload ASAP, or you would like the upload to wait a few days? I hope to fix the remaining issues which should not happen in an kernel from unstable in the next days here in Oldenburg. So I don't need the newer kernel-source immediately but in the next 3-4 days, earlier is better but don't feel pressed to rush something. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing powerpc backport 2.6.12-6 kernel package for sarge
Horms wrote: On Wed, Sep 14, 2005 at 07:35:48AM +0200, Sven Luther wrote: On Wed, Sep 14, 2005 at 11:18:14AM +0900, Horms wrote: On Tue, Sep 13, 2005 at 11:34:13AM +0200, Sven Luther wrote: On Tue, Sep 13, 2005 at 05:51:18PM +0900, Horms wrote: http://packages.vergenet.net/testing/linux-2.6/ I have done a second build, with the following changes, as 2.6.12-5.99.sarge2 Only the first change is relevant, URL as immediately above :) * Change kernel-source build dependancy to kernel-package (= 8.135) [!powerpc] | kernel-package (= 8.135.sarge1) [powerpc] so that this package can be build on an unmodified sarge install on non-powerpc * Add myself and Sven Luther as uploaders Maybe we should move that stuff to the SVN, under dists/sarge/backports or something such ? Yes, i think that would be an excellent idea. perhaps just put it in dists/sarge, or if you want to make a distinction, dists/sarge-backports Debian-sarge is fine, what about uploading those to sarge-proposed-updates ? Not sure if that one is auto-built, or even easily accessible from the user stand-point. Maybe this is one of the things we need to discuss in oldenbourg with Joey ? Good idea, though at this stage it seems unlikely that I will make it there. Bad idea, actually, because sarge-p-u is supposed to hold potential sarge updates and a backport doesn't meet the criteria for that. (Herbert did the same in woody-p-u with 2.4 backports, they had to be removed before sarge at the price of some user confusion who had t-p-u in their sources.list.) Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing powerpc backport 2.6.12-6 kernel package for sarge
Sven Luther wrote: [snip] (Herbert did the same in woody-p-u with 2.4 backports, they had to be removed before sarge at the price of some user confusion who had t-p-u in their sources.list.) Well. The packages have smaller version than the sid ones, so there should be no such confusion. The problem is a different one. Such a package will have a higher version number than the next stable security update. It will also block legitimate sarge updates because of its version unless it is removed, which is an unattractive option because the users who need exactly this version can't reinstall it any more, and the package still blocks security updates on every machine it was installed. BTW, how are the mips/mipsel integration going ? Experimental has now a linux-patch-2.6-mips package. Any chance to get those in for 2.6.12-7 ? Do you need any help or something ? Will you be in Oldenbourg this year ? Yes, I'll see you there. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328324: please build powerpc64 kernel with tg3 support
A. Maitland Bottoms wrote: [snip] I think I'll just try building out of the linux-2.6 Debian source package. Where is the svn for Debian's linux-2.6 kernel tree? http://svn.debian.org/ , Project kernel. I'd like to run svn blame to see where the changelog line came from: - readdition of tg3 driver, as firmware license has been fixed. Maybe that wasn't quite right. Tg3 is built for most other architectures. I think that your interpretation of the fix in firmware license is that it improves the situation from undistributable to non-free distributable. So, perhaps this bug needs to be reassigned to linux-26, and retitled to non-free content in kernel source packages in main should be removed (again). Or probably re-enable tg3 for powerpc and arm. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299204: Fixed except for sarge d-i
tags +sarge thanks This bug only remains present in kernel revision -8 as used by sarge's debian-installer. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324202: include ReiserFS ACL support in 2.6.12 kernel
David Madore wrote: On Tue, Aug 30, 2005 at 01:20:37PM +0900, Horms wrote: Appart from my general feeling that no one should use Reiser FS, Why is that? I mean, certainly every filesystem has its problems, but I don't think there's a consensus that ReiserFS is much worse than the others? I personally find it useful because it doesn't have any limitation on the number of inodes. Exactly those dynamic on-disk structures make it hard to do useful recovery in case of unexpected (e.g. hardware-) errors. More conservatively designed filesystems have better chances to keep the damage to a minimum. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: status of first round of sarge kernel updates
Aurelien Jarno wrote: Hi ! dann frazier a écrit : On Tue, 2005-08-23 at 15:22 -0600, dann frazier wrote: We're getting closer. Please check this for accuracy: http://wiki.debian.net/?DebianKernelSargeUpdateStatus I can try to do hppa this afternoon; any word on m68k, mips s390? What has to be done for mips? My mips machine is a bit slow, but I can build a new kernel package for stable-security, and then test it. I have a sarge chroot on it. Big endian kernels (and the source package) are available from http://people.debian.org/~ths/mips-kernels/sarge-security/ I appreciate additional testing of them. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: status of first round of sarge kernel updates
dann frazier wrote: We're getting closer. Please check this for accuracy: http://wiki.debian.net/?DebianKernelSargeUpdateStatus I can try to do hppa this afternoon; any word on m68k, mips s390? Big endian mips at http://people.debian.org/~ths/mips-kernels/sarge-security/ Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving forward with the 2.4.27 and 2.6.8 kernels
Horms wrote: On Tue, Aug 16, 2005 at 12:02:40PM +0200, Christian T. Steigies wrote: On Tue, Aug 16, 2005 at 03:31:22PM +0900, Horms wrote: On the topic of Sid, I think we need to keep 2.4.27 there for now. I've been told that the s390 installer works it, and its needed for some m68k flavours (mac users who want a working keyboard IRRC). Mac users who want a working keyboard have to use 2.2.25, there is no working 2.4.x kernel for Mac, where as 2.6.12 boots, works, but does not allow you to use keyboard or mouse. 2.4.27 is needed on m68k for all but Amiga it seems, since Amiga is the only flavour that works with 2.6, afaik. I have reports, that MVME167 and Atari do not work, I would not wonder if the other VME flavours have difficulties, too. No reports so far for Q40, Sun3, or HP, but if the other flavours were fixed, I wouldn't mind ignoring the unknown flavours. On Tue, Aug 16, 2005 at 12:36:31PM +0200, Norbert Tretkowski wrote: * Horms wrote: I've been told that the s390 installer works it, and its needed for some m68k flavours (mac users who want a working keyboard IRRC). 2.4.27 is also still needed for the alpha installer. Thanks for this info. So far we have: 2.2.25 needed: m68k not in archive: other 2.4.27 needed: alpha, m68k (2.6 only works on amiga), s390 mips, mipsel as well. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323570: kernel-source-2.4.27: Build fails with default gcc 4.0
George B. wrote: Package: kernel-source-2.4.27 Version: 2.4.27-10 Severity: important *** Please type your report below this line *** Hello, Submitting as promised in #31763. The package depends on non-specific gcc. This is now gcc 4.0 by default. As discussed in #317637, build will fail unless gcc 3.2 is used. The 2.4.27-11 uploaded today depends on gcc-3.3 and should solve that problem. (It is not yet installed in the archive but available from http://packages.vergenet.net/pending/ ) Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#321964: linux-2.6: package that depends on all -headers for $arch
Bastian Blank wrote: On Mon, Aug 08, 2005 at 12:50:47PM -0400, Andres Salomon wrote: Calling it linux-headers-2.6.12-1-i386 doesn't work too well for all archs, since we end up w/ linux-headers-2.6.12-1-powerpc, which conflicts w/ the name of a flavour. Suggestions? linux-headers-2.6.12-1-all (arch: any) Will need to exclude Arch: mips mipsel. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 in volatile?
Sven Luther wrote: On Wed, Aug 10, 2005 at 10:40:12AM +0900, Horms wrote: On Tue, Aug 09, 2005 at 11:40:16PM +0200, Sven Luther wrote: On Tue, Aug 09, 2005 at 10:43:22AM -0400, Andres Salomon wrote: Hi, So, was there any decision whether to provide 2.6.8+security in volatile, or just backport linux-2.6 (2.6.12)? I need to do a 2.6.12 backport, so if people are wanting 2.6.12 for volatile, I'll do that; however, if people want 2.6.8+security in volatile, I'll just put 2.6.12 in p.d.o/~dilinger, and make it known via apt-get.org. I've had reports of breakage with 2.6.12 and sarge which I believe are related to udev, so we might need to keep that updated as well. There is also some breakage with powerpc and older versions of kernel-package; we'd need to determine what's necessary for that (my tests on i386 w/ 2.6.12-1 went just fine w/ the kernel-package that's in sarge). We need to backport kernel-package too, or i can submit a patch against the kernel-patch in sarge ? If we put 2.6.12 in volatile (sarge) then it should use the unified packaging scheme, so we won't have to bother with per-arch kernel-image/kernel-patch packages. Wrong, linux-2.6 needs at least version 9.005 of kernel-package. So either we backport it to sarge, or i provide a patch of the needed functionality for the version of kernel-package in sarge. The latter, according to volatile policy (... must be autobuildable from the same release...). Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6 - subarch and patches
Bastian Blank wrote: On Sat, Aug 06, 2005 at 07:43:06AM +0200, Thiemo Seufer wrote: apt-get install linux-headers-$(uname -r) Fun, yet another thing in the common package which doesn't work for mips (mipsel machines have mips as uname). uname -r != uname -m | $ uname -r | 2.6.10-1-s390x | $ uname -m | s390x Right, but it still fails: hattusa:~$ uname -r 2.4.27-sb1-swarm-bn is also the same for both endiannesses. Thiemo
Re: linux-2.6 - subarch and patches
Bastian Blank wrote: On Sat, Aug 06, 2005 at 09:32:33AM +0200, Thiemo Seufer wrote: Right, but it still fails: hattusa:~$ uname -r 2.4.27-sb1-swarm-bn is also the same for both endiannesses. And the headers package is available for both the debian mips and mipsel architecture. It needs different .configs since endianness is a config option on mips. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6 - subarch and patches
Jurij Smakov wrote: [snip] I don't have any objections to this naming scheme (generally, I don't care about naming so much :-). The only thing which in my opinion _must_ be guaranteed, is that running apt-get install linux-headers-$(uname -r) will install the full set of packages for the currently running kernel. Fun, yet another thing in the common package which doesn't work for mips (mipsel machines have mips as uname). Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 upload
Andres Salomon wrote: Alright folks, I think the packaging is ready to be beaten on by people. So, unless anyone has any concerns/problems/etc, I'm going to assume everything's a go for uploading 2.6.12. The current changes and state of the packaging: - source package is called linux-2.6 - binary image packages have been renamed from kernel-image-* to linux-image-*. binary header packages have been renamed from kernel-headers-* to linux-headers-*. kfreebsd/hurd folks, if you have any comments/concerns/requirements, please be sure to let us know. - debian/control is generated from debian/templates/control.*.in, and naming/descriptions should be consistent across the various archs. - config files are generated from the pieces in debian/arch, with management of configs made a lot easier via tools in trunk/scripts (initconfig and split-config). I will probably tweak settings for the global config a bit more; expect some FTBFS for architectures until we figure out which options are safe for everyone, and which options are suitable only for certain archs. - i'm leaning towards using gcc-3.3, as i'm afraid of gcc-4.0 miscompiling things. however, if any architectures require gcc-4.0, either let me know, or update svn directly. - debian/README* and trunks/docs/ has information that kernel team members will find useful to understand the new packaging. - there are 3 patches that were in 2.6.11 that have been dropped due to lack of interest; sparc, alpha, and powerpc folks should determine their value, at some point. FWIW, I gave up on the common kernel package for mips/mipsel for now, and will build mips kernels via a linux-patch package which build-depends on the source .deb. The reasons which prompted me to do so are listed below, vaguely in order of importance. Thiemo Issues of the common kernel package: General problems: - The 2.6 (instead of 2.6.12 etc.) versioning means previous versions are thrown out of the archive, anything which isn't ready until then will lose support. It is IMHO not realistic to expect the rest of the world to wait for some obscure subarchitecture. - Coupling the smallest fix for a subarchitecture to a full upload of the whole arch any package puts pressure on the autobuilder network without much gain, and causes many users to download new kernels identical to the old ones because of the version bump. - E.g. disable CONFIG_PREEMPT for ia64 and let everyone upgrade their kernel. Implementation problems: - A generic header package is used, plus architecture-specific header packages which add some bits like configuration defines and process structure offsets. Architecture-specific header patches aren't taken into account, but are needed for patches outside include/asm-$arch. - Flavour names are assumed to be unique, this doesn't work well for bi-endian machines (e.g. sb1-swarm-bn for mips/mipsel) and 32/64 bit kernels. - Architecture-specific patches are restricted to a single patch per arch/subarch, with an $arch.* naming. This means to copy an identical patch with different name to support mips/mipsel, it also means all patches which may break some other architecture have to go into a single file, which is ridiculous form a maintenance POV. - Architecture-specific patches have no series mechanism, IOW they aren't really updateable. Even if they had, it is not feasible to keep multiple 2MB mips patches around for the whole duration of the 2.6 kernel series. - The current patch system breaks easily down. If one of the patches has a conflict, it is neither possible to unpatch the already applied patches nor does a patch replay help (because the first already applied patch conflicts now). So it's either rm -rf or to work around the patch system. - Only -p1 patches are accepted - no CVS diff patches, originally psted patches can't be used easily. - If $EDITOR leaves a ~ backup file in the series directory, the patch system doesn't check if the series name is valid and tries to apply the copy as well. - Same goes for the control file generation, some moved away directory gets searched for control.in files as well, no check for valid arch names or the resulting duplicate package definitions. - The resulting control file suggests every available bootloader for each image, with an [ $arch ] specifier. This is generally ugly and doesn't help for e.g. mipsel subarches with per-subarch bootloaders (colo, delo, sibyl). - The shell-snippets-disguised-as-makerules generally fails to catch errors. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 upload
Andres Salomon wrote: [snip] It is IMHO not realistic to expect the rest of the world to wait for some obscure subarchitecture. Who said we're going to wait for some obscure subarchitecture? We're going to keep working on kernels until we freeze for etch, at which point the subarchitectures have a limit amount of time to catch up. The problem is the ongoing development in unstable. It is e.g. not possible to build debian-installer for that subarch and upload it if its kernel isn't already/still in unstable. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 upload
Andres Salomon wrote: [snip] - Dependencies with arch spec for one-arch packages. Right, the control file is full of the packages with control fields like this: Architecture: powerpc Depends: initrd-tools (= 0.1.78), coreutils | fileutils (= 4.0), module-init-tools (= 0.9.13), e2fsprogs (= 1.35-7) [amd64], palo [hppa], mkvmlinuz [powerpc] The non-powerpc dependencies will probably not break anything, but introduce a lot of additional clutter. I understand that it's easier that way, but having only relevant dependencies listed would be cleaner. And, to improve readability, it would be nice to have all the control file generation logic moved to a separate script, which may be called from the the rules file. I disagree. I did it this way because I prefer to see exactly what architectures are using for their boot loaders, etc. That's just my preference. The bootloader dependencies need to be per flavour. It makes no sense to depend on N bootloaders for an architecture where N-1 are unusable for the specific flavour's kernel image. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel-image-2.4.27-r5k-cobalt - possible issues
Ricky Chan wrote: I built debian 3.1 on mips raq2 cobalt with the well known buggy network card yesterday using the new installer rather then then old telnet method. However I got some unexpected results. The pings times to this box was less than 0.5ms which was fine, however as soon as you start downloading packages, the ping time starting incrementing by 1000ms for each ping. I have built around 30/40 of these boxes but used the older 2.4.25 kernel or put my own custom built kernel (2.6.9) http://www.ricky-chan.co.uk/raq2-mips/ on it. By copying slowing my 2.6.9 kernel over (failed a lot of times!), I was able to install and reboot the cobalt. The network issues then no longer existed. I was wondering if the maintainer of the kernel may have forgot to apply the infamous timing patch on the galileo-tulip on the kernel? The maintainer has no access to a cobalt machine for kernel development and has to rely on efforts by others. Could you build the source package at http://people.debian.org/~ths/mips-kernels/cobalt-test/ (it builds only the cobalt kernel) via dpkg-source -x *.dsc apt-get build-dep kernel-patch-2.4.27-mips cd kernel-patch-2.4.27-mips-2.4.27 dpkg-buildpackage -us -uc -rfakeroot -B and tell me if the resulting 2.4.27 kernel works for you? Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming linux-kernel source package
Andres Salomon wrote: Hi, I'm going to suggest renaming our 2.6.12 source package from linux-kernel-2.6.12 to linux-kernel-2.6. Thoughts? Dann Frazier and I have discussed this on IRC a little bit, and come up w/ the following points.. * Source: linux-kernel-2.6, Version: 2.6.12-1 * As long as each arch is in synch, there are no GPL issues with older binary packages being in the archive w/out the source. * Nicer for bugs; http://packages.qa.debian.org/l/linux-kernel-2.6.html gets us all bugs for 2.6.12+ kernels, versus having to look at linux-kernel-2.6.12.html, linux-kernel-2.6.13.html, etc. * Older kernels get removed; no need to ask for manual removal of linux-kernel-2.6.12 after 2.6.13 becomes available for all archs. However, we lose the ability to have multiple 2.6's in a release, which sounds like a win to me; we shouldn't be doing multiple 2.6 releases anymore anyways, the security team has made it clear they don't want to support multiple kernels, and it would be extra pressure for all archs to keep up. This makes it unlikely to ever get working mips/mipsel kernels in the single source package. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming linux-kernel source package
Andres Salomon wrote: On Mon, 11 Jul 2005 00:11:49 +0200, Thiemo Seufer wrote: Andres Salomon wrote: Hi, I'm going to suggest renaming our 2.6.12 source package from linux-kernel-2.6.12 to linux-kernel-2.6. Thoughts? Dann Frazier and I have discussed this on IRC a little bit, and come up w/ the following points.. * Source: linux-kernel-2.6, Version: 2.6.12-1 * As long as each arch is in synch, there are no GPL issues with older binary packages being in the archive w/out the source. * Nicer for bugs; http://packages.qa.debian.org/l/linux-kernel-2.6.html gets us all bugs for 2.6.12+ kernels, versus having to look at linux-kernel-2.6.12.html, linux-kernel-2.6.13.html, etc. * Older kernels get removed; no need to ask for manual removal of linux-kernel-2.6.12 after 2.6.13 becomes available for all archs. However, we lose the ability to have multiple 2.6's in a release, which sounds like a win to me; we shouldn't be doing multiple 2.6 releases anymore anyways, the security team has made it clear they don't want to support multiple kernels, and it would be extra pressure for all archs to keep up. This makes it unlikely to ever get working mips/mipsel kernels in the single source package. Perhaps you could give a reason why this is the case? Because I'm currently at 2.5 of ~8 subarchitectures working for 2.6.12, and I hear already talk about 2.6.13. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming linux-kernel source package
Andres Salomon wrote: [snip] * Older kernels get removed; no need to ask for manual removal of linux-kernel-2.6.12 after 2.6.13 becomes available for all archs. However, we lose the ability to have multiple 2.6's in a release, which sounds like a win to me; we shouldn't be doing multiple 2.6 releases anymore anyways, the security team has made it clear they don't want to support multiple kernels, and it would be extra pressure for all archs to keep up. This makes it unlikely to ever get working mips/mipsel kernels in the single source package. Perhaps you could give a reason why this is the case? Because I'm currently at 2.5 of ~8 subarchitectures working for 2.6.12, and I hear already talk about 2.6.13. I wasn't aware that you worked on mips/mipsel stuff for older kernels in the archive anyways, except for the case when we decide to stabilize on a certain version for a release. In any case, now that experimental is autobuilt, we can upload a new kernel to it and stabilize architectures, while simultaneously updating the older version in sid Does this mean to maintain two separate tracks then? Moving the experimental package to unstable could never be done when it is constantly updated. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCC version change / C++ ABI change
Otavio Salvador wrote: Thiemo Seufer [EMAIL PROTECTED] writes: Junichi Uekawa wrote: Hi, This week, we will change the GCC default versions from 3.3 to 4.0 Would it break kernel 2.4 builds somehow ? I've not been quite following; but the thread almost a month ago seems to indicate thus: http://www.kerneltraffic.org/kernel-traffic/kt20050701_316.html#7 Quite likely, yes. 2.4 Kernels would need to Build-Dep on 3.4. But the current versions of 2.4 doesn't get fixed yet? Most kernel hackers don't care that much about 2.4 any more. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCC version change / C++ ABI change
Horms wrote: On Mon, Jul 04, 2005 at 11:12:21AM +0200, Thiemo Seufer wrote: Otavio Salvador wrote: Thiemo Seufer [EMAIL PROTECTED] writes: Junichi Uekawa wrote: Hi, This week, we will change the GCC default versions from 3.3 to 4.0 Would it break kernel 2.4 builds somehow ? I've not been quite following; but the thread almost a month ago seems to indicate thus: http://www.kerneltraffic.org/kernel-traffic/kt20050701_316.html#7 Quite likely, yes. 2.4 Kernels would need to Build-Dep on 3.4. But the current versions of 2.4 doesn't get fixed yet? Most kernel hackers don't care that much about 2.4 any more. I'd rephrase that as, we need to discuss if 2.4 should be included in etch. I don't think gcc-4.0 is a hard requirement for that. We still have even gcc-2.95 in the archive, and a gcc 3.3/3.4 version is likely to be around for etch. My understanding is that it is needed for some arches, and my personal feeling is that 2.4 is maintained upstream and in many cases is a valid choice over 2.6. I just wanted to hint that upstream is more interested in making 2.6 a more valid choice instead of sinking time in a compiler upgrade for 2.4 which provides little benefit for the kernel. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCC version change / C++ ABI change
Junichi Uekawa wrote: Hi, This week, we will change the GCC default versions from 3.3 to 4.0 Would it break kernel 2.4 builds somehow ? I've not been quite following; but the thread almost a month ago seems to indicate thus: http://www.kerneltraffic.org/kernel-traffic/kt20050701_316.html#7 Quite likely, yes. 2.4 Kernels would need to Build-Dep on 3.4. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Security Updates for Sarge
Horms wrote: [snip] For reference, these are the architectues that I believe the kernel team handles, and the version of the kernel source they are using in Sarge: Base kernel source version of package in Sarge 2.4.27: alpha kernel-tree-2.4.27-9 (seems to be out of date in SVN) hppa kernel-tree-2.4.27-8 i386 kernel-tree-2.4.27-8 ia64 kernel-tree-2.4.27-8 mips kernel-tree-2.4.27-8 (versioned dependancy needs to be changed to kernel-tree-2.4.27-8) mips/mipsel uses the kernel-source package as build dependency instead of kernel-tree. [snip] The changelogs that I would like you to look at are as follows. Almost all of the changes will be in kernel-source, and I believe that the log is accurate. There are also changelogs for each architecture, but these are generally just packaging and kernel-config changes: [snip] mips: version in Sarge: 2.4.27-8.040815-1 http://svn.debian.org/wsvn/kernel/trunk/kernel-2.4/mips/kernel-patch-2.4.27-mips-2.4.27/debian/changelog?op=filerev=0sc=0 mips/mipsel has four additional changes which should go in sarge: - Fix broken ptrace - Fix Cobalt PCI bridge initialisation - Work around crashes on Cobalt under I/O load - Fix crash on startup on serial-less Cobalts Thiemo signature.asc Description: Digital signature
Re: Kernel Security Updates for Sarge
Steve Langasek wrote: [snip] mips/mipsel has four additional changes which should go in sarge: - Fix broken ptrace - Fix Cobalt PCI bridge initialisation - Work around crashes on Cobalt under I/O load - Fix crash on startup on serial-less Cobalts All of which seem to be out of scope in a discussion about security uploads, don't they? It would make little sense to do separate uploads for them. Thiemo signature.asc Description: Digital signature
Re: Kernel Security Updates for Sarge
Horms wrote: On Thu, May 12, 2005 at 10:07:06AM +0200, Thiemo Seufer wrote: Horms wrote: [snip] For reference, these are the architectues that I believe the kernel team handles, and the version of the kernel source they are using in Sarge: Base kernel source version of package in Sarge 2.4.27: alpha kernel-tree-2.4.27-9 (seems to be out of date in SVN) hppa kernel-tree-2.4.27-8 i386 kernel-tree-2.4.27-8 ia64 kernel-tree-2.4.27-8 mips kernel-tree-2.4.27-8 (versioned dependancy needs to be changed to kernel-tree-2.4.27-8) mips/mipsel uses the kernel-source package as build dependency instead of kernel-tree. Ok, but does it patch to a known version before building. That is, if I have kernel-source-2.4.27 2.4.27-8 installed and build the mips kernel image packages, and then I have kernel-source-2.4.27 2.4.27-9 installed, will I get the same result? No, it will build against 2.4.27-9. If building against a known broken kernel source is preferred for some reason, the build dependency could be tightened to match only the 2.4.27-8 source. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Security Updates for Sarge
Steve Langasek wrote: On Thu, May 12, 2005 at 11:07:45AM +0200, Thiemo Seufer wrote: Steve Langasek wrote: [snip] mips/mipsel has four additional changes which should go in sarge: - Fix broken ptrace - Fix Cobalt PCI bridge initialisation - Work around crashes on Cobalt under I/O load - Fix crash on startup on serial-less Cobalts All of which seem to be out of scope in a discussion about security uploads, don't they? It would make little sense to do separate uploads for them. It is nevertheless necessary, according to the security team's historical policy on security uploads. You can upload whatever you want to testing-proposed-updates, *right now*, but it doesn't do our users any good until r1 unless we also get something uploaded to testing-security that will be accepted and actually made available for download. I try to avoid uploading kernels with known security bugs, and a fixed kernel source package isn't available yet. Thiemo signature.asc Description: Digital signature
Bug#283107: telnet-connections to some hosts fail
Jurij Smakov wrote: [snip] The thing is, that not all telnet-connections fail: - telnet to Linux-Host (try 'telnet mailgw1 25'): works - telnet to Solaris-Host (try 'telnet esslingen'): works - telnet to Ascend MAX4000 Access-Server (m-nas1): fails - telnet to Cisco 7200 VXR (try 'telnet ol-gw'): fails Right, I was able to figure out that these bad checksum messages are completely bogus (they are also produced by a tcpdump when I run it on my Ultra5 and telnet to it). So that's not really it :-(. At the moment I am out of ideas. I'll try to build a pristine kernel tomorrow and make a comparison between tcpdump output in these two cases. This suggests the checksum inline assembly in arch/sparc64/lib is somewhat broken, but it seem to be in line with upstream 2.4. It is much more complicated than the 2.6 code, though. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301799: kernel-tree-2.6.11: new upstream source available: 2.6.11.6
Henrique de Moraes Holschuh wrote: On Wed, 30 Mar 2005, Horms wrote: with 2.6.11.X, including the numbering (i.e. next upload should be kernel-source-2.6.11, package version 2.6.11.6-1). I agree it would be good to sync up the patches, but I don't think there is any need to include the .6 in the debian version as we never did this for 2.6.8. It is much more user-friendly, and it readly provides information on the most up-to-date tree it was synced with, in aptitude/dselect/synaptic... The kernel usually also includes backports from newer versions, the fourth level would thus lead to incorrect assumptions. The Debian kernel is not simply the upstream version in Debian packaging. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#241497: RFC and status report: Kernel upgrades for woody-sarge upgrades
Frank Lichtenheld wrote: Hi all. As many of you may know on some machines users will need to install a current kernel before they will be able to upgrade woody to sarge (or better: glibc of woody to glibc of sarge). I've tried to use the available information to provide the needed files for these kernel upgrades. To my knowledge the affected machines/architecures are currently hppa64, sparc sun4m (only some of them) and 80386. JFTR, all mips/mipsel subarchitectures are also affected. For those, however, the sarge kernel without userland backports is good enough, because modules aren't needed for basic system operation. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: a kernel plan for sarge and beyond ...
Andres Salomon wrote: [snip] Steve expressed concern about doing something like that (for obvious reasons); however, something to consider is using tcc for building modules. I have not tried it yet, but one of its touted features is its ability to compile a kernel in 10 seconds on a 2.4ghz p4. The i386 package appears to be about 100k. I'm not sure if it's been ported to !i386. More research into that would need to be done, if the d-i folks found that to be an acceptable solution. The last time I looked it was i386 only. And anyways, using a different compiler is hardly a guarantee for stability. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293481: kernel-image-2.6.8-2-686: Cannot open root device
Nigel Stephens wrote: Package: kernel-image-2.6.8-2-686 Version: 2.6.8-12 Severity: normal My current 2.6.6 kernel boots and runs OK on my Toshiba Tecra S1 laptop. But when I try to boot the 2.6.8 (or 2.6.10) kernel the bootstrap fails early on like this: RAMDISK: Loading 4540 blocks [1 disk] into ramdisk... done. VFS: Mounted root (cramfs filesystem) readonly. VFS: Cannot open root device hda5 or unknown-block(0,0) Please append a correct root= boot option Kernel panic: VFS: Unable to mount root fs on unknown-block(0,0) [snip] title Debian GNU/Linux, kernel 2.6.8-2-686 root(hd0,4) kernel /boot/vmlinuz-2.6.8-2-686 root=/dev/hda5 ro panic=60 initrd /boot/initrd.img-2.6.8-2-686 Looks like some driver went missing from this initrd. This would be a bug in initrd-tools (http://bugs.debian.org/initrd-tools). Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel 2.4.27-1 header files
Simon Dicker wrote: I am trying to replace a PC running the above kernel and I need the kernel header files. I can not find them for a i386 anywhere - I can only find 2.4.27-2. There is some custom hardware that has been tested with the above kernel and I do not want to have to repeat the tests with 2.4.27-2. 2.4.27-2 is 2.4.27-1 with a load of (mostly security crtical) fixes which changed the module ABI. You should consider to upgrade if any of those fixes are relevant for you. Has anyone got them or can I go ahead and use the 2.4.27-2 package to link my drivers in? Old packages are available from snapshot.debian.net. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291357: kernel-source-2.4.27: SIGHUP not being sent when controlling process exits
tags 291357 +sarge thanks Russell Stuart wrote: Package: kernel-source-2.4.27 Version: 2.4.27-6 Severity: important [snip] drivers/char/tty_io.c, line 768, contains this line: /* tty_deferred_ldisc_switch(N_TTY); Note: no trailing */. This is fixed in 2.4.27-7. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291217: NFS-ACL patches for kernel 2.6.9rc2
Paul Coray wrote: The latest patches for kernel 2.6.9rc2 can be found at http://acl.bestbits.at/nfsacl/ (not linked on homepage). The usual way to get feature patches in the debian kernel is by sending them upstream to kernel.org. The known problems section on that webpage suggests there's still some work needed to make the patch acceptable for general use. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel abiname transition and security updates status
Horms wrote: [snip] I have made both kernel-source-2.4.27 and kernel-image-2.4.27-i386 up on http://debian.vergenet.net/pending/ for people to take a look at. Builds fine for mips, images soon available at http://people.debian.org/~ths/mips-kernels/kernel-patch-2.4.27-mips/ Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel abiname transition and security updates status
Christian T. Steigies wrote: [snip] I uploaded new 2.6.8 kernel-images for m68k a week ago, but I did not make it urgent...: Too young, only 7 of 10 days old For 2.4.27 I am waiting for the latest kernel-source to be released before I build new images. This is supposed to happen today/tomorrow? I should be able to get those images ready over the weekend then, and I'll try to remember to make it more urgent... Supposed-to-be final kernel-source can be found at http://debian.vergenet.net/pending/ I have no idea about the abichanges, m68k uses no abiname? Is that a problem? Is there anything else m68k has to do, like build new d-i-k-i-m68k packages? Anything else I am missing? External modules, as well as modules separated out for d-i, will break, so they need to be kept in sync. IOW, needs new d-i-k-i-m68k, preferably uploaded at the same time than the new kernel, and also updated external modules if there are any. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#290925: kernel-source-2.6.10: Blank Screen When Using intelfb Module
Horms wrote: On Mon, Jan 17, 2005 at 08:30:24PM +0100, Georg Wittenburg wrote: Package: kernel-source-2.6.10 Version: 2.6.10-3 Severity: normal When the intelfb module is compiled into the kernel all consoles remain blank until the X server starts up. Using it as a module is not an option for non-CRT screens (see http://www.xfree86.org/~dawes/intelfb.html, which I'm assuming not to be outdated on this issue). This makes the driver unusable for laptops. hlh has already mentioned that we need to walk away from the modular fb code, for reasuns such as this. I am not sure what unplesant side effects that is going to have in relation to mkinitrd and the debian installer. But perhaps 2.6.10 would be a good place to start the rollback. Does this mean all fb drivers would need to be built in? Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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
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
Bug#284356: SONAME bumping and d-i
Horms wrote: Hi, I have put together the packages that I would like to upload as kernel-source-2.4.27 2.4.27-7 and kernel-image-2.4.27-i386 2.4.27-7. This includes increasing the SONAME to 2. Could anyone who is interesetd please take a look. Builds fine on mips. Thiemo
Bug#286803: kernel-source-2.6.9: Kind of a memory leak in kernel 2.6?
MySQL Development wrote: [snip] The problem is that this did not work out. Every time when I run a make on a MySQL source tree, I loose some of my memory. More specifically spoken, the amount of memory, called Active increases, while Cached decreases (names are taken from /proc/meminfo). Just to avoid misunderstandings: Active does not fall back to what it was before the the make process started. After running MySQL makes a couple of times, Active occupies about 80 to 90% of the RAM. After that, it does not grow any more. Nevertheless, only a small fraction of my expensive RAM is left for the file system cache. Have you tried to adjust /proc/sys/vm/vfs_cache_pressure ? linux/Documentation/filesystems/proc.txt might be worth a read. Thiemo
Re: [PROPOSAL] 2.4.27 as default 2.4 kernel for sarge
Norbert Tretkowski wrote: [snip] I'm going to upload an updated kernel-image-2.4.26-alpha package next weekend, please make sure you're using this one, because it'll be build against kernel-source-2.4.26 2.4.26-6, which fixes some security issues. ... not kernel-image-2.4.27-alpha? There was no final decision if we ship 2.4.27 with sarge. If you now build and upload linux-kernel-di-alpha 0.62 with 2.4.27, you have to build 0.63 that downgrades linux-kernel-di-alpha back to 2.4.26 if we don't use 2.4.27 for sarge. 0.61 can't be used for sarge because it was built with kernel-source-2.4.26 2.4.26-2.1 which has some security problems which were fixed later. AFAICS it would be rather something like 0.61sarge1 for sarge, and it is then independent from the decision about 2.4.27. Thiemo
Re: Which 2.4 kernel-source for sarge?
dann frazier wrote: We need to come to an agreement about which kernel-source we will ship for sarge. According to http://wiki.debian.net/index.cgi?DebianKernel, everyone w/ 2.4.26 has 2.4.27 except for powerpc (sparc is building). 2.4.26 has had more testing time - its used in d-i RC1. The latest kernel-source-2.4.26 package appears to be in good shape with respect to security. What arguments are there for moving to 2.4.27 prior to sarge? Updated device mapper and IPsec. Thiemo
Bug#266839: Error while compiling mips kernel 2.6.7 on Cobalt Qube2
severity 266839 wishlist thanks Wouter van Reeven wrote: Package: kernel-source-2.6.7 Version: 2.6.7-4 After downloading the kernel-source package I unzipped and untarred it. Then I ran make menuconfig and checked and verified the correct architecture and machine specs were loaded. Then I quit with saving changes. Next I ran make which exited with this error: The kernel-source package is known to miss half a ton of mips-specific patches, it is not supposed to work for mips/mipsel in its raw form. This may change for future versions if integration of linux-mips.org modifications into the kernel.org tree works well. 2.6 cobalt needs AFAIK some further porting work as well. I plan to do kernel-patch-2.6.8-mips post sarge, and hope the cobalt support is good enough by then. Thiemo
Re: Bug#266839: Error while compiling mips kernel 2.6.7 on Cobalt Qube2
Sven Luther wrote: [snip] 2.6 cobalt needs AFAIK some further porting work as well. I plan to do kernel-patch-2.6.8-mips post sarge, and hope the cobalt support is good enough by then. Just a question, why post-sarge ? Apart from not enough time or such, is there technical reasons for that ? I don't feel like slamming out some mostly untested kernels immediately before a release. Thiemo
Re: status of 2.6.7 ? (Was Re: Bug#256763: kernel-image-2.6.6-i386: not ready for sarge just yet)
Christoph Hellwig wrote: [snip] For more info, read the debian-vote mailing lists archive. And welcome to debian politics :) Hmm, I wonder what this means for the firmware blob issues.. AFAICS every change is postponed until sarge releases, and then the whole circus starts again. Thiemo
