Bug#507557: linux-image-2.6.26-1-r4k-ip22: hangs early at boot on Indigo2
Julien BLACHE wrote: > Thiemo Seufer 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]
Bug#466977: 2.6.24-1-sb1-bcm91250a mipsel hangs running init
Martin Michlmayr wrote: > * Thiemo Seufer <[EMAIL PROTECTED]> [2008-03-03 12:51]: > > > running on a Broadcom SB1 *little endian* the kernel hangs trying to run > > > init. The old 2.6.17 works (linux-image-2.6.17-1-sb1 version 2.6.17-5): > > > > 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). 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
Florian Lohoff wrote:
>
> Package: linux-image-2.6.24-1-sb1-bcm91250a
> Version: 2.6.24-4
> Arch: mipsel
>
> Hi,
> running on a Broadcom SB1 *little endian* the kernel hangs trying to run
> init. The old 2.6.17 works (linux-image-2.6.17-1-sb1 version 2.6.17-5):
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.
Thiemo
This patch marks pages tainted by PIO IDE as dirty, instead of trying
to flush them right away. This
a) fixes PIO IDE for systems without dcache aliases (which lacked
the necessary cache flush so far)
b) improves performance a bit, since some pages may never need a
cache flush
c) obsoletes local_flush_data_cache_page
Signed-off-by: Thiemo Seufer <[EMAIL PROTECTED]>
---
Changed to avoid some compiler warnings.
Index: linux.git/include/asm-mips/mach-generic/ide.h
===
--- linux.git.orig/include/asm-mips/mach-generic/ide.h 2008-03-02
20:15:24.0 +
+++ linux.git/include/asm-mips/mach-generic/ide.h 2008-03-02
21:52:46.0 +
@@ -107,107 +107,66 @@
#endif
/* MIPS port and memory-mapped I/O string operations. */
-static inline void __ide_flush_prologue(void)
+static inline void __ide_set_pages_dirty(const void *addr, unsigned long size)
{
-#ifdef CONFIG_SMP
- if (cpu_has_dc_aliases)
- preempt_disable();
-#endif
-}
+ unsigned long end = (unsigned long)addr + size;
-static inline void __ide_flush_epilogue(void)
-{
-#ifdef CONFIG_SMP
- if (cpu_has_dc_aliases)
- preempt_enable();
-#endif
-}
-
-static inline void __ide_flush_dcache_range(unsigned long addr, unsigned long
size)
-{
- if (cpu_has_dc_aliases) {
- unsigned long end = addr + size;
-
- while (addr < end) {
- local_flush_data_cache_page((void *)addr);
- addr += PAGE_SIZE;
- }
+ while ((unsigned long)addr < end) {
+ SetPageDcacheDirty(virt_to_page(addr));
+ addr += PAGE_SIZE;
}
}
-/*
- * insw() and gang might be called with interrupts disabled, so we can't
- * send IPIs for flushing due to the potencial of deadlocks, see the comment
- * above smp_call_function() in arch/mips/kernel/smp.c. We work around the
- * problem by disabling preemption so we know we actually perform the flush
- * on the processor that actually has the lines to be flushed which hopefully
- * is even better for performance anyway.
- */
static inline void __ide_insw(unsigned long port, void *addr,
unsigned int count)
{
- __ide_flush_prologue();
insw(port, addr, count);
- __ide_flush_dcache_range((unsigned long)addr, count * 2);
- __ide_flush_epilogue();
+ __ide_set_pages_dirty(addr, count * 2);
}
-static inline void __ide_insl(unsigned long port, void *addr, unsigned int
count)
+static inline void __ide_insl(unsigned long port, void *addr,
+ unsigned int count)
{
- __ide_flush_prologue();
insl(port, addr, count);
- __ide_flush_dcache_range((unsigned long)addr, count * 4);
- __ide_flush_epilogue();
+ __ide_set_pages_dirty(addr, count * 4);
}
static inline void __ide_outsw(unsigned long port, const void *addr,
unsigned long count)
{
- __ide_flush_prologue();
outsw(port, addr, count);
- __ide_flush_dcache_range((unsigned long)addr, count * 2);
- __ide_flush_epilogue();
+ __ide_set_pages_dirty(addr, count * 2);
}
static inline void __ide_outsl(unsigned long port, const void *addr,
unsigned long count)
{
- __ide_flush_prologue();
outsl(port, addr, count);
- __ide_flush_dcache_range((unsigned long)addr, count * 4);
- __ide_flush_epilogue();
+ __ide_set_pages_dirty(addr, count * 4);
}
static inline void __ide_mm_insw(void __iomem *port, void *addr, u32 count)
{
- __ide_flush_prologue();
readsw(port, addr, count);
- __ide_flush_dcache_range((unsigned long)addr, count * 2);
- __ide_flush_epilogue();
+ __ide_set_pages_dirty(addr, count * 2);
}
static inline void __ide_mm_insl(void __iomem *port, void *addr, u32 count)
{
- __ide_flush_prologue();
readsl(port, addr, count);
- __ide_flush_dcache_range((unsigned long)addr, count * 4);
- __ide_flush_epilogue();
+ __ide_set_pages_dirty(addr, count * 4);
}
static inline void __ide_mm_outsw(void __iomem *port, void *addr, u32 count)
{
- __ide_flush_prologue();
writesw(port, addr, count);
- __ide_flush_dcache_range((unsigned long)addr, count * 2);
- __ide_flush_epilogue();
+ __ide_set_pages_dirty(addr, count * 2);
}
static inline void __ide_mm_outsl(void __iomem * port, void *ad
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]
Bug#466977: 2.6.24-1-sb1-bcm91250a mipsel hangs running init
Florian Lohoff wrote: > > Package: linux-image-2.6.24-1-sb1-bcm91250a > Version: 2.6.24-4 > Arch: mipsel > > Hi, > running on a Broadcom SB1 *little endian* the kernel hangs trying to run > init. The old 2.6.17 works (linux-image-2.6.17-1-sb1 version 2.6.17-5): Same for big endian. [...] > kjournald starting. Commit interval 5 seconds > EXT3-fs: mounted filesystem with ordered data mode. > VFS: Mounted root (ext3 filesystem) readonly. > Freeing unused kernel memory: 196k freed I tracked that down (in linux-mips.org's 2.6.16 tree, which was my testcase of choice) to: http://www.linux-mips.org/git?p=linux.git;a=commit;h=3a57f2ad7436d27dfa90717921b921fc3a168504 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 +0000, 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 07:04:17PM +0000, Thiemo Seufer wrote: > > 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. > > Do you mean as a default ip22 image or as the only one? I mean as the only one. > How much work > would it be to also provive ip22-32 images? The config is basically the > same except a single CONFIG item... With proper support in the installer, different images, and even further increased buildd time: Quite a lot. Could you try if adding the compiler options I mentioned to the kernel Makefile works for your machine? 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 +0000, 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] 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 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]
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. > > I have tested on 2 machines now and both behave the same way. > Are you probably using a different arcboot or tftp or something? > > This is the machine i tried on today: > >System: IP22 > > Processor: 100 Mhz R4000, with FPU > Sounds like a very early revision of the R4000, could that make a difference? 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]
Re: 2.6.22
Martin Michlmayr wrote: > * Bastian Blank <[EMAIL PROTECTED]> [2007-07-11 14:33]: > > I intend to fork 2.6.22 today. The last 2.6.21 upload should go into > > lenny after all builds are available. So we should be able to > > release 2.6.22 at the end of the week. > > mipsel fails to build the malta flavour: > > LD init/mounts.o > mipsel-linux-gnu-ld: cannot open linker script file ldscripts/elf32btsmip.xr: > No such file or directory > make[5]: *** [init/mounts.o] Error 1 Looks wrong, a *btsmip* linker script is for big endian mips. mipsel would use *ltsmip*. 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. > > 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]
Bug#387498: Bug#395135: Please requeue gclcvs_2.7.0-62 on alpha
Steve Langasek wrote: [snip] > > Come to think of it, this bug might have just appeared on alpha too: > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387498 > > No, it's not the same bug; the test case for system() works fine on my alpha > when compiling with -pg. My current guess about 387498 is it's an instance of the cache alias bugs which were fixed recently upstream. I heard hppa was hit most by it. I hope I can test tomorrow if that guess is correct. 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]
Bug#380089: (no subject)
martin f krafft wrote: > severity 380089 critical > thanks > > 23:32:34 < vorlon> well, then that's a grave/critical bug on initramfs-tools >for creating an unbootable system; it's not the package >relationships themselves that make it RC > 23:32:52 < madduck> but the solution is a conflict. > 23:33:07 < vorlon> that's an acceptable solution, yes Some information was probably lost: [...] 22:32 < madduck> it's the onlyone in this case. 22:32 < madduck> thank you. 22:32 < dato> or perhaps refusing to generate the initramfs 22:33 < vorlon> right -- throwing an error if mdadm is required and it's a version that's known to break booting is also valid 22:34 < madduck> maks: ^ 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: > 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: 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: 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
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: 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
dann frazier wrote: > 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? Mips/mipsel d-i hasn't fully switched to 2.6 yet. Is there a urgent need to remove 2.4 from etch? 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 r 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: Preparing 2.6.16-7, Call for discussion on SECCOMP and HZ_250
maximilian attems wrote: [snip] > > - HZ_250 instead of HZ_1000: If I remember correctly, we kept HZ_1000 > > because it was the prior default. IMHO, we should follow upstream and > > change the default to HZ_250 too. > > > > A short pro/cons is here: http://kerneltrap.org/node/5411 > > > > Considering we plan to use the smp-alternatives patches for both amd64 > > and i386, at least here HZ_250 makes sense. For the other arches and > > flavours, either HZ_100 for smp and HZ_1000 for up/desktop flavours > > could make sense, or just HZ_250 too for the sake of simplicity. > > > > There will for sure be users requesting to revert this change, similar > > to PREEMPT, so I would like to have a concensus in the team regarding > > this option. > > i would stick with HZ_250 everywhere. > the upstream change seems not contested since. Agreed. 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#333834: linux-2.6: Please enabled "audit" support, selinux is pretty much unuseable otherwise.
Erich Schubert wrote: > Hi, > > I'm not entirely sure which kernel config option this refers to, could > > you dig that up? That not withstanding, your suggestion seems fine to > > me, though I would appreciate some feedback from others. I've CCed > > Manoj in case he has some oppinions. > > CONFIG_AUDIT and CONFIG_AUDIT_SYSCALL. > IIRC the latter allows you to disable audit logging from userspace as > well as configure where the logs go to (e.g. via netlink to a userspace > audit daemon) AFAIR CONFIG_AUDIT_SYSCALL was disabled because of its performance overhead and limited usefulness. The debian-kernel list archive should have some discussion about it. 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: [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: 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: > 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]
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]
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]
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]
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]
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]
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: removing /etc/hotplug.d/ support
Marco d'Itri wrote: > On Aug 25, Horms <[EMAIL PROTECTED]> wrote: > > > There are some architectures where 2.4 is required, its > > because of these that it seems that we are stuck with 2.4 for Etch. > > alpha (installer), m68k (2.6 only works on amiga), s390 (installer), > > mips, mipsel > What does "installer" mean? IIRC SuSE supports s390 with 2.6 kernels. > Also, exactly how is 2.6 broken for mips and mipsel? From a quick google > search it looks like it's actively developed and even commercially > supported. Mips/mipsel spans a wide range of hardware with different capabilities and boot methods. There is no generic kernel. 2.6 on mips is currently well supported for some pricey prototype boards and for some older SGI workstations. All those popular mips WLAN devices use still 2.4 kernels, some people started to port some of them to 2.6, but the main hindrance are binary only (and thus 2.4 only) drivers. The next generation of those devices will _probably_ be based on 2.6. Thiemo signature.asc Description: Digital signature
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]
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: 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]
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: 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: 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
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
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: [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: 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: > 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: 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: [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: 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: > 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: 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
Marc Haber wrote: > On Mon, Jul 04, 2005 at 11:12:21AM +0200, Thiemo Seufer wrote: > > Most kernel hackers don't care that much about 2.4 any more. > > This is of course one of the reasons why users feel left alone by the > kernel developers. The gcc version recommended by upstream is still 2.95. :-) 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
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
Sven Luther wrote: [snip] > > > 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. > > Notice though that the right way to fix these issues would be to make a new > set of kernels available in sarge (even though they are not used by d-i), so > that our users get the real thing, and not the patently broken and full of > security issues kernel that we currently ship. s/sarge/t-p-u/ because of GPL cornercases. 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
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: [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: [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=file&rev=0&sc=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
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]
Re: Removing 2.4.25 and 2.4.26?
Christian T. Steigies wrote: [snip] > > Only for some m68k and sparc subarchitectures, and the m68k ones > > have still no newer 2.4 version available. (Status as shown by > > http://people.debian.org/~dannf/kernel-stats/kernel-avail.html) > > I beg your pardon? > > http://packages.qa.debian.org/k/kernel-image-2.4.27-m68k.html > > Maybe your script didn't like the change from half a dozen source packages > to just one for all of m68k. I see, it seems to be outdated WRT. > Besides, bugs against the 2.4.25 and 26 images > have been filed by somebody called Frank Lichtenheld 188 days ago. > > http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=kernel-image-2.4.26-q40 Which is only a bug to block it from sarge, not a removal request against the ftp.d.o pseudopackage. Could you file those for obsoleted packages (or tell Frank if it is ok for him to do so)? Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing 2.4.25 and 2.4.26?
Frank Lichtenheld wrote: > Hi. > > There are still many packages for 2.4.25 and 2.4.26 in unstable. > Is there any reason not to file a bug against ftp.debian.org to > remove these? I could take care of that if nobody from the kernel team > has time to do it. Only for some m68k and sparc subarchitectures, and the m68k ones have still no newer 2.4 version available. (Status as shown by http://people.debian.org/~dannf/kernel-stats/kernel-avail.html) 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]
Re: 2.4.27-9
Horms wrote: > I have finally finished wading through the bug reports and > put togther kernel-source-2.4.27 2.4.27-9 and > kernel-image-2.4.27-i386 2.4.27-9. > > This update does _NOT_ contain ABI breakage, > although one symbol has been added to the ABI. > That is, the fix for CAN-2005-0449 has been omitted. > > I am currently doing the final builds and intend to tag and upload these > later today, or tomorrow at the latest. If you have feedback, now would > be an excellent time to make it known. > > If anyone wants to test these packages, or kick off some builds, > I have made the kernel-source packages available at the URL below. > I will add the i386 kernel-image packages as soon as they finish > building (which takes an hour or so). > > http://debian.vergenet.net/pending/ Builds fine for mips, candidates for tests can be found 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: 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#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]
