Bug#401384: [INTL:pt] Portuguese translation for mkvmlinuz (debconf)

[Rui Branco]

Package: mkvmlinuz
Version: 27
Tags: l10n, patch
Severity: wishlist

Portuguese (pt) translation for mkvmlinuz's debconf messages
by Rui Branco .
Feel free to use it.

For translation updated please contact Rui Branco and CC the Portuguese
translation team 
























pt.po
Description: application/gettext

Bug#400752: linux-modules-extra-2.6: include ndiswrapper

[Kel Modderman]

On Friday 01 December 2006 21:30, Bastian Blank wrote:
> tags 400752 moreinfo
> thanks
>
> On Wed, Nov 29, 2006 at 01:17:20AM +1000, Kel Modderman wrote:
> > Package: linux-modules-extra-2.6
> > Severity: wishlist
> > Tags: patch
> >
> > Please consider including ndiswrapper. Patch attached, based on existing
> > support for spca5xx.
>
> There are reports that ndiswrapper won't work with 4k stack, please
> prove.

Yes, thats right.

> Also I'm not sure if this may go into main at all, see ipw3945 
> for the reasons.

ipw3945 is in contrib, ndiswrapper in main.

If you don't like this proposal (i knew it would have little chance anyway) 
then please tag wontfix.

Thanks, Kel.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

mkvmlinuz 27 MIGRATED to testing

[Debian testing watch]

FYI: The status of the mkvmlinuz source package
in Debian's testing distribution has changed.

  Previous version: 24
  Current version:  27

-- 
This email is automatically generated; [EMAIL PROTECTED] is responsible.
See http://people.debian.org/~henning/trille/ for more information.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#401344: kernel BUG at mm/rmap.c:251! - kernel 2.6.8-2-386 - debian sarge

[dann frazier]

On Sat, Dec 02, 2006 at 10:57:59AM -0800, Horacio wrote:
> 
> Package: kernel-image-2.6.8-2-386
> Version: 2.6.8-16
> 
> I've found this on Dec. 1st in my syslog while running rsync:

Note that you are running a kernel with a large number of security
vulnerabilities - I strongly suggest upgrading to the latest version
of sarge and tracking the avaiable security updates.

I've no reason to believe that the latest sarge version fixes the
issue you described below, however, it'd be more interesting if you were
able to reproduce when running this version.

fwiw, I've only been able to find one other report similar to this -
its interesting to note that it was also a kernel with PREEMPT being
enabled:
 http://lists.xensource.com/archives/html/xen-devel/2004-10/msg00091.html

-- 
dann frazier



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.19, kernel-package problems and what are our plans for etch ...

[Bastian Blank]

On Sat, Dec 02, 2006 at 01:41:50PM -0800, Steve Langasek wrote:
> > yes i want to add 2.6.18.5 to linux-2.6 sid,
> > not sure if it breaks abi through..
> Sounds to me like something to look into *after* 2.6.18 has had a chance to
> reach testing?

You have to force them than.

Bastian

-- 
Killing is stupid; useless!
-- McCoy, "A Private Little War", stardate 4211.8


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.19, kernel-package problems and what are our plans for etch ...

[Steve Langasek]

On Sat, Dec 02, 2006 at 03:41:24PM +0100, maximilian attems wrote:
> On Sat, Dec 02, 2006 at 02:44:11PM +0100, Bastian Blank wrote:
> > On Sat, Dec 02, 2006 at 12:10:00PM +0100, Bastian Blank wrote:
> > > On Sat, Dec 02, 2006 at 11:48:07AM +0100, Sven Luther wrote:
> > > > > We need another upload of linux-2.6 and linux-modules-extra-2.6 to fix
> > > > > the following issues:
> > > > Ok, do we have a plan for this ? 
> > > Not yet.

> > Can we upload that today or are other things waiting?

> yes i want to add 2.6.18.5 to linux-2.6 sid,
> not sure if it breaks abi through..

Sounds to me like something to look into *after* 2.6.18 has had a chance to
reach testing?

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#401358: System freezes under heavy disk IO

[Peter Hirdina]

Package: linux-image-2.6.18-3-k7
Version: 2.6.18-6

After installing the version 2.6.18-6 of the kernel, my machine (SMP,
AthlonMP) just freezes under heavy disk IO (not immediately, but after a
few minutes).

I tried the modules dpt_i2o and i2o_block for my Adaptec 2400A raid
controller, and even tried JFS instead of XFS as filesystem, but it didn't
make any difference. Well, the only difference was the time it took until
the machine froze (actually with JFS it happened faster than with XFS).

I went back to the version 2.6.17-9 and the machine seems to run stable
again, even with more IO than needed to crash 2.6.18-6. So, it looks like
somehwere between those versions, a SMB related bug was introduced in a
more generic place, since the crashes happened across drivers and
filesystems.

regards,
Peter

-
  Peter Hirdina   Frauenstrasse 128  
  [EMAIL PROTECTED] 89073 Ulm / Germany  
-



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.19, kernel-package problems and what are our plans for etch ...

[Russ Allbery]

Teodor-Adrian MICU <[EMAIL PROTECTED]> writes:

> I think it is a good ideea to adopt 2.6.19 for etch if its possible.

Please don't unless we can't avoid it.  Each time we bring in a new
kernel, those of us who maintain external kernel modules have to do a
bunch of work to catch up with all the API changes.  For full 2.6.19
support on all platforms I believe I'd need to pull patches from CVS for
OpenAFS, whereas the current packages are stable and functioning on
2.6.18.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#401352: Significant delays when booting installer in vmware [486 kernel]

[Frans Pop]

Package: linux-2.6
Severity: important
Version: 2.6.18-6
Tags: d-i

Since d-i switched to 2.6.18 I'm seeing significant delays during boot
of the installer in two places. See dmesg fragment below (full dmesg
attached).

If I boot the installer with an RC1 image (using 2.6.17), there are no
noticeable delays at all in the boot process. dmesg attached as well
for comparison, although I don't see any significant differences.

Both delays with 2.6.18 are completely reproducible.


Memory: 154944k/163840k available (1500k kernel code, 8280k reserved, 602k 
data, 256k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
*** significant delay of about 5-7 seconds ***
Calibrating delay using timer specific routine.. 3222.25 BogoMIPS (lpj=6444502)
Security Framework v1.0.0 initialized
SELinux:  Disabled at boot.
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0febfbff     
 
CPU: After vendor identify, caps: 0febfbff     
 
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: After all inits, caps: 0febfbff   0080  
 
Compat vDSO mapped to e000.
CPU: Intel Mobile Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 08
Checking 'hlt' instruction... OK.
ACPI: Core revision 20060707
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
*** significant delay of about 8-10 seconds ***
checking if image is initramfs... it is
Freeing initrd memory: 4182k freed



boot_2.6.18.dmesg.gz
Description: GNU Zip compressed data


boot_2.6.17.dmesg.gz
Description: GNU Zip compressed data


pgpoQFkyLqH2o.pgp
Description: PGP signature

Re: 2.6.19, kernel-package problems and what are our plans for etch ...

[Sven Luther]

On Sat, Dec 02, 2006 at 12:43:06PM -0600, Manoj Srivastava wrote:
> On Sat, 2 Dec 2006 11:36:30 +0100, Bastian Blank <[EMAIL PROTECTED]> said: 
> 
> > On Fri, Dec 01, 2006 at 08:26:10PM +0100, Sven Luther wrote:
> >> - What is stopping 2.6.18 to enter testing ? The PTS says "Should
> >>   ignore,
> >> but forced by vorlon", so does this mean it will enter testing
> >> today ?  What about the remaining (or new) RC bugs ? Some of them
> >> being open against 2.6.17, so also present in testing.
> 
> > We need another upload of linux-2.6 and linux-modules-extra-2.6 to
> > fix the following issues: linux-2.6:
> > - Some small security fixes.
> > - Fix for internal posix types support for s390.
> > - Conflict with too old initramfs generators, the fallback entry
> >   matches them also.
> > - Don't longer disable serial drivers in xen images.
> > linux-modules-extra-2.6:
> > - Disable squashfs on arm, does not work.
> 
> >> - latest info from Bastian was that the 2.6.19-rc6 experimental
> >>   packages in
> >> experimental failed to build because of some kernel-package problem
> >> which caused silent bugs. Bastian, do you have any additional info
> >> to provide which may give a light to the problem ? Manoj, can you
> >> have a look at this, and maybe help us fix the issue ?
> 
> > I'm not longer interrested in communicating errors in software,
> > which is not able to catch errors but reports silent success
> > instead. This is the fourth bug with this result in the last 6
> > months or so.
> 
> And none of which you report. If you can't put together a

Notice that this is the same problem as the guy with 2.6.11 reported.

>  coherent bug report, you can't expect issues to get resolved.
>  Frankly, k-p works fine when used as expected -- linux-2.6 tries to
>  mould it in a fashion which is not exactly supported, by overriding
>  bits and pieces, and I am not surprised when things do not work as
>  you try to force them to.

The real problem is that you don't really integrate well with the kernel team,
and have your own agenda. This is also true from the other side though.

What we really need is a strategy where you work better with the kernel team,
where we have more communication (also applies to Bastian), and where the
stated goal of kernel-package is to build both older kernel and the kernel
packages.

This would be a good starting point to take Jonas idea again, and move the
postinst scripts out of kernel-package and the linux-images, and into
separate package ? 

> Even then, I would respond to bug reports which show
>  misbehavior by kernel-package -- which have not exactly been
>  forthcoming, have they?
> 
> manoj
>  tired of people trying to bend k-p into doing things it is not
>  supposed to do, and then complaining when they fail

Well, to be honest, it goes both way.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#401344: kernel BUG at mm/rmap.c:251! - kernel 2.6.8-2-386 - debian sarge

[Horacio]

Package: kernel-image-2.6.8-2-386
Version: 2.6.8-16

I've found this on Dec. 1st in my syslog while running rsync:

kernel BUG at mm/rmap.c:251!
invalid operand:  [#1]
PREEMPT
Modules linked in: tun rtc ipt_MASQUERADE ipt_LOG iptable_filter parport_pc 
parport agpgart capability commoncap psmouse ide_cd cdrom 8139too mii tulip 
ipt_state ipt_helper ipt_conntrack ip_nat_irc ip_nat_ftp iptable_nat ip_tables 
ip_conntrack_irc ip_conntrack_ftp ip_conntrack reiserfs ide_generic ide_disk 
via82cxxx ide_core unix font vesafb cfbcopyarea cfbimgblt cfbfillrect
CPU:0
EIP:0060:[page_referenced+92/322]Not tainted
EFLAGS: 00010246   (2.6.8-2-386)
EIP is at page_referenced+0x5c/0x142
eax: c6e58000   ebx: c6e58000   ecx: c6e59c40   edx: d853ca10
esi:    edi: d853ca10   ebp: c119bb20   esp: c6e59be8
ds: 007b   es: 007b   ss: 0068
Process rsync (pid: 4171, threadinfo=c6e58000 task=d85bc370)
Stack: 0073 0001  0001  c135f500 c028d224 c0135401
   c6e58000 c119bb38 c119bb20 c028d224 c0136778 c119bb20 c0135401 0001
   0020  c135f2d8 c135e9f8 c6e59c38 c6e59c38 c1205418 c135f418


The rsync was running from a cron job. I got this on a email:

rsync: writefd_unbuffered failed to write 4 bytes: phase "unknown" [sender]: 
Broken pipe (32)
rsync: connection unexpectedly closed (3848042 bytes received so far) 
[generator]
rsync error: error in rsync protocol data stream (code 12) at io.c(420)
rsync: connection unexpectedly closed (4940 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(420)

Here is the FULL kernel log, taken from syslog, and some additional information:

==
syslog
==

Dec  1 04:49:27 localhost kernel: [ cut here ]
Dec  1 04:49:27 localhost kernel: kernel BUG at mm/rmap.c:251!
Dec  1 04:49:27 localhost kernel: invalid operand:  [#1]
Dec  1 04:49:27 localhost kernel: PREEMPT
Dec  1 04:49:27 localhost kernel: Modules linked in: tun rtc ipt_MASQUERADE 
ipt_LOG iptable_filter parport_pc parport agpgart capability commoncap psmouse 
ide_cd cdrom 8139too mii tulip ipt_state ipt_helper ipt_conntrack ip_nat_irc 
ip_nat_ftp iptable_nat ip_tables ip_conntrack_irc ip_conntrack_ftp ip_conntrack 
reiserfs ide_generic ide_disk via82cxxx ide_core unix font vesafb cfbcopyarea 
cfbimgblt cfbfillrect
Dec  1 04:49:27 localhost kernel: CPU:0
Dec  1 04:49:27 localhost kernel: EIP:0060:[page_referenced+92/322]Not 
tainted
Dec  1 04:49:27 localhost kernel: EFLAGS: 00010246   (2.6.8-2-386)
Dec  1 04:49:27 localhost kernel: EIP is at page_referenced+0x5c/0x142
Dec  1 04:49:27 localhost kernel: eax: c6e58000   ebx: c6e58000   ecx: c6e59c40 
  edx: d853ca10
Dec  1 04:49:27 localhost kernel: esi:    edi: d853ca10   ebp: c119bb20 
  esp: c6e59be8
Dec  1 04:49:27 localhost kernel: ds: 007b   es: 007b   ss: 0068
Dec  1 04:49:27 localhost kernel: Process rsync (pid: 4171, threadinfo=c6e58000 
task=d85bc370)
Dec  1 04:49:27 localhost kernel: Stack: 0073 0001  0001 
 c135f500 c028d224 c0135401
Dec  1 04:49:27 localhost kernel:c6e58000 c119bb38 c119bb20 c028d224 
c0136778 c119bb20 c0135401 0001
Dec  1 04:49:27 localhost kernel:0020  c135f2d8 c135e9f8 
c6e59c38 c6e59c38 c1205418 c135f418
Dec  1 04:49:27 localhost kernel: Call Trace:
Dec  1 04:49:27 localhost kernel:  [__pagevec_release+24/35] 
__pagevec_release+0x18/0x23
Dec  1 04:49:27 localhost kernel:  [refill_inactive_zone+436/1172] 
refill_inactive_zone+0x1b4/0x494
Dec  1 04:49:27 localhost kernel:  [__pagevec_release+24/35] 
__pagevec_release+0x18/0x23
Dec  1 04:49:28 localhost kernel:  [shrink_zone+120/162] shrink_zone+0x78/0xa2
Dec  1 04:49:28 localhost kernel:  [shrink_caches+66/79] shrink_caches+0x42/0x4f
Dec  1 04:49:28 localhost kernel:  [try_to_free_pages+150/331] 
try_to_free_pages+0x96/0x14b
Dec  1 04:49:28 localhost kernel:  [__alloc_pages+432/683] 
__alloc_pages+0x1b0/0x2ab
Dec  1 04:49:28 localhost kernel:  [find_or_create_page+59/145] 
find_or_create_page+0x3b/0x91
Dec  1 04:49:28 localhost kernel:  
[__crc_cpufreq_register_governor+2307396/5743486] 
reiserfs_prepare_file_region_for_write+0xeb/0x876 [reiserfs]
Dec  1 04:49:28 localhost kernel:  [unlock_page+26/28] unlock_page+0x1a/0x1c
Dec  1 04:49:28 localhost kernel:  
[__crc_cpufreq_register_governor+2306642/5743486] 
reiserfs_submit_file_region_for_write+0x25b/0x295 [reiserfs]
Dec  1 04:49:28 localhost kernel:  
[__crc_cpufreq_register_governor+2310534/5743486] 
reiserfs_file_write+0x4b7/0x6ae [reiserfs]
Dec  1 04:49:28 localhost kernel:  [sock_aio_read+217/231] 
sock_aio_read+0xd9/0xe7
Dec  1 04:49:28 localhost kernel:  [vfs_write+175/217] vfs_write+0xaf/0xd9
Dec  1 04:49:28 localhost kernel:  [sys_write+59/99] sys_write+0x3b/0x63
Dec  1 04:49:28 localhost kernel:  [syscall_call+7/11] syscall_call+0x7/0xb
Dec  1 04:49:28 localhost kernel: Code: 0f 0b fb 00 60 fe 25 c0 8d 5a c8 8b 43 
38 0f 18 

Re: Module.symvers issues

[Manoj Srivastava]

On Fri, 01 Dec 2006 10:33:37 +0100, Jean Parpaillon <[EMAIL PROTECTED]> said: 

> Dear kernel packagers, I'm trying to packaging a linux 2.6.11 kernel
> for Sid. I started from
> http://svn.debian.org/wsvn/kernel/dists/trunk/linux-2.6 to package
> it.  After patching my linux-2.6.11 vanilla to compile with gcc4 and
> binutils currently in Sid, doing my config with split-config, it
> still remains this issue:

You are probably better off just using kernel-package to
 package older kernels; since k-p has a stated policy of trying to be
 as backwards compatible as possible.

manoj
-- 
A real friend isn't someone you use once and then throw away. A real
friend is someone you can use over and over again.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.19, kernel-package problems and what are our plans for etch ...

[Manoj Srivastava]

On Sat, 2 Dec 2006 11:36:30 +0100, Bastian Blank <[EMAIL PROTECTED]> said: 

> On Fri, Dec 01, 2006 at 08:26:10PM +0100, Sven Luther wrote:
>> - What is stopping 2.6.18 to enter testing ? The PTS says "Should
>>   ignore,
>> but forced by vorlon", so does this mean it will enter testing
>> today ?  What about the remaining (or new) RC bugs ? Some of them
>> being open against 2.6.17, so also present in testing.

> We need another upload of linux-2.6 and linux-modules-extra-2.6 to
> fix the following issues: linux-2.6:
> - Some small security fixes.
> - Fix for internal posix types support for s390.
> - Conflict with too old initramfs generators, the fallback entry
>   matches them also.
> - Don't longer disable serial drivers in xen images.
> linux-modules-extra-2.6:
> - Disable squashfs on arm, does not work.

>> - latest info from Bastian was that the 2.6.19-rc6 experimental
>>   packages in
>> experimental failed to build because of some kernel-package problem
>> which caused silent bugs. Bastian, do you have any additional info
>> to provide which may give a light to the problem ? Manoj, can you
>> have a look at this, and maybe help us fix the issue ?

> I'm not longer interrested in communicating errors in software,
> which is not able to catch errors but reports silent success
> instead. This is the fourth bug with this result in the last 6
> months or so.

And none of which you report. If you can't put together a
 coherent bug report, you can't expect issues to get resolved.
 Frankly, k-p works fine when used as expected -- linux-2.6 tries to
 mould it in a fashion which is not exactly supported, by overriding
 bits and pieces, and I am not surprised when things do not work as
 you try to force them to.

Even then, I would respond to bug reports which show
 misbehavior by kernel-package -- which have not exactly been
 forthcoming, have they?

manoj
 tired of people trying to bend k-p into doing things it is not
 supposed to do, and then complaining when they fail
-- 
You are the only person to ever get this message.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#401269: marked as done ([powerpc] Apple G5 windfram based fan control modules not included or loaded in initramfs-tools generated ramdisks.)

[Debian Bug Tracking System]

Your message dated Sat, 02 Dec 2006 18:02:03 +
with message-id <[EMAIL PROTECTED]>
and subject line Bug#401269: fixed in initramfs-tools 0.85c
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: initramfs-tools
Severity: Important

On Sat, Dec 02, 2006 at 05:45:52PM +0900, Charles Plessy wrote:
> Le Thu, Nov 30, 2006 at 04:12:56PM +0100, Holger Levsen a écrit :
> > 
> > On Thursday 30 November 2006 12:20, Charles Plessy wrote:
> > 
> > > On the other hand, I recommend to test wether they also stay silent on
> > > the installed system as well.
> > 
> > Could you do this? 
> 
> 
> Hi,
> 
> The problem with the fan control is solved for the installer, but
> /etc/modules does not contain the necessary entries to start the fan
> control at boot time on the installed system.

Hi Charles, the problem is not with /etc/modules, but with initramfs-tools.

Mmm, i think i cannot find this bug, so opening a new one with this message.

Max, can you add somethign to initramfs-tools, as we discussed numerous times,
to load the fan control modules ? At worst, you can load the same modules as
is done in d-i.

Friendly,

Sven Luther

--- End Message ---
--- Begin Message ---
Source: initramfs-tools
Source-Version: 0.85c

We believe that the bug you reported is fixed in the latest version of
initramfs-tools, which is due to be installed in the Debian FTP archive:

initramfs-tools_0.85c.dsc
  to pool/main/i/initramfs-tools/initramfs-tools_0.85c.dsc
initramfs-tools_0.85c.tar.gz
  to pool/main/i/initramfs-tools/initramfs-tools_0.85c.tar.gz
initramfs-tools_0.85c_all.deb
  to pool/main/i/initramfs-tools/initramfs-tools_0.85c_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to [EMAIL PROTECTED],
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
maximilian attems <[EMAIL PROTECTED]> (supplier of updated initramfs-tools 
package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [EMAIL PROTECTED])


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat,  2 Dec 2006 18:06:34 +0100
Source: initramfs-tools
Binary: initramfs-tools
Architecture: source all
Version: 0.85c
Distribution: unstable
Urgency: medium
Maintainer: Debian kernel team 
Changed-By: maximilian attems <[EMAIL PROTECTED]>
Description: 
 initramfs-tools - tools for generating an initramfs
Closes: 401269
Changes: 
 initramfs-tools (0.85c) unstable; urgency=medium
 .
   Release "Pour être heureux vraiment Faut plus d'gouvernement"
 .
   * hook-funcions: Show on verbose mode the added binaries and libraries.
 .
   * update-initramfs: Don't silently fail, user won't be able to reboot.
 Thanks Mario Aeby for his blog entry.
 .
   * debian/copyright: Moved to bzr.d.o repo location.
 .
   * hook-functions: Merge 0.69ubuntu22 copy_module_dir fixes, we'll use it
 too postetch. Fix the bashism. Thanks to Jurij Smakov <[EMAIL PROTECTED]>
 .
   * scripts/init-premount/thermal: Load blindly a bunch of thermal modules
 on powerpc as they are not hotpluggable. Might be ugly, but is a safe bet.
 Kernel plattform fix is scheduled for 2.6.20. Push with medium urgency.
 (closes: 401269)
Files: 
 04886281a599eb3b04d92eb94e9ef87b 625 utils optional initramfs-tools_0.85c.dsc
 9b597901b1b4418d2a7f1a454f1b0184 55011 utils optional 
initramfs-tools_0.85c.tar.gz
 12ad38abe454b48097a2313ae37004a6 61824 utils optional 
initramfs-tools_0.85c_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFcbj8jjectMmeA8wRAhfAAKCtaeAJ3zdEbT+xyqUxS1E6Jt2KnACguKND
fk3TUeezOK/+gzBGVT77aEQ=
=4smR
-END PGP SIGNATURE-

--- End Message ---

initramfs-tools_0.85c_i386.changes ACCEPTED

[Debian Installer]

Accepted:
initramfs-tools_0.85c.dsc
  to pool/main/i/initramfs-tools/initramfs-tools_0.85c.dsc
initramfs-tools_0.85c.tar.gz
  to pool/main/i/initramfs-tools/initramfs-tools_0.85c.tar.gz
initramfs-tools_0.85c_all.deb
  to pool/main/i/initramfs-tools/initramfs-tools_0.85c_all.deb


Override entries for your package:
initramfs-tools_0.85c.dsc - source utils
initramfs-tools_0.85c_all.deb - optional utils

Announcing to debian-devel-changes@lists.debian.org
Closing bugs: 401269 


Thank you for your contribution to Debian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.19, kernel-package problems and what are our plans for etch ...

[Jurij Smakov]

On Sat, Dec 02, 2006 at 11:36:30AM +0100, Bastian Blank wrote:
> On Fri, Dec 01, 2006 at 08:26:10PM +0100, Sven Luther wrote:
> >   - What is stopping 2.6.18 to enter testing ? The PTS says "Should ignore,
> > but forced by vorlon", so does this mean it will enter testing today ?
> > What about the remaining (or new) RC bugs ? Some of them being open
> > against 2.6.17, so also present in testing.
> 
> We need another upload of linux-2.6 and linux-modules-extra-2.6 to fix
> the following issues:
> linux-2.6:
> - Some small security fixes.
> - Fix for internal posix types support for s390.
> - Conflict with too old initramfs generators, the fallback entry matches
>   them also.
> - Don't longer disable serial drivers in xen images.
> linux-modules-extra-2.6:
> - Disable squashfs on arm, does not work.

I'm sorry to say that, but my current position is to veto any future 
linux-2.6 upload, unless it also implements the changes to the 
orig.tar.gz in accordance with the release position statement [0] 
following the firmware GR.

[0] http://lists.debian.org/debian-kernel/2006/10/msg00541.html

Best regards,
-- 
Jurij Smakov   [EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/  KeyID: C99E03CC


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#401331: initramfs-tools: lilo failures in update-initramfs are silent.

[maximilian attems]

On Sat, Dec 02, 2006 at 10:06:21AM -0700, David Anselmi wrote:
> 
> When lilo -t fails update-initramfs exits with an error (due to set -e)
> but provides no indication to the user.  When called in postinst the
> failure is reported by, e.g., aptitude but there is no explanation of
> what went wrong.
> 
> This could leave a system unbootable if update-initramfs is run outside
> of package management (where the failure is invisible) or if the user doesn't
> realize an upgrade failure might be serious.
> 
> I suggest that the stderr of lilo -t should at least be provided to the
> user, or perhaps run_lilo() should do set +e and then complain loudly if
> lilo -t fails.

yup the failure needs to be reported,
fully agreed - i'll refix that for 0.85d
 
> -- Package-specific info:
> -- /proc/cmdline
> auto BOOT_IMAGE=Linux ro root=fd00
> 
> -- /proc/filesystems
>   cramfs
>   ext3
> 
> -- lsmod
> [ Snip.  Not relavent to this bug. ]
> 
> -- kernel-img.conf
> do_symlinks = yes
> relative_links = yes
> do_bootloader = no
> do_bootfloppy = no
> do_initrd = yes
> link_in_boot = no

woow people have so broken /etc/kernel-img.conf,
if you have lilo installed you want
do_bootloader = yes
so that lilo will be surely run by linux-image postinst.
 
thanks for feedback

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processing of initramfs-tools_0.85c_i386.changes

[Archive Administrator]

initramfs-tools_0.85c_i386.changes uploaded successfully to localhost
along with the files:
  initramfs-tools_0.85c.dsc
  initramfs-tools_0.85c.tar.gz
  initramfs-tools_0.85c_all.deb

Greetings,

Your Debian queue daemon


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#401331: initramfs-tools: lilo failures in update-initramfs are silent.

[David Anselmi]

Package: initramfs-tools
Version: 0.85b
Severity: normal

When lilo -t fails update-initramfs exits with an error (due to set -e)
but provides no indication to the user.  When called in postinst the
failure is reported by, e.g., aptitude but there is no explanation of
what went wrong.

This could leave a system unbootable if update-initramfs is run outside
of package management (where the failure is invisible) or if the user doesn't
realize an upgrade failure might be serious.

I suggest that the stderr of lilo -t should at least be provided to the
user, or perhaps run_lilo() should do set +e and then complain loudly if
lilo -t fails.

-- Package-specific info:
-- /proc/cmdline
auto BOOT_IMAGE=Linux ro root=fd00

-- /proc/filesystems
cramfs
ext3

-- lsmod
[ Snip.  Not relavent to this bug. ]

-- kernel-img.conf
do_symlinks = yes
relative_links = yes
do_bootloader = no
do_bootfloppy = no
do_initrd = yes
link_in_boot = no


-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages initramfs-tools depends on:
ii  busybox   1:1.1.3-3  Tiny utilities for small and embed
ii  cpio  2.6-17 GNU cpio -- a program to manage ar
ii  klibc-utils   1.4.30-1   small statically-linked utilities 
ii  module-init-tools 3.3-pre3-1 tools for managing Linux kernel mo
pn  udev   (actually this is installed
  but has failed at the moment due
  to lilo being broken)

initramfs-tools recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.19 patches

[Sven Luther]

On Sat, Dec 02, 2006 at 05:23:42PM +0100, Bastian Blank wrote:
> On Sat, Dec 02, 2006 at 05:03:51PM +0100, Sven Luther wrote:
> > Please don't drop the powerpc patches, they were all checkd and updated for
> > 2.6.19-rc6.
> 
> Than fix the categories.

fix the categories ? 

> > Let's keep it for now, if i don't get it resubmitted before 2.6.20, we can
> > drop it.
> 
> It does not build at all and it is long enough in this state. Who needs
> this anyway?

Lot of people i have to do support for.

Well, i intent to fix the build problem, once i have the 2.6.19 package
building myself. Can you give me the svn url for the branch where you fixed
the stuff ? 

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#338405: another patch for busybox support

[maximilian attems]

On Sat, 02 Dec 2006, Russell Coker wrote:

> The following will significantly reduce the size of an initramfs when busybox 
> is used while also enabling all busybox commands (handy if you have an option 
> to run a shell from the initramfs for recovery).  In spite of what maks 
> thinks, the busybox option is still there, so it should be made to work well.

due to partial upgrade path and thus the need of support of lvm2 and mdadm
inside of mkinitramfs itself, busybox is kept. klibc shipps dash, which
is a fine sh. the missing parts in klibc-utils are sed, awk or grep that
is used by aboves hooks.

a really stripped down initramfs does not need busybox nor glibc,
as udev and module-init-tools compiles against klibc.
 
> --- mkinitramfs.orig2006-12-02 15:42:16.0 +1100
> +++ mkinitramfs 2006-12-02 17:25:38.0 +1100
> @@ -228,7 +228,12 @@
>  else
> rm -f ${DESTDIR}/bin/sh
> copy_exec ${BUSYBOXDIR}/busybox /bin/busybox
> -   ln -s ${BUSYBOXDIR}/busybox ${DESTDIR}/bin/sh
> +   rm ${DESTDIR}/bin/busybox
> +   cp ${BUSYBOXDIR}/busybox ${DESTDIR}/bin/busybox
> +   for n in `busybox | tail -19 | tr , \\n | sed -e "s/ \|\t//"|grep .` 
> ; 
> do
> +   ln -f /bin/busybox ${DESTDIR}/bin/$n
> +   done
> +   ln -f /bin/busybox ${DESTDIR}/bin/sh
>  fi
> 
>  # Modutils

ok thanks,
not yet tested but scheduled for 0.85d
bon weekend.

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.19 patches

[Bastian Blank]

On Sat, Dec 02, 2006 at 05:03:51PM +0100, Sven Luther wrote:
> Please don't drop the powerpc patches, they were all checkd and updated for
> 2.6.19-rc6.

Than fix the categories.

> Let's keep it for now, if i don't get it resubmitted before 2.6.20, we can
> drop it.

It does not build at all and it is long enough in this state. Who needs
this anyway?

Bastian

-- 
Each kiss is as the first.
-- Miramanee, Kirk's wife, "The Paradise Syndrome",
   stardate 4842.6


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.19 patches

[Sven Luther]

On Sat, Dec 02, 2006 at 04:18:39PM +0100, Bastian Blank wrote:
> On Sat, Dec 02, 2006 at 03:46:58PM +0100, Bastian Blank wrote:
> > I intend to drop old patches from 2.6.19, this includes:
> > - Anything not categorized (debian/patches/*.patch). There is one
> >   problematic one: alpha-prctl.patch, which is not upstream; the alpha
> >   maintainer have to check that and fix the category.
> > - Anything not debian specific and not submitted within the last 6
> >   months. (I only know one: asfs, which can be easily built as external
> >   module.)
> - Any unused patch. (The output of debian/bin/check-patches.sh)

well, how many of those are not unused but where simply disabled when the
first 2.6.19-rcX builds were tried.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.19 patches

[Sven Luther]

On Sat, Dec 02, 2006 at 03:52:59PM +0100, maximilian attems wrote:
> On Sat, Dec 02, 2006 at 03:46:58PM +0100, Bastian Blank wrote:
> > Hi folks
> > 
> > I intend to drop old patches from 2.6.19, this includes:
> > - Anything not categorized (debian/patches/*.patch). There is one
> >   problematic one: alpha-prctl.patch, which is not upstream; the alpha
> >   maintainer have to check that and fix the category.
> > - Anything not debian specific and not submitted within the last 6
> >   months. (I only know one: asfs, which can be easily built as external
> >   module.)
> > 
> > Bastian
> 
> ack for
> - modular-ide-pnp.patch
>   never accepted upstream and ata is the way forward.
> 
> - fbdev-radeon-noaccel.patch
>   one of those ppc patches that don't get forwarded, why?

Huh, it had not powerpc in the name so i haven't looked at it for ages.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.19 patches

[Sven Luther]

On Sat, Dec 02, 2006 at 03:46:58PM +0100, Bastian Blank wrote:
> Hi folks
> 
> I intend to drop old patches from 2.6.19, this includes:
> - Anything not categorized (debian/patches/*.patch). There is one
>   problematic one: alpha-prctl.patch, which is not upstream; the alpha
>   maintainer have to check that and fix the category.

Please don't drop the powerpc patches, they were all checkd and updated for
2.6.19-rc6.

> - Anything not debian specific and not submitted within the last 6
>   months. (I only know one: asfs, which can be easily built as external
>   module.)

Let's keep it for now, if i don't get it resubmitted before 2.6.20, we can
drop it.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.19 patches

[Bastian Blank]

On Sat, Dec 02, 2006 at 03:46:58PM +0100, Bastian Blank wrote:
> I intend to drop old patches from 2.6.19, this includes:
> - Anything not categorized (debian/patches/*.patch). There is one
>   problematic one: alpha-prctl.patch, which is not upstream; the alpha
>   maintainer have to check that and fix the category.
> - Anything not debian specific and not submitted within the last 6
>   months. (I only know one: asfs, which can be easily built as external
>   module.)
- Any unused patch. (The output of debian/bin/check-patches.sh)

Bastian

-- 
What kind of love is that?  Not to be loved; never to have shown love.
-- Commissioner Nancy Hedford, "Metamorphosis",
   stardate 3219.8


signature.asc
Description: Digital signature

Re: 2.6.19 patches

[maximilian attems]

On Sat, Dec 02, 2006 at 03:46:58PM +0100, Bastian Blank wrote:
> Hi folks
> 
> I intend to drop old patches from 2.6.19, this includes:
> - Anything not categorized (debian/patches/*.patch). There is one
>   problematic one: alpha-prctl.patch, which is not upstream; the alpha
>   maintainer have to check that and fix the category.
> - Anything not debian specific and not submitted within the last 6
>   months. (I only know one: asfs, which can be easily built as external
>   module.)
> 
> Bastian

ack for
- modular-ide-pnp.patch
  never accepted upstream and ata is the way forward.

- fbdev-radeon-noaccel.patch
  one of those ppc patches that don't get forwarded, why?

2.6.19 has the relevant pci_id_table patches from my side,
so happy with it.

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed (with 1 errors): Re: Bug#378344: [powerpc,prep] On PReP boxes, root should be autodetected, since there is no bootloader.

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 378344 lvm2
Bug#378344: initramfs-tools: Should be able to force root device for 
update-initramfs
Bug reassigned from package `initramfs-tools' to `lvm2'.

> rettitle 378344 provide an howto mv root on lvm2 volume
Unknown command or malformed arguments to command.

> severity 378344 wishlist
Bug#378344: initramfs-tools: Should be able to force root device for 
update-initramfs
Severity set to `wishlist' from `grave'

> stop
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#378344: [powerpc,prep] On PReP boxes, root should be autodetected, since there is no bootloader.

[maximilian attems]

reassign 378344 lvm2
rettitle 378344 provide an howto mv root on lvm2 volume
severity 378344 wishlist
stop

On Sat, 02 Dec 2006, Sven Luther wrote:

> severity 378344 grave
> # Upping severity, since this bug makes a PReP d-i install not being able to
> # boot in the resulting system. Furthermore, this is a general regression from
> # sarge and initrd-tools.
> Thanks

378344 is void on the initramfs-tools side.
it's about having an documentation for moving root from
an disc device to an lvm2 volume.
that is definetly not initramfs-tools business.
 
> Max, ...
> 
> When playing with initramfs-tools Motorola Powerstack PReP box, i noticed that
> the machine didn't find the root device on reboot. I had chosen a LVM setup,
> not sure if this influence the issue.
> 
> I had to give the root=/dev/powerstack/root argument by hand on the kernel
> command line, which is less than optimal.

great you try to hi-jack a random non related bug.
aboves is pretty wrong and a dup of #378332
you need to pass a real lvm2 device instead of the stupid symlink
and yes d-i gets that right. you need to pass root=/dev/mapper/vg-lv
 
> I booted into the system, and added ROOT=/dev/powerstack/root, but it would be
> nice if this was autodetected, as it is done in both yaird and initrd-tools.
> 
> Furthermore, it would be nice if the ROOT= option would be documented, and an
> empty entry would be present in the default config file, like the other
> options. Does ROOT=probe also work in initramfs-tools, like it did for
> initrd-tools ? 

no there is no ROOT=probe.
ROOT is documented in mkinitramfs.8

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.19, kernel-package problems and what are our plans for etch ...

[maximilian attems]

On Sat, Dec 02, 2006 at 02:44:11PM +0100, Bastian Blank wrote:
> On Sat, Dec 02, 2006 at 12:10:00PM +0100, Bastian Blank wrote:
> > On Sat, Dec 02, 2006 at 11:48:07AM +0100, Sven Luther wrote:
> > > > We need another upload of linux-2.6 and linux-modules-extra-2.6 to fix
> > > > the following issues:
> > > Ok, do we have a plan for this ? 
> > Not yet.
> 
> Can we upload that today or are other things waiting?
> 
> Bastian

yes i want to add 2.6.18.5 to linux-2.6 sid,
not sure if it breaks abi through..

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

2.6.19 patches

[Bastian Blank]

Hi folks

I intend to drop old patches from 2.6.19, this includes:
- Anything not categorized (debian/patches/*.patch). There is one
  problematic one: alpha-prctl.patch, which is not upstream; the alpha
  maintainer have to check that and fix the category.
- Anything not debian specific and not submitted within the last 6
  months. (I only know one: asfs, which can be easily built as external
  module.)

Bastian

-- 
"What terrible way to die."
"There are no good ways."
-- Sulu and Kirk, "That Which Survives", stardate unknown


signature.asc
Description: Digital signature

Re: 2.6.19, kernel-package problems and what are our plans for etch ...

[Bastian Blank]

On Sat, Dec 02, 2006 at 12:10:00PM +0100, Bastian Blank wrote:
> On Sat, Dec 02, 2006 at 11:48:07AM +0100, Sven Luther wrote:
> > > We need another upload of linux-2.6 and linux-modules-extra-2.6 to fix
> > > the following issues:
> > Ok, do we have a plan for this ? 
> Not yet.

Can we upload that today or are other things waiting?

Bastian

-- 
Men of peace usually are [brave].
-- Spock, "The Savage Curtain", stardate 5906.5


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.19, kernel-package problems and what are our plans for etch ...

[maximilian attems]

On Sat, 02 Dec 2006, Steve Langasek wrote:


> Frankly, 2.6.16 was a total cock-up.  Aside from all the extra work it made
> for the release team, I even found patches I had to reapply for alpha
> because they were dropped on the floor when 2.6.16 was merged to trunk.  I
> am very much opposed to having two kernel versions in unstable at the same
> time.

agreed,
2.6.19 is experimental material.

guys 2.6.18 can still need stabilising,
enough open bugs

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#401229: installation-reports

[Frans Pop]

reassign 401229 initramfs-tools
severity 401229 important
retitle 401229 [hppa] zalon7xx driver not included in initrd
thanks

On Saturday 02 December 2006 00:11, Kurt Fitzner wrote:
> Comments/Problems:
>   A necessary device driver for my system (zalon7xx) was on the install
> CD, but not included in the supplied kernel.  Thus, my system was
> unable to boot after the install.  I have tried RC1 and yesterday's
> daily build.

This is probably a problem in the initramfs-tools package which creates 
the initrd. That should take care of loading the module.

You can work around this by using the rescue mode of the installer (add 
rescue/enable=true boot parameter) and then:
- proceed until you can select the / file system of your new system
- start a chroot shell on that filesystem
- (maybe mount additional filesystems)
- add the module to /etc/initramfs-tools/modules
- update the initrd using update-initramfs

Cheers,
FJP


pgpvZbISwv52f.pgp
Description: PGP signature

Bug#401274: closed by Bastian Blank <[EMAIL PROTECTED]> (Re: Bug#401274: linux-image-2.6.18-3-686: /sbin/update-grub vs /usr/sbin/update-grub (grub2))

[Olaf van der Spek]

Debian Bug Tracking System wrote:

On Sat, Dec 02, 2006 at 11:01:17AM +0100, Olaf van der Spek wrote:

Grub2 put update-grub in another directory (/usr/sbin/update-grub instead of 
/sbin/update-grub).


You should follow the warnigs which are emitted by at least the
update-grub from grub 1: Remove the absolute path from the entry in
/etc/kernel-img.conf.


I've never seen that warning.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.19, kernel-package problems and what are our plans for etch ...

[Sven Luther]

On Sat, Dec 02, 2006 at 02:41:08AM -0800, Steve Langasek wrote:
> On Sat, Dec 02, 2006 at 10:51:57AM +0100, Sven Luther wrote:
> > The -k7 issue, i don't know, can it be a flavour that was dropped or
> > something ? 
> 
> linux-latest-2.6 is not a candidate because not yet uploaded on sparc.
> That's the easy part; linux-modules-extra-2.6 is the harder part, currently
> failing to build on both arm and s390 (c.f. bug #400220).

Can we not just scratch l-m-e-2.6 until those issues are fixed, and migrate
linux-2.6 andl-l-2.6 into testing asap ? We need to get more testing done for
it.

> > > >   - What are our plans for 2.6.19 ? Will we have it enter unstable, and
> > > > maintain the etch kernel through testing-proposed-updates ? I heard 
> > > > this
> > > > mentioned some time back. Will we fork a linux-2.6.19 package in 
> > > > unstable
> > > > ? Will we keep 2.6.19 in experimental for now ? 
> 
> > > I hope you can keep 2.6.19 in experimental for now - it doesn't take so
> > > long to release Etch anymore.
> 
> > Bah, we where told this for sarge, and it took over a year back then. I 
> > don't
> > see us releaseing etch anytime soon, since we don't have had a single 
> > release
> > candidate of d-i with the 2.6.18 kernels in it yet, so moving 2.6.19 to
> > unstable (maybe with a linux-2.6.19 source package) should be nice enough. 
> > We
> > did this already for 2.6.16, so, we know how to do this.
> 
> Frankly, 2.6.16 was a total cock-up.  Aside from all the extra work it made
> for the release team, I even found patches I had to reapply for alpha
> because they were dropped on the floor when 2.6.16 was merged to trunk.  I
> am very much opposed to having two kernel versions in unstable at the same
> time.

Well, the idea is to continue working on 2.6.19 in a separate package, but
keeping 2.6.18 linux-2.6 as the main package, with linux-2.6.19 being a
separate package which will be worked on as separatedly for those peopel who
want.

But you are right, if we want to do more than one kernle, we need an automated
better way to do synchronizations.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed: Re: Bug#401229: installation-reports

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 401229 initramfs-tools
Bug#401229: installation-reports
Bug reassigned from package `installation-reports' to `initramfs-tools'.

> severity 401229 important
Bug#401229: installation-reports
Severity set to `important' from `normal'

> retitle 401229 [hppa] zalon7xx driver not included in initrd
Bug#401229: installation-reports
Changed Bug title.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#401274: marked as done (linux-image-2.6.18-3-686: /sbin/update-grub vs /usr/sbin/update-grub (grub2))

[Debian Bug Tracking System]

Your message dated Sat, 2 Dec 2006 11:38:14 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Bug#401274: linux-image-2.6.18-3-686: /sbin/update-grub vs 
/usr/sbin/update-grub (grub2)
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: linux-image-2.6.18-3-686
Version: 2.6.18-6
Severity: normal

Hi,

Grub2 put update-grub in another directory (/usr/sbin/update-grub instead of 
/sbin/update-grub).

# apt-get install
Reading package lists... Done
Building dependency tree... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
2 not fully installed or removed.
Need to get 0B of archives.
After unpacking 0B of additional disk space will be used.
Setting up linux-image-2.6.18-3-686 (2.6.18-6) ...
Running depmod.
Finding valid ramdisk creators.
Using mkinitrd.yaird to build the ramdisk.
The provided postinst hook script [/sbin/update-grub] could not be run.
dpkg: error processing linux-image-2.6.18-3-686 (--configure):
 subprocess post-installation script returned error exit status 2
dpkg: dependency problems prevent configuration of linux-image-2.6-686:
 linux-image-2.6-686 depends on linux-image-2.6.18-3-686; however:
  Package linux-image-2.6.18-3-686 is not configured yet.
dpkg: error processing linux-image-2.6-686 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-image-2.6.18-3-686
 linux-image-2.6-686
E: Sub-process /usr/bin/dpkg returned an error code (1)
#

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-2-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages linux-image-2.6.18-3-686 depends on:
ii  coreutils 5.97-5.2   The GNU core utilities
ii  debconf [debconf-2.0] 1.5.9  Debian configuration management sy
ii  module-init-tools 3.3-pre3-1 tools for managing Linux kernel mo
ii  yaird [linux-initramfs-tool]  0.0.12-18  Yet Another mkInitRD

Versions of packages linux-image-2.6.18-3-686 recommends:
pn  libc6-i686 (no description available)

-- debconf information:
  linux-image-2.6.18-3-686/postinst/bootloader-error-2.6.18-3-686:
  linux-image-2.6.18-3-686/postinst/old-dir-initrd-link-2.6.18-3-686: true
  linux-image-2.6.18-3-686/postinst/kimage-is-a-directory:
  linux-image-2.6.18-3-686/postinst/old-system-map-link-2.6.18-3-686: true
  linux-image-2.6.18-3-686/postinst/create-kimage-link-2.6.18-3-686: true
  linux-image-2.6.18-3-686/postinst/bootloader-test-error-2.6.18-3-686:
  linux-image-2.6.18-3-686/preinst/abort-overwrite-2.6.18-3-686:
  linux-image-2.6.18-3-686/postinst/old-initrd-link-2.6.18-3-686: true
  shared/kernel-image/really-run-bootloader: true
  linux-image-2.6.18-3-686/preinst/elilo-initrd-2.6.18-3-686: true
  linux-image-2.6.18-3-686/preinst/lilo-initrd-2.6.18-3-686: true
  linux-image-2.6.18-3-686/postinst/depmod-error-initrd-2.6.18-3-686: false
  linux-image-2.6.18-3-686/preinst/bootloader-initrd-2.6.18-3-686: true
  linux-image-2.6.18-3-686/prerm/removing-running-kernel-2.6.18-3-686: true
  linux-image-2.6.18-3-686/prerm/would-invalidate-boot-loader-2.6.18-3-686: true
  linux-image-2.6.18-3-686/preinst/abort-install-2.6.18-3-686:
  linux-image-2.6.18-3-686/preinst/overwriting-modules-2.6.18-3-686: true
  linux-image-2.6.18-3-686/preinst/initrd-2.6.18-3-686:
  linux-image-2.6.18-3-686/preinst/lilo-has-ramdisk:
  linux-image-2.6.18-3-686/preinst/already-running-this-2.6.18-3-686:
  linux-image-2.6.18-3-686/postinst/depmod-error-2.6.18-3-686: false
  linux-image-2.6.18-3-686/preinst/failed-to-move-modules-2.6.18-3-686:

--- End Message ---
--- Begin Message ---
On Sat, Dec 02, 2006 at 11:01:17AM +0100, Olaf van der Spek wrote:
> Grub2 put update-grub in another directory (/usr/sbin/update-grub instead of 
> /sbin/update-grub).

You should follow the warnigs which are emitted by at least the
update-grub from grub 1: Remove the absolute path from the entry in
/etc/kernel-img.conf.

This is not a bug.

Bastian

-- 
Yes, it is written.  Good shall always destroy evil.
-- Sirah the Yang, "The Omega Glory", stardate unknown
--- End Message ---

Bug#400439: RFC: initramfs-tools postinst causes system inconsistency?

[Nikita V. Youshchenko]

Current suituation - when initramfs for one semi-randomly selected 
linux-image package is updated, and others are not, and even administrator 
is not notified in any way, leads to system inconsistensy.

Which I believe is against debian quality standards.

I'm forwarding this to debian-devel for futher discussion.


> On Sun, 26 Nov 2006, Nikita V. Youshchenko wrote:
> > Looks line postinst script of initramfs-tools package just runs
> > 'update-initramfs -u'
>
> yes and it will stay like this.
>
> > This looks to update initramfs image for one of installed linux-image
> > packages, while keeping it as-is for all other packages. This could
> > lead to different sorts of inconsistency.
> >
> > E.g. on one of systems, I have linux-image-2.6.18-2-xen-k7 and
> > linux-image-2.6.18-2-k7 packages installed. Normally xen version is
> > running, but non-xen version is kept for the case if things will go
> > wrong.
>
> this is a known case where the sorting gets wrong,
> but power user, who have several kernels installed can
> take care of that.
>
> > So what is stated in the man page ('update-initramfs -u updates
> > the initramfs of the newest kernel') is not true. 2.6.18-2-xen-k7 *is*
> > newest, but it's initramfs image is not updated.
> > I think that '-u' whthout '-k' in it's current implementation does not
> > make sence at all, because aclually it updates initramfs of
> > semi-random kernel.
>
> just if you install several kernels of the same version,
> than it picks the image on alphabetical order.
>
> > I thinks that tho things should be done
> > - postinst should be changed either to call 'update-initramfs -u -k
> > all', or to ask somehow what images should be updated,
> > - update-initramfs should be modified either to require -k, or to use
> >   better logic to find out what kernel image is the 'latest'.
>
> the sorting algorythm could be refined,
> but needs to take into account that the current running
> is not the latest..
> postetch material anyway.


pgpcthOrOkMIw.pgp
Description: PGP signature

Re: 2.6.19, kernel-package problems and what are our plans for etch ...

[Bastian Blank]

On Sat, Dec 02, 2006 at 11:48:07AM +0100, Sven Luther wrote:
> > We need another upload of linux-2.6 and linux-modules-extra-2.6 to fix
> > the following issues:
> Ok, do we have a plan for this ? 

Not yet.

> > I'm not longer interrested in communicating errors in software, which is
> > not able to catch errors but reports silent success instead. This is the
> > fourth bug with this result in the last 6 months or so.
> 
> Well, we can :
>   1) Revert the infrastructure changes to the 2.6.18 one.

No.

>   2) You could give as much information as you can about the problem, so that
>   someone else (well, probably not me, because Manoj will not speak with me as
>   far as i know), can follow up on this with him.

I don't know what the problem is. I only kown: it does not work on the
autobuilders.

Bastian

-- 
Prepare for tomorrow -- get ready.
-- Edith Keeler, "The City On the Edge of Forever",
   stardate unknown


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#401281: Xorg shows black/garbled screen

[Paul van Tilburg]

Package: linux-image-2.6.18-3-powerpc
Version: 2.6.18-6
Severity: normal

When I booted linux-image-2.6.18-3-powerpc today, Xorg showed a black
screen on my PowerBook G4 (TiBook) and nothing more, rendering X rather
unusable.  When I use my brightness-adjustment keys up or down, it switches
to a white screen with dancing lines on it.

I'm using the following boot param: video=radeonfb
I also use Xorg with the radeon driver.

When I switch back to my still installed linux 2.6.18-2-powerpc, everything
works fine again.

If you need more information, please let me know.
Regards,

Paul

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (102, 'experimental')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18-2-powerpc
Locale: LANG=C, LC_CTYPE=nl_NL.UTF8 (charmap=UTF-8)

Versions of packages linux-image-2.6.18-3-powerpc depends on:
ii  coreutils 5.97-5.2   The GNU core utilities
ii  debconf [debconf-2.0] 1.5.9  Debian configuration management sy
ii  initramfs-tools [linux-initra 0.85b  tools for generating an initramfs
ii  mkvmlinuz 27 create a kernel to boot a PowerPC 
ii  module-init-tools 3.3-pre3-1 tools for managing Linux kernel mo

linux-image-2.6.18-3-powerpc recommends no packages.

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.19, kernel-package problems and what are our plans for etch ...

[Steve Langasek]

On Sat, Dec 02, 2006 at 10:51:57AM +0100, Sven Luther wrote:
> The -k7 issue, i don't know, can it be a flavour that was dropped or
> something ? 

linux-latest-2.6 is not a candidate because not yet uploaded on sparc.
That's the easy part; linux-modules-extra-2.6 is the harder part, currently
failing to build on both arm and s390 (c.f. bug #400220).

> > >   - What are our plans for 2.6.19 ? Will we have it enter unstable, and
> > > maintain the etch kernel through testing-proposed-updates ? I heard 
> > > this
> > > mentioned some time back. Will we fork a linux-2.6.19 package in 
> > > unstable
> > > ? Will we keep 2.6.19 in experimental for now ? 

> > I hope you can keep 2.6.19 in experimental for now - it doesn't take so
> > long to release Etch anymore.

> Bah, we where told this for sarge, and it took over a year back then. I don't
> see us releaseing etch anytime soon, since we don't have had a single release
> candidate of d-i with the 2.6.18 kernels in it yet, so moving 2.6.19 to
> unstable (maybe with a linux-2.6.19 source package) should be nice enough. We
> did this already for 2.6.16, so, we know how to do this.

Frankly, 2.6.16 was a total cock-up.  Aside from all the extra work it made
for the release team, I even found patches I had to reapply for alpha
because they were dropped on the floor when 2.6.16 was merged to trunk.  I
am very much opposed to having two kernel versions in unstable at the same
time.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.19, kernel-package problems and what are our plans for etch ...

[Sven Luther]

On Sat, Dec 02, 2006 at 11:36:30AM +0100, Bastian Blank wrote:
> On Fri, Dec 01, 2006 at 08:26:10PM +0100, Sven Luther wrote:
> >   - What is stopping 2.6.18 to enter testing ? The PTS says "Should ignore,
> > but forced by vorlon", so does this mean it will enter testing today ?
> > What about the remaining (or new) RC bugs ? Some of them being open
> > against 2.6.17, so also present in testing.
> 
> We need another upload of linux-2.6 and linux-modules-extra-2.6 to fix
> the following issues:
> linux-2.6:
> - Some small security fixes.
> - Fix for internal posix types support for s390.
> - Conflict with too old initramfs generators, the fallback entry matches
>   them also.
> - Don't longer disable serial drivers in xen images.
> linux-modules-extra-2.6:
> - Disable squashfs on arm, does not work.

Ok, do we have a plan for this ? 

> >   - latest info from Bastian was that the 2.6.19-rc6 experimental packages 
> > in
> > experimental failed to build because of some kernel-package problem 
> > which
> > caused silent bugs. Bastian, do you have any additional info to provide
> > which may give a light to the problem ? Manoj, can you have a look at
> > this, and maybe help us fix the issue ? 
> 
> I'm not longer interrested in communicating errors in software, which is
> not able to catch errors but reports silent success instead. This is the
> fourth bug with this result in the last 6 months or so.

Well, we can :

  1) Revert the infrastructure changes to the 2.6.18 one.

  2) You could give as much information as you can about the problem, so that
  someone else (well, probably not me, because Manoj will not speak with me as
  far as i know), can follow up on this with him.

In particular, one issue which remains open in the current situation, is that
some could argue that it is not a k-p bug, but one in the infrastructure code,
and as very few people apart from you have an oversight of what is really
happeneing.

I guess the more satisfying solution is 2), you provide a bit of info about
what the problem is, and someone else goes to manoj and or to kernel-package,
and resolve the problem.

Thanks for your reply, Bastian,

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.19, kernel-package problems and what are our plans for etch ...

[Teodor-Adrian MICU]

I think it is a good ideea to adopt 2.6.19 for etch if its possible. I
looked over the changelogs in 2.6.18 and there is one issue that
concerns me:

commit a4fce7747b167aa5e9aa43c4f816744d8a97e021
Author: Patrick McHardy <[EMAIL PROTECTED]>
Date:   Wed Oct 11 01:53:26 2006 -0700

   NETFILTER: NAT: fix NOTRACK checksum handling

   The whole idea with the NOTRACK netfilter target is that
   you can force the netfilter code to avoid connection
   tracking, and all costs assosciated with it, by making
   traffic match a NOTRACK rule.

   But this is totally broken by the fact that we do a checksum
   calculation over the packet before we do the NOTRACK bypass
   check, which is very expensive.  People setup NOTRACK rules
   explicitly to avoid all of these kinds of costs.

   This patch from Patrick, already in Linus's tree, fixes the
   bug.

   Move the check for ip_conntrack_untracked before the call to
   skb_checksum_help to fix NOTRACK excemptions from NAT. Pre-2.6.19
   NAT code breaks TSO by invalidating hardware checksums for every
   packet, even if explicitly excluded from NAT through NOTRACK.

   2.6.19 includes a fix that makes NAT and TSO live in harmony,
   but the performance degradation caused by this deserves making
   at least the workaround work properly in -stable.

On 12/2/06, Sven Luther <[EMAIL PROTECTED]> wrote:

On Sat, Dec 02, 2006 at 10:37:01AM +0100, Andreas Barth wrote:
> * Sven Luther ([EMAIL PROTECTED]) [061201 20:30]:
> >   - What is stopping 2.6.18 to enter testing ? The PTS says "Should ignore,
> > but forced by vorlon", so does this mean it will enter testing today ?
> > What about the remaining (or new) RC bugs ? Some of them being open
> > against 2.6.17, so also present in testing.
>
> If one of the release managers uses the force-hint, nothing from the
> first stage (RC-bugs, date, out-of-date, ...) will block the testing
> migration anymore.
>
> However, in the second stage, installability is checked. According to
> todays output, these packages are broken by the transition:
> trying: linux-2.6
> skipped: linux-2.6 (15 <- 32)
> got: 115+0: i-115
> * i386: kernel-image-2.6-386, kernel-image-2.6-686, 
kernel-image-2.6-686-smp, kernel-image-2.6-k7, kernel-image-2.6-k7-smp, 
linux-headers-2.6-486, linux-headers-2.6-686, linux-headers-2.6-686-bigmem, 
linux-headers-2.6-k7, linux-headers-2.6-vserver-686, linux-headers-2.6-vserver-k7, 
linux-headers-2.6-xen-686, linux-headers-2.6-xen-k7, linux-headers-2.6.18-3-486, 
linux-headers-2.6.18-3-686, linux-headers-2.6.18-3-686-bigmem, 
linux-headers-2.6.18-3-all, linux-headers-2.6.18-3-all-i386, 
linux-headers-2.6.18-3-k7, linux-headers-2.6.18-3-vserver-686, 
linux-headers-2.6.18-3-vserver-k7, linux-headers-2.6.18-3-xen-686, 
linux-headers-2.6.18-3-xen-k7, linux-headers-2.6.18-3-xen-vserver-686, 
linux-image-2.6-486, linux-image-2.6-686, linux-image-2.6-686-bigmem, 
linux-image-2.6-686-smp, linux-image-2.6-k7, linux-image-2.6-k7-smp, 
linux-image-2.6-vserver-686, linux-image-2.6-vserver-k7, linux-image-2.6-xen-686, 
linux-image-2.6-xen-k7, linux-image-486, linux-image-686, linux-image-686-bigmem, 
linux-image-k7, linux-image-vserver-686, linux-image-vserver-k7, 
linux-image-xen-686, linux-image-xen-k7, loop-aes-2.6-486, loop-aes-2.6-686, 
loop-aes-2.6-686-bigmem, loop-aes-2.6-k7, loop-aes-2.6-vserver-686, 
loop-aes-2.6-vserver-k7, loop-aes-2.6.17-2-486, loop-aes-2.6.17-2-686, 
loop-aes-2.6.17-2-686-bigmem, loop-aes-2.6.17-2-k7, loop-aes-2.6.17-2-vserver-686, 
loop-aes-2.6.17-2-vserver-k7, nvidia-kernel-legacy-2.6-486, 
nvidia-kernel-legacy-2.6-686, nvidia-kernel-legacy-2.6-686-smp, 
nvidia-kernel-legacy-2.6-k7, nvidia-kernel-legacy-2.6-k7-smp, 
redhat-cluster-modules-2.6-486, redhat-cluster-modules-2.6-686, 
redhat-cluster-modules-2.6-686-bigmem, redhat-cluster-modules-2.6-k7, 
redhat-cluster-modules-2.6-vserver-686, redhat-cluster-modules-2.6-vserver-k7, 
redhat-cluster-modules-2.6-xen-686, redhat-cluster-modules-2.6-xen-k7, 
redhat-cluster-modules-2.6.17-2-486, redhat-cluster-modules-2.6.17-2-686, 
redhat-cluster-modules-2.6.17-2-686-bigmem, redhat-cluster-modules-2.6.17-2-k7, 
redhat-cluster-modules-2.6.17-2-vserver-686, 
redhat-cluster-modules-2.6.17-2-vserver-k7, 
redhat-cluster-modules-2.6.17-2-xen-686, redhat-cluster-modules-2.6.17-2-xen-k7, 
spca5xx-modules-2.6-486, spca5xx-modules-2.6-686, spca5xx-modules-2.6-686-bigmem, 
spca5xx-modules-2.6-k7, spca5xx-modules-2.6-vserver-686, 
spca5xx-modules-2.6-vserver-k7, spca5xx-modules-2.6-xen-686, 
spca5xx-modules-2.6-xen-k7, spca5xx-modules-2.6.17-2-486, 
spca5xx-modules-2.6.17-2-686, spca5xx-modules-2.6.17-2-686-bigmem, 
spca5xx-modules-2.6.17-2-k7, spca5xx-modules-2.6.17-2-vserver-686, 
spca5xx-modules-2.6.17-2-vserver-k7, spca5xx-modules-2.6.17-2-xen-686, 
spca5xx-modules-2.6.17-2-xen-k7, squashfs-modules-2.6-486, 
squashfs-modules-2.6-686, squashfs-modules-2.6-686-bigmem, 
squashfs-modules-2.6-k7, squashfs-modules-2.6-vserver-686, 
squashfs-modules-2.6-vs

Re: 2.6.19, kernel-package problems and what are our plans for etch ...

[Bastian Blank]

On Fri, Dec 01, 2006 at 08:26:10PM +0100, Sven Luther wrote:
>   - What is stopping 2.6.18 to enter testing ? The PTS says "Should ignore,
> but forced by vorlon", so does this mean it will enter testing today ?
> What about the remaining (or new) RC bugs ? Some of them being open
> against 2.6.17, so also present in testing.

We need another upload of linux-2.6 and linux-modules-extra-2.6 to fix
the following issues:
linux-2.6:
- Some small security fixes.
- Fix for internal posix types support for s390.
- Conflict with too old initramfs generators, the fallback entry matches
  them also.
- Don't longer disable serial drivers in xen images.
linux-modules-extra-2.6:
- Disable squashfs on arm, does not work.

>   - latest info from Bastian was that the 2.6.19-rc6 experimental packages in
> experimental failed to build because of some kernel-package problem which
> caused silent bugs. Bastian, do you have any additional info to provide
> which may give a light to the problem ? Manoj, can you have a look at
> this, and maybe help us fix the issue ? 

I'm not longer interrested in communicating errors in software, which is
not able to catch errors but reports silent success instead. This is the
fourth bug with this result in the last 6 months or so.

Bastian

-- 
It is more rational to sacrifice one life than six.
-- Spock, "The Galileo Seven", stardate 2822.3


signature.asc
Description: Digital signature

Bug#401274: linux-image-2.6.18-3-686: /sbin/update-grub vs /usr/sbin/update-grub (grub2)

[Olaf van der Spek]

Package: linux-image-2.6.18-3-686
Version: 2.6.18-6
Severity: normal

Hi,

Grub2 put update-grub in another directory (/usr/sbin/update-grub instead of 
/sbin/update-grub).

# apt-get install
Reading package lists... Done
Building dependency tree... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
2 not fully installed or removed.
Need to get 0B of archives.
After unpacking 0B of additional disk space will be used.
Setting up linux-image-2.6.18-3-686 (2.6.18-6) ...
Running depmod.
Finding valid ramdisk creators.
Using mkinitrd.yaird to build the ramdisk.
The provided postinst hook script [/sbin/update-grub] could not be run.
dpkg: error processing linux-image-2.6.18-3-686 (--configure):
 subprocess post-installation script returned error exit status 2
dpkg: dependency problems prevent configuration of linux-image-2.6-686:
 linux-image-2.6-686 depends on linux-image-2.6.18-3-686; however:
  Package linux-image-2.6.18-3-686 is not configured yet.
dpkg: error processing linux-image-2.6-686 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-image-2.6.18-3-686
 linux-image-2.6-686
E: Sub-process /usr/bin/dpkg returned an error code (1)
#

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-2-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages linux-image-2.6.18-3-686 depends on:
ii  coreutils 5.97-5.2   The GNU core utilities
ii  debconf [debconf-2.0] 1.5.9  Debian configuration management sy
ii  module-init-tools 3.3-pre3-1 tools for managing Linux kernel mo
ii  yaird [linux-initramfs-tool]  0.0.12-18  Yet Another mkInitRD

Versions of packages linux-image-2.6.18-3-686 recommends:
pn  libc6-i686 (no description available)

-- debconf information:
  linux-image-2.6.18-3-686/postinst/bootloader-error-2.6.18-3-686:
  linux-image-2.6.18-3-686/postinst/old-dir-initrd-link-2.6.18-3-686: true
  linux-image-2.6.18-3-686/postinst/kimage-is-a-directory:
  linux-image-2.6.18-3-686/postinst/old-system-map-link-2.6.18-3-686: true
  linux-image-2.6.18-3-686/postinst/create-kimage-link-2.6.18-3-686: true
  linux-image-2.6.18-3-686/postinst/bootloader-test-error-2.6.18-3-686:
  linux-image-2.6.18-3-686/preinst/abort-overwrite-2.6.18-3-686:
  linux-image-2.6.18-3-686/postinst/old-initrd-link-2.6.18-3-686: true
  shared/kernel-image/really-run-bootloader: true
  linux-image-2.6.18-3-686/preinst/elilo-initrd-2.6.18-3-686: true
  linux-image-2.6.18-3-686/preinst/lilo-initrd-2.6.18-3-686: true
  linux-image-2.6.18-3-686/postinst/depmod-error-initrd-2.6.18-3-686: false
  linux-image-2.6.18-3-686/preinst/bootloader-initrd-2.6.18-3-686: true
  linux-image-2.6.18-3-686/prerm/removing-running-kernel-2.6.18-3-686: true
  linux-image-2.6.18-3-686/prerm/would-invalidate-boot-loader-2.6.18-3-686: true
  linux-image-2.6.18-3-686/preinst/abort-install-2.6.18-3-686:
  linux-image-2.6.18-3-686/preinst/overwriting-modules-2.6.18-3-686: true
  linux-image-2.6.18-3-686/preinst/initrd-2.6.18-3-686:
  linux-image-2.6.18-3-686/preinst/lilo-has-ramdisk:
  linux-image-2.6.18-3-686/preinst/already-running-this-2.6.18-3-686:
  linux-image-2.6.18-3-686/postinst/depmod-error-2.6.18-3-686: false
  linux-image-2.6.18-3-686/preinst/failed-to-move-modules-2.6.18-3-686:


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#378344: [powerpc,prep] On PReP boxes, root should be autodetected, since there is no bootloader.

[Sven Luther]

severity 378344 grave
# Upping severity, since this bug makes a PReP d-i install not being able to
# boot in the resulting system. Furthermore, this is a general regression from
# sarge and initrd-tools.
Thanks

Max, ...

When playing with initramfs-tools Motorola Powerstack PReP box, i noticed that
the machine didn't find the root device on reboot. I had chosen a LVM setup,
not sure if this influence the issue.

I had to give the root=/dev/powerstack/root argument by hand on the kernel
command line, which is less than optimal.

I booted into the system, and added ROOT=/dev/powerstack/root, but it would be
nice if this was autodetected, as it is done in both yaird and initrd-tools.

Furthermore, it would be nice if the ROOT= option would be documented, and an
empty entry would be present in the default config file, like the other
options. Does ROOT=probe also work in initramfs-tools, like it did for
initrd-tools ? 

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed: [powerpc,prep] On PReP boxes, root should be autodetected, since there is no bootloader.

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> severity 378344 grave
Bug#378344: initramfs-tools: Should be able to force root device for 
update-initramfs
Severity set to `grave' from `wishlist'

> # Upping severity, since this bug makes a PReP d-i install not being able to
> # boot in the resulting system. Furthermore, this is a general regression from
> # sarge and initrd-tools.
> Thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#397942: marked as done (linux-image-2.6.18-2-powerpc64: Please build windfarm_pm81 in the kernel, not as a module.)

[Debian Bug Tracking System]

Your message dated Sat, 2 Dec 2006 10:52:13 +0100
with message-id <[EMAIL PROTECTED]>
and subject line g5 imacs now silent?
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: linux-image-2.6.18-2-powerpc64
Version: 2.6.18-5
Severity: important

Dear Kernel team,

The code controlling fan speed on iMac G5 do not work correctly as a
module. As a consequence, the fans run full speed with the standard
kernel in Debian. This renders the mac unusable: the fans are _very_
loud when they are fullspeed.

The only solution I know is to build windfarm_pm81 directly in the
kernel. This is only doable for experienced users. I hope that you can
manage to bring a corrected kernel in Etch, otherwise I am affraid that
nobody except developpers will use Debian on iMacs G5.

Lastly, is is not impossible that all of this extends to the other
windfarm modules (91 and 112).

Have a nice day,

Charles Plessy, Wako, Saitama, Japan.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: powerpc (ppc64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16farm
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)

Versions of packages linux-image-2.6.18-2-powerpc64 depends on:
ii  module-init-tools 3.2.2-1tools for managing Linux kernel mo
ii  yaird [linux-initramfs-tool]  0.0.12-18  Yet Another mkInitRD

linux-image-2.6.18-2-powerpc64 recommends no packages.

-- debconf information:
  
linux-image-2.6.18-2-powerpc64/postinst/bootloader-test-error-2.6.18-2-powerpc64:
  
linux-image-2.6.18-2-powerpc64/postinst/old-system-map-link-2.6.18-2-powerpc64: 
true
  
linux-image-2.6.18-2-powerpc64/preinst/failed-to-move-modules-2.6.18-2-powerpc64:
  
linux-image-2.6.18-2-powerpc64/prerm/removing-running-kernel-2.6.18-2-powerpc64:
 true
  linux-image-2.6.18-2-powerpc64/postinst/bootloader-error-2.6.18-2-powerpc64:
  linux-image-2.6.18-2-powerpc64/preinst/abort-overwrite-2.6.18-2-powerpc64:
  
linux-image-2.6.18-2-powerpc64/postinst/create-kimage-link-2.6.18-2-powerpc64: 
true
  linux-image-2.6.18-2-powerpc64/preinst/initrd-2.6.18-2-powerpc64:
  
linux-image-2.6.18-2-powerpc64/preinst/overwriting-modules-2.6.18-2-powerpc64: 
true
  shared/kernel-image/really-run-bootloader: true
  linux-image-2.6.18-2-powerpc64/preinst/lilo-has-ramdisk:
  linux-image-2.6.18-2-powerpc64/preinst/lilo-initrd-2.6.18-2-powerpc64: true
  linux-image-2.6.18-2-powerpc64/preinst/abort-install-2.6.18-2-powerpc64:
  
linux-image-2.6.18-2-powerpc64/postinst/old-dir-initrd-link-2.6.18-2-powerpc64: 
true
  linux-image-2.6.18-2-powerpc64/preinst/elilo-initrd-2.6.18-2-powerpc64: true
  
linux-image-2.6.18-2-powerpc64/postinst/depmod-error-initrd-2.6.18-2-powerpc64: 
false
  linux-image-2.6.18-2-powerpc64/preinst/bootloader-initrd-2.6.18-2-powerpc64: 
true
  linux-image-2.6.18-2-powerpc64/postinst/kimage-is-a-directory:
  
linux-image-2.6.18-2-powerpc64/prerm/would-invalidate-boot-loader-2.6.18-2-powerpc64:
 true
  linux-image-2.6.18-2-powerpc64/postinst/depmod-error-2.6.18-2-powerpc64: false
  
linux-image-2.6.18-2-powerpc64/preinst/already-running-this-2.6.18-2-powerpc64:
  linux-image-2.6.18-2-powerpc64/postinst/old-initrd-link-2.6.18-2-powerpc64: 
true

--- End Message ---
--- Begin Message ---
Hi,

On Thursday 30 November 2006 18:06, Sven Luther wrote:
[#397942]
> > If this is correct, this bug can be closed. Is it correct?
> The bug should be retitled and reassigned to initramfs-tools, if it is not
> already.

It only makes sense to do this, if its confirmed, that initramfs-tools doesn't 
make sure the modules are loaded. I lack this confirmation atm.

Can someone confirm (or deny) that on a newly installed sid system, these 
modules are not loaded?

If so, I'm happy to open a bug against initramfs-tools, but I close this bug 
now, because the history of it is not interesting to read for the 
initramfs-tools maintainer anyway :)

> Holger: thanks for the work you are doing. Can you also comment on :
>   #397973: [powerpci/mac] partman-md appears to not write back the raid
> flag to partitions.
> Maybe it would be worth to raise the severity of this bug, but i can hardly
> do this, or i will be seen as whiner who ups the severity of his pet bugs,
> can i ask you to have a look at them ?

I think the severity is right, if it's not a bit too high already :) RAID is 
not working, that's bad, but not the end of the world. So certainly not 
higher than important (which it is), mayb

Re: 2.6.19, kernel-package problems and what are our plans for etch ...

[Sven Luther]

On Sat, Dec 02, 2006 at 10:37:01AM +0100, Andreas Barth wrote:
> * Sven Luther ([EMAIL PROTECTED]) [061201 20:30]:
> >   - What is stopping 2.6.18 to enter testing ? The PTS says "Should ignore,
> > but forced by vorlon", so does this mean it will enter testing today ?
> > What about the remaining (or new) RC bugs ? Some of them being open
> > against 2.6.17, so also present in testing.
> 
> If one of the release managers uses the force-hint, nothing from the
> first stage (RC-bugs, date, out-of-date, ...) will block the testing
> migration anymore.
> 
> However, in the second stage, installability is checked. According to
> todays output, these packages are broken by the transition:
> trying: linux-2.6
> skipped: linux-2.6 (15 <- 32)
> got: 115+0: i-115
> * i386: kernel-image-2.6-386, kernel-image-2.6-686, 
> kernel-image-2.6-686-smp, kernel-image-2.6-k7, kernel-image-2.6-k7-smp, 
> linux-headers-2.6-486, linux-headers-2.6-686, linux-headers-2.6-686-bigmem, 
> linux-headers-2.6-k7, linux-headers-2.6-vserver-686, 
> linux-headers-2.6-vserver-k7, linux-headers-2.6-xen-686, 
> linux-headers-2.6-xen-k7, linux-headers-2.6.18-3-486, 
> linux-headers-2.6.18-3-686, linux-headers-2.6.18-3-686-bigmem, 
> linux-headers-2.6.18-3-all, linux-headers-2.6.18-3-all-i386, 
> linux-headers-2.6.18-3-k7, linux-headers-2.6.18-3-vserver-686, 
> linux-headers-2.6.18-3-vserver-k7, linux-headers-2.6.18-3-xen-686, 
> linux-headers-2.6.18-3-xen-k7, linux-headers-2.6.18-3-xen-vserver-686, 
> linux-image-2.6-486, linux-image-2.6-686, linux-image-2.6-686-bigmem, 
> linux-image-2.6-686-smp, linux-image-2.6-k7, linux-image-2.6-k7-smp, 
> linux-image-2.6-vserver-686, linux-image-2.6-vserver-k7, 
> linux-image-2.6-xen-686, linux-image-2.6-xen-k7, linux-image-486, 
> linux-image-686, linux-image-686-bigmem, linux-image-k7, 
> linux-image-vserver-686, linux-image-vserver-k7, linux-image-xen-686, 
> linux-image-xen-k7, loop-aes-2.6-486, loop-aes-2.6-686, 
> loop-aes-2.6-686-bigmem, loop-aes-2.6-k7, loop-aes-2.6-vserver-686, 
> loop-aes-2.6-vserver-k7, loop-aes-2.6.17-2-486, loop-aes-2.6.17-2-686, 
> loop-aes-2.6.17-2-686-bigmem, loop-aes-2.6.17-2-k7, 
> loop-aes-2.6.17-2-vserver-686, loop-aes-2.6.17-2-vserver-k7, 
> nvidia-kernel-legacy-2.6-486, nvidia-kernel-legacy-2.6-686, 
> nvidia-kernel-legacy-2.6-686-smp, nvidia-kernel-legacy-2.6-k7, 
> nvidia-kernel-legacy-2.6-k7-smp, redhat-cluster-modules-2.6-486, 
> redhat-cluster-modules-2.6-686, redhat-cluster-modules-2.6-686-bigmem, 
> redhat-cluster-modules-2.6-k7, redhat-cluster-modules-2.6-vserver-686, 
> redhat-cluster-modules-2.6-vserver-k7, redhat-cluster-modules-2.6-xen-686, 
> redhat-cluster-modules-2.6-xen-k7, redhat-cluster-modules-2.6.17-2-486, 
> redhat-cluster-modules-2.6.17-2-686, 
> redhat-cluster-modules-2.6.17-2-686-bigmem, 
> redhat-cluster-modules-2.6.17-2-k7, 
> redhat-cluster-modules-2.6.17-2-vserver-686, 
> redhat-cluster-modules-2.6.17-2-vserver-k7, 
> redhat-cluster-modules-2.6.17-2-xen-686, 
> redhat-cluster-modules-2.6.17-2-xen-k7, spca5xx-modules-2.6-486, 
> spca5xx-modules-2.6-686, spca5xx-modules-2.6-686-bigmem, 
> spca5xx-modules-2.6-k7, spca5xx-modules-2.6-vserver-686, 
> spca5xx-modules-2.6-vserver-k7, spca5xx-modules-2.6-xen-686, 
> spca5xx-modules-2.6-xen-k7, spca5xx-modules-2.6.17-2-486, 
> spca5xx-modules-2.6.17-2-686, spca5xx-modules-2.6.17-2-686-bigmem, 
> spca5xx-modules-2.6.17-2-k7, spca5xx-modules-2.6.17-2-vserver-686, 
> spca5xx-modules-2.6.17-2-vserver-k7, spca5xx-modules-2.6.17-2-xen-686, 
> spca5xx-modules-2.6.17-2-xen-k7, squashfs-modules-2.6-486, 
> squashfs-modules-2.6-686, squashfs-modules-2.6-686-bigmem, 
> squashfs-modules-2.6-k7, squashfs-modules-2.6-vserver-686, 
> squashfs-modules-2.6-vserver-k7, squashfs-modules-2.6-xen-686, 
> squashfs-modules-2.6-xen-k7, squashfs-modules-2.6.17-2-486, 
> squashfs-modules-2.6.17-2-686, squashfs-modules-2.6.17-2-686-bigmem, 
> squashfs-modules-2.6.17-2-k7, squashfs-modules-2.6.17-2-vserver-686, 
> squashfs-modules-2.6.17-2-vserver-k7, squashfs-modules-2.6.17-2-xen-686, 
> squashfs-modules-2.6.17-2-xen-k7, unionfs-modules-2.6-486, 
> unionfs-modules-2.6-686, unionfs-modules-2.6-686-bigmem, 
> unionfs-modules-2.6-k7, unionfs-modules-2.6.17-2-486, 
> unionfs-modules-2.6.17-2-686, unionfs-modules-2.6.17-2-686-bigmem, 
> unionfs-modules-2.6.17-2-k7
> 
> I could use a force-hint on linux-modules-extra-2.6 as well, but as long
> as it is out-of-date on so many architectures, that won't improve the
> picture. And also, why do e.g. linux-image-2.6-vserver-k7 get
> uninstallable (hm, that could be a bug in britney though).

Ok, this is the linux-modules-extra-2.6 problem, which should be solved by
removing the module which is broken. not sure which one it was.

The -k7 issue, i don't know, can it be a flavour that was dropped or something 
? 

> >   - What are our plans for 2.6.19 ? Will we have it enter unstable, and
> > maintain the etch kernel through testing-proposed-updates ? I heard this
>

Re: 2.6.16.y -stable branch

[Frans Pop]

On Friday 01 December 2006 23:33, [EMAIL PROTECTED] wrote:
> I just noticed that Adrian Bunk's stable 2.6.16.y branch has been
> removed from Etch, and I think that sucks.

Not quite true: Adrian Bunk's tree has never been in Etch. The 
linux-2.6.16 package contained just the regular 2.6.16 kernel from 
linuxhq, not Adrian Bunk's tree. It was just uploaded as a separate 
package for technical reasons.

The main reason that Adrian Bunks tree is not available in Debian is that 
the kernel team is not interested in maintaining that version (or rather 
a separate version in general) and providing security support for it.

Cheers,
FJP


pgp6ldiU3PW0m.pgp
Description: PGP signature

Bug#401269: [powerpc] Apple G5 windfram based fan control modules not included or loaded in initramfs-tools generated ramdisks.

[Sven Luther]

Package: initramfs-tools
Severity: Important

On Sat, Dec 02, 2006 at 05:45:52PM +0900, Charles Plessy wrote:
> Le Thu, Nov 30, 2006 at 04:12:56PM +0100, Holger Levsen a écrit :
> > 
> > On Thursday 30 November 2006 12:20, Charles Plessy wrote:
> > 
> > > On the other hand, I recommend to test wether they also stay silent on
> > > the installed system as well.
> > 
> > Could you do this? 
> 
> 
> Hi,
> 
> The problem with the fan control is solved for the installer, but
> /etc/modules does not contain the necessary entries to start the fan
> control at boot time on the installed system.

Hi Charles, the problem is not with /etc/modules, but with initramfs-tools.

Mmm, i think i cannot find this bug, so opening a new one with this message.

Max, can you add somethign to initramfs-tools, as we discussed numerous times,
to load the fan control modules ? At worst, you can load the same modules as
is done in d-i.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.19, kernel-package problems and what are our plans for etch ...

[Andreas Barth]

* Sven Luther ([EMAIL PROTECTED]) [061201 20:30]:
>   - What is stopping 2.6.18 to enter testing ? The PTS says "Should ignore,
> but forced by vorlon", so does this mean it will enter testing today ?
> What about the remaining (or new) RC bugs ? Some of them being open
> against 2.6.17, so also present in testing.

If one of the release managers uses the force-hint, nothing from the
first stage (RC-bugs, date, out-of-date, ...) will block the testing
migration anymore.

However, in the second stage, installability is checked. According to
todays output, these packages are broken by the transition:
trying: linux-2.6
skipped: linux-2.6 (15 <- 32)
got: 115+0: i-115
* i386: kernel-image-2.6-386, kernel-image-2.6-686, 
kernel-image-2.6-686-smp, kernel-image-2.6-k7, kernel-image-2.6-k7-smp, 
linux-headers-2.6-486, linux-headers-2.6-686, linux-headers-2.6-686-bigmem, 
linux-headers-2.6-k7, linux-headers-2.6-vserver-686, 
linux-headers-2.6-vserver-k7, linux-headers-2.6-xen-686, 
linux-headers-2.6-xen-k7, linux-headers-2.6.18-3-486, 
linux-headers-2.6.18-3-686, linux-headers-2.6.18-3-686-bigmem, 
linux-headers-2.6.18-3-all, linux-headers-2.6.18-3-all-i386, 
linux-headers-2.6.18-3-k7, linux-headers-2.6.18-3-vserver-686, 
linux-headers-2.6.18-3-vserver-k7, linux-headers-2.6.18-3-xen-686, 
linux-headers-2.6.18-3-xen-k7, linux-headers-2.6.18-3-xen-vserver-686, 
linux-image-2.6-486, linux-image-2.6-686, linux-image-2.6-686-bigmem, 
linux-image-2.6-686-smp, linux-image-2.6-k7, linux-image-2.6-k7-smp, 
linux-image-2.6-vserver-686, linux-image-2.6-vserver-k7, 
linux-image-2.6-xen-686, linux-image-2.6-xen-k7, linux-image-486, 
linux-image-686, linux-image-686-bigmem, linux-image-k7, 
linux-image-vserver-686, linux-image-vserver-k7, linux-image-xen-686, 
linux-image-xen-k7, loop-aes-2.6-486, loop-aes-2.6-686, 
loop-aes-2.6-686-bigmem, loop-aes-2.6-k7, loop-aes-2.6-vserver-686, 
loop-aes-2.6-vserver-k7, loop-aes-2.6.17-2-486, loop-aes-2.6.17-2-686, 
loop-aes-2.6.17-2-686-bigmem, loop-aes-2.6.17-2-k7, 
loop-aes-2.6.17-2-vserver-686, loop-aes-2.6.17-2-vserver-k7, 
nvidia-kernel-legacy-2.6-486, nvidia-kernel-legacy-2.6-686, 
nvidia-kernel-legacy-2.6-686-smp, nvidia-kernel-legacy-2.6-k7, 
nvidia-kernel-legacy-2.6-k7-smp, redhat-cluster-modules-2.6-486, 
redhat-cluster-modules-2.6-686, redhat-cluster-modules-2.6-686-bigmem, 
redhat-cluster-modules-2.6-k7, redhat-cluster-modules-2.6-vserver-686, 
redhat-cluster-modules-2.6-vserver-k7, redhat-cluster-modules-2.6-xen-686, 
redhat-cluster-modules-2.6-xen-k7, redhat-cluster-modules-2.6.17-2-486, 
redhat-cluster-modules-2.6.17-2-686, 
redhat-cluster-modules-2.6.17-2-686-bigmem, redhat-cluster-modules-2.6.17-2-k7, 
redhat-cluster-modules-2.6.17-2-vserver-686, 
redhat-cluster-modules-2.6.17-2-vserver-k7, 
redhat-cluster-modules-2.6.17-2-xen-686, 
redhat-cluster-modules-2.6.17-2-xen-k7, spca5xx-modules-2.6-486, 
spca5xx-modules-2.6-686, spca5xx-modules-2.6-686-bigmem, 
spca5xx-modules-2.6-k7, spca5xx-modules-2.6-vserver-686, 
spca5xx-modules-2.6-vserver-k7, spca5xx-modules-2.6-xen-686, 
spca5xx-modules-2.6-xen-k7, spca5xx-modules-2.6.17-2-486, 
spca5xx-modules-2.6.17-2-686, spca5xx-modules-2.6.17-2-686-bigmem, 
spca5xx-modules-2.6.17-2-k7, spca5xx-modules-2.6.17-2-vserver-686, 
spca5xx-modules-2.6.17-2-vserver-k7, spca5xx-modules-2.6.17-2-xen-686, 
spca5xx-modules-2.6.17-2-xen-k7, squashfs-modules-2.6-486, 
squashfs-modules-2.6-686, squashfs-modules-2.6-686-bigmem, 
squashfs-modules-2.6-k7, squashfs-modules-2.6-vserver-686, 
squashfs-modules-2.6-vserver-k7, squashfs-modules-2.6-xen-686, 
squashfs-modules-2.6-xen-k7, squashfs-modules-2.6.17-2-486, 
squashfs-modules-2.6.17-2-686, squashfs-modules-2.6.17-2-686-bigmem, 
squashfs-modules-2.6.17-2-k7, squashfs-modules-2.6.17-2-vserver-686, 
squashfs-modules-2.6.17-2-vserver-k7, squashfs-modules-2.6.17-2-xen-686, 
squashfs-modules-2.6.17-2-xen-k7, unionfs-modules-2.6-486, 
unionfs-modules-2.6-686, unionfs-modules-2.6-686-bigmem, 
unionfs-modules-2.6-k7, unionfs-modules-2.6.17-2-486, 
unionfs-modules-2.6.17-2-686, unionfs-modules-2.6.17-2-686-bigmem, 
unionfs-modules-2.6.17-2-k7

I could use a force-hint on linux-modules-extra-2.6 as well, but as long
as it is out-of-date on so many architectures, that won't improve the
picture. And also, why do e.g. linux-image-2.6-vserver-k7 get
uninstallable (hm, that could be a bug in britney though).


>   - What are our plans for 2.6.19 ? Will we have it enter unstable, and
> maintain the etch kernel through testing-proposed-updates ? I heard this
> mentioned some time back. Will we fork a linux-2.6.19 package in unstable
> ? Will we keep 2.6.19 in experimental for now ? 

I hope you can keep 2.6.19 in experimental for now - it doesn't take so
long to release Etch anymore.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/

Processed: Re: Bug#400488: no fans after S3 sleep on many laptops

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> severity 400488 important
Bug#400488: no fans after S3 sleep on many laptops
Severity set to `important' from `grave'

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#400488: no fans after S3 sleep on many laptops

[Bastian Blank]

severity 400488 important
thanks

On Sun, Nov 26, 2006 at 03:26:32PM +0100, Bas Zoetekouw wrote:
> With the kernel from linux-image-2.6.18-2-686, fans for my laptop
> (HP nc6120) don't work anymore after an S3 suspend/resume cycle.  This
> causes the system to spontaneously shutdown under load causing data
> loss (or posibly it might even break the hardware), ergo the grave
> severity.

It does not fail for everyone, so grave is not appropriate.

> This issue is known by kernel upstream [1], and is at least partly
> fixed in 2.6.19-rc4.  I've been using the patches of [1] on my Ubuntu
> install on this same laptop (just switched it over to debian
> yesterday) for weeks, and they fixed the problem for me.

There is no commit in the linus tree. The comments also said something
about acpi-test.

Bastian

-- 
Beam me up, Scotty!


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#400544: marked as done (Fails to install properly on Sarge)

[Debian Bug Tracking System]

Your message dated Sat, 2 Dec 2006 09:16:42 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Bug#400544: Fails to install properly on Sarge
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: linux-image-2.6.18-3-vserver-k7
Version: 2.6.18-6
Severity: important

Setting up linux-image-2.6.18-3-vserver-k7 (2.6.18-6) ...

 Hmm. The package shipped with a symbolic link
 /lib/modules/2.6.18-3-vserver-k7/source
 However, I can not read the target: No such file or directory
 Therefore, I am deleting /lib/modules/2.6.18-3-vserver-k7/source

Running depmod.
Finding valid ramdisk creators.
Using mkinitrd.yaird to build the ramdisk.
yaird warning: consider upgrading to mdadm 2.2 or newer to support
changes in device boot ordering
readlink: invalid option -- m
Try `readlink --help' for more information.
readlink: invalid option -- m
Try `readlink --help' for more information.
readlink: invalid option -- m
Try `readlink --help' for more information.
readlink: invalid option -- m
Try `readlink --help' for more information.


Using yaird 0.0.12-18

--- End Message ---
--- Begin Message ---
Version: 2.6.18-6

On Sun, Nov 26, 2006 at 06:47:19PM -0600, Adam Majer wrote:
> readlink: invalid option -- m
> Try `readlink --help' for more information.

Fixed in 2.6.18-6.

-- 
We do not colonize.  We conquer.  We rule.  There is no other way for us.
-- Rojan, "By Any Other Name", stardate 4657.5
--- End Message ---

Bug#401035: linux-image-2.6-686: errors with hard disk ST340823A

[Bastian Blank]

On Fri, Dec 01, 2006 at 02:48:08PM +0100, [EMAIL PROTECTED] wrote:
> > On Thu, Nov 30, 2006 at 01:59:30PM +0100, Ramon Sanchez wrote:
> >> This is the error, they appears a lot of times:
> > This error looks like broken hardware, not something software can fix.
> The error doesn't appear in 2.6.8 and 2.4.27, and the error appears in
> many computers that have a ST340823A disk with a modern kernel, so I think
> that it is not a hardware error.

As it does not happen with other disks and the kernel don't specialcase
disk types, it is rather likely a bug in this disk type. Is the
mentioned sector within the sector count of the disk?

Bastian

-- 
She won' go Warp 7, Cap'n!  The batteries are dead!


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]