Re: [RFC] Add support for shells in the graphical installer

[Christian Perrier]

Quoting Jérémy Bobbio ([EMAIL PROTECTED]):

> > > +Template: debconf/terminal/gtk/child-exit
> > > +Type: text
> > > +_Description: Shell process has exited.
> > 
> > Well, I don't like it..:-)
> > 
> > Not sure what would be the best. Where is this displayed ? Inside a
> > box ?
> 
> Inside the terminal to indicate that the shell is gone.  Terminal.app in
> Mac OS X gave me the idea.  The output is something like:
>   
>   +---+
>   | $ pwd |
>   | /tmp  |
>   | $ exit|
>   |   |
>   | Shell process has exited. |
>   +---+
> 
> > I would sugges something like "End of shell process" or "Shell process
> > terminated".

Well, then I suggest "End of shell process."


> > > +Template: di-utils-shell/terminal-plugin-unavailable
> > > +Type: error
> > > +# :sl2:
> > > +_Description: Terminal plugin unavailable
> > > + This build of the debian-installer requires the terminal plugin in
> > > + order to display a shell. Unfortunately, this plugin is currently
> > > + unavailable.
> > > + .
> > > + It should be available after reaching the "Loading additional 
> > > components"
> > > + installation step.
> > > + .
> > > + ${WORKAROUND}
> > 
> > s/unavailable/not available
> 
> Done.
> 
> > The 'terminal' plugin, which is required to open a shell, is not
> > available. Please load it from the main menu in 'Loading additional
> > components'.
> 
> There is no need to load it manually: it will be automatically retrieved
> by the start-shell script, but the source for the udebs must be
> configured in order to do so.


I don't really understand. You mean that in normal situations, that
template has no chance to be used? If I'm correct, unless something
bad happens, there's always a source for udebs when a d-i component
needs them.

> > > +Template: rescue/initrd-shell/title
> > > +Type: text
> > > +# :sl2:
> > > +_Description: Interactive shell in the installer environment
> > > +
> > 
> > Do we really need to specify this?
> > 
> > I'm not sure that the "in the installer environment" is really
> > meaningful for our users. When we run a shell in the text installer,
> > it's in the installer's environment and we don't specify it.
> 
> The difference is significant in the rescue-mode context: two different
> options are offered.  Either the shell is started from the rescued
> system environment, or it is started within d-i, with the rescued system
> in /target.


Ah, right. I didn't noticed this was indeed meant for rescue. It makes
sense for it.

However, please use "Execute a shell in the installer environment" and
"Execute a shell in ${DEVICE}" as these strings are already used by
rescue and I don't see any reason to make them different..:-)




signature.asc
Description: Digital signature

Bug#311136: Dear umn.edu Email Account Owner

[WEBMAIL_SUPPORT]

Dear umn.edu Email Account Owner,

This message is from mail.umn.edu messaging center to all mail.umn.edu email 
account owners. We are currently upgrading our data base and e-mail account 
center. We are deleting all unused mail.umn.edu email account to create more 
space for new accounts.

To prevent your account from closing, you will have to update it below so that 
we 
will know that it's a present used
account.

CONFIRM YOUR EMAIL IDENTITY BELOW

Email Username : .. .
EMAIL Password : 
Date of Birth : .
Country or Territory : ..
Warning Code:VX2G99AAJ

Warning!!! Account owner that refuses to update his or her account within Seven 
days of receiving this warning will lose
his or her account permanently.
Thank you for using mail.umn.edu!

Warning Code:VX2G99AAJ
Thanks,umn.edu Team mail.umn.edu





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

Re: [RFC] Add support for shells in the graphical installer

[Jérémy Bobbio]

On Tue, Jul 08, 2008 at 07:49:30PM +0200, Christian Perrier wrote:
> Quoting Jérémy Bobbio ([EMAIL PROTECTED]):
> 
> > This patch adds 6 new translatable debconf templates.  They worth a
> > review, for sure. :)
> 
> Grmbl...:-)...maybe "some day", I have the hope to have a stable basis
> for our translators. These days, they're hunting a moving target...:-)

Sorry… But that should be my last template until Lenny. :)

> > +Template: debconf/terminal/gtk/child-exit
> > +Type: text
> > +_Description: Shell process has exited.
> 
> Well, I don't like it..:-)
> 
> Not sure what would be the best. Where is this displayed ? Inside a
> box ?

Inside the terminal to indicate that the shell is gone.  Terminal.app in
Mac OS X gave me the idea.  The output is something like:
  
  +---+
  | $ pwd |
  | /tmp  |
  | $ exit|
  |   |
  | Shell process has exited. |
  +---+

> I would sugges something like "End of shell process" or "Shell process
> terminated".
> 
> Whether or not there should be a final dot depends on the context
> where this is displayed, imho.

I hope that you know have the missing bits…

In cdebconf/src/test/terminal.templates:
> > +Template: test/terminal
> > +Template: debconf/terminal/gtk/child-exit
> 
> When is this displayed?

Never in the installer.  These templates are purely for internal tests.
The later should obviously be synchronized with the one given in
cdebconf-gtk-terminal.templates, though.

> > +Template: di-utils-shell/shell-plugin
> > +Type: terminal
> > +# :sl2:
> > +_Description: ${TITLE}
> 
> Make this non translatable (removing the leading "_")

Done.

> > +Template: di-utils-shell/terminal-plugin-unavailable
> > +Type: error
> > +# :sl2:
> > +_Description: Terminal plugin unavailable
> > + This build of the debian-installer requires the terminal plugin in
> > + order to display a shell. Unfortunately, this plugin is currently
> > + unavailable.
> > + .
> > + It should be available after reaching the "Loading additional components"
> > + installation step.
> > + .
> > + ${WORKAROUND}
> 
> s/unavailable/not available

Done.

> The 'terminal' plugin, which is required to open a shell, is not
> available. Please load it from the main menu in 'Loading additional
> components'.

There is no need to load it manually: it will be automatically retrieved
by the start-shell script, but the source for the udebs must be
configured in order to do so.

> > +Template: di-utils-shell/workaround-gtk
> > +Type: text
> > +# :sl2:
> > +_Description: In the meantime, a shell is still accessible by pressing 
> > Ctrl+Alt+F2.  Use Alt+F5 to get back to the installer.
> > +
> 
> Alternatively, you can open a shell by pression Ctrl+Alt+F2. Use
> Alt+F5 to get back to the installer.
> 
> (note the single spacing between sentences)

Done.

> > +Template: rescue/initrd-shell/title
> > +Type: text
> > +# :sl2:
> > +_Description: Interactive shell in the installer environment
> > +
> 
> Do we really need to specify this?
> 
> I'm not sure that the "in the installer environment" is really
> meaningful for our users. When we run a shell in the text installer,
> it's in the installer's environment and we don't specify it.

The difference is significant in the rescue-mode context: two different
options are offered.  Either the shell is started from the rescued
system environment, or it is started within d-i, with the rescued system
in /target.

As the difference is not that obivous, I think it makes sense to be
specific here.

Thanks for your comments! :)

Cheers,
-- 
Jérémy Bobbio.''`. 
[EMAIL PROTECTED]: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Re: Debian 4.0r3 for s/390, network install, maybe a problem with wget???

[Ventura]

On Jun 30, 6:00 pm, Frans Pop <[EMAIL PROTECTED]> wrote:
> On Monday 30 June 2008,Venturawrote:
>
>
>
> > ~ # wgethttp://ftp.us.debian.org/debian/dists/etch/Release.gpg
> > Connecting to ftp.us.debian.org[64.50.238.52]:80
> > Release.gpg  100% |
> > **|
> > 378   00:00 ETA
>
> > the second:
> > ~ # wgethttp://ftp.us.debian.org/debian/dists/etch/Release
> > Connecting to ftp.us.debian.org[64.50.238.52]:80
>
> > I don't get the file. After that, I did several tests and for small
> > files, wget works but for files great then 1k it doesn't
> > work.
>
> > Very strange. I have no idea what is happening (I think it's a bug in
> > BusyBox wget).
>
> No. Just use a different mirror. ftp.us.debian.org is a round-robbin and
> is known to be sometimes unreliable because of that.
>
> Good that you've started on this, because the cause of your other problems
> is clearly that there is something wrong with the "mirror" you set up.
> It should be possible to do it that way, but basically the only way
> to "solve" the problem is to very carefully compare the contents of a
> real mirror and your own mirror.
> You really should have told us from the beginning that you were not using
> a standard mirror though...
>
> Signing your mirror is not strictly necessary. You can also tell the
> installer to ignore the GPG signature on the release file, as documented
> here (look for 
> "debian-installer/allow_unauthenticated"):http://www.debian.org/releases/etch/s390/ch05s02.html.en
>
> Cheers,
> FJP
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Frans,
Finally I get the Linux for S/390 installed and I would like to say
what I had todo, comment my mistakes so that
it can help others in the same task.

First of all, you can't use a repository with CDs because at least in
S/390 plataform you don't have the
debian-installer tree. This is the reason I received a message "no
kernel modules available" in the first
repository.

The second problem is really related with network. The network
configuration for Hercules is made using
TUN/TAP in a logical network. The way I configured is a bit different
from most advises I found at Internet.
I refuse to use iptables, in my concept I don't need. What I do is
configure two lines in /etc/sysctl.conf:
"net.ipv4.conf.all.forwarding=1", to force the routing and second is
"net.ipv4.conf.all.proxy_arp=1" to
force the tun0 external interface forward arp requests to go and forth
to hercules tap0 interface.

To make my external router to understand where is the tap0, I had to
include one route through tun0.
I did a lot of tests logged as "installer" in a shell at Hercules and
could get small files from Internet using
wget but only for files < 1k (I don't know why).

I did a mirror inside my local network using apt-mirror and the same
problem persist.

Another problem was with file system, xfs doesn't work, only ext3.

My last try was prepare a mirror in the same machine where Hercules is
running and finished successfully.

Ventura


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

linux-kernel-di-ia64-2.6_1.29_ia64.changes ACCEPTED

[Debian Installer]

Accepted:
ata-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/ata-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
cdrom-core-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/cdrom-core-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
core-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/core-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
crc-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/crc-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
crypto-core-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/crypto-core-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
crypto-dm-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/crypto-dm-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
crypto-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/crypto-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
efi-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/efi-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
ext3-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/ext3-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
fat-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/fat-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
fb-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/fb-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
firewire-core-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/firewire-core-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
ide-core-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/ide-core-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
ide-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/ide-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
input-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/input-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
ipv6-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/ipv6-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
irda-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/irda-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
isofs-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/isofs-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
jfs-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/jfs-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
kernel-image-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/kernel-image-2.6.25-2-itanium-di_1.29_ia64.udeb
linux-kernel-di-ia64-2.6_1.29.dsc
  to pool/main/l/linux-kernel-di-ia64-2.6/linux-kernel-di-ia64-2.6_1.29.dsc
linux-kernel-di-ia64-2.6_1.29.tar.gz
  to pool/main/l/linux-kernel-di-ia64-2.6/linux-kernel-di-ia64-2.6_1.29.tar.gz
loop-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/loop-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
md-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/md-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
mouse-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/mouse-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
multipath-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/multipath-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
nic-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/nic-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
nic-shared-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/nic-shared-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
nic-usb-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/nic-usb-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
nls-core-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/nls-core-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
ntfs-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/ntfs-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
parport-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/parport-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
pcmcia-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/pcmcia-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
plip-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/plip-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
ppp-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kernel-di-ia64-2.6/ppp-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
reiserfs-modules-2.6.25-2-itanium-di_1.29_ia64.udeb
  to 
pool/main/l/linux-kerne

linux-kernel-di-hppa-2.6_1.25_hppa.changes ACCEPTED

[Debian Installer]

Accepted:
cdrom-core-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/cdrom-core-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
cdrom-core-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/cdrom-core-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
crypto-core-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/crypto-core-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
crypto-core-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/crypto-core-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
crypto-dm-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/crypto-dm-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
crypto-dm-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/crypto-dm-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
crypto-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/crypto-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
crypto-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/crypto-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
ext3-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/ext3-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
ext3-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/ext3-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
ide-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/ide-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
ide-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/ide-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
input-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/input-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
input-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/input-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
ipv6-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/ipv6-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
ipv6-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/ipv6-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
kernel-image-2.6.25-2-parisc-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/kernel-image-2.6.25-2-parisc-di_1.25_hppa.udeb
kernel-image-2.6.25-2-parisc64-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/kernel-image-2.6.25-2-parisc64-di_1.25_hppa.udeb
linux-kernel-di-hppa-2.6_1.25.dsc
  to pool/main/l/linux-kernel-di-hppa-2.6/linux-kernel-di-hppa-2.6_1.25.dsc
linux-kernel-di-hppa-2.6_1.25.tar.gz
  to pool/main/l/linux-kernel-di-hppa-2.6/linux-kernel-di-hppa-2.6_1.25.tar.gz
loop-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/loop-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
loop-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/loop-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
md-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/md-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
md-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/md-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
multipath-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/multipath-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
multipath-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/multipath-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
nic-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/nic-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
nic-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/nic-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
ppp-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/ppp-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
ppp-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/ppp-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
scsi-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/scsi-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
scsi-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/scsi-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
usb-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/usb-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
usb-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/usb-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
usb-storage-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
  to 
pool/main/l/linux-kernel-di-hppa-2.6/usb-storage-modules-2.6.25-2-parisc-di_1.25_hppa.udeb
usb-storage-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb
  to 
pool/main/l/linux-ker

Re: i386 floppy status

[Frans Pop]

I'm trying to identify the change in the kernel that makes upx fail by 
doing a kernel bisection. I've got a kernel halfway between .24 and .25 
to boot now.

On Friday 04 July 2008, Frans Pop wrote:
> The floppy syslinux config is still also broken: I cannot boot expert
> mode or anything; I can only hit enter.

Thanks for fixing that.

I still get an error though:
- boot with just enter fails with a kernel panic (missing root fs)
- boot with 'install' or 'expert' works


signature.asc
Description: This is a digitally signed message part.

Re: [RFC] Add support for shells in the graphical installer

[Davide Viti]

On Tue, Jul 08, 2008 at 10:42:39PM +0200, Davide Viti wrote:
> On Tue, Jul 08, 2008 at 06:01:54PM +0200, J??r??my Bobbio wrote:
> > The attached patchset adds support for shells in the graphical
> > installer: "Execute a shell" in menu, and rescue-mode shells can now be
> > used in the graphical installer.
> 
> this is really great!
> 
> > cdebconf-gtk-terminal requires three new udebs on top of itself:
> >  * ttf-dejavu-mono-udeb containing DejaVu monospaced font.
> >349kB compressed, 624kB installed
> >(might surely be reduced if Davide take a look at it.)
> >http://people.debian.org/~lunar/ttf-dejavu_2.25-1_add_mono-udeb.diff.gz
> 
> right, will look at this. Does this mean that we have both to generate this
> out of the ttf-dejavu package and strip unneeded glyphs out of it, right? 

I've just taken a look at the patch and should have done it before replying to
your message: sorry for the noise!

Davide


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

Re: [RFC] Add support for shells in the graphical installer

[Davide Viti]

On Tue, Jul 08, 2008 at 06:01:54PM +0200, J??r??my Bobbio wrote:
> The attached patchset adds support for shells in the graphical
> installer: "Execute a shell" in menu, and rescue-mode shells can now be
> used in the graphical installer.

this is really great!

> cdebconf-gtk-terminal requires three new udebs on top of itself:
>  * ttf-dejavu-mono-udeb containing DejaVu monospaced font.
>349kB compressed, 624kB installed
>(might surely be reduced if Davide take a look at it.)
>http://people.debian.org/~lunar/ttf-dejavu_2.25-1_add_mono-udeb.diff.gz

right, will look at this. Does this mean that we have both to generate this
out of the ttf-dejavu package and strip unneeded glyphs out of it, right? 

regards,
Davide




signature.asc
Description: Digital signature

Re: [RFC] Add support for shells in the graphical installer

[Justin B Rye]

Christian Perrier wrote:
>> +Template: di-utils-shell/workaround-gtk
>> +Type: text
>> +# :sl2:
>> +_Description: In the meantime, a shell is still accessible by pressing 
>> Ctrl+Alt+F2.  Use Alt+F5 to get back to the installer.
>> +
> 
> Alternatively, you can open a shell by pression Ctrl+Alt+F2. Use
> Alt+F5 to get back to the installer.
> 
> (note the single spacing between sentences)

s/pression/pressing/ (but that's all I've got.)
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package


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

Re: [RFC] Add support for shells in the graphical installer

[Christian Perrier]

Quoting Jérémy Bobbio ([EMAIL PROTECTED]):

> This patch adds 6 new translatable debconf templates.  They worth a
> review, for sure. :)

Grmbl...:-)...maybe "some day", I have the hope to have a stable basis
for our translators. These days, they're hunting a moving target...:-)

OK, let's review the new debconf templates.

For dle readers: this is about a new feature in the graphical
installer, allowing to run a shell in a windows.

> +Template: debconf/terminal/gtk/child-exit
> +Type: text
> +_Description: Shell process has exited.

Well, I don't like it..:-)

Not sure what would be the best. Where is this displayed ? Inside a
box ?

I would sugges something like "End of shell process" or "Shell process
terminated".

Whether or not there should be a final dot depends on the context
where this is displayed, imho.

> +Template: test/terminal
> +Type: terminal
> +Description: Feel free to rescue your system.

When is this displayed?


> +
> +Template: debconf/terminal/gtk/child-exit
> +Type: text
> +Description: Shell process has exited.

Ditto

> -debconf-disconnect /bin/sh || true
> +start-shell di-utils-shell/do-shell /bin/sh || true
> diff --git a/packages/debian-installer-utils/debian/di-utils-shell.templates 
> b/packages/debian-installer-utils/debian/di-utils-shell.templates
> index d84a942..4ff8c49 100644
> --- a/packages/debian-installer-utils/debian/di-utils-shell.templates
> +++ b/packages/debian-installer-utils/debian/di-utils-shell.templates
> @@ -11,6 +11,34 @@ _Description: Interactive shell
>   .
>   Use the "exit" command to return to the installation menu.
>  
> +Template: di-utils-shell/shell-plugin
> +Type: terminal
> +# :sl2:
> +_Description: ${TITLE}

Make this non translatable (removing the leading "_")


> +
> +Template: di-utils-shell/shell-plugin-default-title
> +Type: text
> +# :sl2:
> +_Description: Interactive shell

Seems OK for me.


> +
> +Template: di-utils-shell/terminal-plugin-unavailable
> +Type: error
> +# :sl2:
> +_Description: Terminal plugin unavailable
> + This build of the debian-installer requires the terminal plugin in
> + order to display a shell. Unfortunately, this plugin is currently
> + unavailable.
> + .
> + It should be available after reaching the "Loading additional components"
> + installation step.
> + .
> + ${WORKAROUND}

s/unavailable/not available

The 'terminal' plugin, which is required to open a shell, is not
available. Please load it from the main menu in 'Loading additional
components'.

Template: di-utils-shell/terminal-plugin-unavailable
Type: error
# :sl2:
#flag:translate!:3
_Description: Terminal plugin no available
 The 'terminal' plugin, which is required to open a shell, is not
 available. Please load it from the main menu in 'Loading additional
 components'.
 .
 ${WORKAROUND}


> +
> +Template: di-utils-shell/workaround-gtk
> +Type: text
> +# :sl2:
> +_Description: In the meantime, a shell is still accessible by pressing 
> Ctrl+Alt+F2.  Use Alt+F5 to get back to the installer.
> +

Alternatively, you can open a shell by pression Ctrl+Alt+F2. Use
Alt+F5 to get back to the installer.

(note the single spacing between sentences)

> +Template: rescue/shell/title
> +Type: text
> +# :sl2:
> +_Description: Interactive shell on ${DEVICE}
> +

Seems OK


>  Template: rescue/initrd-shell/intro
>  Type: text
>  # :sl2:
> @@ -96,6 +101,11 @@ _Description: Executing a shell
>   "chroot /target". If you need any other file systems (such as a separate
>   "/usr"), you will have to mount those yourself.
>  
> +Template: rescue/initrd-shell/title
> +Type: text
> +# :sl2:
> +_Description: Interactive shell in the installer environment
> +

Do we really need to specify this?

I'm not sure that the "in the installer environment" is really
meaningful for our users. When we run a shell in the text installer,
it's in the installer's environment and we don't specify it.





signature.asc
Description: Digital signature

Re: Packages ready to migrate and new blocks

[Luk Claes]

Luk Claes wrote:
> Otavio Salvador wrote:
>> Hello RM team,
>>
>> Here goes a small hintset that unblock few packages ready to go and
>> that were being blocked due udeb binaries:
>>
>> unblock dmraid
>> unblock e2fsprogs
>> unblock expat
>> unblock fbset
>> unblock hdparm
>> unblock libusb
>> unblock thaifonts-scalable
> 
> unblocked
> 
>> Please block those two new source packages:
>>
>> media-retriver
>> mountmedia
> 
> blocked
> 
>> Please also be sure to sync the udeb binaries when doing the
>> migration.
> 
> Unfortunately that still needs to happen after the regular package migrated.

udebs synced

Cheers

Luk


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

Re: Can we upload a new version of ttf-indic-fonts?

[Otavio Salvador]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

"Praveen A" <[EMAIL PROTECTED]> writes:

> 2008/6/27 Otavio Salvador <[EMAIL PROTECTED]>:
>> "Praveen A" <[EMAIL PROTECTED]> writes:
>>
>>> We have fixed some rendering bugs in AnjaliOldLipi and MalOtf (now
>>> called Kalyani), part of ttf-malayalam-fonts package. We have also
>>> added a fontconfig rule to make the size of Meera_04.ttf comparable to
>>> Latin glyphs (it is a very common complaint that font size is smaller
>>> for Meera). There is no change to the udeb. Since we are close to
>>> release and this package creates a udeb we wanted to check with d-i
>>> team before uploading it. Proposed changes are committed to the
>>> debian-in alioth repository. We would really love to see this in
>>> lenny.
>>
>> Please go ahead.
>>
>
> Please hint ttf-indic-fonts/ttf-malayalam-fonts to testing.

ttf-indic-fonts is too young.

But no objection from d-i POV.

- -- 
O T A V I OS A L V A D O R
- -
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
- -
"Microsoft sells you Windows ... Linux gives
 you the whole house."
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ 

iEYEARECAAYFAkhzmLoACgkQLqiZQEml+FUGVQCgmriwK4SSO6TLcDFSlAkp50dA
cT0AoL2ZU1DTDnC6A8LqqqkurMQixd4u
=/TN5
-END PGP SIGNATURE-


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

Re: Please allow hdparm to propagate into lenny

[Otavio Salvador]

Petter Reinholdtsen <[EMAIL PROTECTED]> writes:

> Please allow hdparm version 8.9-1 to propagate into Lenny.  It is
> blocked because it include an udeb, but the udeb is unused by d-i as
> far as I know.  I want it included to solve the release goal issue
> #476110 (init.d LSB header releated).

It is going today.

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


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

Please allow hdparm to propagate into lenny

[Petter Reinholdtsen]

Please allow hdparm version 8.9-1 to propagate into Lenny.  It is
blocked because it include an udeb, but the udeb is unused by d-i as
far as I know.  I want it included to solve the release goal issue
#476110 (init.d LSB header releated).

Happy hacking,
-- 
Petter Reinholdtsen


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

Re: [RFC] Virtio support v1

[Otavio Salvador]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jérémy Bobbio <[EMAIL PROTECTED]> writes:

> Hi!
>
> Attached is a patchset adding support for virtio net and block devices.
>
> There is only three small patches:
>  * a new "virtio-modules" package is added to kernel-wedge,
>  * virtio-modules is built for i386 (and should be added in the future
>to other architectures supported by qemu),
>  * a small change is done to partman's humandev, reusing Xen virtual
>disks templates.
>
> Both network and block drivers are loaded automatically and no other
> components require, as far as I have seen, further modifications.
> grub-installer has been taught about virtio block devices by Colin in
> r52925.
>
> The speed improvements seems quite important from my tests, so I
> really think this is a worthwhile inclusion (at least for us, d-i
> developpers ;) ).

This looks OK from my side to commit.

- -- 
O T A V I OS A L V A D O R
- -
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
- -
"Microsoft sells you Windows ... Linux gives
 you the whole house."
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ 

iEYEARECAAYFAkhzlpAACgkQLqiZQEml+FVK8QCglSmvzTvdzrQct/f9V1dMMfFR
u+AAn27UTSUUePSFItsRSUGVhzbFh4H8
=mJFf
-END PGP SIGNATURE-


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

[RFC] Add support for shells in the graphical installer

[Jérémy Bobbio]

Hi!

It feels quite strange to look back at the past year and realize that
first task I really decided to tackle in the debian-installer might be
done with this mail…  The experience has been pretty intense and thanks
for the ride! :)

The attached patchset adds support for shells in the graphical
installer: "Execute a shell" in menu, and rescue-mode shells can now be
used in the graphical installer.

Main changes:
 * A new source package is introduced, cdebconf-terminal, which builds
   cdebconf-gtk-terminal.  It contains the "terminal" plugin for the
   GTK+ frontend.
 * A new script, start-shell, is added to di-utils-shell.  This script
   either uses debconf-disconnect (old style) or a newly introduced
   template using the new "terminal" type.  In order to reduce the
   memory footprint, start-shell tries to anna-install
   cdebconf-gtk-terminal when the plugin is not available.
 * di-utils-shell.postinst, rescue.d/shell and rescue.d/initrd-shell all
   uses start-shell.

The result is quite nice, and the user experience is very similar
between the different frontends.  The impact on the current code by
these changes are really low and they should be seen as strong candidate
for inclusion in Lenny.

cdebconf-gtk-terminal requires three new udebs on top of itself:
 * ttf-dejavu-mono-udeb containing DejaVu monospaced font.
   349kB compressed, 624kB installed
   (might surely be reduced if Davide take a look at it.)
   http://people.debian.org/~lunar/ttf-dejavu_2.25-1_add_mono-udeb.diff.gz
 * libvte9-udeb containing the VteTerminal widget used by the
   plugin.
   315kB compressed, 688kB installed
   http://people.debian.org/~lunar/vte_0.16.14-1_enable_udeb.diff.gz
 * libncurses5-udeb needed by libvte.
   80k compressed, 172k installed
   http://people.debian.org/~lunar/ncurses_5.6+20080614-1_enable_udeb.diff.gz

This patch adds 6 new translatable debconf templates.  They worth a
review, for sure. :)

I can't provide a test image right now as I am lacking the necessary
network connectivity.  I will try to provide one as soon as possible.
If there is no strong objections after a first round of testing, I would
like to ask for the changes outside d-i without waiting too much.

As all this work as been done offline, the changelogs probably miss a
"Closes" or two.

Cheers,
-- 
Jérémy Bobbio.''`. 
[EMAIL PROTECTED]: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
commit 67a8e6b7a46ceae376833e537c731099c6749d5f
Author: Jérémy Bobbio <[EMAIL PROTECTED]>
Date:   Sun Jul 6 20:54:58 2008 +

Add cdebconf-terminal package

cdebconf-terminal builds a plugin for the GTK+ frontend adding the
possibility to display terminals as debconf questions.

This will allow shells to be started inside the graphical installer like
the other frontends.

As the terminal widget is provided by VTE, the package depends on
libvte9-udeb.  It also depends on ttf-dejavu-mono-udeb to display properly
monospaced fonts.
---
 packages/cdebconf-terminal/Makefile.in |   51 
 packages/cdebconf-terminal/configure.ac|   31 +++
 .../debian/cdebconf-gtk-terminal.install   |1 +
 .../debian/cdebconf-gtk-terminal.templates |3 +
 packages/cdebconf-terminal/debian/changelog|5 +
 packages/cdebconf-terminal/debian/compat   |1 +
 packages/cdebconf-terminal/debian/control  |   19 ++
 packages/cdebconf-terminal/debian/copyright|   30 +++
 packages/cdebconf-terminal/debian/po/POTFILES.in   |1 +
 packages/cdebconf-terminal/debian/po/templates.pot |   23 ++
 packages/cdebconf-terminal/debian/rules|   78 ++
 packages/cdebconf-terminal/gtk-plugin-terminal.c   |  270 
 12 files changed, 513 insertions(+), 0 deletions(-)

diff --git a/packages/cdebconf-terminal/Makefile.in b/packages/cdebconf-terminal/Makefile.in
new file mode 100644
index 000..9d156b6
--- /dev/null
+++ b/packages/cdebconf-terminal/Makefile.in
@@ -0,0 +1,51 @@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
+bindir=${prefix}/bin
+sbindir=${prefix}/sbin
+libdir=${prefix}/lib
+moddir=${libdir}/cdebconf/frontend
+sharedir=${prefix}/share/debconf
+mandir=${prefix}/share/man
+incdir=${prefix}/include/cdebconf
+
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@ -I.
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
+
+CFLAGS += -funsigned-char -fstrict-aliasing -Wall -W -Werror -Wundef \
+	-Wwrite-strings -Wsign-compare -Wno-unused-parameter -Winit-self \
+	-Wpointer-arith -Wredundant-decls -Wno-format-zero-length \
+	-Wmissing-prototypes -Wmissing-format-attribute
+
[EMAIL PROTECTED]@
+PLUGIN_MODULES=$(addsuffix -plugin-$(PACKAGE).so,$(FRONTENDS))
+
+all: $(PLUGIN_MODULES)
+
+install: $(PLUGIN_MODULES)
+	for p in $(PLUGIN_MODULES); do \
+		install -m755 -d $(DESTDIR)/$(moddir)/$${p%%-*} ; \
+		install -m6

Re: Selection of kernel for Lenny

[maximilian attems]

On Tue, Jul 08, 2008 at 05:41:57PM +0300, Eugene V. Lyubimkin wrote:
> maximilian attems wrote:
> > * Read-only bind mounts
> > 
> > which can come in really handy for chroots and buildd.
> JFYI: recently 'bindfs' package was uploaded to Debian archive, it can
> do it easily without new kernel.

not at vfs level.

-- 
maks


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

Re: Selection of kernel for Lenny

[Eugene V. Lyubimkin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

maximilian attems wrote:
> * Read-only bind mounts
> 
> which can come in really handy for chroots and buildd.
JFYI: recently 'bindfs' package was uploaded to Debian archive, it can
do it easily without new kernel.

My 2 cents, only.

Regards,
Eugene V. Lyubimkin

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhzfLUACgkQchorMMFUmYwwOACgwTTcdSiNuJiko0tT+mG8seHc
APgAnRSe2822LNilSH8Yfohmq4APr2O6
=GI4a
-END PGP SIGNATURE-


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

Re: Selection of kernel for Lenny

[maximilian attems]

On Tue, Jul 08, 2008 at 03:27:17PM +0200, Pierre Habouzit wrote:
> On Tue, Jul 08, 2008 at 12:43:49PM +, maximilian attems wrote:
> > On Tue, Jul 08, 2008 at 12:56:50PM +0200, Pierre Habouzit wrote:
> > > On Tue, Jul 08, 2008 at 06:59:40AM +, maximilian attems wrote:
> > > > On Mon, Jul 07, 2008 at 07:54:44PM +0200, Andreas Barth wrote:
> > > > > * Pierre Habouzit ([EMAIL PROTECTED]) [080707 19:48]:
> > > > > > Changing kernel at this point of the release would be too 
> > > > > > destructive,
> > > > > > so unless there is a big fat problem in the .25 that the .26 should 
> > > > > > fix
> > > > > > and is unbackportable (does such a beast even exist ?) I'm rather
> > > > > > opposed to it. Note that the asm/page.h mess is still not fixed 
> > > > > > thanks
> > > > > > to hppa.
> > > > > > 
> > > > > > Disclaimer: it's my own opinion, I did not check what other Release 
> > > > > > Team
> > > > > > member think about this.
> > > > > 
> > > > > I agree with you, at least with my current informations.
> > > > 
> > > > please read the changelog trunk on all the 2.6.26 fixes.
> > > 
> > >   Huh, that's not really our work, you as the maintainer should help us
> > > understand why we would like to deal with 3 months of FTBFS *right now*.
> > > Not to mention the libata changes fjp talks about, that would probably
> > > break many upgrades and for which there is no known solution.
> > 
> > right so the 2.6.26 summary:
> > * closes 50 bugs on upload (mostly 2.6.25 regressions)
> 
>   I'm really afraid with the number of bugs it'll open though.

upstream has much better control of it thanks to kernelopps,
random .config boot tests and regression handling.
 
> > * has upstream coordination with xen and openvz
> 
>   Does this mean that dom0 will work with .26 ? If yes, then maybe .26
> is really worth considering. If not, this is quite moot.

we get snapshot working, that is *important* for guest.
otherwise you would not be able to migrate your debian guest.

and please don't dismiss openvz, which is the new emerging namespace
solution that has more features then vserver and works actively on
upstream merge. we have worked together with openvz devs to have
.26 openvz images.
 
> > * is the first version with kernel debugger
> > * much better laptop support (wireless, uvc,..)
> > * kvm ported to IA64, PPC and S390

of course a lot of fixes and forgot to mention the
* Read-only bind mounts

which can come in really handy for chroots and buildd.
 
> > > > we have allways stated that .26 will be the release kernel.
> > > 
> > >   The sole mail from the kernel team that I can find is[0]. We've seen
> > > no updates from you since AFAICT. Given the content of the mail, and its
> > > age, I don't see how we can know that.
> > 
> > right to debian-release that was the last time we got asked to give a
> > statement. in discussion on d-kernel and with d-boot we allways stated
> > to work on 2.6.26 for Lenny.
> 
>   Well, we did asked for updates from core teams in our mails to d-d-a
> numerous times without our prior nagging, which was clearly meant to
> avoid this kind of communication issues.
> 
>   For the rest I assume the release team will have to discuss things a
> bit further.

okay sorry for having not catched that.
 
> > >   [1] e.g. have you done full scale archive rebuilds to show that a new
> > >   linux-libc-dev won't at least cause dozens of FTBFS like the
> > >   2.6.25 did ?
> > 
> > there are statements from waldi and vorlon to consider the 2.6.25
> > linux-libc-dev status as frozen.
> 
>   Well, that's a sine qua non condition. L-L-Dev breakages are horrible,
> and we just cannot aford one. It does not mean that I consider .26 to be
> a clever idea right now, but a l-l-d breakage would be a plain no-go.

sure fully agreeed.

-- 
maks


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

Re: Selection of kernel for Lenny

[Pierre Habouzit]

On Tue, Jul 08, 2008 at 12:43:49PM +, maximilian attems wrote:
> On Tue, Jul 08, 2008 at 12:56:50PM +0200, Pierre Habouzit wrote:
> > On Tue, Jul 08, 2008 at 06:59:40AM +, maximilian attems wrote:
> > > On Mon, Jul 07, 2008 at 07:54:44PM +0200, Andreas Barth wrote:
> > > > * Pierre Habouzit ([EMAIL PROTECTED]) [080707 19:48]:
> > > > > Changing kernel at this point of the release would be too destructive,
> > > > > so unless there is a big fat problem in the .25 that the .26 should 
> > > > > fix
> > > > > and is unbackportable (does such a beast even exist ?) I'm rather
> > > > > opposed to it. Note that the asm/page.h mess is still not fixed thanks
> > > > > to hppa.
> > > > > 
> > > > > Disclaimer: it's my own opinion, I did not check what other Release 
> > > > > Team
> > > > > member think about this.
> > > > 
> > > > I agree with you, at least with my current informations.
> > > 
> > > please read the changelog trunk on all the 2.6.26 fixes.
> > 
> >   Huh, that's not really our work, you as the maintainer should help us
> > understand why we would like to deal with 3 months of FTBFS *right now*.
> > Not to mention the libata changes fjp talks about, that would probably
> > break many upgrades and for which there is no known solution.
> 
> right so the 2.6.26 summary:
> * closes 50 bugs on upload (mostly 2.6.25 regressions)

  I'm really afraid with the number of bugs it'll open though.

> * has upstream coordination with xen and openvz

  Does this mean that dom0 will work with .26 ? If yes, then maybe .26
is really worth considering. If not, this is quite moot.

> * is the first version with kernel debugger
> * much better laptop support (wireless, uvc,..)
> * kvm ported to IA64, PPC and S390

> > > we have allways stated that .26 will be the release kernel.
> > 
> >   The sole mail from the kernel team that I can find is[0]. We've seen
> > no updates from you since AFAICT. Given the content of the mail, and its
> > age, I don't see how we can know that.
> 
> right to debian-release that was the last time we got asked to give a
> statement. in discussion on d-kernel and with d-boot we allways stated
> to work on 2.6.26 for Lenny.

  Well, we did asked for updates from core teams in our mails to d-d-a
numerous times without our prior nagging, which was clearly meant to
avoid this kind of communication issues.

  For the rest I assume the release team will have to discuss things a
bit further.

> >   [1] e.g. have you done full scale archive rebuilds to show that a new
> >   linux-libc-dev won't at least cause dozens of FTBFS like the
> >   2.6.25 did ?
> 
> there are statements from waldi and vorlon to consider the 2.6.25
> linux-libc-dev status as frozen.

  Well, that's a sine qua non condition. L-L-Dev breakages are horrible,
and we just cannot aford one. It does not mean that I consider .26 to be
a clever idea right now, but a l-l-d breakage would be a plain no-go.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp25s3AHL4sy.pgp
Description: PGP signature

Re: Selection of kernel for Lenny

[maximilian attems]

On Tue, Jul 08, 2008 at 12:56:50PM +0200, Pierre Habouzit wrote:
> On Tue, Jul 08, 2008 at 06:59:40AM +, maximilian attems wrote:
> > On Mon, Jul 07, 2008 at 07:54:44PM +0200, Andreas Barth wrote:
> > > * Pierre Habouzit ([EMAIL PROTECTED]) [080707 19:48]:
> > > > Changing kernel at this point of the release would be too destructive,
> > > > so unless there is a big fat problem in the .25 that the .26 should fix
> > > > and is unbackportable (does such a beast even exist ?) I'm rather
> > > > opposed to it. Note that the asm/page.h mess is still not fixed thanks
> > > > to hppa.
> > > > 
> > > > Disclaimer: it's my own opinion, I did not check what other Release Team
> > > > member think about this.
> > > 
> > > I agree with you, at least with my current informations.
> > 
> > please read the changelog trunk on all the 2.6.26 fixes.
> 
>   Huh, that's not really our work, you as the maintainer should help us
> understand why we would like to deal with 3 months of FTBFS *right now*.
> Not to mention the libata changes fjp talks about, that would probably
> break many upgrades and for which there is no known solution.

right so the 2.6.26 summary:
* closes 50 bugs on upload (mostly 2.6.25 regressions)
* has upstream coordination with xen and openvz
* is the first version with kernel debugger
* much better laptop support (wireless, uvc,..)
* kvm ported to IA64, PPC and S390
 
> > we have allways stated that .26 will be the release kernel.
> 
>   The sole mail from the kernel team that I can find is[0]. We've seen
> no updates from you since AFAICT. Given the content of the mail, and its
> age, I don't see how we can know that.

right to debian-release that was the last time we got asked to give a
statement. in discussion on d-kernel and with d-boot we allways stated
to work on 2.6.26 for Lenny.
 
> > I don't understand why this would come as a surprise.
> 
>   I'll start with reminding you that the toolchain is frozen and that
> the kernel is part of it.
> 
>   Now could you explain how changing kernel for a new upstream, with the
> well known fact that one needs to wait for the .2/.3 to have a decent
> working kernel (IOW in at least 2/3 weeks after the release) is not a
> disruptive change[1]?  Add testing migration to that, plus tied
> transitions, then I expect a really good rationale from you to explain
> why a 6-8 weeks delay in the toolchain freeze (IOW in the release
> process) is acceptable and needed[2].

a freeze exception for releasing debian with an uptodate and tuned
system is worth.
 
>   [1] e.g. have you done full scale archive rebuilds to show that a new
>   linux-libc-dev won't at least cause dozens of FTBFS like the
>   2.6.25 did ?

there are statements from waldi and vorlon to consider the 2.6.25
linux-libc-dev status as frozen.


kind regards

-- 
maks

ps fjp is wrong we don't switch to pata and are not forced to do
   so for 2.6.26, no idea, where he got that idea.


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

Re: Selection of kernel for Lenny

[Otavio Salvador]

maximilian attems <[EMAIL PROTECTED]> writes:

> On Mon, Jul 07, 2008 at 10:09:43PM +0200, Frans Pop wrote:
>> On Monday 07 July 2008, maximilian attems wrote:
>> > > There are valid arguments to be found for staying with 2.6.25 a bit
>> > > longer, but "D-I has not yet converted to it" is NOT one of them.
>> >
>> > testing users are currently on an unsupported kernel.
>> 
>> Eh, how does that follow my last para which I assume you are commenting 
>> on, but which has nothing to do with testing?
>> 
>> A side-note to your comment though...
>> 
>> IMO testing kernel support is the weakest point in the current upload 
>> strategy by the kernel team. By uploading the next upstream release to 
>> unstable basically as soon as it's available upstream, Debian users (both 
>> unstable and testing) are frequently missing out on at least one or two 
>> upstream stable updates for the previous stable ("stable -1") release.
>
> agreed on the week point, but not to your conclusions.
> it often happens that d-i is blocking on older release.
> like the beta that happened to want to stick to 2.6.22
> which was a pure catastrophe, half a year too old, without
> support for e1000e and newer intel boards..

This was mostly caused due  the risk of the kernel to not be ready on
time. We do need to have a better process to avoid those two problems
to happen from now on.

<...>
>> My personal opinion is that it would be better to delay the upload of new 
>> upstream releases to unstable until the .2 or maybe even .3 upstream 
>> stable update has become available. This would mean a bit more work for 
>> the kernel team, but I would expect that to be solvable.
>
> don't see any point on that.
> it wouldn't accelerate the meta package sort.

But it would accelerate the d-i migration since we could mostly of
time do the switch at same time of kernel going sid.

>> That would also give more time for initial arch-specific and l-m-e issues 
>> for the new upstream to be worked out (e.g. in experimental) without 
>> breaking unstable too much. IMO a new kernel version should only be 
>> uploaded to unstable if kernel meta packages can be updated at roughly 
>> the same time.
>
> this is a currently a week point, but unstable is the place to sort
> such.

No. experimental is the place for that.

>> It would also allow to upload a few more stable updates for "stable -1" 
>> and to migrate those to testing, giving testing users on average better 
>> support and it would give D-I some more "breathing space" to do releases.
>> 
>> When a new stable *is* uploaded, D-I should be able to switch faster too 
>> (at least, if there's someone willing to do the initial kernel-wedge 
>> work) as the main criterium for D-I to switch to a new kernel version is: 
>> does the new version look about to be ready to migrate to testing, which 
>> current early uploads of the kernel to unstable effectively never are.
>
> 
> never seen that, d-i has always been dragging.
> 
>
> would wish that kmuto be an official d-i member. he even
> tracks rc snapshot releases when necessary.

It is different case when we are working with a full set of
architectures and planning to not hurt users.

You need to agree that if one derivative breaks, it hurts much less
people then if oficial d-i breaks.

>> > > A much more important argument is that .25 has seen and will almost
>> > > certainly continue to get a lot more stabilization effort upstream
>> > > than is "normal" for upstream kernel releases because long term
>> > > releases for at least two important other distros are based on it. I
>> > > doubt .26 will get the same upstream attention.
>> > > Given the lack of capacity in Debian to do any real stabilization
>> > > (cherry picking/backporting of fixes from later releases) ourselves,
>> > > that could IMO be an important consideration for staying with .25 for
>> > > Lenny.
>> >
>> > that doesn't matter a lot, if you look into our 2.6.18 or the RH patch
>> > biest you'll notice the RH men force boot behind their backporting
>> > machine.
>> 
>> I'm having serious trouble parsing what you're trying to say here. Could 
>> you rephrase?
>
> you never checked the rh kernel. they do a *lot* of backporting and
> have a big team working on that. so you'll notice that none of those
> patches landed in ours. so your argument sounds nice, but doesn't
> help in practise.
>
> .26 got a *lot* upstream attention and solves a number of .25 regressions.
> it is wanted for read-only bind mounts, kernel debugger, kvm + xen + wireless
> improvements, allmost net namespaces and uvc cam support.

And how about the other and correlated changes that would be need like
toolchain and base? We're on _freeze_, bear that on mind. 

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

Re: Can we upload a new version of ttf-indic-fonts?

[Praveen A]

2008/6/27 Otavio Salvador <[EMAIL PROTECTED]>:
> "Praveen A" <[EMAIL PROTECTED]> writes:
>
>> We have fixed some rendering bugs in AnjaliOldLipi and MalOtf (now
>> called Kalyani), part of ttf-malayalam-fonts package. We have also
>> added a fontconfig rule to make the size of Meera_04.ttf comparable to
>> Latin glyphs (it is a very common complaint that font size is smaller
>> for Meera). There is no change to the udeb. Since we are close to
>> release and this package creates a udeb we wanted to check with d-i
>> team before uploading it. Proposed changes are committed to the
>> debian-in alioth repository. We would really love to see this in
>> lenny.
>
> Please go ahead.
>

Please hint ttf-indic-fonts/ttf-malayalam-fonts to testing.

Cheers
Praveen
-- 
പ്രവീണ്‍ അരിമ്പ്രത്തൊടിയില്‍
 I know my rights; I want my phone call!
 What use is a phone call, if you are unable to speak?
(as seen on /.)
Join The DRM Elimination Crew Now!
http://fci.wikia.com/wiki/Anti-DRM-Campaign

Re: Selection of kernel for Lenny

[Pierre Habouzit]

On Tue, Jul 08, 2008 at 06:59:40AM +, maximilian attems wrote:
> On Mon, Jul 07, 2008 at 07:54:44PM +0200, Andreas Barth wrote:
> > * Pierre Habouzit ([EMAIL PROTECTED]) [080707 19:48]:
> > > Changing kernel at this point of the release would be too destructive,
> > > so unless there is a big fat problem in the .25 that the .26 should fix
> > > and is unbackportable (does such a beast even exist ?) I'm rather
> > > opposed to it. Note that the asm/page.h mess is still not fixed thanks
> > > to hppa.
> > > 
> > > Disclaimer: it's my own opinion, I did not check what other Release Team
> > > member think about this.
> > 
> > I agree with you, at least with my current informations.
> 
> please read the changelog trunk on all the 2.6.26 fixes.

  Huh, that's not really our work, you as the maintainer should help us
understand why we would like to deal with 3 months of FTBFS *right now*.
Not to mention the libata changes fjp talks about, that would probably
break many upgrades and for which there is no known solution.

> we have allways stated that .26 will be the release kernel.

  The sole mail from the kernel team that I can find is[0]. We've seen
no updates from you since AFAICT. Given the content of the mail, and its
age, I don't see how we can know that.

> I don't understand why this would come as a surprise.

  I'll start with reminding you that the toolchain is frozen and that
the kernel is part of it.

  Now could you explain how changing kernel for a new upstream, with the
well known fact that one needs to wait for the .2/.3 to have a decent
working kernel (IOW in at least 2/3 weeks after the release) is not a
disruptive change[1]?  Add testing migration to that, plus tied
transitions, then I expect a really good rationale from you to explain
why a 6-8 weeks delay in the toolchain freeze (IOW in the release
process) is acceptable and needed[2].

  The fact that you're unable to understand that is quite worrying.


  [0] http://lists.debian.org/debian-release/2007/04/msg00189.html

  [1] e.g. have you done full scale archive rebuilds to show that a new
  linux-libc-dev won't at least cause dozens of FTBFS like the
  2.6.25 did ?

  [2] and I'm pretty sure the d-i crew has alike reservations.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp0bgV1QrYgd.pgp
Description: PGP signature

Re: RFS: di-netboot-assistant (ITP #489812)

[Franklin PIAT]

Hello,

On Mon, 2008-07-07 at 20:18 -0400, Joey Hess wrote:
> Franklin PIAT wrote:
> > I am looking for a sponsor for my package "di-netboot-assistant".
> > (I am CCing debian-boot in case someone has some interest in it)
> 
> This looks like some nice work. I wonder if it would make sense for it
> to be maintained inside the d-i project?

As far as I am concerned, that would be fine.

> Some review:
> 
> - Minor typos in the README, mostly involving number (ie, missing
>"s" on plural words).

I've reviewed it... I will also submit the documentation to
debian-english as I've probably left some mistakes.

> - It shouldn't need syslinux to be installed on the tftp server.
>   - pxelinux.0 is already included in the netboot tarball
>   - menu.c32 is not, but vesamenu.c32 is (in testing), and can also do
> menus and submenus

I wanted to be sure that it works Etch.
Also, I had a quick look at vesamenu, but all configuration snippets
seems to be loaded at once so there might be some bad interaction
between the different releases (?). I don't have enough time right now
for that, but it's a must have for Lenny+1.

> - The docs say that to use the top-level menu it should use
> filename "debian-installer/etch/i386/pxelinux.0";
>   Why is that in etch/ ? Wouldn't it be clearer to put the file in
>   debian-installer/i386/pxelinux.0?

I've fixed the documentation to match the actual file location.

Currently, all the meta-menu stuffs are installed in /debian-installer/
(because I have /debian-installer/lenny/i386 but
not /debian-installer/i386. May be I should have arranged the
directories the other way around : /debian-installer/i386/lenny ? )

> - No checking is done of the validity of downloaded files. It should check
>   the images/MD5SUMS file. (Unfortunatly there's no signed trust path for it
>   to check.)

That would be nice.
The daily images don't have MD5SUMS either. I've added it to my todo
list.

> - Seems to use the french keymap by default?

;) fixed.

> - Suggest s/NetBoot Meta-menu/netboot overview menu/

done.

> - The di-sources.list seems redundant. I think that the regular sources.list
>   could be parsed to get the mirror urls, and those modified to get the 
>   d-i image locations. The file would still be useful for the dailies,
>   or other distributions

I couldn't figure out how to parse and use the sources.list. Especially
for systems with multiple entries in sources.list (backport...) and
those with mirror that looks like ftp.my-isp.com/debian

I assume I could still grep and sed /etc/apt/sources.list :
 grep -E 
"^deb[[:blank:]]*(http|ftp)://[[:alnum:]]*\.[a-z]{2}\.debian\.org.*${DIST}" 
But it would only work for general case.

I couldn't find a clean way to specify the mirror, since it could be
specific for each distribution and/or architecture. I'm just wondering
how live-helper and debootstrap have addressed this problem.

Any idea ?

> but it would be nice to not have to modify it to use a !french mirror.

done

dupload di-netboot-assistant_0.33_i386.changes


Franklin


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

Re: Selection of kernel for Lenny (was: 2.6.25-2 testing sync)

[maximilian attems]

On Mon, Jul 07, 2008 at 10:09:43PM +0200, Frans Pop wrote:
> On Monday 07 July 2008, maximilian attems wrote:
> > > There are valid arguments to be found for staying with 2.6.25 a bit
> > > longer, but "D-I has not yet converted to it" is NOT one of them.
> >
> > testing users are currently on an unsupported kernel.
> 
> Eh, how does that follow my last para which I assume you are commenting 
> on, but which has nothing to do with testing?
> 
> A side-note to your comment though...
> 
> IMO testing kernel support is the weakest point in the current upload 
> strategy by the kernel team. By uploading the next upstream release to 
> unstable basically as soon as it's available upstream, Debian users (both 
> unstable and testing) are frequently missing out on at least one or two 
> upstream stable updates for the previous stable ("stable -1") release.

agreed on the week point, but not to your conclusions.
it often happens that d-i is blocking on older release.
like the beta that happened to want to stick to 2.6.22
which was a pure catastrophe, half a year too old, without
support for e1000e and newer intel boards..
 
> We worked around this for .24 by doing an upstream stable update through 
> t-p-u.

dannf did and he is from the kernel team.
it was not a workaround, but again a stick to previous instead of
working forward.
 
> Upstream does seem to recognize the fact that a new release will need at 
> least a few updates before it is actually "stable and usable", and will 
> therefore do at least a few stable updates (for both "new stable" 
> and "stable -1" in parallel). This basically happens in parallel to the 
> new merge window (say the time to -rc2) and some upstream releases get
> "longer term" upstream stable support (.18, .22, .25).

.22 didn't stay long with us. this was said back then for .16 and
didn't matter on the long run.
 
> My personal opinion is that it would be better to delay the upload of new 
> upstream releases to unstable until the .2 or maybe even .3 upstream 
> stable update has become available. This would mean a bit more work for 
> the kernel team, but I would expect that to be solvable.

don't see any point on that.
it wouldn't accelerate the meta package sort.

 
> That would also give more time for initial arch-specific and l-m-e issues 
> for the new upstream to be worked out (e.g. in experimental) without 
> breaking unstable too much. IMO a new kernel version should only be 
> uploaded to unstable if kernel meta packages can be updated at roughly 
> the same time.

this is a currently a week point, but unstable is the place to sort
such.
 
> It would also allow to upload a few more stable updates for "stable -1" 
> and to migrate those to testing, giving testing users on average better 
> support and it would give D-I some more "breathing space" to do releases.
> 
> When a new stable *is* uploaded, D-I should be able to switch faster too 
> (at least, if there's someone willing to do the initial kernel-wedge 
> work) as the main criterium for D-I to switch to a new kernel version is: 
> does the new version look about to be ready to migrate to testing, which 
> current early uploads of the kernel to unstable effectively never are.


never seen that, d-i has always been dragging.


would wish that kmuto be an official d-i member. he even
tracks rc snapshot releases when necessary.
 
> > > A much more important argument is that .25 has seen and will almost
> > > certainly continue to get a lot more stabilization effort upstream
> > > than is "normal" for upstream kernel releases because long term
> > > releases for at least two important other distros are based on it. I
> > > doubt .26 will get the same upstream attention.
> > > Given the lack of capacity in Debian to do any real stabilization
> > > (cherry picking/backporting of fixes from later releases) ourselves,
> > > that could IMO be an important consideration for staying with .25 for
> > > Lenny.
> >
> > that doesn't matter a lot, if you look into our 2.6.18 or the RH patch
> > biest you'll notice the RH men force boot behind their backporting
> > machine.
> 
> I'm having serious trouble parsing what you're trying to say here. Could 
> you rephrase?

you never checked the rh kernel. they do a *lot* of backporting and
have a big team working on that. so you'll notice that none of those
patches landed in ours. so your argument sounds nice, but doesn't
help in practise.

.26 got a *lot* upstream attention and solves a number of .25 regressions.
it is wanted for read-only bind mounts, kernel debugger, kvm + xen + wireless
improvements, allmost net namespaces and uvc cam support.

-- 
maks


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

Re: Selection of kernel for Lenny

[maximilian attems]

On Mon, Jul 07, 2008 at 07:54:44PM +0200, Andreas Barth wrote:
> * Pierre Habouzit ([EMAIL PROTECTED]) [080707 19:48]:
> > Changing kernel at this point of the release would be too destructive,
> > so unless there is a big fat problem in the .25 that the .26 should fix
> > and is unbackportable (does such a beast even exist ?) I'm rather
> > opposed to it. Note that the asm/page.h mess is still not fixed thanks
> > to hppa.
> > 
> > Disclaimer: it's my own opinion, I did not check what other Release Team
> > member think about this.
> 
> I agree with you, at least with my current informations.

please read the changelog trunk on all the 2.6.26 fixes.

we have allways stated that .26 will be the release kernel.
i don't understand why this would come as a surprise.

.26 is to be released in a week, which is early enough to
prepare all stuff including testing migration.

-- 
maks


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

linux-kernel-di-hppa-2.6_1.25_hppa.changes is NEW

[Debian Installer]

(new) cdrom-core-modules-2.6.25-2-parisc-di_1.25_hppa.udeb standard 
debian-installer
CDROM support
 This package contains core CDROM support for the Linux kernel.
(new) cdrom-core-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb standard 
debian-installer
CDROM support
 This package contains core CDROM support for the Linux kernel.
(new) crypto-core-modules-2.6.25-2-parisc-di_1.25_hppa.udeb extra 
debian-installer
Core crypto modules
 This package contains crypto modules needed for both encrypted file systems,
 the crypto devicemapper and wireless networking (WEP).
(new) crypto-core-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb extra 
debian-installer
Core crypto modules
 This package contains crypto modules needed for both encrypted file systems,
 the crypto devicemapper and wireless networking (WEP).
(new) crypto-dm-modules-2.6.25-2-parisc-di_1.25_hppa.udeb extra debian-installer
devicemapper crypto module
 This package contains the devicemapper crypto (dm-crypt) module.
(new) crypto-dm-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb extra 
debian-installer
devicemapper crypto module
 This package contains the devicemapper crypto (dm-crypt) module.
(new) crypto-modules-2.6.25-2-parisc-di_1.25_hppa.udeb extra debian-installer
crypto modules
 This package contains crypto modules.
(new) crypto-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb extra debian-installer
crypto modules
 This package contains crypto modules.
(new) ext3-modules-2.6.25-2-parisc-di_1.25_hppa.udeb standard debian-installer
EXT3 filesystem support
 This package contains the EXT3 filesystem module for the Linux kernel.
(new) ext3-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb standard debian-installer
EXT3 filesystem support
 This package contains the EXT3 filesystem module for the Linux kernel.
(new) ide-modules-2.6.25-2-parisc-di_1.25_hppa.udeb standard debian-installer
IDE drivers
 This package contains IDE drivers for the Linux kernel.
(new) ide-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb standard debian-installer
IDE drivers
 This package contains IDE drivers for the Linux kernel.
(new) input-modules-2.6.25-2-parisc-di_1.25_hppa.udeb extra debian-installer
Input devices support
 This package contains input device drivers for the Linux kernel.
(new) input-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb extra debian-installer
Input devices support
 This package contains input device drivers for the Linux kernel.
(new) ipv6-modules-2.6.25-2-parisc-di_1.25_hppa.udeb extra debian-installer
IPv6 driver
 This package contains the IPv6 driver for the Linux kernel.
(new) ipv6-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb extra debian-installer
IPv6 driver
 This package contains the IPv6 driver for the Linux kernel.
(new) kernel-image-2.6.25-2-parisc-di_1.25_hppa.udeb extra debian-installer
Linux kernel binary image for the Debian installer
 This package contains the Linux kernel image for the Debian installer
 boot images. It does _not_ provide a usable kernel for your full
 Debian system.
(new) kernel-image-2.6.25-2-parisc64-di_1.25_hppa.udeb extra debian-installer
Linux kernel binary image for the Debian installer
 This package contains the Linux kernel image for the Debian installer
 boot images. It does _not_ provide a usable kernel for your full
 Debian system.
linux-kernel-di-hppa-2.6_1.25.dsc
  to pool/main/l/linux-kernel-di-hppa-2.6/linux-kernel-di-hppa-2.6_1.25.dsc
linux-kernel-di-hppa-2.6_1.25.tar.gz
  to pool/main/l/linux-kernel-di-hppa-2.6/linux-kernel-di-hppa-2.6_1.25.tar.gz
(new) loop-modules-2.6.25-2-parisc-di_1.25_hppa.udeb standard debian-installer
Loopback filesystem support
 This package contains loopback filesystem support for the Linux kernel.
(new) loop-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb standard debian-installer
Loopback filesystem support
 This package contains loopback filesystem support for the Linux kernel.
(new) md-modules-2.6.25-2-parisc-di_1.25_hppa.udeb extra debian-installer
RAID and LVM support
 This package contains RAID and LVM modules for the Linux kernel.
(new) md-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb extra debian-installer
RAID and LVM support
 This package contains RAID and LVM modules for the Linux kernel.
(new) multipath-modules-2.6.25-2-parisc-di_1.25_hppa.udeb extra debian-installer
Multipath support
 This package contains DM-Multipath modules for the Linux kernel.
(new) multipath-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb extra 
debian-installer
Multipath support
 This package contains DM-Multipath modules for the Linux kernel.
(new) nic-modules-2.6.25-2-parisc-di_1.25_hppa.udeb standard debian-installer
Common NIC drivers
 This package contains common NIC drivers for the Linux kernel.
(new) nic-modules-2.6.25-2-parisc64-di_1.25_hppa.udeb standard debian-installer
Common NIC drivers
 This package contains common NIC drivers for the Linux kernel.
(new) ppp-modules-2.6.25-2-parisc-di_1.25_hppa.udeb optional debian-installer
PPP drivers
 This package contains PPP drivers for the Linux kernel.
(new) ppp-module