Bug#382602: Breaks Root-on-RAID when /boot != /root)

[maximilian attems]

On Sat, Aug 12, 2006 at 02:43:00AM -0400, Daniel Dickinson wrote:
> 
> Upgrading initramfs (when package in testing changed) resulted in
> non-booting system.  I managed to fix things by adding a script to
> init-premount that activates (mdam -assemble's) the raid5 device
> (/dev/md1) that contains my root filessystem.  This probably won't
> occur on systems where /boot is on the root filesystem because (AIUI)
> the boot raid device is automagically activated.
> 
> The reason that the root device isn't activated by mdadm in local-top
> is that it is trying to use /etc/mdadm.conf which it doesn't find.
> (I don't know if /etc/mdadm/mdadm.conf is what it's trying to use, or
> if it is supposed to copy that file to /etc in the initramfs file).

urgs yes there is a typo in scripts/local-top/mdraid,
needs to use /conf/mdadm.conf that is created by mkinitramfs,
instead of /etc/mdadm.conf.

please post which mdadm version you are using?
dpkg -l mdadm
also please post the output of 
mdadm --examine --scan


 
> The script I added is (less the  tags):

looks sane and nice quick workaround.
 
thanks for report!

--
maks


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

Bug#381844: itramfs-tools doesn't produce working ramdisk on amd64 with MODULES=list

[maximilian attems]

On Fri, 11 Aug 2006, Ivan Sergio Borgonovo wrote:

> > yes please use MODULES=most
> 
> I did it, both initrd didn't work.
> The "most" one was twice as large as the "list" ones (the working and
> the not working one), but this didn't help it to work.
> Summary:
> 
> a) 1 "list" initrd generated before last initramfs-tools that is *working* 
> ~300Kb
> 
> b) 1 "list" initrd generated after last initramfs-tools that is *not working* 
> ~360Kb
> 
> c) 1 "most" initrd generated after last initramfs-tools that is *not working* 
> ~600Kb

i'd like to see that initrd, please put it up somewhere on the web,
or send it me privately.
 
> a) and b) were generated with the *same* /etc/initramfs-tools/modules

hmm you didn't share yet the content of /etc/initramfs-tools/modules ??
 
> BTW I used this syntax:
> mkinitramfs -o /root/initrd.img-2.6.17-1-amd64-k8-smp-most
> -r /dev/md3 2.6.17-1-amd64-k8-smp

the root hardcoding shouldn't be necassary, checkout to pass the
right grub root param.

recommended way is:
update-initramfs -u -k 2.6.17-1-amd64-k8-smp

-- 
maks


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

Bug#381315: initramfs-tools: install /usr/share/initramfs-tools/conf.d/* into initramfs image

[maximilian attems]

tags 381315 pending
stop

On Thu, 03 Aug 2006, Vagrant Cascadian wrote:

> Package: initramfs-tools
> Version: 0.73
> Severity: normal
> Tags: patch
> 
> it seems that initramfs-tools includes the
> /usr/share/initramfs-tools/conf.d snippets at build time, but does not
> install them into the initramfs image.

i agree that your patch makes a lot of sense from consistency reasons!

but i thought of /usr/share/initramfs-tools/conf.d, to change the
mkinitramfs building and not the boot, behaviour. like overriding
BUSYBOX=no in /etc/initramfs-tools/initramfs.conf due to
/usr/share/initramfs-tools/conf.d/lvm2 with BUSYBOX=yes

btw a quick scan shows that the conf.d usage is not yet documented,
but you are right the intention was for boottime RESUME setting.

so i'll apply your patch and will think of another location for
the mkinitramfs build tuning.
 
> attached patch is revision 198 from:
> 

thanks.

-- 
maks


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

Bug#381677: initramfs-tools: Temporary files and initramfs world-readable

[maximilian attems]

On Sun, 06 Aug 2006, Lionel Elie Mamane wrote:

> The generated initramfs is world-readable (as well as the temporary
> files); this leaks cryptographic keys (in password-protected form) to
> all users on the system when the root fs is encrypted (because these
> keys then get copied to the initramfs, at least in the loop-aes
> case). See bug #378488 for a discussion of this in the context of
> loop-aes.

yaird installs initrd.img with 600 without giving any further
reasons -> see #336454
no reply from maintainer since bug is filed.

 
> This patch fixes that. As making these files running user only
> readable does not, as far as I can see, hurt even when not strictly
> necessary, the patch just does it unconditionnaly.
> 
> 
> Please apply (or comment). Thanks.

i'd have waited for someone else to voice there concerns.
i like the initramfs-tools initrd.img to be debuggable as
user (quick check of their contents).

also loop-aes is quite a specific use case,
so i'm not in big favour of setting the umask in general
to the proposed value as in general there is no gpg key
in the initramfs.

-- 
maks


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

initramfs-tools_0.73d_amd64.changes ACCEPTED

[Debian Installer]

Accepted:
initramfs-tools_0.73d.dsc
  to pool/main/i/initramfs-tools/initramfs-tools_0.73d.dsc
initramfs-tools_0.73d.tar.gz
  to pool/main/i/initramfs-tools/initramfs-tools_0.73d.tar.gz
initramfs-tools_0.73d_all.deb
  to pool/main/i/initramfs-tools/initramfs-tools_0.73d_all.deb


Override entries for your package:
initramfs-tools_0.73d.dsc - source utils
initramfs-tools_0.73d_all.deb - optional utils

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


Thank you for your contribution to Debian.


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

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Jonas Smedegaard]

On Sat, 12 Aug 2006 08:40:44 +0200 Sven Luther wrote:

> So, if you like to be around with people with total lack of human
> decency, then you should accept when they are criticized for it.

And/or you should stop repeating yourself.

-- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm


pgpPd3wkOTVKE.pgp
Description: PGP signature

Processing of initramfs-tools_0.73d_amd64.changes

[Archive Administrator]

initramfs-tools_0.73d_amd64.changes uploaded successfully to localhost
along with the files:
  initramfs-tools_0.73d.dsc
  initramfs-tools_0.73d.tar.gz
  initramfs-tools_0.73d_all.deb

Greetings,

Your Debian queue daemon


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

Bug#382602: marked as done (Breaks Root-on-RAID when /boot != /root))

[Debian Bug Tracking System]

Your message dated Sat, 12 Aug 2006 04:02:08 -0700
with message-id <[EMAIL PROTECTED]>
and subject line Bug#382602: fixed in initramfs-tools 0.73d
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
Version: 0.73c
Severity: important


Upgrading initramfs (when package in testing changed) resulted in
non-booting system.  I managed to fix things by adding a script to
init-premount that activates (mdam -assemble's) the raid5 device
(/dev/md1) that contains my root filessystem.  This probably won't
occur on systems where /boot is on the root filesystem because (AIUI)
the boot raid device is automagically activated.

The reason that the root device isn't activated by mdadm in local-top
is that it is trying to use /etc/mdadm.conf which it doesn't find.
(I don't know if /etc/mdadm/mdadm.conf is what it's trying to use, or
if it is supposed to copy that file to /etc in the initramfs file).

The script I added is (less the  tags):


#!/bin/sh

PREREQ="udev"

prereqs()
{
echo "$PREREQ"
}

case $1 in
# get pre-requisites
prereqs)
prereqs
exit 0
;;
esac

# Assemble root RAID
mknod /dev/md1 b 9 1
mdadm --assemble -m 1 /dev/md1 /dev/hda2 /dev/hdb2 /dev/hdc2



-- Package-specific info:
-- /proc/cmdline
root=/dev/md1 ro 

-- /proc/filesystems
cramfs
ext3

-- lsmod
Module  Size  Used by
nfs   189068  2 
nfsd  200772  8 
exportfs5248  1 nfsd
lockd  54248  3 nfs,nfsd
nfs_acl 3328  2 nfs,nfsd
sunrpc133476  5 nfs,nfsd,lockd,nfs_acl
appletalk  31476  20 
ipv6  218912  18 
tcp_diag1664  0 
inet_diag  10056  2 tcp_diag
snd_pcm_oss44128  0 
snd_mixer_oss  15744  2 snd_pcm_oss
ide_generic 1216  0 [permanent]
mousedev   10496  1 
tsdev   7296  0 
i810_audio 31060  0 
ac97_codec 17100  1 i810_audio
evdev   8832  0 
shpchp 39424  0 
pci_hotplug24308  1 shpchp
snd_intel8x0   29532  1 
sis_agp 8196  1 
snd_ac97_codec 82848  1 snd_intel8x0
snd_ac97_bus2112  1 snd_ac97_codec
agpgart29296  1 sis_agp
snd_mpu401  7328  0 
snd_mpu401_uart 6656  1 snd_mpu401
snd_pcm74504  3 snd_pcm_oss,snd_intel8x0,snd_ac97_codec
snd_timer  20420  1 snd_pcm
snd_page_alloc  9864  2 snd_intel8x0,snd_pcm
snd_rawmidi22496  1 snd_mpu401_uart
snd_seq_device  8332  1 snd_rawmidi
snd46400  10 
snd_pcm_oss,snd_mixer_oss,snd_intel8x0,snd_ac97_codec,snd_mpu401,snd_mpu401_uart,snd_pcm,snd_timer,snd_rawmidi,snd_seq_device
soundcore   8736  3 i810_audio,snd
rtc11444  0 
pcspkr  3012  0 
psmouse34504  0 
serio_raw   6532  0 
analog  9888  0 
parport_pc 31728  0 
parport32008  1 parport_pc
floppy 55916  0 
gameport   13576  1 analog
ext3  116872  8 
jbd47316  1 ext3
mbcache 7684  1 ext3
dm_mirror  17460  0 
dm_snapshot15388  0 
ide_cd 35680  0 
cdrom  32240  1 ide_cd
ide_disk   14720  15 
usbhid 32416  1 
sis551312108  0 [permanent]
generic 4228  0 [permanent]
ide_core  111536  5 ide_generic,ide_cd,ide_disk,sis5513,generic
ehci_hcd   26952  0 
ohci_hcd   17348  0 
usbcore   36  5 usbhid,ehci_hcd,ohci_hcd
sis900 20992  0 
mii 5248  1 sis900
thermal13064  0 
processor  21760  1 thermal
fan 4548  0 
raid5  22272  3 
xor13960  1 raid5
raid1  19520  1 
md_mod 64596  6 raid5,raid1
dm_mod 48180  9 dm_mirror,dm_snapshot
sisfb 205012  1 


-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (200, 'testing'), (75, 'unstable'), (10, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.16-2-k7
Locale: LANG=en_CA, LC_CTYPE=en_CA (charmap=ISO-8859-1)

Versions of packages initramfs-tools depends on:
ii  busybox-cvs-static   

Bug#381315: marked as done (initramfs-tools: install /usr/share/initramfs-tools/conf.d/* into initramfs image)

[Debian Bug Tracking System]

Your message dated Sat, 12 Aug 2006 04:02:08 -0700
with message-id <[EMAIL PROTECTED]>
and subject line Bug#381315: fixed in initramfs-tools 0.73d
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
Version: 0.73
Severity: normal
Tags: patch

it seems that initramfs-tools includes the
/usr/share/initramfs-tools/conf.d snippets at build time, but does not
install them into the initramfs image.

attached patch is revision 198 from:

http://llama.freegeek.org/~vagrant/bzr-archives/initramfs-tools/vagrant-initramfs-tools

configuration files in /etc/initramfs-tools/conf.d will
override /usr/share/initramfs-tools/conf.d files of the same name.

live well,
  vagrant
=== modified file 'mkinitramfs'
--- mkinitramfs 
+++ mkinitramfs 
@@ -83,15 +83,14 @@
 
 . "${CONFDIR}/initramfs.conf"
 EXTRA_CONF=''
-for i in ${CONFDIR}/conf.d/*; do
+for i in /usr/share/initramfs-tools/conf.d/* ${CONFDIR}/conf.d/*; do
EXTRA_CONF="${EXTRA_CONF} $(basename $i | grep 
'^[a-z0-9][a-z0-9\._-]*$' | grep -v '\.dpkg-.*$')";
 done
 for i in ${EXTRA_CONF}; do
-   . ${CONFDIR}/conf.d/${i}
-done
-for i in /usr/share/initramfs-tools/conf.d/*; do
-   if [ -e $i ]; then
-   . ${i}
+   if [ -e  ${CONFDIR}/conf.d/${i} ]; then
+   . ${CONFDIR}/conf.d/${i}
+   elif [ -e  /usr/share/initramfs-tools/conf.d/${i} ]; then
+   . /usr/share/initramfs-tools/conf.d/${i}
fi
 done
 
@@ -204,7 +203,11 @@
 echo "DPKG_ARCH=${DPKG_ARCH}" > ${DESTDIR}/conf/arch.conf
 copy_exec "${CONFDIR}/initramfs.conf" /conf
 for i in ${EXTRA_CONF}; do
-   copy_exec "${CONFDIR}/conf.d/${i}" /conf/conf.d
+   if [ -e "${CONFDIR}/conf.d/${i}" /conf/conf.d ]; then
+   copy_exec "${CONFDIR}/conf.d/${i}" /conf/conf.d
+   elif [ -e "/usr/share/initramfs-tools/conf.d/${i}" ]; then
+   copy_exec "/usr/share/initramfs-tools/conf.d/${i}" /conf/conf.d
+   fi
 done
 echo "ROOT=${ROOT}" > ${DESTDIR}/conf/conf.d/root
 

--- End Message ---
--- Begin Message ---
Source: initramfs-tools
Source-Version: 0.73d

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.73d.dsc
  to pool/main/i/initramfs-tools/initramfs-tools_0.73d.dsc
initramfs-tools_0.73d.tar.gz
  to pool/main/i/initramfs-tools/initramfs-tools_0.73d.tar.gz
initramfs-tools_0.73d_all.deb
  to pool/main/i/initramfs-tools/initramfs-tools_0.73d_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, 12 Aug 2006 09:43:55 +0200
Source: initramfs-tools
Binary: initramfs-tools
Architecture: source all
Version: 0.73d
Distribution: unstable
Urgency: high
Maintainer: Debian kernel team 
Changed-By: maximilian attems <[EMAIL PROTECTED]>
Description: 
 initramfs-tools - tools for generating an initramfs
Closes: 381315 382602
Changes: 
 initramfs-tools (0.73d) unstable; urgency=high
 .
   * scripts/local-top/mdraid: Fix path of expected mdadm config file.
 Thanks Daniel Dickinson <[EMAIL PROTECTED]> for report. (closes: 382602)
 .
   * mkinitramfs: Treat /usr/share/initramfs-tools/conf.d config snippets as
 the configuration files in /etc/initramfs-tools/conf.d. A configuration
 file with the same name will override the first. (closes: 381315)
 Thanks Vagrant Cascadian <[EMAIL PROTECTED]> for the patch.
 .
   * mkinitramfs.8: Document conf.d existence.
 .
   * hooks/lvm: Really remove it, logic is in mkinitramfs.
 .
   * urgency high for the mdraid bug fix, rest is trivial.
Files: 
 ba5bf210ff825fe2b3eb5619404df320 625 utils optional initramfs-tools_0.73d.dsc
 3266cf0960af31d3c5fcab98dc70050d 46033 utils optional 
initramfs-tools_0.73d.tar.gz
 505d6ceb23bf79b54fa8022e6c87db33 51190 utils optional 
initramfs-tools_0.73d_all.deb

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

iD8DBQFE3bRW6n7So0GVSSARAjm5AJ460fzw

Bug#381677: initramfs-tools: Temporary files and initramfs world-readable

[Jonas Smedegaard]

On Sat, 12 Aug 2006 10:43:16 +0200 maximilian attems wrote:

> On Sun, 06 Aug 2006, Lionel Elie Mamane wrote:
> 
> > The generated initramfs is world-readable (as well as the temporary
> > files); this leaks cryptographic keys (in password-protected form)
> > to all users on the system when the root fs is encrypted (because
> > these keys then get copied to the initramfs, at least in the
> > loop-aes case). See bug #378488 for a discussion of this in the
> > context of loop-aes.
> 
> yaird installs initrd.img with 600 without giving any further
> reasons -> see #336454
> no reply from maintainer since bug is filed.

Acknowledged - that bug lack response from me.

But why bring that up here? Is the lack of response in a yaird bugreport
somehow proof of the opposite in intramfs-tools being correct?


But whatever - let's discuss yaird in this initramfs-tools bugreport.

yaird runs as root, and collects info from several places, some of
which may be readable only as root. It then stores that collected info
in a newly created file. As a precaution, this newly created file is
created only accessible by root, so as to not accidentally leak info.

For yaird, this mostly works well. One situation that I am aware of is
the use of ramdisks for diskless environments like lessdisks (see
bug#336518 where access rights is also - lightly - discussed).

Bug#336454 is still open as it indeed is an open issue what is the
"correct" permissions of initrd images, and yaird is controversial in
this area (as well as in other ones!).


 - Jonas

-- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm


pgpWRi0RlZjum.pgp
Description: PGP signature

Re: Move of update-grub and grub-install to /usr/sbin

[Otavio Salvador]

"Sam Morris" <[EMAIL PROTECTED]> writes:

>> You don't need grub-install to install grub
>
> Not according to
> . But I do
> think that lib/grub, sbin/grub-install and so on should move to /usr, or
> update-grub should be rewritten to function without /usr being mounted.

This is a different issue. grub shell currently doesn't check if image
files are of same version of grub itself so the user need to know that
if he upgraded the grub and wish to use the shell to install it he
needs to copy the new images by himself.

-- 
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://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."


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

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Goswin von Brederlow]

CC limited to debian-kernel as this isn't for release anymore.

Sven Luther <[EMAIL PROTECTED]> writes:

> On Sat, Aug 12, 2006 at 12:46:18AM +0200, Goswin von Brederlow wrote:
>> And actualy just recently the first one was uploaded to non-free
>> including udebs:
>> 
>> http://ftp.debian.org/debian/pool/non-free/f/firmware-non-free/
>> 
>> Now the DAK must be configured to create a
>> dists/sid/non-free/debian-installer/ subdir and index files for the
>> udebs. But I feel we are already one step closer to the goal.
>> 
>> Step 1: Create non-free udebs.  *checked*
>> Step 2: Add DAK config  *waiting for ftp-masters*
>> Step 3: Add D-I support
>
> I would propose something even more advanced, and not put the kernel .udebs
> into the main debian-installer thing, but into a separate section.
>
> The way i envision this, we would create a debian/sid/main|non-free/kernel
> section, where the kernel .udebs would be hold, and we start building them
> from the main kernel package.
>
> Ideally, we would go a step further, and have
> debian/sid/main|non-free/kernel/ sections, so we can split the kernel
> .udeb packages in a finer grain, and each running installer will only be
> seeing the modules corresponding to the kernel flavour he is running.

What for? The installer always needs the installer udebs. Having the
kernel udebs in another section just means more files to generate and
to download that can go wrong. It saves nothing.

Splitting the udebs by flavour would save a few bytes on the Packages
file but the only affect that has would be a few bytes less downloaded
(inconsequential) and a few bytes less ram used (if you are that low
then you have problems anyway).

If you want the user to only see the kernel components that match the
running kernel then filter them in the display. I don't think
splintering the Index files into tons of sections is the way to go
there. Also think about what that would mean for a newly added kernel
flavour in terms of delays till the DAK gets reconfigured for a new
section.

> This was my proposal from the start, and if you think down to it, it is the
> best solution for all the kernel/d-i related problems, and would allow to
> complete the work started with the common packaging, into a solution where
> there will be only a single package build, easily doable on the usual buildd
> network, will allow the most flexible solution for abi bumps and security
> upgrades.

The layout of the Index files and sections used has absoluetly no
effect on either abi bumps nor security nor in any way the package
building. Extra sections just means much more work for the DAK with
little to no benefit. I don't even consider that a good
solution. Quite opposite. The requirement of a new section for a new
kernel flavour would create a lot of delays for the kernel-team when
adding a new flavour.

> But then, i was not able to complete these ideas, due to my mothers illness
...

And there you go again. STOP IT PLEASE. It is totaly off-topic.

...
> So, you see, if i am angry and hurt, and you dislike me repeating it always,
> you know who to blame. 

You for repeating it over and over. With every repetition the
precieved blames shifts a little bit to your side until all people see
precieve is that you are to blame.

MfG
Goswin


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

linux-2.6_2.6.17-6_amd64.changes ACCEPTED

[Debian Installer]

Accepted:
linux-headers-2.6.17-2-all-amd64_2.6.17-6_amd64.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.17-2-all-amd64_2.6.17-6_amd64.deb
linux-headers-2.6.17-2-all_2.6.17-6_amd64.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.17-2-all_2.6.17-6_amd64.deb
linux-headers-2.6.17-2-amd64_2.6.17-6_amd64.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.17-2-amd64_2.6.17-6_amd64.deb
linux-headers-2.6.17-2-vserver-amd64_2.6.17-6_amd64.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.17-2-vserver-amd64_2.6.17-6_amd64.deb
linux-headers-2.6.17-2-vserver_2.6.17-6_amd64.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.17-2-vserver_2.6.17-6_amd64.deb
linux-headers-2.6.17-2_2.6.17-6_amd64.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.17-2_2.6.17-6_amd64.deb
linux-image-2.6.17-2-amd64_2.6.17-6_amd64.deb
  to pool/main/l/linux-2.6/linux-image-2.6.17-2-amd64_2.6.17-6_amd64.deb
linux-image-2.6.17-2-vserver-amd64_2.6.17-6_amd64.deb
  to pool/main/l/linux-2.6/linux-image-2.6.17-2-vserver-amd64_2.6.17-6_amd64.deb


Override entries for your package:
linux-headers-2.6.17-2-all-amd64_2.6.17-6_amd64.deb - optional devel
linux-headers-2.6.17-2-all_2.6.17-6_amd64.deb - optional devel
linux-headers-2.6.17-2-amd64_2.6.17-6_amd64.deb - optional devel
linux-headers-2.6.17-2-vserver-amd64_2.6.17-6_amd64.deb - optional devel
linux-headers-2.6.17-2-vserver_2.6.17-6_amd64.deb - optional devel
linux-headers-2.6.17-2_2.6.17-6_amd64.deb - optional devel
linux-image-2.6.17-2-amd64_2.6.17-6_amd64.deb - optional admin
linux-image-2.6.17-2-vserver-amd64_2.6.17-6_amd64.deb - optional admin



Thank you for your contribution to Debian.


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

linux-2.6_2.6.17-6_i386.changes ACCEPTED

[Debian Installer]

Accepted:
linux-headers-2.6.17-2-486_2.6.17-6_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.17-2-486_2.6.17-6_i386.deb
linux-headers-2.6.17-2-686-bigmem_2.6.17-6_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.17-2-686-bigmem_2.6.17-6_i386.deb
linux-headers-2.6.17-2-686_2.6.17-6_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.17-2-686_2.6.17-6_i386.deb
linux-headers-2.6.17-2-all-i386_2.6.17-6_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.17-2-all-i386_2.6.17-6_i386.deb
linux-headers-2.6.17-2-all_2.6.17-6_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.17-2-all_2.6.17-6_i386.deb
linux-headers-2.6.17-2-k7_2.6.17-6_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.17-2-k7_2.6.17-6_i386.deb
linux-headers-2.6.17-2-vserver-686_2.6.17-6_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.17-2-vserver-686_2.6.17-6_i386.deb
linux-headers-2.6.17-2-vserver-k7_2.6.17-6_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.17-2-vserver-k7_2.6.17-6_i386.deb
linux-headers-2.6.17-2-vserver_2.6.17-6_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.17-2-vserver_2.6.17-6_i386.deb
linux-headers-2.6.17-2_2.6.17-6_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.17-2_2.6.17-6_i386.deb
linux-image-2.6.17-2-486_2.6.17-6_i386.deb
  to pool/main/l/linux-2.6/linux-image-2.6.17-2-486_2.6.17-6_i386.deb
linux-image-2.6.17-2-686-bigmem_2.6.17-6_i386.deb
  to pool/main/l/linux-2.6/linux-image-2.6.17-2-686-bigmem_2.6.17-6_i386.deb
linux-image-2.6.17-2-686_2.6.17-6_i386.deb
  to pool/main/l/linux-2.6/linux-image-2.6.17-2-686_2.6.17-6_i386.deb
linux-image-2.6.17-2-k7_2.6.17-6_i386.deb
  to pool/main/l/linux-2.6/linux-image-2.6.17-2-k7_2.6.17-6_i386.deb
linux-image-2.6.17-2-vserver-686_2.6.17-6_i386.deb
  to pool/main/l/linux-2.6/linux-image-2.6.17-2-vserver-686_2.6.17-6_i386.deb
linux-image-2.6.17-2-vserver-k7_2.6.17-6_i386.deb
  to pool/main/l/linux-2.6/linux-image-2.6.17-2-vserver-k7_2.6.17-6_i386.deb


Override entries for your package:
linux-headers-2.6.17-2-486_2.6.17-6_i386.deb - optional devel
linux-headers-2.6.17-2-686-bigmem_2.6.17-6_i386.deb - optional devel
linux-headers-2.6.17-2-686_2.6.17-6_i386.deb - optional devel
linux-headers-2.6.17-2-all-i386_2.6.17-6_i386.deb - optional devel
linux-headers-2.6.17-2-all_2.6.17-6_i386.deb - optional devel
linux-headers-2.6.17-2-k7_2.6.17-6_i386.deb - optional devel
linux-headers-2.6.17-2-vserver-686_2.6.17-6_i386.deb - optional devel
linux-headers-2.6.17-2-vserver-k7_2.6.17-6_i386.deb - optional devel
linux-headers-2.6.17-2-vserver_2.6.17-6_i386.deb - optional devel
linux-headers-2.6.17-2_2.6.17-6_i386.deb - optional devel
linux-image-2.6.17-2-486_2.6.17-6_i386.deb - optional admin
linux-image-2.6.17-2-686-bigmem_2.6.17-6_i386.deb - optional admin
linux-image-2.6.17-2-686_2.6.17-6_i386.deb - optional admin
linux-image-2.6.17-2-k7_2.6.17-6_i386.deb - optional admin
linux-image-2.6.17-2-vserver-686_2.6.17-6_i386.deb - optional admin
linux-image-2.6.17-2-vserver-k7_2.6.17-6_i386.deb - optional admin



Thank you for your contribution to Debian.


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

linux-2.6_2.6.17-6_powerpc.changes ACCEPTED

[Debian Installer]

Accepted:
linux-2.6_2.6.17-6.diff.gz
  to pool/main/l/linux-2.6/linux-2.6_2.6.17-6.diff.gz
linux-2.6_2.6.17-6.dsc
  to pool/main/l/linux-2.6/linux-2.6_2.6.17-6.dsc
linux-doc-2.6.17_2.6.17-6_all.deb
  to pool/main/l/linux-2.6/linux-doc-2.6.17_2.6.17-6_all.deb
linux-headers-2.6.17-2-all-powerpc_2.6.17-6_powerpc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.17-2-all-powerpc_2.6.17-6_powerpc.deb
linux-headers-2.6.17-2-all_2.6.17-6_powerpc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.17-2-all_2.6.17-6_powerpc.deb
linux-headers-2.6.17-2-powerpc-miboot_2.6.17-6_powerpc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.17-2-powerpc-miboot_2.6.17-6_powerpc.deb
linux-headers-2.6.17-2-powerpc-smp_2.6.17-6_powerpc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.17-2-powerpc-smp_2.6.17-6_powerpc.deb
linux-headers-2.6.17-2-powerpc64_2.6.17-6_powerpc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.17-2-powerpc64_2.6.17-6_powerpc.deb
linux-headers-2.6.17-2-powerpc_2.6.17-6_powerpc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.17-2-powerpc_2.6.17-6_powerpc.deb
linux-headers-2.6.17-2-vserver-powerpc64_2.6.17-6_powerpc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.17-2-vserver-powerpc64_2.6.17-6_powerpc.deb
linux-headers-2.6.17-2-vserver-powerpc_2.6.17-6_powerpc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.17-2-vserver-powerpc_2.6.17-6_powerpc.deb
linux-headers-2.6.17-2-vserver_2.6.17-6_powerpc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.17-2-vserver_2.6.17-6_powerpc.deb
linux-headers-2.6.17-2_2.6.17-6_powerpc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.17-2_2.6.17-6_powerpc.deb
linux-image-2.6.17-2-powerpc-miboot_2.6.17-6_powerpc.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.17-2-powerpc-miboot_2.6.17-6_powerpc.deb
linux-image-2.6.17-2-powerpc-smp_2.6.17-6_powerpc.deb
  to pool/main/l/linux-2.6/linux-image-2.6.17-2-powerpc-smp_2.6.17-6_powerpc.deb
linux-image-2.6.17-2-powerpc64_2.6.17-6_powerpc.deb
  to pool/main/l/linux-2.6/linux-image-2.6.17-2-powerpc64_2.6.17-6_powerpc.deb
linux-image-2.6.17-2-powerpc_2.6.17-6_powerpc.deb
  to pool/main/l/linux-2.6/linux-image-2.6.17-2-powerpc_2.6.17-6_powerpc.deb
linux-image-2.6.17-2-vserver-powerpc64_2.6.17-6_powerpc.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.17-2-vserver-powerpc64_2.6.17-6_powerpc.deb
linux-image-2.6.17-2-vserver-powerpc_2.6.17-6_powerpc.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.17-2-vserver-powerpc_2.6.17-6_powerpc.deb
linux-manual-2.6.17_2.6.17-6_all.deb
  to pool/main/l/linux-2.6/linux-manual-2.6.17_2.6.17-6_all.deb
linux-patch-debian-2.6.17_2.6.17-6_all.deb
  to pool/main/l/linux-2.6/linux-patch-debian-2.6.17_2.6.17-6_all.deb
linux-source-2.6.17_2.6.17-6_all.deb
  to pool/main/l/linux-2.6/linux-source-2.6.17_2.6.17-6_all.deb
linux-support-2.6.17-2_2.6.17-6_all.deb
  to pool/main/l/linux-2.6/linux-support-2.6.17-2_2.6.17-6_all.deb
linux-tree-2.6.17_2.6.17-6_all.deb
  to pool/main/l/linux-2.6/linux-tree-2.6.17_2.6.17-6_all.deb


Override entries for your package:
linux-2.6_2.6.17-6.dsc - optional devel
linux-doc-2.6.17_2.6.17-6_all.deb - optional doc
linux-headers-2.6.17-2-all-powerpc_2.6.17-6_powerpc.deb - optional devel
linux-headers-2.6.17-2-all_2.6.17-6_powerpc.deb - optional devel
linux-headers-2.6.17-2-powerpc-miboot_2.6.17-6_powerpc.deb - optional devel
linux-headers-2.6.17-2-powerpc-smp_2.6.17-6_powerpc.deb - optional devel
linux-headers-2.6.17-2-powerpc64_2.6.17-6_powerpc.deb - optional devel
linux-headers-2.6.17-2-powerpc_2.6.17-6_powerpc.deb - optional devel
linux-headers-2.6.17-2-vserver-powerpc64_2.6.17-6_powerpc.deb - optional devel
linux-headers-2.6.17-2-vserver-powerpc_2.6.17-6_powerpc.deb - optional devel
linux-headers-2.6.17-2-vserver_2.6.17-6_powerpc.deb - optional devel
linux-headers-2.6.17-2_2.6.17-6_powerpc.deb - optional devel
linux-image-2.6.17-2-powerpc-miboot_2.6.17-6_powerpc.deb - optional admin
linux-image-2.6.17-2-powerpc-smp_2.6.17-6_powerpc.deb - optional admin
linux-image-2.6.17-2-powerpc64_2.6.17-6_powerpc.deb - optional admin
linux-image-2.6.17-2-powerpc_2.6.17-6_powerpc.deb - optional admin
linux-image-2.6.17-2-vserver-powerpc64_2.6.17-6_powerpc.deb - optional admin
linux-image-2.6.17-2-vserver-powerpc_2.6.17-6_powerpc.deb - optional admin
linux-manual-2.6.17_2.6.17-6_all.deb - optional doc
linux-patch-debian-2.6.17_2.6.17-6_all.deb - optional devel
linux-source-2.6.17_2.6.17-6_all.deb - optional devel
linux-support-2.6.17-2_2.6.17-6_all.deb - optional devel
linux-tree-2.6.17_2.6.17-6_all.deb - optional devel

Announcing to debian-devel-changes@lists.debian.org


Thank you for your contribution to Debian.


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

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Sat, Aug 12, 2006 at 03:13:13PM +0200, Goswin von Brederlow wrote:
> CC limited to debian-kernel as this isn't for release anymore.
> 
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> > On Sat, Aug 12, 2006 at 12:46:18AM +0200, Goswin von Brederlow wrote:
> >> And actualy just recently the first one was uploaded to non-free
> >> including udebs:
> >> 
> >> http://ftp.debian.org/debian/pool/non-free/f/firmware-non-free/
> >> 
> >> Now the DAK must be configured to create a
> >> dists/sid/non-free/debian-installer/ subdir and index files for the
> >> udebs. But I feel we are already one step closer to the goal.
> >> 
> >> Step 1: Create non-free udebs.  *checked*
> >> Step 2: Add DAK config  *waiting for ftp-masters*
> >> Step 3: Add D-I support
> >
> > I would propose something even more advanced, and not put the kernel .udebs
> > into the main debian-installer thing, but into a separate section.
> >
> > The way i envision this, we would create a debian/sid/main|non-free/kernel
> > section, where the kernel .udebs would be hold, and we start building them
> > from the main kernel package.
> >
> > Ideally, we would go a step further, and have
> > debian/sid/main|non-free/kernel/ sections, so we can split the 
> > kernel
> > .udeb packages in a finer grain, and each running installer will only be
> > seeing the modules corresponding to the kernel flavour he is running.
> 
> What for? The installer always needs the installer udebs. Having the
> kernel udebs in another section just means more files to generate and
> to download that can go wrong. It saves nothing.

The installer needs the installer .udebs of the flavours it is using, but
hardly any others. This mean we would save on memory space used to hold the 3
in-memory copy of the Packages file.

> Splitting the udebs by flavour would save a few bytes on the Packages
> file but the only affect that has would be a few bytes less downloaded
> (inconsequential) and a few bytes less ram used (if you are that low
> then you have problems anyway).

But it would make space for a more fine-grained .udeb classification, which
would in turn result in a considerable memory and bandwidth saving, as only
the modules really used are downloaded.

Furthermore this will allow the kernel .udebs to be moved into the common
kernel package, without costing the installer folk any flexibility, as they
will not have need to balance the module .udebs and thus keep control of them.

Furthermore, with a set of smart tools, some Makefile/Kconfig analysis, and a
bit of graph theory, it would allow to automate the module .udeb creation,
based only on the choice of .config options, and thus make the job of the
porters so much easier, needing only to consider the config options one single
time, to see if they need to be enabled, and then decide if this particular
option is one which would enable a module which would be needed for the
installer.

All the rest, the description, the depednecy graph, etc, will be taken from
the kernel source directly (with a few overrides for dependencies for some
modules who do not (yet maybe) carry the dependency information in their
source code.

> If you want the user to only see the kernel components that match the
> running kernel then filter them in the display. I don't think

Well, apart from the installer pulling some 2.4.27-apus .udebs in on a
2.6.12-powerpc flavour, which is indeed a mistake which would be solved by
this solution, this is hardly the point.

The main point here, is that it is easily doable to automate a set of tasks,
and to keep only the small minimum set of human decision in a single place,
and thus spare everyone a lot of work, which is after all what computers where
invented for in the first place.

Compare this to the current situation, favored by the installer team, probably
just to oppose me, where every porter has to redo the module selection job by
hand, where none of them are informed about the problems faced by the others,
where a slight indisponibility of one of the porters result in thee brokeness
of the related build, and accusations of lazyness by the d-i leaders, and you
see how this would be dissatisfying, and how the d-i leaders in their
pettiness see my technical proposals as an attack against their supremacy.

> splintering the Index files into tons of sections is the way to go
> there. Also think about what that would mean for a newly added kernel
> flavour in terms of delays till the DAK gets reconfigured for a new
> section.

Indeed. But then, there is probably another set of modifications that could be
done to help this go around. The kernel team has already stated that they are
not really happy in the way of how NEW is handled in relation of kernels.

Another solution to the non-free DFSG mess and this would be to take the
kernel fully out of debian, and have our own infrastructure to handle it as we
see fit. This would solve the problem of those people in debian who like to do
unneeded work, and im

Processed: tagging 381677

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.9.20
> tags 381677 - patch
Bug#381677: initramfs-tools: Temporary files and initramfs world-readable
Tags were: patch
Tags removed: patch

>
End of message, 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]

Processed: tagging 381351

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.9.20
> tags 381351 - patch
Bug#381351: initramfs-tools: ide-disk/specific ide modules not loaded and 
vgchange -ay fails using lvm2
Tags were: patch
Tags removed: patch

>
End of message, 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#381844: itramfs-tools doesn't produce working ramdisk on amd64 with MODULES=list

[maximilian attems]

On Sat, 12 Aug 2006, maximilian attems wrote:
> i'd like to see that initrd, please put it up somewhere on the web,
> or send it me privately.

ok i looked at it, and appears perfectly fine.

so i really need more info, please post the log of your unsucessfull boot.

if the root is not found it should put you into an rescue console after
some timeout.  there please check your root devices are there
ls /dev/sda /dev/sdb
cat /proc/mdstat
which modules are loaded:
cat /proc/modules

also please post form there non working (checkout netcat usage)
dmesg

-- 
maks


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

Bug#382675: rm scripts not removing /var/lib/usplash

[Guarded Identity]

Package: usplash
Severity: normal

*** Please type your report below this line ***

Hi, 

(reportbugs is acting up, so I'm sending this E-mail manually; please let me 
know if there's a problem with the formatting... should be fine since I just 
copied what reportbug tried to send)

Just wanted to let you know in the spirit of reducing cruft that it
would be nice if your package uninstalled more completely and removed
/var/lib/usplash and any contents in it like the usplash pipe.

Thanks,
Sukant Hajra

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (90, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.17-hole
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Re: linux-modules-2.6.16-2-xen-686_2.6.16-15 depends on initramfs-tools

[Andrea Brenci]

On Sat, Jul 08, 2006 at 11:02:57PM +1000, James Harper wrote:
> Package: linux-modules-2.6.16-2-xen-686
> Version: 2.6.16-15
> Severity: important
> 
> 
> linux-modules-2.6.16-2-xen-686 only contains modules for xen domains,
> and should not require any initrd or initramfs tools.
> 

linux-modules-2.6.16-2-xen contains vital modules for booting the system
if you use linux-image-2.6.16-2-xen; after installing the previous two
packets I couldn't boot my system because I used an initrd file from
another kernel (2.6.17), so the folder /lib/modules/2.6.16-2-xen was
missing from the initrd file, and the boot process stopped because there was no 
available driver for my ide disk; after creating a new initrd file with 
"update-initramfs -k 2.6.16-2-xen-k7 -c", my system booted without problems 
into dom0. Maybe if you recompile the kernel, you don't need the drivers in 
/lib/modules/2.6.16-2-xen folder during the boot process, but if you use the 
kernel packet you do.
In any case, I think that a linux-modules postinst script creating the proper 
initrd file would be nice.Of course if that doesn't cause troubles I don't 
see...

Regards,
Andrea Brenci


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

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Goswin von Brederlow]

Sven Luther <[EMAIL PROTECTED]> writes:

>> What for? The installer always needs the installer udebs. Having the
>> kernel udebs in another section just means more files to generate and
>> to download that can go wrong. It saves nothing.
>
> The installer needs the installer .udebs of the flavours it is using, but
> hardly any others. This mean we would save on memory space used to hold the 3
> in-memory copy of the Packages file.

-rw-r--r-- 1 reprepro nogroup 187K Aug 11 04:53 
dists/sid/main/debian-installer/binary-amd64/Packages

Is that really a problem? If so then work on reducing the number of
copies from 3 to 1 plus a compressed one. You could also filter out
kernel modules for other flavours while downloading the file prior top
saving it. For more space filter out all the udebs already installed too.

Having all the udebs in one Packages file is convenient for
debian-installer when building, for debian-cd, for mirror scripts and
so on. Don't forget that.

And don't forget that the businesscard or netinst CDs have filtered
Packages files for the udebs with only the right udebs in there. Only
the netboot and full CD images waste those few Kb.

>> Splitting the udebs by flavour would save a few bytes on the Packages
>> file but the only affect that has would be a few bytes less downloaded
>> (inconsequential) and a few bytes less ram used (if you are that low
>> then you have problems anyway).
>
> But it would make space for a more fine-grained .udeb classification, which
> would in turn result in a considerable memory and bandwidth saving, as only
> the modules really used are downloaded.
>
> Furthermore this will allow the kernel .udebs to be moved into the common
> kernel package, without costing the installer folk any flexibility, as they
> will not have need to balance the module .udebs and thus keep control of them.

More udebs increases the Packages files. That works contrary to what
you want (save space). As for saving download bandwith, saving 1MB of
udebs compared to the 500-2000MB debs of a normal install is quite
incosequential. You might be optimizing at the wrong end here.

I also see how more sections would change any of this? Has someone
said we can't do finer grained kernel module udebs because the
Packages file will grow to big with all those udebs? I think a far
bigger reason would be flooding NEW with so many tiny udebs on an ABI
change and thus driving ftp-master nuts.

> Furthermore, with a set of smart tools, some Makefile/Kconfig analysis, and a
> bit of graph theory, it would allow to automate the module .udeb creation,
> based only on the choice of .config options, and thus make the job of the
> porters so much easier, needing only to consider the config options one single
> time, to see if they need to be enabled, and then decide if this particular
> option is one which would enable a module which would be needed for the
> installer.
>
> All the rest, the description, the depednecy graph, etc, will be taken from
> the kernel source directly (with a few overrides for dependencies for some
> modules who do not (yet maybe) carry the dependency information in their
> source code.

You can already do that. Just because the modules are not copied into
udebs at the end does not mean you can't pretend. Just imagine they
get copied and do all your magic. After that you have a set of modules
and the depmod file for them that D-I uses to split modules into
udebs.

>> If you want the user to only see the kernel components that match the
>> running kernel then filter them in the display. I don't think
>
> Well, apart from the installer pulling some 2.4.27-apus .udebs in on a
> 2.6.12-powerpc flavour, which is indeed a mistake which would be solved by
> this solution, this is hardly the point.
>
> The main point here, is that it is easily doable to automate a set of tasks,
> and to keep only the small minimum set of human decision in a single place,
> and thus spare everyone a lot of work, which is after all what computers where
> invented for in the first place.

No automation exists so for now someone has to do it manualy and that
someone is the D-I team currently as they know what D-I needs. And not
the kernel-team. Currently building udebs from the linux-2.6 source
would add another indirection to the build process, not remove one.

> Compare this to the current situation, favored by the installer team, probably
> just to oppose me, where every porter has to redo the module selection job by
> hand, where none of them are informed about the problems faced by the others,
> where a slight indisponibility of one of the porters result in thee brokeness
> of the related build, and accusations of lazyness by the d-i leaders, and you
> see how this would be dissatisfying, and how the d-i leaders in their
> pettiness see my technical proposals as an attack against their supremacy.

The same can be said to happen for the kernel-team. Changing
responcibility to another team does not magicaly so

Bug#382699: Debian patch does not work right with make-kpkg

[Goswin Brederlow]

Package: linux-patch-debian-2.6.16
Version: 2.6.16-17
Severity: normal
File: /usr/src/kernel-patches/all/2.6.16/apply/debian

Hi,

the apply script of the debian patch assumed that '--arch 
--subarch ' is given as option and depending on that applies
the optional patches. Since make-kpkg does not pass those options on
the commandline when patching the kernel it is impossible to build any
kernel that requires the extra patches from a series, like xen or
vserver.

Please also check for the KPKG_ARCH and KPKG_SUBARCH (and any other
options) that make-kpkg sets and not just the commandline when
deciding what patches to apply.

MfG
Goswin

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-frosties-2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages linux-patch-debian-2.6.16 depends on:
ii  bzip2 1.0.3-3high-quality block-sorting file co
ii  python2.4-minimal 2.4.3-7A minimal subset of the Python lan

linux-patch-debian-2.6.16 recommends no packages.

-- no debconf information


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

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Sat, Aug 12, 2006 at 07:46:16PM +0200, Goswin von Brederlow wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> >> What for? The installer always needs the installer udebs. Having the
> >> kernel udebs in another section just means more files to generate and
> >> to download that can go wrong. It saves nothing.
> >
> > The installer needs the installer .udebs of the flavours it is using, but
> > hardly any others. This mean we would save on memory space used to hold the 
> > 3
> > in-memory copy of the Packages file.
> 
> -rw-r--r-- 1 reprepro nogroup 187K Aug 11 04:53 
> dists/sid/main/debian-installer/binary-amd64/Packages
> 
> Is that really a problem? If so then work on reducing the number of
> copies from 3 to 1 plus a compressed one. You could also filter out
> kernel modules for other flavours while downloading the file prior top
> saving it. For more space filter out all the udebs already installed too.
> 
> Having all the udebs in one Packages file is convenient for
> debian-installer when building, for debian-cd, for mirror scripts and
> so on. Don't forget that.
> 
> And don't forget that the businesscard or netinst CDs have filtered
> Packages files for the udebs with only the right udebs in there. Only
> the netboot and full CD images waste those few Kb.
> 
> >> Splitting the udebs by flavour would save a few bytes on the Packages
> >> file but the only affect that has would be a few bytes less downloaded
> >> (inconsequential) and a few bytes less ram used (if you are that low
> >> then you have problems anyway).
> >
> > But it would make space for a more fine-grained .udeb classification, which
> > would in turn result in a considerable memory and bandwidth saving, as only
> > the modules really used are downloaded.
> >
> > Furthermore this will allow the kernel .udebs to be moved into the common
> > kernel package, without costing the installer folk any flexibility, as they
> > will not have need to balance the module .udebs and thus keep control of 
> > them.
> 
> More udebs increases the Packages files. That works contrary to what

Indeed. The proposal to split the packages file in a per flavour kernel
repository comes directly from the need to counterbalance this augmentation of
the number of packages.

Also, do you really need a gazillion of not-for-your-hardware modules
installed ? 

> you want (save space). As for saving download bandwith, saving 1MB of
> udebs compared to the 500-2000MB debs of a normal install is quite
> incosequential. You might be optimizing at the wrong end here.

Indeed.

> I also see how more sections would change any of this? Has someone
> said we can't do finer grained kernel module udebs because the
> Packages file will grow to big with all those udebs? I think a far

Indeed, this was the main critic against the finer grained module proposal
(apart from all the hateful stuff they said to me at the same time naturally).

> bigger reason would be flooding NEW with so many tiny udebs on an ABI
> change and thus driving ftp-master nuts.

Nope, because they would all be part of the same source package, and i think
they can easily enough authorize all binaries of a single source package.

> 
> > Furthermore, with a set of smart tools, some Makefile/Kconfig analysis, and 
> > a
> > bit of graph theory, it would allow to automate the module .udeb creation,
> > based only on the choice of .config options, and thus make the job of the
> > porters so much easier, needing only to consider the config options one 
> > single
> > time, to see if they need to be enabled, and then decide if this particular
> > option is one which would enable a module which would be needed for the
> > installer.
> >
> > All the rest, the description, the depednecy graph, etc, will be taken from
> > the kernel source directly (with a few overrides for dependencies for some
> > modules who do not (yet maybe) carry the dependency information in their
> > source code.
> 
> You can already do that. Just because the modules are not copied into
> udebs at the end does not mean you can't pretend. Just imagine they
> get copied and do all your magic. After that you have a set of modules
> and the depmod file for them that D-I uses to split modules into
> udebs.

"the depmod file that D-I uses to split modules into .udebs". You must be
living in another planet than me. Right now the modules are split manually, in
a stupid painstakingly repetitive and time-consuming way. And you can't even
per-arch/subarch override properly the default choice done in kernel-wedge.

Notice also that the apus flavour was killed from d-i once they kicked me out,
because it was too much work for them to fix it.

> >> If you want the user to only see the kernel components that match the
> >> running kernel then filter them in the display. I don't think
> >
> > Well, apart from the installer pulling some 2.4.27-apus .udebs in on a
> > 2.6.12-powerpc flavour, which is indeed a mistake which would be solved by
> > this so

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Goswin von Brederlow]

Sven Luther <[EMAIL PROTECTED]> writes:

> On Sat, Aug 12, 2006 at 07:46:16PM +0200, Goswin von Brederlow wrote:
>> Sven Luther <[EMAIL PROTECTED]> writes:
>> 
>> >> What for? The installer always needs the installer udebs. Having the
>> >> kernel udebs in another section just means more files to generate and
>> >> to download that can go wrong. It saves nothing.
>> >
>> > The installer needs the installer .udebs of the flavours it is using, but
>> > hardly any others. This mean we would save on memory space used to hold 
>> > the 3
>> > in-memory copy of the Packages file.
>> 
>> -rw-r--r-- 1 reprepro nogroup 187K Aug 11 04:53 
>> dists/sid/main/debian-installer/binary-amd64/Packages
>> 
>> Is that really a problem? If so then work on reducing the number of
>> copies from 3 to 1 plus a compressed one. You could also filter out
>> kernel modules for other flavours while downloading the file prior top
>> saving it. For more space filter out all the udebs already installed too.
>> 
>> Having all the udebs in one Packages file is convenient for
>> debian-installer when building, for debian-cd, for mirror scripts and
>> so on. Don't forget that.
>> 
>> And don't forget that the businesscard or netinst CDs have filtered
>> Packages files for the udebs with only the right udebs in there. Only
>> the netboot and full CD images waste those few Kb.
>> 
>> >> Splitting the udebs by flavour would save a few bytes on the Packages
>> >> file but the only affect that has would be a few bytes less downloaded
>> >> (inconsequential) and a few bytes less ram used (if you are that low
>> >> then you have problems anyway).
>> >
>> > But it would make space for a more fine-grained .udeb classification, which
>> > would in turn result in a considerable memory and bandwidth saving, as only
>> > the modules really used are downloaded.
>> >
>> > Furthermore this will allow the kernel .udebs to be moved into the common
>> > kernel package, without costing the installer folk any flexibility, as they
>> > will not have need to balance the module .udebs and thus keep control of 
>> > them.
>> 
>> More udebs increases the Packages files. That works contrary to what
>
> Indeed. The proposal to split the packages file in a per flavour kernel
> repository comes directly from the need to counterbalance this augmentation of
> the number of packages.

So instead of having 5 module udebs for my ONE generic kernel I get
200? For say amd64 it would be a big step back.

How many archs with flavours are we talking about anyway? I think m68k
has 3 flavours and ppc some and every other archs has a generic
flavour or drivers buildin already.

> Also, do you really need a gazillion of not-for-your-hardware modules
> installed ? 

All my hardware (that includes m68k) has absolutley 0 problems with
that. They will be installed in D-I and they will be installed on the
finished system. No point breaking my neck to get less installed
during D-I.

>> you want (save space). As for saving download bandwith, saving 1MB of
>> udebs compared to the 500-2000MB debs of a normal install is quite
>> incosequential. You might be optimizing at the wrong end here.
>
> Indeed.

So why then do you want to split module udebs?

You just agreed that downloading the module udebs is inconsequential
given their size. You agreed that more udebs increases the Index files
which is bad.

So all I'm left with is that you don't end up with as much modules in
the ramdisk. Something I find irelevant unless you talk about the
low-mem flavour.

Is the space taken up by the installed modules your actual argument
for having finer grained module udebs?

...
>> You can already do that. Just because the modules are not copied into
>> udebs at the end does not mean you can't pretend. Just imagine they
>> get copied and do all your magic. After that you have a set of modules
>> and the depmod file for them that D-I uses to split modules into
>> udebs.
>
> "the depmod file that D-I uses to split modules into .udebs". You must be
> living in another planet than me. Right now the modules are split manually, in
> a stupid painstakingly repetitive and time-consuming way. And you can't even
> per-arch/subarch override properly the default choice done in kernel-wedge.

Last I used it, and that is some time ago, the dependencies where
automatically checked on build. Maybe someone broke that but that
could be repaired easily enough.

...
>> the kernel-team. Currently building udebs from the linux-2.6 source
>> would add another indirection to the build process, not remove one.
>
> Another indirection ? It would mean that in a single upload, all kernel
> related .debs and .udebs are built. Furthermore, it allows to autobuild the
> kernel, which is not currently possible for the .udebs, which means 10+ times
> human intervention, uncoordinated uploads, uncoordinated NEW handling, random
> delays for each arch, and that the porters are left alone with random breakage
> introduced by untested changes of 

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Goswin von Brederlow]

[EMAIL PROTECTED] (Marco d'Itri) writes:

> On Aug 07, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>
>> > No, because those are not linked together with the GPLed code, but are a 
>> > mere
>> > aggregation of works inside the same media, i.e. the binary file. Those
>> > non-free firmware will never run inside the same memory space as the 
>> > kernel,
>> > and are offloaded to a peripheral processor, and the communication media
>> > between the kernel and this peripheral processor running said firmware is
>> > clearly defined, there is no doubt that those non-free firmware do not 
>> > break
>> > the kernel GPL.
>
>> They are linked in, they have symbols, the code directly references
>> their address. Can you name one tool that will easily remove such
> No. They are a char array, it's data copied where the hardware wants it.
> It's not code called by other functions.

That still leaves the symbol for the variable holding the char array
and its size. The code copying the data references that variable and
size. I didn't say the code is called.

Compare it to including a hexdump of an image or sound in a header
file and including that in the binary. And compare it with having that
same image or sound as external file shipped in the same deb.

Assume the image/sound was rendered/generated from some source format
not included in the source. E.g. povray input.

Is it an aggregation with the image linked into the binary?

>> "aggregated" code from the kernel image?
> Not relevant.

If it is an aggregation then there must be a way to break it up and
only keep the GPLed parts. I think that is very much relevant. I don't
think you can call something an aggregation if it is inseperably bound
together.

MfG
Goswin


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

Bug#382711: linux-image-2.6.16-2-xen-amd64-k8: sata assertion failure and kernel oops

[Phil Blundell]

Package: linux-image-2.6.16-2-xen-amd64-k8
Version: 2.6.16-17
Severity: normal

A few minutes ago, one of our amd64 machines fell over with the errors
below.  It has two Maxtor disks attached to an nVidia controller,
running as a raid1 pair: the boot-time messages look like this:

libata version 1.20 loaded.
sata_nv :00:0e.0: version 0.8
PCI: Setting latency timer of device :00:0e.0 to 64
ata1: SATA max UDMA/133 cmd 0xE800 ctl 0xE482 bmdma 0xE000 irq 11
ata2: SATA max UDMA/133 cmd 0xE400 ctl 0xE082 bmdma 0xE008 irq 11
ata1: SATA link up 3.0 Gbps (SStatus 123)
ata1: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4773 85:7c69 86:3e01 87:4763
88:407f
ata1: dev 0 ATA-7, max UDMA/133, 160086528 sectors: LBA48
ata1: dev 0 configured for UDMA/133
scsi0 : sata_nv
ata2: SATA link down (SStatus 0)
scsi1 : sata_nv
  Vendor: ATA   Model: Maxtor 6V080E0Rev: VA11
  Type:   Direct-Access  ANSI SCSI revision: 05
PCI: Setting latency timer of device :00:0f.0 to 64
ata3: SATA max UDMA/133 cmd 0xDC00 ctl 0xD882 bmdma 0xD400 irq 10
ata4: SATA max UDMA/133 cmd 0xD800 ctl 0xD482 bmdma 0xD408 irq 10
ata3: SATA link up 3.0 Gbps (SStatus 123)
ata3: dev 0 cfg 49:2f00 82:7c6b 83:7f69 84:4773 85:7c69 86:3e01 87:4763
88:407f
ata3: dev 0 ATA-7, max UDMA/133, 160086528 sectors: LBA48
ata3: dev 0 configured for UDMA/133
scsi2 : sata_nv
ata4: SATA link down (SStatus 0)
scsi3 : sata_nv
  Vendor: ATA   Model: Maxtor 6V080E0Rev: VA11
  Type:   Direct-Access  ANSI SCSI revision: 05

Here's the log of the crash:

--

Aug 12 20:14:03 uebercounty kernel: ata1: translated ATA stat/err
0x37/00 to SCSI SK/ASC/ASCQ 0x4/00/00
Aug 12 20:17:03 uebercounty kernel: ata1: status=0x37 { DeviceFault
SeekComplete CorrectedError Index Error }
Aug 12 20:17:03 uebercounty kernel: ata1: command 0x35 timeout, stat
0xb7 host_stat 0x21
Aug 12 20:17:03 uebercounty kernel: ata1: translated ATA stat/err
0xb7/00 to SCSI SK/ASC/ASCQ 0xb/47/00
Aug 12 20:17:03 uebercounty kernel: ata1: status=0xb7 { Busy }
Aug 12 20:17:03 uebercounty kernel: sd 0:0:0:0: SCSI error: return code
= 0x802
Aug 12 20:17:03 uebercounty kernel: sda: Current: sense key: Aborted
Command
Aug 12 20:17:03 uebercounty kernel: Additional sense: Scsi parity
error
Aug 12 20:17:03 uebercounty kernel: end_request: I/O error, dev sda,
sector 4096967
Aug 12 20:17:03 uebercounty kernel: raid1: Disk failure on sda3,
disabling device.
Aug 12 20:17:03 uebercounty kernel: ^IOperation continuing on 1 devices
Aug 12 20:17:03 uebercounty kernel: ATA: abnormal status 0xB7 on port
0xE807
Aug 12 20:17:03 uebercounty kernel: ATA: abnormal status 0xB7 on port
0xE807
Aug 12 20:17:33 uebercounty kernel: ATA: abnormal status 0xB7 on port
0xE807
Aug 12 20:17:33 uebercounty kernel: ata1: command 0x35 timeout, stat
0xb7 host_stat 0x21
Aug 12 20:17:33 uebercounty kernel: ata1: translated ATA stat/err
0xb7/00 to SCSI SK/ASC/ASCQ 0xb/47/00
Aug 12 20:17:33 uebercounty kernel: ata1: status=0xb7 { Busy }
Aug 12 20:17:33 uebercounty kernel: sd 0:0:0:0: SCSI error: return code
= 0x802
Aug 12 20:17:33 uebercounty kernel: sda: Current: sense key: Aborted
Command
Aug 12 20:17:33 uebercounty kernel: Additional sense: Scsi parity
error
Aug 12 20:17:33 uebercounty kernel: end_request: I/O error, dev sda,
sector 5243841
Aug 12 20:17:33 uebercounty kernel: ATA: abnormal status 0xB7 on port
0xE807
Aug 12 20:17:33 uebercounty kernel: ATA: abnormal status 0xB7 on port
0xE807
Aug 12 20:17:33 uebercounty /USR/SBIN/CRON[12579]: (root) CMD (
run-parts --report /etc/cron.hourly)
Aug 12 20:17:33 uebercounty kernel: ATA: abnormal status 0xB7 on port
0xE807
Aug 12 20:17:33 uebercounty kernel: ata1: command 0x35 timeout, stat
0xb7 host_stat 0x21
Aug 12 20:17:33 uebercounty kernel: ata1: translated ATA stat/err
0xb7/00 to SCSI SK/ASC/ASCQ 0xb/47/00
Aug 12 20:17:33 uebercounty kernel: ata1: status=0xb7 { Busy }
Aug 12 20:17:33 uebercounty kernel: sd 0:0:0:0: SCSI error: return code
= 0x802
Aug 12 20:17:33 uebercounty kernel: sda: Current: sense key: Aborted
Command
Aug 12 20:17:33 uebercounty kernel: Additional sense: Scsi parity
error
Aug 12 20:17:33 uebercounty kernel: end_request: I/O error, dev sda,
sector 5257775
Aug 12 20:17:33 uebercounty kernel: ATA: abnormal status 0xB7 on port
0xE807
Aug 12 20:17:33 uebercounty last message repeated 2 times
[...]
Aug 12 20:31:05 uebercounty kernel: ata1: command 0xa1 timeout, stat
0xb7 host_stat 0x0
Aug 12 20:31:05 uebercounty kernel: ata1: translated ATA stat/err
0xb7/00 to SCSI SK/ASC/ASCQ 0xb/47/00
Aug 12 20:31:05 uebercounty kernel: ata1: status=0xb7 { Busy }
Aug 12 20:31:05 uebercounty kernel: Assertion failed! qc !=
NULL,drivers/scsi/libata-core.c,ata_pio_poll,line=2897
Aug 12 20:31:20 uebercounty last message repeated 911 times
Aug 12 20:31:20 uebercounty kernel: Assertion failed! qc !=
NULL,drivers/scsi/libata-core.c,ata_pio_poll,line=2897
Aug 12 20:31:23 uebercounty last message repeated 182 times
Aug 12 20:31:23 uebercounty

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Sat, Aug 12, 2006 at 10:32:54PM +0200, Goswin von Brederlow wrote:
> > Indeed. The proposal to split the packages file in a per flavour kernel
> > repository comes directly from the need to counterbalance this augmentation 
> > of
> > the number of packages.
> 
> So instead of having 5 module udebs for my ONE generic kernel I get
> 200? For say amd64 it would be a big step back.

Indeed, but smaller ones.

> How many archs with flavours are we talking about anyway? I think m68k
> has 3 flavours and ppc some and every other archs has a generic
> flavour or drivers buildin already.

I know that the more exotic ones have many flavours. Also, the amount of
packages will be proportional of the non-builtin drivers. POwerpc has
currently 5 d-i flavours (or would have if the new d-i powerpc people did they
work correctly), powerpc, powerpc64, powerpc-miboot, prep and apus. 

> > Also, do you really need a gazillion of not-for-your-hardware modules
> > installed ? 
> 
> All my hardware (that includes m68k) has absolutley 0 problems with
> that. They will be installed in D-I and they will be installed on the
> finished system. No point breaking my neck to get less installed
> during D-I.
> 
> >> you want (save space). As for saving download bandwith, saving 1MB of
> >> udebs compared to the 500-2000MB debs of a normal install is quite
> >> incosequential. You might be optimizing at the wrong end here.
> >
> > Indeed.
> 
> So why then do you want to split module udebs?

Because the current way of doing it is problematic. The d-i folk don't want to
give control of it to the kernel team, and the new proposal handled they
keeping the same and even better control of how to build the ramdisks, while
at the same time building the module .udebs from the common kernel source,
thus saving around 2 weeks of time the d-i folk need to adjust to a new abi or
version, thus making for more timely kernel security updates, and making the
work of the divers security teams easier.

> You just agreed that downloading the module udebs is inconsequential
> given their size. You agreed that more udebs increases the Index files
> which is bad.

Err, let's say we have 5 flavours like on powerpc, and each would have 200+
little module .udebs, which gives us Package numbers of 1000+. Worse if there
are more flavours. This is the part that joeyh objected to this plan of
spliting modules because of the fact that d-i loads three in memory copy of
the Packages file, which in turn prompted the idea of per-flavour
repositories.

If you look at the whole idea though, you find out that it is a really neat
solution to this problem, it cares for all the technical hurdles, and is
elegant and nice, and if you throw in the part that can be automated, it saves
work for everyone involved.

In my book, this makes it a good idea, or at least something that should be
tried, and not something you have to menace the implementator so he doesn't
dare pursue it.

> So all I'm left with is that you don't end up with as much modules in
> the ramdisk. Something I find irelevant unless you talk about the
> low-mem flavour.

And the fact that it is much easier to update config option and add and remove
new modules doesn't count. Naturally, you don't handle kernel .udebs. I did,
and it was a royal pain in the ass to handle those, it took me hours, for
stuff that was already done 10 times for the other flavours. And even a few
days ago, the powerpc64 flavour was still broken with the 2.6.17 kernels,
because some random module listed in the list of modules was not present.

The whole concept is of an extreme fragility, prone to break again and again,
cause lot of work for all involved, who become irritable, and bash on you when
you even mention it.

This, in my book, is not an example of good software engineering, and any
proposal to help improve this should be worth considering.

> Is the space taken up by the installed modules your actual argument
> for having finer grained module udebs?

Nope, but then i told you that in the first mail already :)

> ...
> >> You can already do that. Just because the modules are not copied into
> >> udebs at the end does not mean you can't pretend. Just imagine they
> >> get copied and do all your magic. After that you have a set of modules
> >> and the depmod file for them that D-I uses to split modules into
> >> udebs.
> >
> > "the depmod file that D-I uses to split modules into .udebs". You must be
> > living in another planet than me. Right now the modules are split manually, 
> > in
> > a stupid painstakingly repetitive and time-consuming way. And you can't even
> > per-arch/subarch override properly the default choice done in kernel-wedge.
> 
> Last I used it, and that is some time ago, the dependencies where
> automatically checked on build. Maybe someone broke that but that
> could be repaired easily enough.

The dependencies, yes, with a manual override which you have to use in
mysterious cases. The actual module list is fully

Bug#382716: can't load envctrl module

[Clint Adams]

Package: linux-image-2.6.17-1-sparc64
Version: 2.6.17-5

% sudo modprobe envctrl  
FATAL: Error inserting envctrl
(/lib/modules/2.6.17-1-sparc64/kernel/drivers/sbus/char/envctrl.ko):
Unknown symbol in module, or unknown parameter (see dmesg)

% dmesg|grep envctrl
envctrl: Unknown symbol execve


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

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Sat, Aug 12, 2006 at 11:03:29PM +0200, Goswin von Brederlow wrote:
> [EMAIL PROTECTED] (Marco d'Itri) writes:
> 
> > On Aug 07, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> >
> >> > No, because those are not linked together with the GPLed code, but are a 
> >> > mere
> >> > aggregation of works inside the same media, i.e. the binary file. Those
> >> > non-free firmware will never run inside the same memory space as the 
> >> > kernel,
> >> > and are offloaded to a peripheral processor, and the communication media
> >> > between the kernel and this peripheral processor running said firmware is
> >> > clearly defined, there is no doubt that those non-free firmware do not 
> >> > break
> >> > the kernel GPL.
> >
> >> They are linked in, they have symbols, the code directly references
> >> their address. Can you name one tool that will easily remove such
> > No. They are a char array, it's data copied where the hardware wants it.
> > It's not code called by other functions.
> 
> That still leaves the symbol for the variable holding the char array
> and its size. The code copying the data references that variable and
> size. I didn't say the code is called.

Yeah, thanks very much. I suggest you go over to the FSF site, and read the
GPL faq, and then come back and discuss this again. I did so during that
discussion last year, and as said, that argumentation convinced the broadcom
legal department, and even the FSF had nothing to say against it.

A quick clue to help your search, the important parts are the one about the
'significant interface' or something such, and i seriously doubt that having a
single variable referencing the non-free stuff is enough for that.

Or else, consider this in a different way. On your computer disk, you have a
bunch of binary files, those are called partitions, and hold data in a
filesystem format. If you have any part of a GPLed binary on that filesystem,
which is referenced by an inode or similar, and a non-free work (and you have
probably bunch of unlicenced non-free stuff, like this email for example),
referenced by another inode, then this doesn't make this email a derivative
work of the linux kernel.

> Compare it to including a hexdump of an image or sound in a header
> file and including that in the binary. And compare it with having that
> same image or sound as external file shipped in the same deb.

Well, the FSF argues that it is not important where the file is, as long as
there is a logical link, in order to have the GPL cross the dynamic linking
barrier. In the same way, the only relationship of the non-free firmware or
your image or sound, is that it is transported in the same binary, and used as
data offloaded to the peripheral device.

> Assume the image/sound was rendered/generated from some source format
> not included in the source. E.g. povray input.

So ? What has this to do with it ? 

> Is it an aggregation with the image linked into the binary?

It depends if your binary is an image compressor, and only transports the
image, or if said image is used in the binary for icons of its GUI for example
or as splash screen.

> >> "aggregated" code from the kernel image?
> > Not relevant.
> 
> If it is an aggregation then there must be a way to break it up and
> only keep the GPLed parts. I think that is very much relevant. I don't
> think you can call something an aggregation if it is inseperably bound
> together.

Well, sure there is part to separate them. You could imagine a (non-free) tool
called before lilo or grub, and which would upload those firmwares for the
peripheral device to be ready when the free driver comes into play.

Or you could use the new initramfs/firmware loading kernel infrastructure to
separate the firmware from the kernel.

Err, is not this latest one what you are suggesting we do ? So, if i
understood you well, your own argumentation is hitting you back there, and
this is usually proof that there is something terribly wrong in your
argumentation to start with.

Friendly,

Sven Luther


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

New desktop features provided by new version of update-notifier

[Gustavo Noronha Silva]

Fellow Debianers,

I'm writing to you all in order to present some new features added to
the Debian Desktop, and to discuss how we could make use of them in
some of our subsystems.

I just uploaded update-notifier 0.42.12-1 to unstable. Unfortunately I
lost dinstall for the day, so we'll only see the results in unstable
many hours from now, though I've uploaded them to a public location[0].

update-notifier is a program made by the Ubuntu guys which puts a
notification icon in the notification area and warns the user about
updates being available, and allowing them to run update-manager (a
simple upgrade manager tool based on Synaptic).

This version of the Debian package brings some more robust utnubu work,
such as making the reboot required notification and Debian CD insertion
detection work.

The first feature is useful for those packages which are critical, and
which really want a reboot after upgrade, such as kernel, perhaps libc,
and any library or package fixing security problems. These simply need
to run /usr/share/update-notifier/notify-reboot-required (which will
touch /var/run/reboot-required) on postinst, and a notification will
appear to the user at his desktop telling them that a reboot is
required, and allowing them after the package manager is done "applying
changes".

This is done in Ubuntu by communicating with GDM through a nice program
called gdm-signal, which was built using code from gnome-panel and some
more written by Rob Taylor, and which is distributed in Ubuntu's
powermanagement-interface package; I included this work in
update-notifier as a private program, for now, but maybe we should add
it to our gdm package? Ubuntu does not seem to have provisions for KDE;
if our KDE guys know how we'd go about doing the same for KDM, let me
know; same goes for XFCE and other desktops which support the
notification area protocol, and would, thus, be able to run
update-notifier.

The second feature is quite cool; update-notifier uses hal to detect
that a new CD/DVD was inserted and tries to figure out whether that is
a Ubuntu CD; I patched the program to also look for Debian CDs, and to
avoid messing with translations, the messages have Ubuntu replaced by
Debian in runtime, after the translation is got from gettext if the CD
that was inserted is a Debian CD.

I'm writing to all of you so that you are aware that these nice desktop
features are now included in Debian, and so we can discuss whether and
how we'll make use of them to accomplish a nicer Debian Desktop. Please
follow up issues related to a specific "subteam" in the approppriate
mailing list, but please keep me CC'ed.

For coolness effect, here's the first time I saw a Debian CD being
detected in my desktop:

http://kov.eti.br/~kov/update-notifier-debian-cd.png

See you,

[0]: http://people.debian.org/~kov/stuff/

-- 
Gustavo Noronha Silva <[EMAIL PROTECTED]>
http://people.debian.org/~kov/


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

Bug#382720: Error at configure

[Patrick Matthäi]

Package: initramfs-tools
Version: 0.73d

Hello,
The newest update of initramfs-tools seems to be broken by me.


Richte initramfs-tools ein (0.73d) ...
update-initramfs: Generating /boot/initrd.img-2.6.17-1-k7
/usr/sbin/mkinitramfs: line 206: [: /etc/initramfs-tools/conf.d/resume: 
binary operator expected


Richte thunderbird ein (1.5.0.5-1) ...
Returned debconf: Debian



the-me:/home/me# dpkg-reconfigure initramfs-tools
update-initramfs: Generating /boot/initrd.img-2.6.17-1-k7
/usr/sbin/mkinitramfs: line 206: [: /etc/initramfs-tools/conf.d/resume: 
binary operator expected

the-me:/home/me# cat /etc/initramfs-tools/conf.d/resume
RESUME=/dev/hda5

hda5 is the right partititon.


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

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Goswin von Brederlow]

Sven Luther <[EMAIL PROTECTED]> writes:

> On Sat, Aug 12, 2006 at 10:32:54PM +0200, Goswin von Brederlow wrote:
>> > Indeed. The proposal to split the packages file in a per flavour kernel
>> > repository comes directly from the need to counterbalance this 
>> > augmentation of
>> > the number of packages.
>> 
>> So instead of having 5 module udebs for my ONE generic kernel I get
>> 200? For say amd64 it would be a big step back.
>
> Indeed, but smaller ones.
>
>> How many archs with flavours are we talking about anyway? I think m68k
>> has 3 flavours and ppc some and every other archs has a generic
>> flavour or drivers buildin already.
>
> I know that the more exotic ones have many flavours. Also, the amount of
> packages will be proportional of the non-builtin drivers. POwerpc has
> currently 5 d-i flavours (or would have if the new d-i powerpc people did they
> work correctly), powerpc, powerpc64, powerpc-miboot, prep and apus. 

So the worst case is 5 flavours while most archs have only one. Your
solution would cut the number of kernel udebs by at most a factor of 5
while you want to increase by a factor of 40. That is still a net loss
by a factor of 8 for 5 flavours.

>> So why then do you want to split module udebs?
>
> Because the current way of doing it is problematic. The d-i folk don't want to
> give control of it to the kernel team, and the new proposal handled they
> keeping the same and even better control of how to build the ramdisks, while
> at the same time building the module .udebs from the common kernel source,
> thus saving around 2 weeks of time the d-i folk need to adjust to a new abi or
> version, thus making for more timely kernel security updates, and making the
> work of the divers security teams easier.

Who controls the udebs has nothing to do with splitting the module
udebs into smaller chunks. You could split them while D-I has control
of them or have them build by the kernel team and not split them up
further or do both. The two issues are independent of each other.

>> You just agreed that downloading the module udebs is inconsequential
>> given their size. You agreed that more udebs increases the Index files
>> which is bad.
>
> Err, let's say we have 5 flavours like on powerpc, and each would have 200+
> little module .udebs, which gives us Package numbers of 1000+. Worse if there
> are more flavours. This is the part that joeyh objected to this plan of
> spliting modules because of the fact that d-i loads three in memory copy of
> the Packages file, which in turn prompted the idea of per-flavour
> repositories.
>
> If you look at the whole idea though, you find out that it is a really neat
> solution to this problem, it cares for all the technical hurdles, and is
> elegant and nice, and if you throw in the part that can be automated, it saves
> work for everyone involved.

Say you do get your per flavour split despite increasing the number of
kernel modules worst arch has to deal with by a factor of 8 and for
most archs a factor of 40.

Can you imaging the poor users of a low-mem system going through the
list of 200+ components to pick out the right modules to download?
Neat?

> In my book, this makes it a good idea, or at least something that should be
> tried, and not something you have to menace the implementator so he doesn't
> dare pursue it.
>
>> So all I'm left with is that you don't end up with as much modules in
>> the ramdisk. Something I find irelevant unless you talk about the
>> low-mem flavour.
>
> And the fact that it is much easier to update config option and add and remove
> new modules doesn't count. Naturally, you don't handle kernel .udebs. I did,
> and it was a royal pain in the ass to handle those, it took me hours, for
> stuff that was already done 10 times for the other flavours. And even a few
> days ago, the powerpc64 flavour was still broken with the 2.6.17 kernels,
> because some random module listed in the list of modules was not present.
>
> The whole concept is of an extreme fragility, prone to break again and again,
> cause lot of work for all involved, who become irritable, and bash on you when
> you even mention it.

I did it when working on the amd64 D-I for sarge. I found it quite
trivial to do, a matter of minutes. In fact a hell of a lot simpler
and way faster than getting the linux-2.6 source package to do
something for me.

The kernel-wedge lists do break from time to time but they are simple
to adjust and quick to rebuild.

And another advantage with kernel-wedge: You can easily take your
(maybe even prebuild) custom kernel and create udebs from it. I would
hate to have to add the SuSe or RH patch sets to the linux-2.6 source
to build kernel udebs for hardware that requires their patches.

> This, in my book, is not an example of good software engineering, and any
> proposal to help improve this should be worth considering.

Still not convinced. You do have some points but I see more drawbacks
and problems than advantages.

>> Is

Bug#382740: /usr/sbin/mkinitramfs: line 206: [: /etc/initramfs-tools/conf.d/resume: binary operator expected

[Arthur Marsh]

Package: initramfs-tools
Version: 0.73d
Severity: important


When installing initramfs-tools I get:

Setting up initramfs-tools (0.73d) ...
update-initramfs: Generating /boot/initrd.img-2.6.17
/usr/sbin/mkinitramfs: line 206: [: /etc/initramfs-tools/conf.d/resume: 
binary operator expected
I: mdadm: RAID support installed to mount all RAID arrays during boot.
I: mdadm: use `dpkg-reconfigure -plow mdadm` to change this.

The script does appear to successfully make a new initramfs

-- Package-specific info:
-- /proc/cmdline
root=/dev/hda5 ro noisapnp 

-- /proc/filesystems
cramfs
ext3
vfat

-- lsmod
Module  Size  Used by
iptable_filter  3072  0 
ip_tables  13380  1 iptable_filter
x_tables   13508  1 ip_tables
binfmt_misc11304  1 
ppdev   8516  0 
lp 10948  0 
apm20176  1 
realtime3976  0 
commoncap   6944  1 realtime
ipv6  223648  20 
cifs  185664  2 
nls_iso8859_1   4224  1 
nls_utf82176  4 
nls_cp437   5888  3 
vfat   11936  3 
fat46780  1 vfat
dm_snapshot15716  0 
dm_mirror  19504  0 
dm_mod 50712  2 dm_snapshot,dm_mirror
snd_emu10k1_synth   6912  0 
snd_emux_synth 31360  1 snd_emu10k1_synth
snd_seq_virmidi 7296  1 snd_emux_synth
snd_seq_midi_emul   5920  1 snd_emux_synth
snd_seq_dummy   3940  0 
snd_seq_oss30400  0 
snd_seq_midi8128  0 
snd_seq_midi_event  7008  3 snd_seq_virmidi,snd_seq_oss,snd_seq_midi
shpchp 34504  0 
pci_hotplug27908  1 shpchp
snd_seq47536  9 
snd_emux_synth,snd_seq_virmidi,snd_seq_midi_emul,snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event
tsdev   7424  0 
mousedev   10824  1 
snd_emu10k1   103524  2 snd_emu10k1_synth
snd_rawmidi23008  3 snd_seq_virmidi,snd_seq_midi,snd_emu10k1
snd_ac97_codec 83232  1 snd_emu10k1
snd_ac97_bus2400  1 snd_ac97_codec
snd_pcm_oss36800  0 
snd_mixer_oss  16704  1 snd_pcm_oss
snd_pcm75652  3 snd_emu10k1,snd_ac97_codec,snd_pcm_oss
snd_seq_device  7916  8 
snd_emu10k1_synth,snd_emux_synth,snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq,snd_emu10k1,snd_rawmidi
snd_timer  21316  3 snd_seq,snd_emu10k1,snd_pcm
snd_page_alloc  9544  2 snd_emu10k1,snd_pcm
snd_util_mem4608  2 snd_emux_synth,snd_emu10k1
snd_hwdep   8996  2 snd_emux_synth,snd_emu10k1
snd50148  16 
snd_emux_synth,snd_seq_virmidi,snd_seq_dummy,snd_seq_oss,snd_seq,snd_emu10k1,snd_rawmidi,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_device,snd_timer,snd_hwdep
psmouse34728  0 
parport_pc 32324  1 
parport33640  3 ppdev,lp,parport_pc
emu10k1_gp  3840  0 
gameport   14728  2 emu10k1_gp
serio_raw   6596  0 
evdev   9088  1 
intel_agp  21148  1 
agpgart30028  1 intel_agp
i2c_piix4   8560  0 
i2c_core   19968  1 i2c_piix4
pcspkr  3072  0 
8250_pnp8736  0 
rtc12564  0 
floppy 54596  0 
soundcore   9600  1 snd
ext3  119080  2 
jbd53044  1 ext3
mbcache 8452  1 ext3
raid1  21216  1 
md_mod 69748  2 raid1
ide_cd 35712  0 
cdrom  32544  1 ide_cd
ide_disk   15200  10 
generic 4452  0 [permanent]
usbhid 35840  0 
piix9508  0 [permanent]
ohci_hcd   18564  0 
ehci_hcd   28296  0 
uhci_hcd   20680  0 
ide_core  112264  4 ide_cd,ide_disk,generic,piix
usbcore   112544  5 usbhid,ohci_hcd,ehci_hcd,uhci_hcd
8139cp 20832  0 
8139too25088  0 
mii 5312  2 8139cp,8139too
processor  25736  0 


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)

Versions of packages initramfs-tools depends on:
ii  busybox   1:1.1.3-2  Tiny utilities for small and embed
ii  cpio  2.6-17 GNU cpio -- a program to manage ar
ii  klibc-utils   1.4.19-1   small statically-linked utilities 
ii  module-init-tools 3.2.2-3tools for managing Linux kernel mo
ii  udev  0.093-1/dev/ and hotplug ma

Bug#382740: initramfs-tools: if statement incorrect

[Michael Setzer]

Package: initramfs-tools
Version: 0.73d
Followup-For: Bug #382740

The if statement in line 206 has an error in it,
it must read

if [ -e "${CONFDIR}/conf.d/${i}" ]; then

and not

if [ -e "${CONFDIR}/conf.d/${i}" /conf/conf.d ]; then

Best wishes,

Michael

-- Package-specific info:
-- /proc/cmdline
root=/dev/hda6 ro vga=794 

-- /proc/filesystems
cramfs
reiserfs
ntfs
vfat

-- lsmod
Module  Size  Used by
nfsd  198596  17 
exportfs5888  1 nfsd
ppdev   8772  0 
lp 11108  0 
button  6800  0 
ac  5124  0 
battery 9476  0 
autofs419844  2 
ipv6  223968  18 
nfs   195404  1 
lockd  54152  3 nfsd,nfs
nfs_acl 3840  2 nfsd,nfs
sunrpc138876  13 nfsd,nfs,lockd,nfs_acl
nls_cp437   6144  1 
vfat   12288  1 
fat47196  1 vfat
nls_iso8859_1   4480  2 
ntfs  197844  1 
dm_snapshot15968  0 
dm_mirror  19216  0 
dm_mod 50520  2 dm_snapshot,dm_mirror
sr_mod 16228  0 
sbp2   21128  0 
eeprom  7248  0 
w83l785ts   7184  0 
asb100 19156  0 
hwmon_vid   2880  1 asb100
nvidia   4549844  10 
ide_generic 1664  0 [permanent]
tsdev   7680  0 
snd_intel8x0   30428  0 
mousedev   11108  0 
snd_ac97_codec 82976  1 snd_intel8x0
snd_ac97_bus2624  1 snd_ac97_codec
evdev   9344  1 
snd_pcm_oss36704  0 
snd_mixer_oss  16192  1 snd_pcm_oss
eth139418564  0 
nvidia_agp  7772  1 
agpgart30152  2 nvidia,nvidia_agp
snd_pcm74884  3 snd_intel8x0,snd_ac97_codec,snd_pcm_oss
snd_timer  21124  1 snd_pcm
i2c_nforce2 6912  0 
snd48548  6 
snd_intel8x0,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
soundcore   9440  1 snd
snd_page_alloc  9800  2 snd_intel8x0,snd_pcm
shpchp 34528  0 
pci_hotplug27516  1 shpchp
i2c_core   19904  5 eeprom,w83l785ts,asb100,nvidia,i2c_nforce2
parport_pc 32612  1 
parport33544  3 ppdev,lp,parport_pc
analog 10976  0 
8250_pci   20160  0 
rtc12724  0 
floppy 54788  0 
psmouse34888  0 
serio_raw   6852  0 
pcspkr  3328  0 
8250_pnp8960  0 
gameport   14600  1 analog
sd_mod 19008  0 
reiserfs  214464  1 
usb_storage71488  0 
ide_cd 36128  0 
cdrom  32864  2 sr_mod,ide_cd
ide_disk   15360  5 
sata_nv 9668  0 
libata 62476  1 sata_nv
scsi_mod  123784  5 sr_mod,sbp2,sd_mod,usb_storage,libata
generic 4676  0 [permanent]
ohci_hcd   18500  0 
ehci_hcd   28360  0 
usbcore   112384  4 usb_storage,ohci_hcd,ehci_hcd
forcedeth  26700  0 
amd74xx12956  0 [permanent]
ide_core  111432  6 
ide_generic,usb_storage,ide_cd,ide_disk,generic,amd74xx
ohci1394   31088  0 
ieee1394   88056  3 sbp2,eth1394,ohci1394
thermal13128  0 
processor  25800  1 thermal
fan 4804  0 


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-1-k7
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages initramfs-tools depends on:
ii  busybox   1:1.1.3-2  Tiny utilities for small and embed
ii  cpio  2.6-17 GNU cpio -- a program to manage ar
ii  klibc-utils   1.4.19-1   small statically-linked utilities 
ii  module-init-tools 3.2.2-3tools for managing Linux kernel mo
ii  udev  0.093-1/dev/ and hotplug management daemo

initramfs-tools recommends no packages.

-- no debconf information


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

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Thomas Bushnell BSG]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Is it an aggregation with the image linked into the binary?

It doesn't matter for Debian's purposes.

While the GPL permits shipping a GPL'd program "merely aggregated"
alongside a non-free program, we don't ship the nonfree part no matter
what, so it hardly matters to us whether it's also a GPL violation.

Thomas


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

Re: Move of update-grub and grub-install to /usr/sbin

[Geert Stappers]

On Fri, Aug 11, 2006 at 06:10:15PM -0300, Otavio Salvador wrote:
> Hello,
> 
> I plan to upload a group of changes to grub and grub-installer to
> move update-grub and grub-install to /usr/sbin/.
> 
> For this to happen, my transition plan is described bellow:
> 
>  - A new grub package would be uploaded to unstable having a group of
>wrappers that will call /usr/sbin utilities but warn the user to
>edit his/her /etc/kernel-img.conf. That keeps backward
>compatibility with previous kernels and will be in place until Etch
>is released,
> 
>  - A NEWS.Debian entry describing the change in grub would be add too,
> 
>  - grub-installer would have a change to don't use full paths in
>kernel-img.conf entries _but_ this one need to migrate to etch
>together with linux-2.6 2.6.17-6 OR new installations will be
>broken.
> 
> RM team, is ok to me go forward with it?

I think the above misses the _why_

The announce only mentions the new, the proposed, location.

I'm happy with the removal of the full paths, but not happy with /usr/sbin

Please allow to "grub install" _without_ the filesystem _/usr mounted_.
So either move it to /bin or /sbin, both are mounted when in single user
mode (as mostly used for recovery)


Cheers
Geert Stappers


signature.asc
Description: Digital signature

Re: Move of update-grub and grub-install to /usr/sbin

[Otavio Salvador]

Geert Stappers <[EMAIL PROTECTED]> writes:

>> RM team, is ok to me go forward with it?
>
> I think the above misses the _why_
>
> The announce only mentions the new, the proposed, location.
>
> I'm happy with the removal of the full paths, but not happy with /usr/sbin
>
> Please allow to "grub install" _without_ the filesystem _/usr mounted_.
> So either move it to /bin or /sbin, both are mounted when in single user
> mode (as mostly used for recovery)

You don't need grub-install to install grub and usually, when
something gets wrong, you use the grub console to workaround the
problem.

grub-install and update-grub uses binaries provided by /usr/bin and
won't work anyway.

-- 
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://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."


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

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Goswin von Brederlow]

Sven Luther <[EMAIL PROTECTED]> writes:

> On Sat, Aug 12, 2006 at 11:03:29PM +0200, Goswin von Brederlow wrote:
>> Compare it to including a hexdump of an image or sound in a header
>> file and including that in the binary. And compare it with having that
>> same image or sound as external file shipped in the same deb.
>
> Well, the FSF argues that it is not important where the file is, as long as
> there is a logical link, in order to have the GPL cross the dynamic linking
> barrier. In the same way, the only relationship of the non-free firmware or
> your image or sound, is that it is transported in the same binary, and used as
> data offloaded to the peripheral device.
>
>> Assume the image/sound was rendered/generated from some source format
>> not included in the source. E.g. povray input.
>
> So ? What has this to do with it ? 

So you can't claim the hexdump (or binary file) is the prefered form
of modification (source).

>> Is it an aggregation with the image linked into the binary?
>
> It depends if your binary is an image compressor, and only transports the
> image, or if said image is used in the binary for icons of its GUI for example
> or as splash screen.

If I just dump my hexcode of the image/sound to my black box (qiv or
xmms for example) for (dis)playing then I only transport the file. If
I (dis)play it myself then it isn't an aggregation. Intresting.

Or does the black box have to be hardware?

>> >> "aggregated" code from the kernel image?
>> > Not relevant.
>> 
>> If it is an aggregation then there must be a way to break it up and
>> only keep the GPLed parts. I think that is very much relevant. I don't
>> think you can call something an aggregation if it is inseperably bound
>> together.
>
> Well, sure there is part to separate them. You could imagine a (non-free) tool
> called before lilo or grub, and which would upload those firmwares for the
> peripheral device to be ready when the free driver comes into play.

I can imagine a tool that rewrites non-free parts of a binary as free
software from scratch without breaking any laws about reverse
engeneering too. Does that mean they exist or are even possible? no.

> Or you could use the new initramfs/firmware loading kernel infrastructure to
> separate the firmware from the kernel.

That requires changes in the source. Exactly those changes is what I
say must happen. The firmware loading kernel infrastructure marks a
clear lines where an external blob of firmware gets loaded that isn't
part of the kernel binary itself.

> Err, is not this latest one what you are suggesting we do ? So, if i
> understood you well, your own argumentation is hitting you back there, and
> this is usually proof that there is something terribly wrong in your
> argumentation to start with.

No. You just argumented my point. The source changes to seperate the
firmware and to use the firmware loading kernel infrastructure makes a
difference imho.

Also notice that with the firmware loading kernel infrastructure you
can just delete the firmware file and the loader will give a simple
error. Good luck trying to remove the char *firmware from a kernel
image and not have it crash. Best you can do there is fill it with
dummy data.

> Friendly,
>
> Sven Luther

MfG
Goswin


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

Re: barriers on filesystems for laptops by default?

[martin f krafft]

debian-kernel on CC, here's the base URL:
  http://lists.debian.org/debian-boot/2006/08/msg00408.html

If there are discussion, I suggest we remove debian-boot from CC!
I thus set reply-to to d-k.

also sprach martin f krafft <[EMAIL PROTECTED]> [2006.08.12.1236 +0100]:
> I guess I'll approach Hans Razor and Theodore about this.

Here's Theo:

  This is correct, and Chris Mason has recently submitted patches to
  change the default.  (For both ext3 and reiserfs)

  The reason why it was disabled at first was because it was new
  code, and concerns about whether drives would implement it
  properly, and whether there were any problems with the code.
  Probably too much time passed between when the code was introduced
  and when it was enabled by default, but most filesystem developers
  are a conservative bunch, and while they might be willing to
  enable features when it is their own data at risk, they are less
  willing to enable it by default and inflict said changes on users
  without being 100% sure that it is bugfree(tm).

  The patches were submitted about a week ago on LKML; it probably
  would be appropriate to include them in the next spin of the
  Debian kernel image.

Thus, please include the patch...

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"it is impossible to foresee the consequences of being clever."
-- cristopher strachey


signature.asc
Description: Digital signature (GPG/PGP)