Bug#441442: [Spsc-sysadmin] Bug#441442: linux-headers-2.6.18-5: does not update menu.lst

[Andreas Laesser]

Sorry, this was a mistake, it's not the linux-headers-package, it was the 
linux-image-2.6.18-5 package. 
If there is a new kernel installed, respectively a update from 2.6.18-4 to 
2.6.18-5, the menu.lst entry in grub wont be updated. 

best regards Andreas

On Monday 10 September 2007 12:13, you wrote:
> On Sun, 09 Sep 2007, Andreas Laesser wrote:
> > Package: linux-headers-2.6.18-5
> > Version: 2.6.18.dfsg.1-13etch2
> > Severity: normal
> >
> >
> > If you have installed a transmition-package like
> > linux-image-2.6.18-686-smp it wont update your menu.lst. You have
> > manually execute update-grub.
>
> i don't get you at all.
>
> what does a headers package have to do with grub?
>
> best regards

-- 
=
_
   / ___/Andreas Laesser
  / //_// // Signal Proc.& Speech Communication Lab.
   __/ /___/ / __Graz University of Technology
 /___////__  Inffeldgasse 12 | A-8010 Graz | Austria

http://spsc.tugraz.at   Tel: +43 (0)316 873 4439
=



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

Bug#304721: US $ 69.95 Pice for 100mg x 10 pills

[Miguel Fountain]

buy now 100mg x 90 pills $159.95
http://afterstick.com




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

Bug#415474: mkinitramfs fails with monolithic kernels

[Damien Desmarets]

I had the same problem and I have resolved it by patching
/usr/share/kernel-package/pkg/image/preinst :

374,376d373
< else {
<   mkdir("$modules_base/$version", 0755);
< }

I don't know if this is clean but it's better for the portability of my
.deb kernel.
With this patch I can install it anywhere without modification on the
differents server where I install the kernel package. If I had patched
the mkinitramfs I will have to patch all my servers ... impossible !

So I think it's a better solution to patch kernel-package than
initramfs-tools for the moment until the initramfs-tools' maintainer
fix it in a new release (please).

Regards,
Damien Desmarets




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

Processed: Re: Bug#440720: [SPARC]: non-SMP kernel fail on SunFIres with >= 2 CPUs

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 440720 linux-2.6
Bug#440720: [SPARC]: non-SMP kernel fail on SunFIres with >= 2 CPUs
Bug reassigned from package `debian-installer' to `linux-2.6'.

> found 440720 2.6.21-6
Bug#440720: [SPARC]: non-SMP kernel fail on SunFIres with >= 2 CPUs
Bug marked as found in version 2.6.21-6.

> 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#415474: mkinitramfs fails with monolithic kernels

[maximilian attems]

cher damien,

On Thu, Sep 13, 2007 at 04:59:30PM +0200, Damien Desmarets wrote:
> 
> So I think it's a better solution to patch kernel-package than
> initramfs-tools for the moment until the initramfs-tools' maintainer
> fix it in a new release (please).

yes it's on my TODO, currently it is a time issue,
if you can provide me a user account on a box with monolithic kernel
i'd be happy to fix it for next release.

best regards

-- 
maks



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

Bug#441442: [Spsc-sysadmin] Bug#441442: linux-headers-2.6.18-5: does not update menu.lst

[dann frazier]

On Wed, Sep 12, 2007 at 10:40:18PM +0200, Andreas Laesser wrote:
> Sorry, this was a mistake, it's not the linux-headers-package, it was the 
> linux-image-2.6.18-5 package. 
> If there is a new kernel installed, respectively a update from 2.6.18-4 to 
> 2.6.18-5, the menu.lst entry in grub wont be updated. 

linux-image-2.6.18-5 doesn't call update-grub directly - rather it
relies on hooks defined in /etc/kernel-img.conf. Are those hooks
missing? Are those hooks there and failing to run? Have you modified
your menu.lst file such that update-grub is unable to insert new
definitions?

-- 
dann frazier




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

Bug#440720: [SPARC]: non-SMP kernel fail on SunFIres with >= 2 CPUs

[Bernd Zeimetz]

Hi,

> Looks like we need to discuss the available options for this
> problem. Other issue is to know if current snapshots of 2.6.23 does
> work or not on this hardware.
> 
> Bernd, can you test lastest 2.6.23 snapshot and see if it works? Check
> at http://wiki.debian.org/DebianKernel for more information where to
> find them.

I've installed the machine using a 2.6.23-rc5 _smp_ kernel, all older
non-smp kernels failed to boot, and as Ihad to build my own installer
and kernel anyway I've decided to use an smp version.

As it takes a _long_ time to reboot a machine with a "crashed" CPU
(which was the result of all non-SMP kernel tests so far), and the
machine should be in production yet, I would like to avoid to try a
non-smp kernel on this machine.
I've looked trough the sparc64 commits (about 80) between 2.6.22 and
2.6.23-rc6 and there was non which looked like it would address such an
issue. If you can point me to such a change I'll give a non-smp kernel a
try.
Also I'm pretty sure that non-smp kernels just don't work on the
machine. As far as I understand the way those machines work is that at
least two CPUs have to be in an operating state as they share one CPU
Data switch (if you have a look into such a machine you see that always
2 CPUs + their memory are sitting in a CPU bay, and as far as I know you
can't run the system with an odd number of CPUs.
All processors share the same pysical memory address space and use -
depending on the number of CPUs - different cache coherence protocols,
so as far as I understand it such a system can't work at all without
having all CPUs properly initialized. But probably somebody with a
better knowledge about this architecture can give us some insight on
that, therefore I'm forwarding the message to debian-sparc, too.

Probably interesting to read for you:
http://www.sun.com/processors/manuals/USIIIv2.pdf
http://docs-pdf.sun.com/806-6592-11/806-6592-11.pdf



Cheers,

Bernd

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 



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

Bug#440720: [SPARC]: non-SMP kernel fail on SunFIres with >= 2 CPUs

[Otavio Salvador]

Bernd Zeimetz <[EMAIL PROTECTED]> writes:

> Hi,
>
>> Looks like we need to discuss the available options for this
>> problem. Other issue is to know if current snapshots of 2.6.23 does
>> work or not on this hardware.
>> 
>> Bernd, can you test lastest 2.6.23 snapshot and see if it works? Check
>> at http://wiki.debian.org/DebianKernel for more information where to
>> find them.
>
> I've installed the machine using a 2.6.23-rc5 _smp_ kernel, all older
> non-smp kernels failed to boot, and as Ihad to build my own installer
> and kernel anyway I've decided to use an smp version.

Have you tested it witn a non-smp kernel?

> As it takes a _long_ time to reboot a machine with a "crashed" CPU
> (which was the result of all non-SMP kernel tests so far), and the
> machine should be in production yet, I would like to avoid to try a
> non-smp kernel on this machine.

Right. It makes difficult to us to know if has or not been fixed since
your last try.

> I've looked trough the sparc64 commits (about 80) between 2.6.22 and
> 2.6.23-rc6 and there was non which looked like it would address such an
> issue. If you can point me to such a change I'll give a non-smp kernel a
> try.

Right :(

> Also I'm pretty sure that non-smp kernels just don't work on the
> machine. As far as I understand the way those machines work is that at
> least two CPUs have to be in an operating state as they share one CPU
> Data switch (if you have a look into such a machine you see that always
> 2 CPUs + their memory are sitting in a CPU bay, and as far as I know you
> can't run the system with an odd number of CPUs.
> All processors share the same pysical memory address space and use -
> depending on the number of CPUs - different cache coherence protocols,
> so as far as I understand it such a system can't work at all without
> having all CPUs properly initialized. But probably somebody with a
> better knowledge about this architecture can give us some insight on
> that, therefore I'm forwarding the message to debian-sparc, too.
>
> Probably interesting to read for you:
> http://www.sun.com/processors/manuals/USIIIv2.pdf
> http://docs-pdf.sun.com/806-6592-11/806-6592-11.pdf

If that's true then we might have two options:

 - add a subarch for sparc with the needed kernel changes for it;
 - change default kernel on installer to be smp;

What other think about that? (added debian-boot on cc due this)

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
-
"Microsoft sells you Windows ... Linux gives
 you the whole house."



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

Bug#440720: [SPARC]: non-SMP kernel fail on SunFIres with >= 2 CPUs

[Bernd Zeimetz]

Hi,


>>> Bernd, can you test lastest 2.6.23 snapshot and see if it works? Check
>>> at http://wiki.debian.org/DebianKernel for more information where to
>>> find them.
>> I've installed the machine using a 2.6.23-rc5 _smp_ kernel, all older
>> non-smp kernels failed to boot, and as Ihad to build my own installer
>> and kernel anyway I've decided to use an smp version.
> 
> Have you tested it witn a non-smp kernel?

Well, I've tried to boot a non-SMP kernel (2.6.23-rc5) a few minutes ago
(... and I had to power-cycle it, it is running selftests now), and
the machine froze after

Remapping the kernel... done.
OF stdout device is: /[EMAIL PROTECTED],70/[EMAIL PROTECTED]/[EMAIL 
PROTECTED],40:a
Booting Linux...


Which is just the same state as described in

http://lists.debian.org/debian-sparc/2007/09/msg00045.html
which talks about a SunFire v240 which uses 2 US III CPus. Please note
that the last non-SMP kernels seem (as in: according to goole) to boot
well on the SunFire v210, which is a 1 HE machine with ONE cpu only.

> 
>> As it takes a _long_ time to reboot a machine with a "crashed" CPU
>> (which was the result of all non-SMP kernel tests so far), and the
>> machine should be in production yet, I would like to avoid to try a
>> non-smp kernel on this machine.
> 
> Right. It makes difficult to us to know if has or not been fixed since
> your last try.

As I said before, I doubt that this fixable - you have to use a SMP kernel.

>  - add a subarch for sparc with the needed kernel changes for it;

As this seems to affect all machines running more than one US III CPU
this would probably a good thing. Not only that those machines start to
be avaiable at ebay for not-s-much-money and are still sold, and the
Ultrasparc IV should have the same features (issues in this case), this
would make more then sense to allow to run Debian on serious sparc Hardware.

>  - change default kernel on installer to be smp;

I've given that idea a try and tried to boot a SMP kernel on a single
cpu (US IIi) machine and the machine froze in the same state as the v880
above. So I guess it's not possible to run SMP kernels on all sparc
machines.


Cheers,

Bernd

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 



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

Bug#440720: [SPARC]: non-SMP kernel fail on SunFIres with >= 2 CPUs

[Richard Mortimer]

On Thu, 2007-09-13 at 22:30 +0200, Bernd Zeimetz wrote:
> Well, I've tried to boot a non-SMP kernel (2.6.23-rc5) a few minutes ago
> (... and I had to power-cycle it, it is running selftests now), and
> the machine froze after
> 
> Remapping the kernel... done.
> OF stdout device is: /[EMAIL PROTECTED],70/[EMAIL PROTECTED]/[EMAIL 
> PROTECTED],40:a
> Booting Linux...

Try adding   -p   to the silo commandline. That will direct all early
log output direct to the console and you should see the kernel panic
that is undoubtedly happening before the kernel is fully initialised.

Richard

-- 
Richard Mortimer <[EMAIL PROTECTED]>




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

Bug#440720: [SPARC]: non-SMP kernel fail on SunFIres with >= 2 CPUs

[Bernd Zeimetz]

Richard Mortimer wrote:
> On Thu, 2007-09-13 at 22:30 +0200, Bernd Zeimetz wrote:
>> Well, I've tried to boot a non-SMP kernel (2.6.23-rc5) a few minutes ago
>> (... and I had to power-cycle it, it is running selftests now), and
>> the machine froze after
>>
>> Remapping the kernel... done.
>> OF stdout device is: /[EMAIL PROTECTED],70/[EMAIL PROTECTED]/[EMAIL 
>> PROTECTED],40:a
>> Booting Linux...
> 
> Try adding   -p   to the silo commandline. That will direct all early
> log output direct to the console and you should see the kernel panic
> that is undoubtedly happening before the kernel is fully initialised.

Here is the interesting part:

checking if image is initramfs... it is
Freeing initrd memory: 6214k freed
Mini RTC Driver
/[EMAIL PROTECTED],40: US3 memory controller at 0440 [ACTIVE]
/[EMAIL PROTECTED],40: US3 memory controller at 04c0 [ACTIVE]
/[EMAIL PROTECTED],40: US3 memory controller at 04000140 [ACTIVE]
ERROR(0): Cheetah error trap taken afsr[1000] 
afar[040001c0] TL1(0)
ERROR(0): TPC[4377f4] TNPC[4377f8] O7[4379d0] TSTATE[80001606]
ERROR(0): TPC
ERROR(0): M_SYND(0),  E_SYND(0)
ERROR(0): Highest priority error (1000) "Unmapped error from system 
bus"
ERROR(0): D-cache idx[0] tag[] utag[] 
stag[]
ERROR(0): D-cache data0[] data1[] 
data2[] data3[]
ERROR(0): I-cache idx[0] tag[] utag[] 
stag[] u[] l[]
ERROR(0): I-cache INSN0[] INSN1[] 
INSN2[] INSN3[]
ERROR(0): I-cache INSN4[] INSN5[] 
INSN6[] INSN7[]
ERROR(0): E-cache idx[0] tag[]
ERROR(0): E-cache data0[] data1[] 
data2[] data3[]
Kernel panic - not syncing: Irrecoverable deferred error trap.


If you want the full output, please let me know. THere was nothing unusual so 
far, though.


Bernd

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 



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

Bug#442187: linux-image-2.6.22-2-686: 2.6.22-2-686 fails to discover lvm logical volumes; 2.6.22-1-686 works ok

[Tomasz Melcer]

Package: linux-image-2.6.22-2-686
Version: 2.6.22-4
Severity: important

linux-image-2.6.22-2-686 fails to discover (and therefore mount) logical
volumes of lvm2 storage. I have got root filesystem inside lvm,
therefore I cannot boot into system using that kernel. The last screen
of logs contains:

#v+
VFS: Cannot open root device "mapper/vg-root" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the available partitions:
Kernel panic - not syncing: VFS: Unable to mount fs on unknown-block(0,0)
#v-

The rest of the screen is filled with data about keyboards, mices...;
nothing related to harddrive/ata driver. Besides, I cannot see earlier
messages (well, panic is panic).

linux-image-2.6.22-1-686 works correctly, I am able to mount root fs and
proceed with system boot.

I don't know how to provide further information. If there is any method
(excluding making root fs outside lvm, i cannot do that on this machine),
i can try to provide more data.

The machine is Compaq TC1000 laptop. IDE interface is:
:00:07.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)

-- Package-specific info:

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-1-686 (SMP w/1 CPU core)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages linux-image-2.6.22-2-686 depends on:
ii  initramfs-tools [linux-initr 0.91tools for generating an initramfs
ii  module-init-tools3.3-pre11-4 tools for managing Linux kernel mo

Versions of packages linux-image-2.6.22-2-686 recommends:
ii  libc6-i6862.6.1-2GNU C Library: Shared libraries [i

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



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

Bug#442190: linux-image-2.6.18-5-sparc64-smp: iptables -j MARK --set-mark causes "MARK target: invalid size 16 != 8"

[Hunter Blanks]

Package: linux-image-2.6.18-5-sparc64-smp
Version: 2.6.18.dfsg.1-13etch2
Severity: important


This bug occurs while using the standard iptables (version 1.3.6.0debian1-5), 
and may be referenced both at

http://www.mail-archive.com/[EMAIL PROTECTED]/msg01213.html

and, perhaps also at:

http://lists.netfilter.org/pipermail/netfilter-devel/2007-June/028369.html

It can be fixed, allegedly, either by upgrading to 2.6.21 or by compiling 
iptables in 64 bit userland, so I have filing
the bug under both packages.


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: sparc (sparc64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-sparc64-smp
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages linux-image-2.6.18-5-sparc64-smp depends on:
ii  coreutils 5.97-5.3   The GNU core utilities
ii  debconf [debconf-2.0] 1.5.11 Debian configuration management sy
ii  initramfs-tools [linux-initra 0.85h  tools for generating an initramfs
ii  module-init-tools 3.3-pre4-2 tools for managing Linux kernel mo

linux-image-2.6.18-5-sparc64-smp recommends no packages.

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



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

Re: Debian's Linux kernel continues to regress on freedom

[Holger Levsen]

Hi,

On Wednesday 12 September 2007 15:37, Robert Millan wrote:
> > There isn't any patch that should be required here.  There is already a
> > script in the kernel team repo to be used for pruning non-free firmware
> > from the tarball, and it appears that whoever produced the initial
> > uploads of 2.6.21 and 2.6.22 for Debian omitted this step.
> Why not running this script in debian/rules, causing builds to abort when
> the non-free files are still present?

Seems like a good idea, except that the script will also fail if upstream 
removes something - I don't know how often this happens though.

I guess this info should be added to some bug, so it does eventually 
happen ;-) 


regards,
Holger


pgpCRBTQhUsgi.pgp
Description: PGP signature