Bug#632824: linux-image-2.6.39-2-686-pae: linux = 2.6.39 and spacefun splash screen don't mix: system fails to come up

2011-07-06 Thread Thorsten Glaser
Package: linux-2.6 Version: 2.6.39-2 Severity: important This is the laptop of a coworker which runs Debian testing, but I have observed this problem on a Linux kvm VM running Debian unstable as well previously. To enable the spacefun splash screen, I had to do the following, according to

Bug#632824: linux-image-2.6.39-2-686-pae: linux = 2.6.39 and spacefun splash screen don't mix: system fails to come up

2011-07-06 Thread Thorsten Glaser
Yves-Alexis Perez dixit: I don't know what graphic card you use but if supported you really Depends… one is kvm, so some kind of cirruz logic or generic vga, then we have laptops with intel, ati and nievida, so we need a generic solution. should use kernel mode setting. How does one use that?

Bug#632824: linux-image-2.6.39-2-686-pae: linux = 2.6.39 and spacefun splash screen don't mix: system fails to come up

2011-07-06 Thread Thorsten Glaser
Julien Cristau dixit: The generic solution is disable the splash screen pretty much. Which directly contradicts the goal of this exercise. bye, //mirabilos, who doesn’t *WANT* to go back to Kubuntu usplash -- ch you introduced a merge commit│mika % g rebase -i HEAD^^ mika sorry, no

Bug#632824: linux-image-2.6.39-2-686-pae: linux = 2.6.39 and spacefun splash screen don't mix: system fails to come up

2011-07-06 Thread Thorsten Glaser
Jonathan Nieder dixit: FYI: http://lists.freedesktop.org/archives/dri-devel/2011-April/010396.html Interesting, but of course limits us to versions supporting that. I’d prefer some generic VESA VBE method. This used to work (using vga= options), so this is a regression. bye, //mirabilos --

Bug#632824: linux-image-2.6.39-2-686-pae: linux = 2.6.39 and spacefun splash screen don't mix: system fails to come up

2011-07-06 Thread Thorsten Glaser
Jonathan Nieder dixit: Can you reproduce this with an upstream kernel? Can you bisect? Nope, won’t get paid for _that_ much effort. Sorry. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 52675-93 • Fax: +49 228 52675-25 HRB AG Bonn

[m68k] Patches for 3.0 (was Re: linux-2.6_2.6.39-1_amd64.changes ACCEPTED into unstable)

2011-06-29 Thread Thorsten Glaser
: On Wed, Jun 29, 2011 at 19:38, Thorsten Glaser t...@mirbsd.de wrote: Geert Uytterhoeven dixit: I folded it into your previous patch and pushed it out for 3.1. Can you make a patch (series) on top of 3.0 and mail that to debian-kernel asking for inclusion in the next 3.0 upload, on the ground

Re: [m68k] Patches for 3.0

2011-06-29 Thread Thorsten Glaser
maximilian attems dixit: aboves confuses me, I don't see any m68k patches in the trunk branch heading for the next 3.0-rcX upload? Yes, they were in 2.6.38 but someone removed them before 2.6.39 in Debian. All but this one patch, replaced by (see below), were included in 2.6.39 upstream though,

Bug#522773: possible solutions for __unused problem

2011-06-19 Thread Thorsten Glaser
Robert Millan dixit: I can see they wouldn't be excited about it, but they might also accept You know that there are more than one BSD, but only one glibc, IIRC Drepper isn’t even its maintainer any more. Try persuading for example Theo de Raadt of anything which doesn’t have any immediate

Bug#522773: possible solutions for __unused problem

2011-06-19 Thread Thorsten Glaser
Ben Hutchings dixit: Honestly, when resolving this I’d go for “who has the older rights”. Maybe look at how CSUR resolves different claims to the same part of the Unicode PUA, or something like that. Nevertheless, thanks on picking this up. Debian GNU/Linux is the older system; the Debian

Re: linux-2.6_2.6.38-5_m68k.changes ACCEPTED

2011-05-12 Thread Thorsten Glaser
Ben Hutchings dixit: Anyway, I don't think the TPM drivers could be used on most non-x86 architectures. We should just disable them. Yes, these are good candidates for being left out. WLAN devices probably as well, but I’ll leave that to the platform experts to decide. (Most TPMs are included

Re: linux-2.6_2.6.38-5_m68k.changes ACCEPTED

2011-05-12 Thread Thorsten Glaser
Geert Uytterhoeven dixit: I suspect this list is also applicable to atari and amiga (?) Yeah, I should look into updating the defconfigs again. Mh. Debian provides their own configs as well though, I think Wouter/Stephen/cts should have a look at them. (You should have seen the comments by

Re: [patch] m68k, mm: set all online nodes in N_NORMAL_MEMORY

2011-04-27 Thread Thorsten Glaser
by David Rientjes +rient...@google.com attempting to set node state immediately when +bringing the node online. Signed-off-by: Michael Schmitz schm...@debian.org -Tested-by: Thorsten Glaser t...@debian.org +Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org +CC: sta...@kernel.org --- arch

Re: Debian/m68k kernel (preview)

2011-04-24 Thread Thorsten Glaser
Ben Hutchings dixit: You don't need to unset ECONET or X25 in debian/config/m68k/config; they OK. As I said, for the configs I just merged what was there in Debian’s 2.6.32 tree already, added one RTC option and made the others from m into y on atari. Feel free to twiddle them around in any way

Re: Debian/m68k kernel (preview)

2011-04-24 Thread Thorsten Glaser
that’s relevant to someone, based on my previous expe- rience with these two patches. I will, of course, mail back when I actually submit these to the Debian Kernel Team. +++ linux-2.6-2.6.38/debian/changelog + [ Thorsten Glaser ] + * [m68k] Disable staging drivers (taken from Debian 2.6.32

Re: Debian/m68k kernel

2011-04-24 Thread Thorsten Glaser
Dixi quod… Changes from the previous one: […] Dear Debian Linux Kernel team, please consider that patch (it was made against 2.6.38-4) for inclusion in your next upload. It’s lots better than everything we had before (i.e. Ethernet and the framebuf- fer console work and SLUB doesn’t panic).

Re: Debian/m68k kernel

2011-04-24 Thread Thorsten Glaser
Ben Hutchings dixit: Applied, with the exception of the debian/config/m68k/config change. A line of the form '# CONFIG_FOO is unset' really is the correct way to unset CONFIG_FOO; it is not just a comment. OK. Thanks a lot in any case. I’ll wait for your next upload (and my build of gcc-4.4 to

Bug#598893: eglibc sysroot

2010-10-13 Thread Thorsten Glaser
Finn Thain dixit: I guess you patched your compilers as discussed on linux-m68k? Interestingly enough, I was not hit by GCC PR/41302 because I built with CONFIG_ARCH_WANT_FRAME_POINTERS=y and CONFIG_FRAME_POINTER=y to work around GCC PR/37052 already which defines not only

Bug#598893: linux-2.6 [m68k]: please work around gcc-4.3 ICE bug (37052)

2010-10-06 Thread Thorsten Glaser
Bastian Blank dixit: m68k is not a release architecture. Also all newer kernels uses gcc 4.4. It doesn’t happen in gcc-4.4 but the kernel currently in sid uses gcc-4.3. bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or

Bug#598893: linux-2.6 [m68k]: please work around gcc-4.3 ICE bug (37052)

2010-10-06 Thread Thorsten Glaser
Ben Hutchings dixit: On Wed, Oct 06, 2010 at 04:25:43PM +, Thorsten Glaser wrote: Bastian Blank dixit: m68k is not a release architecture. Also all newer kernels uses gcc 4.4. It doesnb But we aren't going to release with m68k, so why not concentrate on trunk/experimental? Makes

Bug#599121: linux-2.6: [m68k] nfeth driver vanished? no network connectivity!

2010-10-04 Thread Thorsten Glaser
Source: linux-2.6 Version: 2.6.32-24 Severity: important Tags: experimental sid After compiling an m68k kernel for ARAnyM using the atari platform, requiring the fix from Debian #598893 as well as a patch I've sub- mitted upstream¹ in order to allow inclusion into the Debian kernel, and getting

Bug#598893: linux-2.6 [m68k]: please work around gcc-4.3 ICE bug (37052)

2010-10-03 Thread Thorsten Glaser
Dixi quod… Please see to that -fno-omit-frame-pointer is used during compilation of a Debian m68k kernel as long as it is built with gcc-4.3 (I think defining CONFIG_FRAME_POINTER should be enough, I have yet to build any kernel at all though and have not tested this). ARCH_WANT_FRAME_POINTERS

Bug#598893: linux-2.6 [m68k]: please work around gcc-4.3 ICE bug (37052)

2010-10-03 Thread Thorsten Glaser
+CONFIG_ARCH_WANT_FRAME_POINTERS=y +CONFIG_FRAME_POINTER=y Corresponding changelog entry: [ Thorsten Glaser ] * debian/config/m68k/config: define CONFIG_ARCH_WANT_FRAME_POINTERS and CONFIG_FRAME_POINTER to yes (Closes: #598893) Note that this *only* applies to the sid kernel

Bug#598893: linux-2.6 [m68k]: please work around gcc-4.3 ICE bug (37052)

2010-10-02 Thread Thorsten Glaser
Source: linux-2.6 Version: 2.6.32-24 Severity: wishlist Tags: sid Please see to that -fno-omit-frame-pointer is used during compilation of a Debian m68k kernel as long as it is built with gcc-4.3 (I think defining CONFIG_FRAME_POINTER should be enough, I have yet to build any kernel at all though

Re: [DRAFT v2] Policy for Linux kernel, initramfs, boot loader update process

2010-07-08 Thread Thorsten Glaser
Guillem Jover dixit: A bit of background info. For GNU/kFreeBSD the kernel images are named 'kfreebsd-image-*', for GNU/Hurd they are named 'gnumach'. (I should probably rename gnumach to match the current kernel naming convention.) I wonder if there will ever be packages like

Bug#522773: [issues] glibc uses '__unused' as identifier, which is traditionally used by BSD as macro

2009-09-09 Thread Thorsten Glaser
Moritz Muehlenhoff dixit: You need to get this changed upstream, we won't deviate from upstream for this. You probably have better contact to upstream, would you be so kind as to bring this forward with them? Thanks in advance. Sincerely, //mirabilos -- I believe no one can invent an

Bug#522773: linux-libc-dev: uses __unused as identifier, which is traditionally used by BSD as macro

2009-04-06 Thread Thorsten Glaser
Package: linux-libc-dev Version: 2.6.29-2 Severity: wishlist (mass filing with linux-libc-dev and libc6-dev) /usr/include/asm/stat.h:long__unused[3]; /usr/include/linux/icmp.h: __be16 __unused; /usr/include/linux/sysctl.h:unsigned long __unused[4]; These

<    1   2   3