date:20080724

On Thu, Jul 24, 2008 at 08:06:43AM +0200, Grégory Oestreicher wrote:
> > On Wed, Jul 23, 2008 at 10:19:20PM +0200, GrÃ©gory Oestreicher wrote:
> > I was planning to have another look at it soon, but if you have the time
> > to update and test it before that, that would indeed be great. :)
> 
> Well I had some time to merge both patches by hand (not a big deal) and
> they still apply to the latest SVN of all required packages.
> 
> However I could not test it yet as I wasn't able to boot any Lenny CD
> image (bot genuine or remastered for the tests) using qemu on an Etch
> system.

Try passing "-std-vga", as I think vesamenu might be the issue.

Another more twisted way to workaround graphic card issues:
 * Start qemu with "-nographic",
 * Press "Control-a", then "c",
 * Type "sendkey tab", then "sendkey spc", then "sendkey c", then
   (ommiting "sendkey") 'o', 'n', 's', 'o', 'l', 'e', 'equal', 't', 't',
   'y', 'shift-s', '0' and finally 'ret'.
 * Press "Control-a", then "c" again, and you should be in front of a
   d-i through serial console installation.

> While I search a workaround, I attach the patch and the test recipes
> modified to add some "randomly" placed lvname{ } to this message in
> case someone has the possibility to test them. When tested, they can
> be added to the bugreport.

Please also test "normal" guided partitioning using LVM and LVM+crypto,
if you can.

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

signature.asc
Description: Digital signature

Bug#491712: firmware for iwl4965 is asked in disk-detect (was: installation-reports: HP lenovo R61i laptop)

On Wednesday 23 July 2008, Joey Hess wrote:
> Frans Pop wrote:
> > You change has not yet be committed though, so this could be taken
> > along. It would just be:
> > ls -1 /sys/class/net | grep -v "^lo$"
>
> I like keeping bugfixes separate from potential bug introduction. :-)
> And your code needs to grep out 'lo/'

No. With '-1' you don't get trailing slashes for directories.



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

Re: Please unblock pango1.0 and glib2.0

2008-07-24 Thread Luk Claes

Otavio Salvador wrote:
> Luk Claes <[EMAIL PROTECTED]> writes:
> 
>> Josselin Mouette wrote:
>>> Hi,
>>>
>>> please allow pango1.0 1.20.5-1 and glib2.0 2.16.4-2 migrate to testing.
>>> Both have important bugfixes.
>> Both need ack from debian-boot
> 
> No objection

unblocked

Cheers

Luk


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

Bug#492188: [INTL:sv] Swedish strings for hw-detect debconf

2008-07-24 Thread Martin Bagge

package: hw-detect
severity: wishlist
tags: patch l10n

-- 
brother
http://frakalendern.se# THIS FILE IS GENERATED AUTOMATICALLY FROM THE D-I PO MASTER FILES
# The master files can be found under packages/po/
#
# DO NOT MODIFY THIS FILE DIRECTLY: SUCH CHANGES WILL BE LOST
#
# THIS FILE IS AUTOMATICALLY GENERATED FROM THE MASTER FILE
# packages/po/sv.po
#
# DO NOT MODIFY IT DIRECTLY : SUCH CHANGES WILL BE LOST
#
# Swedish messages for debian-installer.
# Copyright (C) 2003 Software in the Public Interest, Inc.
# This file is distributed under the same license as debian-installer.
#
# Swedish translation by:
# Per Olofsson <[EMAIL PROTECTED]>
# Daniel Nylander <[EMAIL PROTECTED]>, 2006.
#
msgid ""
msgstr ""
"Project-Id-Version: debian-installer\n"
"Report-Msgid-Bugs-To: [EMAIL PROTECTED]"
"POT-Creation-Date: 2008-06-24 22:50+\n"
"PO-Revision-Date: 2008-07-24 12:21+0100\n"
"Last-Translator: Martin Bagge <[EMAIL PROTECTED]>\n"
"Language-Team: Swedish <[EMAIL PROTECTED]>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: select
#. Choices
#. :sl2:
#: ../ethdetect.templates:1001
msgid "no ethernet card"
msgstr "inget ethernetkort"

#. Type: select
#. Choices
#. :sl2:
#. "none of the above" should be understood as "none of the above choices"
#: ../ethdetect.templates:1001
#: ../disk-detect.templates:3001
msgid "none of the above"
msgstr "ingen av ovanstÃ¥ende"

#. Type: select
#. Description
#. :sl2:
#: ../ethdetect.templates:1002
msgid "Driver needed by your Ethernet card:"
msgstr "Drivrutin som behÃ¶vs fÃ¶r ditt ethernetkort:"

#. Type: select
#. Description
#. :sl2:
#: ../ethdetect.templates:1002
msgid "No Ethernet card was detected. If you know the name of the driver needed 
by your Ethernet card, you can select it from the list."
msgstr "Hittade inget ethernetkort. Om du vet namnet pÃ¥ drivrutinen som krÃ¤vs 
av ditt ethernetkort kan du vÃ¤lja den frÃ¥n listan."

#. Type: boolean
#. Description
#. :sl3:
#: ../ethdetect.templates:2001
msgid "Do you intend to use FireWire Ethernet?"
msgstr "Har du planerat att anvÃ¤nda Ethernet Ã¶ver FireWire?"

#. Type: boolean
#. Description
#. :sl3:
#: ../ethdetect.templates:2001
msgid "No Ethernet card was detected, but a FireWire interface is present. It's 
possible, though unlikely, that with the right FireWire hardware connected to 
it, this could be your primary Ethernet interface."
msgstr "Inget Ethernetkort hittades men ett FireWire-grÃ¤nssnitt hittades. Det 
Ã¤r mÃ¶jligt, kanske inte normalt, att med rÃ¤tt FireWire-tillbehÃ¶r ansluten 
till det att det hÃ¤r Ã¤r ditt primÃ¤ra Ethernet-grÃ¤nssnitt."

#. Type: error
#. Description
#. :sl2:
#: ../ethdetect.templates:3001
msgid "Ethernet card not found"
msgstr "Hittade inget Ethernetkort"

#. Type: error
#. Description
#. :sl2:
#: ../ethdetect.templates:3001
msgid "No Ethernet card was found on the system."
msgstr "Inget ethernetkort hittades i systemet."

#. Type: text
#. Description
#. :sl1:
#: ../ethdetect.templates:4001
msgid "Detecting network hardware"
msgstr "Identifierar nÃ¤tverksmaskinvara"

#. Type: text
#. Description
#. Main menu item
#. :sl1:
#: ../ethdetect.templates:5001
msgid "Detect network hardware"
msgstr "Identifiera nÃ¤tverksmaskinvara"

#. Type: text
#. Description
#. Main menu item
#. :sl1:
#: ../disk-detect.templates:1001
msgid "Detect disks"
msgstr "Identifiera diskar"

#. Type: text
#. Description
#. :sl1:
#: ../disk-detect.templates:2001
msgid "Detecting disks and all other hardware"
msgstr "Identifierar hÃ¥rddiskar och all annan maskinvara"

#. Type: select
#. Choices
#. :sl2:
#: ../disk-detect.templates:3001
msgid "continue with no disk drive"
msgstr "fortsÃ¤tt utan diskettenhet"

#. Type: select
#. Description
#. :sl2:
#: ../disk-detect.templates:3002
msgid "Driver needed for your disk drive:"
msgstr "Drivrutin som behÃ¶vs fÃ¶r din diskettenhet:"

#. Type: select
#. Description
#. :sl2:
#: ../disk-detect.templates:3002
msgid "No disk drive was detected. If you know the name of the driver needed by 
your disk drive, you can select it from the list."
msgstr "Hittade ingen diskettenhet. Om du vet namnet pÃ¥ den drivrutin som 
krÃ¤vs fÃ¶r din diskettenhet kan du vÃ¤lja den frÃ¥n listan."

#. Type: error
#. Description
#. :sl2:
#: ../disk-detect.templates:4001
msgid "No partitionable media"
msgstr "Inget partitioneringsbart media"

#. Type: error
#. Description
#. :sl2:
#: ../disk-detect.templates:4001
msgid "No partitionable media were found."
msgstr "Hittade inget partitioneringsbart media."

#. Type: error
#. Description
#. :sl2:
#: ../disk-detect.templates:4001
msgid "P

Re: [PATCH] RAID10 and RAID6

On Sun, Jul 20, 2008 at 12:49:39PM -0700, Ryan Niebur wrote:
> here are the patches

A test image of the patches applied on top of the rework of MD devices
initialisation is available at:
  http://people.debian.org/~lunar/d-i+md_love+raid6_10-mini.iso

Due to disk space constraints (*sigh*) I was not able to test a full
installation on RAID10 or RAID6.  But I was able to create such
MD partitions without troubles.

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


signature.asc
Description: Digital signature

Re: Automatic activation of pre-existing RAID/LVM devices (was: RAID10 and RAID6)

On Sun, Jul 20, 2008 at 09:26:12PM +0200, Frans Pop wrote:
> On Saturday 19 July 2008, Jérémy Bobbio wrote:
> > I have quickly reviewed all bug reports against these two packages and
> > no bugs seem to mention this issue.  Either the relevant installation
> > reports were not sorted correctly or we can assume that it is a pretty
> > minor issue and that our users did work around it themselves.
> 
> This is not about users complaining about it, but about internal 
> consistency. The locking infrastructure was added by David as part of 
> p-crypto and then also added for new LVM devices.

Oh… Ok.  So devices and partitions locking are a feature that was added during
Etch development cycle.  As partman-md has not really received the attention it
should have since, the code has not been updated to use locking as well.
Did I understood you correctly?

Do you see the absence of proper locking infrastructure as a blocker for the
changes in the initialization model?  For partman-md in Lenny?

Let's agree that partman-md should really be reworked on during our next
release cycle ; as I have read many time, by its complete inclusion in
partman as a first task.

> I think I extended it to be used for pre-existing LVM volumes (but I may be
> wrong).

Quoting do_initial_setup() in partman-lvm/choose_partition/lvm/do_option:

  [ "$RET" = true ] && log-output -t partman-lvm vgchange -a y
  # TODO: We need to update and lock the devices that LVM just claimed

Despite its roughness, the patch proposed earlier locks Physical Volumes
properly after the initial device detection.

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

signature.asc
Description: Digital signature

Bug#492178: marked as done ([INTL:sv] Swedish strings for cdrom-detect debconf)


Your message dated Thu, 24 Jul 2008 14:26:12 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Re: Bug#492178: [INTL:sv] Swedish strings for cdrom-detect 
debconf
has caused the Debian Bug report #492178,
regarding [INTL:sv] Swedish strings for cdrom-detect debconf
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
492178: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492178
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
package: cdrom-detect
severity: wishlist
tags: patch l10n

-- 
brother
http://frakalendern.se# THIS FILE IS AUTOMATICALLY GENERATED FROM THE MASTER FILE
# packages/po/sv.po
#
# DO NOT MODIFY IT DIRECTLY : SUCH CHANGES WILL BE LOST
#
# THIS FILE IS AUTOMATICALLY GENERATED FROM THE MASTER FILE
# packages/po/sv.po
#
# DO NOT MODIFY IT DIRECTLY : SUCH CHANGES WILL BE LOST
#
# Swedish messages for debian-installer.
# Copyright (C) 2003 Software in the Public Interest, Inc.
# This file is distributed under the same license as debian-installer.
#
# Swedish translation by:
# Per Olofsson <[EMAIL PROTECTED]>
# Daniel Nylander <[EMAIL PROTECTED]>, 2006.
#
msgid ""
msgstr ""
"Project-Id-Version: debian-installer\n"
"Report-Msgid-Bugs-To: [EMAIL PROTECTED]"
"POT-Creation-Date: 2008-06-22 22:49+\n"
"PO-Revision-Date: 2008-07-24 11:55+0100\n"
"Last-Translator: Martin Bagge <[EMAIL PROTECTED]>\n"
"Language-Team: Swedish <[EMAIL PROTECTED]>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#. :sl2:
#: ../cdrom-detect.templates:1001
msgid "Load CD-ROM drivers from removable media?"
msgstr "LÃ¤sa in drivrutiner fÃ¶r cd-rom-enheter frÃ¥n annat flyttbart media?"

#. Type: boolean
#. Description
#. :sl2:
#. Type: boolean
#. Description
#. :sl2:
#: ../cdrom-detect.templates:1001
#: ../cdrom-detect.templates:3001
msgid "No common CD-ROM drive was detected."
msgstr "Ingen vanlig cd-rom-lÃ¤sare identifierades."

#. Type: boolean
#. Description
#. :sl2:
#: ../cdrom-detect.templates:1001
msgid "You may need to load additional CD-ROM drivers from removable media, 
such as a driver floppy. If you have such media available now, insert it, and 
continue. Otherwise, you will be given the option to manually select CD-ROM 
modules."
msgstr "Du kan behÃ¶va lÃ¤sa in ytterligare drivrutiner fÃ¶r cd-rom-enheter 
frÃ¥n flyttbart media, exempelvis en diskett. Om du har en sÃ¥dant media - 
anslut det och fortsÃ¤tt. Annars kommer du att ges tillfÃ¤lle att manuellt 
vÃ¤lja cd-rom-moduler."

#. Type: text
#. Description
#. :sl1:
#: ../cdrom-detect.templates:2001
msgid "Detecting hardware to find CD-ROM drives"
msgstr "Identifierar maskinvara fÃ¶r att hitta cd-rom-enheter"

#. Type: boolean
#. Description
#. :sl2:
#: ../cdrom-detect.templates:3001
msgid "Manually select a CD-ROM module and device?"
msgstr "VÃ¤lj en cd-rom-modul och enhet manuellt?"

#. Type: boolean
#. Description
#. :sl2:
#: ../cdrom-detect.templates:3001
msgid "Your CD-ROM drive may be an old Mitsumi or another non-IDE, non-SCSI 
CD-ROM drive. In that case you should choose which module to load and the 
device to use. If you don't know which module and device are needed, look for 
some documentation or try a network installation instead of a CD-ROM 
installation."
msgstr "Din cd-rom-lÃ¤sare kan vara en gammal Mitsumi eller en annan 
cd-rom-lÃ¤sare av annan typ Ã¤n IDE eller SCSI. Om sÃ¥ Ã¤r fallet bÃ¶r du 
vÃ¤lja vilken modul som ska lÃ¤sas in och den enhet som ska anvÃ¤ndas. Om du 
inte vet vilken modul och enhet som behÃ¶vs sÃ¥ sÃ¶k efter dokumentation eller 
fÃ¶rsÃ¶k med en nÃ¤tverksinstallation istÃ¤llet fÃ¶r en cd-rom-installation."

#. Type: boolean
#. Description
#. :sl2:
#: ../cdrom-detect.templates:4001
msgid "Try again to mount the CD-ROM?"
msgstr "FÃ¶rsÃ¶ka montera cd-skivan igen?"

#. Type: boolean
#. Description
#. :sl2:
#: ../cdrom-detect.templates:4001
msgid "Your installation CD-ROM couldn't be mounted. This probably means that 
the CD-ROM was not in the drive. If so you can insert it and try again."
msgstr "Din installationsskiva kunde inte monteras. Det betyder fÃ¶rmodligen 
att cd-skivan inte var inmatad i enheten. Om sÃ¥ var fallet kan du mata in den 
och fÃ¶rsÃ¶ka igen."

#. Type: select
#. Description
#. :sl2:
#: ../cdrom-detect.templates:5001
msgid "Module needed for accessing the CD-ROM:"
msgstr "Modul som behÃ¶vs fÃ¶r att komma Ã¥t cd-rom:en:"

#. Type: select
#. Description
#. :sl2:
#: ../cdrom-detect.templates:5001
msgid "The automatic detection didn't find a CD-ROM drive. You can try to load 
a specific module if you have a

Bug#492188: marked as done ([INTL:sv] Swedish strings for hw-detect debconf)


Your message dated Thu, 24 Jul 2008 14:26:34 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Re: Bug#492188: [INTL:sv] Swedish strings for hw-detect debconf
has caused the Debian Bug report #492188,
regarding [INTL:sv] Swedish strings for hw-detect debconf
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
492188: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492188
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
package: hw-detect
severity: wishlist
tags: patch l10n

-- 
brother
http://frakalendern.se# THIS FILE IS GENERATED AUTOMATICALLY FROM THE D-I PO MASTER FILES
# The master files can be found under packages/po/
#
# DO NOT MODIFY THIS FILE DIRECTLY: SUCH CHANGES WILL BE LOST
#
# THIS FILE IS AUTOMATICALLY GENERATED FROM THE MASTER FILE
# packages/po/sv.po
#
# DO NOT MODIFY IT DIRECTLY : SUCH CHANGES WILL BE LOST
#
# Swedish messages for debian-installer.
# Copyright (C) 2003 Software in the Public Interest, Inc.
# This file is distributed under the same license as debian-installer.
#
# Swedish translation by:
# Per Olofsson <[EMAIL PROTECTED]>
# Daniel Nylander <[EMAIL PROTECTED]>, 2006.
#
msgid ""
msgstr ""
"Project-Id-Version: debian-installer\n"
"Report-Msgid-Bugs-To: [EMAIL PROTECTED]"
"POT-Creation-Date: 2008-06-24 22:50+\n"
"PO-Revision-Date: 2008-07-24 12:21+0100\n"
"Last-Translator: Martin Bagge <[EMAIL PROTECTED]>\n"
"Language-Team: Swedish <[EMAIL PROTECTED]>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: select
#. Choices
#. :sl2:
#: ../ethdetect.templates:1001
msgid "no ethernet card"
msgstr "inget ethernetkort"

#. Type: select
#. Choices
#. :sl2:
#. "none of the above" should be understood as "none of the above choices"
#: ../ethdetect.templates:1001
#: ../disk-detect.templates:3001
msgid "none of the above"
msgstr "ingen av ovanstÃ¥ende"

#. Type: select
#. Description
#. :sl2:
#: ../ethdetect.templates:1002
msgid "Driver needed by your Ethernet card:"
msgstr "Drivrutin som behÃ¶vs fÃ¶r ditt ethernetkort:"

#. Type: select
#. Description
#. :sl2:
#: ../ethdetect.templates:1002
msgid "No Ethernet card was detected. If you know the name of the driver needed 
by your Ethernet card, you can select it from the list."
msgstr "Hittade inget ethernetkort. Om du vet namnet pÃ¥ drivrutinen som krÃ¤vs 
av ditt ethernetkort kan du vÃ¤lja den frÃ¥n listan."

#. Type: boolean
#. Description
#. :sl3:
#: ../ethdetect.templates:2001
msgid "Do you intend to use FireWire Ethernet?"
msgstr "Har du planerat att anvÃ¤nda Ethernet Ã¶ver FireWire?"

#. Type: boolean
#. Description
#. :sl3:
#: ../ethdetect.templates:2001
msgid "No Ethernet card was detected, but a FireWire interface is present. It's 
possible, though unlikely, that with the right FireWire hardware connected to 
it, this could be your primary Ethernet interface."
msgstr "Inget Ethernetkort hittades men ett FireWire-grÃ¤nssnitt hittades. Det 
Ã¤r mÃ¶jligt, kanske inte normalt, att med rÃ¤tt FireWire-tillbehÃ¶r ansluten 
till det att det hÃ¤r Ã¤r ditt primÃ¤ra Ethernet-grÃ¤nssnitt."

#. Type: error
#. Description
#. :sl2:
#: ../ethdetect.templates:3001
msgid "Ethernet card not found"
msgstr "Hittade inget Ethernetkort"

#. Type: error
#. Description
#. :sl2:
#: ../ethdetect.templates:3001
msgid "No Ethernet card was found on the system."
msgstr "Inget ethernetkort hittades i systemet."

#. Type: text
#. Description
#. :sl1:
#: ../ethdetect.templates:4001
msgid "Detecting network hardware"
msgstr "Identifierar nÃ¤tverksmaskinvara"

#. Type: text
#. Description
#. Main menu item
#. :sl1:
#: ../ethdetect.templates:5001
msgid "Detect network hardware"
msgstr "Identifiera nÃ¤tverksmaskinvara"

#. Type: text
#. Description
#. Main menu item
#. :sl1:
#: ../disk-detect.templates:1001
msgid "Detect disks"
msgstr "Identifiera diskar"

#. Type: text
#. Description
#. :sl1:
#: ../disk-detect.templates:2001
msgid "Detecting disks and all other hardware"
msgstr "Identifierar hÃ¥rddiskar och all annan maskinvara"

#. Type: select
#. Choices
#. :sl2:
#: ../disk-detect.templates:3001
msgid "continue with no disk drive"
msgstr "fortsÃ¤tt utan diskettenhet"

#. Type: select
#. Description
#. :sl2:
#: ../disk-detect.templates:3002
msgid "Driver needed for your disk drive:"
msgstr "Drivrutin som behÃ¶vs fÃ¶r din diskettenhet:"

#. Type: select
#. Description
#. :sl2:
#: ../disk-detect.templates:3002
msgid "No disk drive was detected. If you know the name of the driver needed by 
your disk drive, you can select it from the list."
msgstr "Hittade ingen diskettenhet. Om du v

how to create debian-installer for amd64 on i386 system ?

2008-07-24 Thread sol-666

Hello,

I'am a debian administrator, and I want to use netboot.
I've two questions.

First:
Recently I found documentationd wich explain how to create debian-installer
from source with SSH and pressed :
http://www.pckult.net/tutoriaux/23-linux/1135-installer-debian-sur-une-machine-distante-avec-pxe-ssh-et-debian-installer
http://wiki.debian.org/DebianInstaller/Remote
http://wiki.debian.org/DebianInstaller/NetworkConsole
http://www.opensource-blog.com/single-news/article/comment-installer-debian-sur-une-machine-distante-avec-pxe-ssh-et-debian-installer/

I want to create netboot image for many systems mainly AMD64 andi386 for ubuntu
and debian.

I read the Makefile and I saw that when you compile, it use the architecture of
the system (i386 on debian i386 and amd64 on debian amd64). How can I create a
netboot image for amd64 on a i386 system ?

Here http://wiki.debian.org/DebianInstaller/NetworkConsole, someone use this
command "fakeroot make build_powerpc_netboot" but it doesn't work for me. I
also try with build_amd64_netboot and build_i386_netboot.

Second:
I want to know where I can found all documentation about netboot. What are all
possibilities with it?
Documentation with explain modules that can be added to the debian installer
like network-console (SSH)...

Many thanks

Vous adorez les chats ! Voilà un max de vidéos tendres et humoristiques.
http://video.voila.fr/

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

Re: unblocking e2fsprogs

2008-07-24 Thread Robert Millan

On Thu, Jul 24, 2008 at 01:13:06AM +0100, Adeodato Simó wrote:
> 
> > In addition 1.41.0 closed a large number of bugs over 1.40.11, and is
> > the first version to have ext4 support.

Btw, a version of GRUB 2 with ext4dev support was just uploaded
(1.96+20080717-1).

-- 
Robert Millan

 I know my rights; I want my phone call!
 What good is a phone call… if you are unable to speak?
(as seen on /.)

-- 
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

On Wed, Jul 23, 2008 at 04:27:24PM +0200, Davide Viti wrote:
> On Tue, Jul 22, 2008 at 02:04:59AM +0200, J??r??my Bobbio wrote:
> > On Sun, Jul 20, 2008 at 08:04:29PM +0200, Frans Pop wrote:
> > > That is still with the to-much-reduced font udeb, isn't it? Or did Davide 
> > > already provide a new version for you?
> > 
> > I have used the last one mentioned by Davide on the list, which is the
> > too-much-reduced one, IIRC.
> 
> I've prepared a new package […]

Which I have used to produce a new image, see:
  http://people.debian.org/~lunar/g-i+terminal-mini.iso

(Home and End keys should work fine.)

> Here some numbers:
> 73738  ttf-dejavu-mono-udeb_2.25-2_all.udeb
> 123660 DejaVuSansMono.ttf

And more numbers:
(not including rescue-mode and rescue-check as the previous image)

  * initrd size:
  without:   12609 k
 with:   13473 k
=> +   864 k

  * memory after boot:
  without:  47044 k
 with:  49060 k
=> + 2016 k

  * memory for the shell:
  before shell: 49496 k
  during shell: 50612 k
=> + 1116 k

(Test process: qemu, expert installation, adding a shell on ttyS0 by
editing /etc/inittab with BOOT_DEBUG, switching to serial console and
looking at the "used" column with the "free" command.)

In its current (and hopefully final) version, support for shells in the
graphical installer require the introduction of three new udebs, namely:
cdebconf-terminal, libvte9-udeb and ttf-dejavu-mono-udeb.

I would take care of cdebconf-terminal as part of d-i,
ttf-dejavu-mono-udeb as been worked on by Davide and Loïc Minier already
integrated most of the required changes in VTE's packaging repository.

I think that most issues I have been told about have now been solved.
I would be happy if we could take a final decision quite soon.  I can
see four options:

 [ ] NACK
 [ ] Further discussions after Lenny is released
 [ ] Merge now, including cdebconf-gtk-terminal in the gtk initrd
 [ ] Merge now, loading cdebconf-gtk-terminal on demand

I would tick the third one myself.  As far as I have seen, the memory
usage stays below 64 MB memory before anna drop its translation.  And
having a shell is pretty worthwhile when you have trouble with your
network setup… :)

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

signature.asc
Description: Digital signature

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

On Wed, Jul 23, 2008 at 07:10:38PM +0200, Frans Pop wrote:
> On Tuesday 22 July 2008, Jérémy Bobbio wrote:
> > If you want to have a look, I have updated the test image at:
> >   http://people.debian.org/~lunar/g-i+terminal-mini.iso
> >
> > I am quite happy with the result. :)
> 
> Yes, much more natural IMO.
> 
> For the "goback confirmation dialog" I suggest changing the text to 
> something a bit more positive (avoid "kill"; mention of "terminal 
> process" is technical). Something like:
>   "Resume installation
>Choose "Continue" to really exit the shell and resume the installation;
>any processes still running in the shell will be aborted."

Thanks for your proposal, which I have happily integrated.

(If wonder if there is any material I could read which would help me to
write more helpful documentation, help strings and similar stuff…)

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


signature.asc
Description: Digital signature

Re: unblocking e2fsprogs

2008-07-24 Thread Theodore Tso

On Thu, Jul 24, 2008 at 03:34:26PM +0200, Robert Millan wrote:
> On Thu, Jul 24, 2008 at 01:13:06AM +0100, Adeodato Simó wrote:
> > 
> > > In addition 1.41.0 closed a large number of bugs over 1.40.11, and is
> > > the first version to have ext4 support.
> 
> Btw, a version of GRUB 2 with ext4dev support was just uploaded
> (1.96+20080717-1).

I wouldn't dream of asking debian-boot to support ext4dev at this late
date --- but there is one thing I would ask.  As I recall, there was a
temporary fix to force to use of 128 byte inodes for the interim etch
release of the d-i.  Could we make sure that temporary fix is removed
for Lenny, so that by default new filesystems are created with 256
byte inodes?

256 byte inodes will significantly speed up Debian systems that use
any of the following programs/technologies: Selinux, Samba4, trackerd,
and/or ext4dev.  Basically, any program that uses extended attributes
(which is the reason for the first three items on that list) will be
much faster with 256 byte inodes.  Ext4dev uses the 256 byte inodes to
support some of its various new features, such as nanosecond time
resolution (important given that compilers can finish compiling a
program in under a second), the creation timestamp, 64-bit i_version
support for NFSv4, etc.

The kernel has supported 256 byte inodes for a long time; the issue
was merely Grub needed a specific patch for 128-byte inodes, and folks
didn't want to patch grub for an interim etch release.  I believe the
grub patch *has* been in Lenny for quite some time, however.  (There
was one update to that patch to make sure really ancient revision 0
filesystems don't confuse grub.)

- Ted

Date: Tue, 22 Jul 2008 10:05:21 -0500
From: Eric Sandeen <[EMAIL PROTECTED]>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
Subject: Re: Bug#491076: grub-install does not work

[...]

There was  a bug in the large inode support that I added to grub, which other 
distros picked up from red hat.  The following patch should fix it:  (apologies
for likely email patch-mangling)

 Original Message 
Subject: Broken inode_size handling in grub-fedora-9.patch
Date: Mon, 21 Jul 2008 01:40:25 -0600
From: RB <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]

Just thought I'd give you a heads-up: I was working on Gentoo bug
#220687 and I ran into an issue with a patch we seem to have gotten
from you guys, by way of Debian.

In stage2/fsys_ext2fs.c (on line 38552 of your patch), you add a macro
to find EXT2_INODE_SIZE by just pulling it from the superblock.
Unfortunately, in the non-dynamic revision of ext2 that space is
zero-padded and the result is a floating-point exception when
attempting to boot from any old-style ext2 images.  Boot-time div/0
failures are a blast to debug...   :) 

This is a rough patch against your patch with more code sucked out of
linux/ext2_fs.h - I have no way to test it against a fedora system and
it's a little chunky/odd, but it should give you an idea of what seems
to be the fix.  It compiles and runs happily on my systems.  Thanks
for your time!

RB

--- grub-fedora-9.patch 2008-07-21 01:26:34.454960640 -0600
+++ grub-fedora-9-fixed.patch2008-07-21 01:35:18.343451893 -0600
@@ -38529,7 +38529,7 @@
 };

   struct ext2_group_desc
-@@ -206,18 +251,21 @@ struct ext2_dir_entry
+@@ -206,18 +251,26 @@ struct ext2_dir_entry
   ((struct ext2_super_block *)(FSYS_BUF))
   #define GROUP_DESC \
   ((struct ext2_group_desc *) \
@@ -38549,7 +38549,12 @@
   #define EXT2_ADDR_PER_BLOCK(s)  (EXT2_BLOCK_SIZE(s) / sizeof (__u32))
   #define EXT2_ADDR_PER_BLOCK_BITS(s) (log2(EXT2_ADDR_PER_BLOCK(s)))

-+#define EXT2_INODE_SIZE(s)(SUPERBLOCK->s_inode_size)
++#define EXT2_GOOD_OLD_REV 0   /* The good old (original) format */
++#define EXT2_DYNAMIC_REV  1   /* V2 format w/ dynamic inode sizes */
++#define EXT2_GOOD_OLD_INODE_SIZE 128
++#define EXT2_INODE_SIZE(s)(((s)->s_rev_level == EXT2_GOOD_OLD_REV) ? \
++   EXT2_GOOD_OLD_INODE_SIZE : \
++   (s)->s_inode_size)
  +#define EXT2_INODES_PER_BLOCK(s) 
(EXT2_BLOCK_SIZE(s)/EXT2_INODE_SIZE(s))
  +
   /* linux/ext2_fs.h */

-- Peter

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

Re: unblocking e2fsprogs

On Thursday 24 July 2008, Theodore Tso wrote:
> I wouldn't dream of asking debian-boot to support ext4dev at this late
> date --- but there is one thing I would ask.  As I recall, there was a
> temporary fix to force to use of 128 byte inodes for the interim etch
> release of the d-i.  Could we make sure that temporary fix is removed
> for Lenny, so that by default new filesystems are created with 256
> byte inodes?

The change was only made *when installing etch* using the lenny installer, 
so the default for lenny installs has never been changed from what you 
set in e2fsprogs.

Cheers,
FJP

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

Re: unblocking e2fsprogs

2008-07-24 Thread Theodore Tso

On Thu, Jul 24, 2008 at 06:02:37PM +0200, Frans Pop wrote:
> On Thursday 24 July 2008, Theodore Tso wrote:
> > I wouldn't dream of asking debian-boot to support ext4dev at this late
> > date --- but there is one thing I would ask.  As I recall, there was a
> > temporary fix to force to use of 128 byte inodes for the interim etch
> > release of the d-i.  Could we make sure that temporary fix is removed
> > for Lenny, so that by default new filesystems are created with 256
> > byte inodes?
> 
> The change was only made *when installing etch* using the lenny installer, 
> so the default for lenny installs has never been changed from what you 
> set in e2fsprogs.
> 

Thanks for clarifying, I wasn't sure how the change was made in d-i
for etch.

- Ted


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

Bug#492051: Lenny Beta 2 installer failure

On Wed, Jul 23, 2008 at 03:26:27PM +0100, Jon Thackray wrote:
> Despite the fact that my system is using what is now a relatively well 
> known Intel motherboard, the netinst could not find CDROM drivers. The 
> CDROM is a standardr IDE CDROM, designed by Toshiba/Samsung, model SH-C522. 
> The motherboard is an Intel 955 chipset board, model type D955XBKLKR.
> 
> The installer was also unable to find network drivers for this board.
> 
> I have previously been able to install to this combination of board and 
> CDROM using netinst, so this fault represents a regression.

Could you please try with a daily built image?  You will be able to
download them from the links on:
  http://www.debian.org/devel/debian-installer/

Please use the "Save debug logs" menu option if you still encounter
problem, as with the present information you gave us, it's pretty hard
to figure out what is the problem.

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

signature.asc
Description: Digital signature

Re: unblocking e2fsprogs

2008-07-24 Thread Robert Millan

On Thu, Jul 24, 2008 at 10:58:39AM -0400, Theodore Tso wrote:
> On Thu, Jul 24, 2008 at 03:34:26PM +0200, Robert Millan wrote:
> > On Thu, Jul 24, 2008 at 01:13:06AM +0100, Adeodato Simó wrote:
> > > 
> > > > In addition 1.41.0 closed a large number of bugs over 1.40.11, and is
> > > > the first version to have ext4 support.
> > 
> > Btw, a version of GRUB 2 with ext4dev support was just uploaded
> > (1.96+20080717-1).
> 
> I wouldn't dream of asking debian-boot to support ext4dev at this late
> date --- but there is one thing I would ask.  As I recall, there was a
> temporary fix to force to use of 128 byte inodes for the interim etch
> release of the d-i.  Could we make sure that temporary fix is removed
> for Lenny, so that by default new filesystems are created with 256
> byte inodes?
> 
> 256 byte inodes will significantly speed up Debian systems that use
> any of the following programs/technologies: Selinux, Samba4, trackerd,
> and/or ext4dev.  Basically, any program that uses extended attributes
> (which is the reason for the first three items on that list) will be
> much faster with 256 byte inodes.  Ext4dev uses the 256 byte inodes to
> support some of its various new features, such as nanosecond time
> resolution (important given that compilers can finish compiling a
> program in under a second), the creation timestamp, 64-bit i_version
> support for NFSv4, etc.
> 
> The kernel has supported 256 byte inodes for a long time; the issue
> was merely Grub needed a specific patch for 128-byte inodes, and folks
> didn't want to patch grub for an interim etch release.  I believe the
> grub patch *has* been in Lenny for quite some time, however.  (There
> was one update to that patch to make sure really ancient revision 0
> filesystems don't confuse grub.)

I'm not sure what you mean by interim etch release (is that the so-called
"etch and a half"?).  Anyway, as far as GRUB is concerned you need:

  - grub-pc | grub (>= 0.97-30)

  - Mind #491076

-- 
Robert Millan

 I know my rights; I want my phone call!
 What good is a phone call… if you are unable to speak?
(as seen on /.)


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

Bug#490382: netcfg: Wireless configuration issues with ath5k

2008-07-24 Thread Glenn Saberton

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

As all mac80211 drivers will have this problem, I have made a few more
changes in netcfg. When iw_get_basic_config is called, the current freq
is stored. Non mac80211 drivers appear to ignore this after a trigger to
associate, but mac80211 drivers appear to keep this set when
iw_set_basic_config is called. This patch uses iw_set_ext  instead to
set the various values. Also because mac80211 drivers only trigger an
association event after values are set, and then finally essid, it now
resets essid after wep key is set.  Appears to still work ok with
madwifi, ath5k will now associate but not get a lease (Due to the 2.6.25
issues with ath5k, I suspect the driver not netcfg) and iwl3945 works,
but only after reconfiguring the wireless (need to investigate this further)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkiIu6MACgkQV8GyuTwyskOr6ACgiJAAwIADAjhHtPbQaJHpF2Jt
6FEAnjYx0C2RbBO+kw0Io4Sz7kOMwiDL
=MBW+
-END PGP SIGNATURE-
diff --git a/packages/netcfg/wireless.c b/packages/netcfg/wireless.c
index ed07b8a..c5fd54a 100644
--- a/packages/netcfg/wireless.c
+++ b/packages/netcfg/wireless.c
@@ -32,7 +32,8 @@ int netcfg_wireless_set_essid (struct debconfclient * client, char *iface, char*
 {
 int ret, couldnt_associate = 0;
 wireless_config wconf;
-char* tf = NULL, *user_essid = NULL, *ptr = wconf.essid;
+struct iwreq wrq;
+char* tf = NULL, *user_essid = NULL;
 
 iw_get_basic_config (wfd, iface, &wconf);
 
@@ -50,10 +51,24 @@ int netcfg_wireless_set_essid (struct debconfclient * client, char *iface, char*
 if (!strcmp(client->value, "Ad-hoc network (Peer to peer)"))
 mode = ADHOC;
 
-wconf.has_mode = 1;
-wconf.mode = mode;
+wrq.u.essid.flags = 1;
+wrq.u.mode = mode;
+
+if (iw_set_ext(wfd, iface, SIOCSIWMODE, &wrq) < 0) {
+di_warning("Set mode failed");
+return 1;
+}
+/* set freq to auto, this has been set earlier, checking for ifaces */
 
-debconf_input(client, priority ? priority : "low", "netcfg/wireless_essid");
+wrq.u.freq.m = -1;
+wrq.u.freq.e = 0;
+wrq.u.freq.flags = 0;
+
+if (iw_set_ext(skfd, iface, SIOCSIWFREQ, &wrq) < 0) {
+di_warning("Setting freq to auto failed");
+return -1;
+}
+debconf_input(client, priority ? priority : "high", "netcfg/wireless_essid");
 
 if (debconf_go(client) == 30)
 return GO_BACK;
@@ -63,16 +78,24 @@ int netcfg_wireless_set_essid (struct debconfclient * client, char *iface, char*
 
 automatic:
 /* question not asked or user doesn't care or we're successfully associated */
-if (!empty_str(wconf.essid) || empty_str(client->value)) 
+if (empty_str(client->value)) 
 {
 int i, success = 0;
 
 /* Default to any AP */
-wconf.essid[0] = '\0';
-wconf.essid_on = 0;
-
-iw_set_basic_config (wfd, iface, &wconf);
+essid = malloc(IW_ESSID_MAX_SIZE +1);
+essid[0] = '\0';
+wrq.u.essid.pointer = essid;
+wrq.u.essid.flags = 0;
 
+if (iw_set_ext(skfd, iface, SIOCSIWESSID, &wrq) < 0) {
+di_warning("Setting essid to any/off failed");
+free(essid);
+essid = NULL;
+return 1;
+}
+free(essid);
+essid = NULL;
 /* Wait for association.. (MAX_SECS seconds)*/
 #define MAX_SECS 3
 
@@ -164,29 +187,30 @@ automatic:
 
 essid = user_essid;
 
-memset(ptr, 0, IW_ESSID_MAX_SIZE + 1);
-snprintf(wconf.essid, IW_ESSID_MAX_SIZE + 1, "%s", essid);
-wconf.has_essid = 1;
-wconf.essid_on = 1;
+wrq.u.essid.pointer = essid;
+wrq.u.essid.flags = 1;
+wrq.u.essid.length = strlen(essid);
 
-iw_set_basic_config (wfd, iface, &wconf);
+if (iw_set_ext(skfd, iface, SIOCSIWESSID, &wrq) < 0) {
+di_warning("Set essid %s failed", essid);
+return 1;
+}
 
 return 0;
 }
 
 static void unset_wep_key (char* iface)
 {
-wireless_config wconf;
-int ret;
-
-iw_get_basic_config(wfd, iface, &wconf);
+struct iwreq wrq;
 
-wconf.has_key = 1;
-wconf.key[0] = '\0';
-wconf.key_flags = IW_ENCODE_DISABLED | IW_ENCODE_NOKEY;
-wconf.key_size = 0;
+wrq.u.data.pointer = (caddr_t) NULL;
+wrq.u.data.flags = IW_ENCODE_DISABLED | IW_ENCODE_NOKEY;
+wrq.u.data.length = 0;
 
-ret = iw_set_basic_config (wfd, iface, &wconf);
+if (iw_set_ext(skfd, iface, SIOCSIWENCODE, &wrq) < 0) {
+di_warning("Clear wepkey failed");
+return -1;
+}
 }
 
 int netcfg_wireless_set_wep (struct debconfclient * client, char* iface)
@@ -247,6 +271,15 @@ int netcfg_wireless_set_wep (struct debconfclient * client, char* iface)
 return -1;
 }
 
+/* Reset essid for mac80211 based drivers */
+wrq.u.essid.pointer = essid;
+wrq.u.essid.length = strlen(essid);
+

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

2008-07-24 Thread Otavio Salvador

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

>  [4] NACK
>  [3] Further discussions after Lenny is released
>  [1] Merge now, including cdebconf-gtk-terminal in the gtk initrd
>  [2] Merge now, loading cdebconf-gtk-terminal on demand
>
> I would tick the third one myself.  As far as I have seen, the memory
> usage stays below 64 MB memory before anna drop its translation.  And
> having a shell is pretty worthwhile when you have trouble with your
> network setup… :)

This is my "vote"

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


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

Bug#491712: firmware for iwl4965 is asked in disk-detect (was: installation-reports: HP lenovo R61i laptop)

Frans Pop wrote:
> No. With '-1' you don't get trailing slashes for directories.

FWIW, that's a busyboxism. I'd use find.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#492077: debian-installer: avoid searching for libgcc_s.so

John Reiser wrote:
> Many executables used by the installer depend on libgcc_s.so.  Searching for
> this library (by ld-linux.so just after execve) takes more than 1% of install
> time.  The search tries:
>2375 open("/lib/tls/libgcc_s.so.1", O_RDONLY) = -1 ENOENT
>2373 open("/lib/fast-mult/libgcc_s.so.1", O_RDONLY) = -1 ENOENT
>2372 open("/lib/v5l/libgcc_s.so.1", O_RDONLY) = -1 ENOENT
>2372 open("/lib/v5l/fast-mult/libgcc_s.so.1", O_RDONLY) = -1 ENOENT
>2356 open("/lib/tls/v5l/fast-mult/libgcc_s.so.1", O_RDONLY) = -1 ENOENT
>2355 open("/lib/tls/fast-mult/libgcc_s.so.1", O_RDONLY) = -1 ENOENT
>2351 open("/lib/tls/v5l/libgcc_s.so.1", O_RDONLY) = -1 ENOENT
> before finding it in /lib.  [Those counts in the first column are for less 
> than
> 1/3 of base install on a NSLU2 armel-eabi in low-memory mode.]

[EMAIL PROTECTED]:~>time perl -e 'for (1..16625) { open(IN, "/no/file") }'  
0.03user 0.03system 0:00.06elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k

So for a typical install on modern hardware, these 16 thousand extra syscalls
use less than 0.1 second.

I don't have my slug handy to try, but 1% of install time sounds very excessive
even there.

Also, when trying to optimise something, it's generally a good idea
to find an optimiation target that yields significantly better than 1%
improvement.. So, for example, optimising partman to not fork > 1 thousand
child processes when building its menu would probably yield a much more
noticeable benefit. There's a bug in the BTS about that too, IIRC.

> The search can be avoided, by forcing it to succeed on the first try:
>export LD_LIBRARY_PATH=/lib

That stikes me as potentially a very dangerous hack. Also, it doesn't
really result in fewer syscalls here:

[EMAIL PROTECTED]:~>strace busybox 2>&1 |grep open 
open("/etc/ld.so.cache", O_RDONLY)  = 5
open("/lib/i686/cmov/libm.so.6", O_RDONLY) = 5
open("/lib/i686/cmov/libc.so.6", O_RDONLY) = 5
[EMAIL PROTECTED]:~>LD_LIBRARY_PATH=/lib strace busybox 2>&1 |grep open
open("/lib/tls/i686/sse2/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file 
or directory)
open("/lib/tls/i686/sse2/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or 
directory)
open("/lib/tls/i686/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or 
directory)
open("/lib/tls/i686/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or 
directory)
open("/lib/tls/sse2/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or 
directory)
open("/lib/tls/sse2/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or 
directory)
open("/lib/tls/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or 
directory)
open("/lib/tls/libm.so.6", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/lib/i686/sse2/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or 
directory)
open("/lib/i686/sse2/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or 
directory)
open("/lib/i686/cmov/libm.so.6", O_RDONLY) = 5
open("/lib/i686/cmov/libc.so.6", O_RDONLY) = 5


IIRC the linker/glibc already has a bug open about its innefficient
attempts to open libraries that arn't there. I don't think we should try
to work around such a bug in the installer.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#492086: partman: menus are very slow

There is already discussion about how to speed up partman elsewhere in
the BTS.

Minor shell efficiency tricks are not going to help much. It forks
*thousands* of processes per menu.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#492077: debian-installer: avoid searching for libgcc_s.so

Joey Hess wrote:
> [EMAIL PROTECTED]:~>time perl -e 'for (1..16625) { open(IN, "/no/file") }'
>   
> 0.03user 0.03system 0:00.06elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k
> 
> So for a typical install on modern hardware, these 16 thousand extra syscalls
> use less than 0.1 second.
> 
> I don't have my slug handy to try, but 1% of install time sounds very 
> excessive
> even there.

[EMAIL PROTECTED]:~>time perl -e 'for (1..16625) { open(IN, "/no/file") }'
0.97user 0.28system 0:01.26elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k

So even on the slug, if these syscalls take the claimed 1% of the install time,
then the entire installation must take less than 3 minutes!

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#492246: setting package to archdetect hw-detect ethdetect disk-detect, tagging 492246, tagging 491712

# Automatically generated email from bts, devscripts version 2.10.34
# via tagpending 
#
# hw-detect (1.65) UNRELEASED; urgency=low
#
#  * ethdetect: Some modules do not request firmware until their interface
#has been brought up. So up and down every interface so missing firmware
#can be detected. Closes: #491712
#  * check-missing-firmware: Don't display dups. Closes: #492246 

package archdetect hw-detect ethdetect disk-detect
tags 492246 + pending
tags 491712 + pending




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

Processed: setting package to archdetect hw-detect ethdetect disk-detect, tagging 492246, tagging 491712

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.10.34
> # via tagpending
> #
> # hw-detect (1.65) UNRELEASED; urgency=low
> #
> #  * ethdetect: Some modules do not request firmware until their interface
> #has been brought up. So up and down every interface so missing firmware
> #can be detected. Closes: #491712
> #  * check-missing-firmware: Don't display dups. Closes: #492246
> package archdetect hw-detect ethdetect disk-detect
Ignoring bugs not assigned to: hw-detect archdetect ethdetect disk-detect

> tags 492246 + pending
Bug#492246: firmware listed multiple times during firmware loading
There were no tags set.
Tags added: pending

> tags 491712 + pending
Bug#491712: firmware for iwl4965 is asked in disk-detect
There were no tags set.
Tags added: pending

>
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#491712: firmware for iwl4965 is asked in disk-detect (was: installation-reports: HP lenovo R61i laptop)

On Thursday 24 July 2008, Joey Hess wrote:
> Frans Pop wrote:
> > No. With '-1' you don't get trailing slashes for directories.
>
> FWIW, that's a busyboxism.

And bashism too then...

> I'd use find. 

Yes, I thought of that. I dislike having to restrict depth but it would 
allow to explicitly select dirs.

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

Re: [PATCH] RAID10 and RAID6

On Sunday 20 July 2008, Ryan Niebur wrote:
> here are the patches

Other than the comments below and final testing this looks ready for 
committing to me.

Please also test creating (and deleting) multiple RAID devices in the 
same "configure RAID" session, for example RAID1 for /boot + RAID5 for 
LVM + RAID 1 for swap + RAID0 for /home/media (or whatever).


Patch 1:
+   LEVEL=${1#RAID}

This statement should probably go _before_ the case statement to determine 
minimum sizes. That would also "reunite" the setting of the minimum size 
in the template with the code that determines it.

+   # Loop until at least one device has been selected for RAID 1

Comment is incorrect. We want only 1 device, not "at least". So it should 
be: "# For RAID 1 only one device can be selected"


Patch 2:
+  f - far copies: Multiple copies have very different offsets

The explanation for the other two options end with a ".", this one does 
not. I would suggest _removing_ the period for the other two options.

+   [ $(echo $RET | sed s/.//) -le $DEV_COUNT ]; then

Please add quotes around the sed regexp. Maybe not strictly needed, but 
reduces the risk of unexpected errors, improves readability and 
consistency with rest of code.


Patch3:
Looking at the diff in templates this is really worth doing. Should reduce 
memory usage nicely.

+   for i in devcount devs sparecount sparedevs; do
+   db_subst mdcfg/raid$i LEVEL "$LEVEL"
+   done

I had to look at this a couple of times before I got what was happening. 
Also note that you again split the determination of minimum size and 
setting its use for templates, which makes the logic less clear.

I would suggest moving the 3 lines quoted above to before the case 
statement for min. size and add a comment before them.
Keep the two lines that subst/set min size for the template together after 
that case statement and also add a comment.

Cheers,
FJP


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

Re: Please unblock nano 2.0.7-3

2008-07-24 Thread Adeodato Simó

* Jordi Mallach [Thu, 24 Jul 2008 21:07:34 +0200]:

> Hi,

Hi Jordi,

> I'm requesting a freeze exception for nano 2.0.7-3, when current in
> lenny is 2.0.7-1.

Ok; nano is not frozen because of the freeze (yet), but just because it
produces an udeb. Thanks for the detailed explanations, though :), CCing
-boot to get an ack.

>  * -2 was uploaded on July 3rd to fix two important bugs that caused
>segfaults or freezes in nano.

>  * -3 was uploaded with an extra patch to solve a FTBFS due to missing 
>arguments to open() in a pair of bits of the code.

> Relevant changelog entries:

>* debian/patches/ja_help_freeze.patch: apply patch from Mitsuya Shibata
>  to fix an endless loop when displaying help using a Japanese locale.
>  (fixes LP #201769).
>* debian/patches/small_window_sigsegv.patch: apply patch from SVN to
>  fix a segfault when running nano on a too small terminal terminal.
>* Add patch open_flags.patch to add mode parametre to open() to solve a
>  FTBFS in Ubuntu 8.10, compiled with -D_FORTIFY_SOURCE=2 (LP: 247692).

> The first two patches have been in unstable for 3 weeks and have not
> caused any new bug reports. The third patch should be trivial and has
> been in unstable for nearly 2 weeks, and has not brought up any new
> issues neither on unstable or Ubuntu intrepid.

> If nobody objects, having in mind nano does affect Debian installer via
> an updated nano-udeb, I'd like to see these cherrypicked patches in lenny.

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
As scarce as truth is, the supply has always been in excess of the demand.
-- Josh Billings


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

Re: [PATCH] RAID10 and RAID6

One more...

Patch 1:
+   let SELECTED++

I don't think we use that syntax anywhere else in D-I, at least I cannot 
remember seeing it. Please use 'SELECTED=$(($SELECTED + 1))' instead.


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

Processed: setting package to archdetect hw-detect ethdetect disk-detect, tagging 492249

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.10.34
> # via tagpending
> #
> # hw-detect (1.65) UNRELEASED; urgency=low
> #
> #  * check-missing-firmware: Check that debs are the right architecture before
> #trying to use them. Closes: #492249
> #
> package archdetect hw-detect ethdetect disk-detect
Ignoring bugs not assigned to: hw-detect archdetect ethdetect disk-detect

> tags 492249 + pending
Bug#492249: does not handle firmware packages for other architectures on media
There were no tags set.
Tags added: pending

>
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#492249: setting package to archdetect hw-detect ethdetect disk-detect, tagging 492249

# Automatically generated email from bts, devscripts version 2.10.34
# via tagpending 
#
# hw-detect (1.65) UNRELEASED; urgency=low
#
#  * check-missing-firmware: Check that debs are the right architecture before
#trying to use them. Closes: #492249
#

package archdetect hw-detect ethdetect disk-detect
tags 492249 + pending




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

Bug#490896: marked as done (Keyboard related issues in the graphical installer)

Your message dated Thu, 24 Jul 2008 22:12:14 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Re: Bug#490896: Keyboard related issues in the graphical 
installer
has caused the Debian Bug report #490896,
regarding Keyboard related issues in the graphical installer
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)

-- 
490896: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490896
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: cdebconf-gtk-udeb

Meta bug report for keyboard issues seen in the graphical installer which 
are often caused by bugs in libraries we use or other components.

This BR can be blocked by those bugs and thus serve as a single reference 
point.

--- End Message ---
--- Begin Message ---
On Tue, Jul 15, 2008 at 06:44:25AM +0200, Frans Pop wrote:
> Meta bug report for keyboard issues seen in the graphical installer which 
> are often caused by bugs in libraries we use or other components.
> 
> This BR can be blocked by those bugs and thus serve as a single reference 
> point.

All bugs have been solved.  Tests on the i386 netboot mini.iso dated
20080724-19:33 were positive about it. :)

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

signature.asc
Description: Digital signature
--- End Message ---

Processed: setting package to archdetect hw-detect ethdetect disk-detect, tagging 492248

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.10.34
> # via tagpending
> #
> # hw-detect (1.65) UNRELEASED; urgency=low
> #
> #  * post-base-installer: If dpkg fails to install a firmware package, likely
> #because it has dependencies outside base, remove it rather than leaving
> #the db in an inconsistent state. Note that bugs have been filed to get 
> all
> #such firmware packages fixed. Closes: #492248
> #
> package archdetect hw-detect ethdetect disk-detect
Ignoring bugs not assigned to: hw-detect archdetect ethdetect disk-detect

> tags 492248 + pending
Bug#492248: installation firmware packages with dependencies fails in 
post-base-installer hook
There were no tags set.
Tags added: pending

>
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#492248: setting package to archdetect hw-detect ethdetect disk-detect, tagging 492248

# Automatically generated email from bts, devscripts version 2.10.34
# via tagpending 
#
# hw-detect (1.65) UNRELEASED; urgency=low
#
#  * post-base-installer: If dpkg fails to install a firmware package, likely
#because it has dependencies outside base, remove it rather than leaving
#the db in an inconsistent state. Note that bugs have been filed to get all
#such firmware packages fixed. Closes: #492248
#

package archdetect hw-detect ethdetect disk-detect
tags 492248 + pending




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

Bug#492086: partman: menus are very slow

John Reiser wrote:
> First, avoid searching for "cat" every time.  The default search tries:
>/usr/local/sbin/cat
>/usr/local/bin/cat
>/usr/sbin/cat
>/usr/bin/cat
>/sbin/cat
> before finding /bin/cat.  Instead: use 'which' or 'type' to do the search 
> once,
> assign the result to a local variable, and expand the variable instead of
> searching:
>CAT=$(which cat)
>$($CAT $dir/default_response)
> Or, in nearly all cases the result is known ahead of time:
>CAT=/bin/cat

So the question is, how much system time do the following failing system calls
actually take, when multiplied by the number of calls to "cat" made in
the lifetime of partman:

[EMAIL 
PROTECTED]:~>PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 
strace -f busybox sh -c 'cat /dev/null' 2>&1 |grep execv
[pid 32292] execve("/usr/local/sbin/cat", ["cat", "/dev/null"], [/* 45 vars 
*/]) = -1 ENOENT (No such file or directory)
[pid 32292] execve("/usr/local/bin/cat", ["cat", "/dev/null"], [/* 45 vars */]) 
= -1 ENOENT (No such file or directory)
[pid 32292] execve("/usr/sbin/cat", ["cat", "/dev/null"], [/* 45 vars */]) = -1 
ENOENT (No such file or directory)
[pid 32292] execve("/usr/bin/cat", ["cat", "/dev/null"], [/* 45 vars */]) = -1 
ENOENT (No such file or directory)
[pid 32292] execve("/sbin/cat", ["cat", "/dev/null"], [/* 45 vars */]) = -1 
ENOENT (No such file or directory)
[pid 32292] execve("/bin/cat", ["cat", "/dev/null"], [/* 45 vars */]) = 0

We can use a small C program to time an arbitrary number of failing exec's:

[EMAIL PROTECTED]:~>cat foo.c 
main () {
int i;
for (i=0; i < 10; i++)
execve("/no/such/path/to/cat", 0);
}

[EMAIL PROTECTED]:~>make foo
make: `foo' is up to date.
[EMAIL PROTECTED]:~>time ./foo
Command exited with non-zero status 255
0.01user 0.23system 0:00.27elapsed 90%CPU (0avgtext+0avgdata 0maxresident)k

So, for 1 second of time to be used searching the PATH for it, d-i would
have to run cat 7 times on modern hardware (the nslu2 is of course
~ 500 times slower). OTOH, actually running cat, as opposed to searching
for it, takes much much more time.. The same hardware can only run cat
1500 times per second.

Conclusion 1: System calls are much much faster than you'd think. Except that
successfully doing a fork+exec is slow.

Conclusion 2: Benchmark before optimising. In this case, trying to
optimise away the wrong system calls is a waste of time.

PS: Reordering PATH to put /usr/bin first and omit /usr/local/bin would
be the easy way to optimise this, IF searching the path were actually
a significant time sink. However, it does not appear to be.

PPS: Actually _eliminating_ calls to cat and other binaries in partman would
 of course help. A partman written in C should be 100 to 1000 times as
 fast as the current one.

-- 
see shy jo

signature.asc
Description: Digital signature

Re: RFC: Output files for netboot-xen flavour

2008-07-24 Thread Ian Campbell

On Tue, 2008-07-22 at 12:35 +0200, Frans Pop wrote:
> On Tuesday 22 July 2008, Ian Campbell wrote:
> > I've attached a patch which implements this and would appreciate any
> > comments. In particular I'm pretty sure dumping xm-debian.cfg into
> > build/config/i386 is not the right place -- any suggestions?
> 
> Such files belong in build/boot/x86 and can be copied from there as 
> needed.

Thanks, I've done that.

> You should also check if the current MANIFEST entries are still needed and 
> if a new MANIFEST entry is needed for your config file.

Good point, thanks!

New patch is attached with these two changes and the updates from
Bastian's review of the python code. Output is:
$ tree dest/netboot/xen/
dest/netboot/xen/
|-- initrd.gz
|-- vmlinuz
`-- xm-debian.cfg

Only remaining concern is how to authenticate the downloaded files, is
there a way? I couldn't find a signature of anything relevant in the
dists tree so I just stuck a print of "WARNING: Installer kernel and
ramdisk are not authenticated." which is a bit lame...

Since linux-kernel-di-i386-2.6 went through new yesterday I included the
patch to enable the netboot-xen flavour. An upload of the new
base-installer (for the 686-bigmem kernel selection) is needed before it
becomes usable though.

Ian.
-- 
Ian Campbell

BOFH excuse #62:

need to wrap system in aluminum foil to fix problem
Index: config/i386/netboot-xen.cfg
===
--- config/i386/netboot-xen.cfg	(revision 54567)
+++ config/i386/netboot-xen.cfg	(working copy)
@@ -2,6 +2,7 @@
 TYPE=netboot
 include config/i386/netboot.cfg
 EXTRANAME=netboot/xen/
-MANIFEST-NETBOOT_DIR = "PXE boot directory for tftp server (Xen)"
-MANIFEST-NETBOOT_TAR = "tarball of PXE boot directory (Xen)"
-MANIFEST-MINIISO = "tiny CD image that boots the netboot installer (Xen)"
+MANIFEST-KERNEL = "kernel image for installing under Xen"
+MANIFEST-INITRD = "initrd for installing under Xen"
+MANIFEST-XENCFG = "example Xen configuration"
+TARGET = $(KERNEL) $(INITRD) xen_config
Index: config/i386.cfg
===
--- config/i386.cfg	(revision 54567)
+++ config/i386.cfg	(working copy)
@@ -1,4 +1,4 @@
-MEDIUM_SUPPORTED = cdrom netboot netboot-gtk hd-media # netboot-xen #floppy #monolithic
+MEDIUM_SUPPORTED = cdrom netboot netboot-gtk netboot-xen hd-media #floppy #monolithic
 
 # The version of the kernel to use.
 BASEVERSION = 2.6.25-2
Index: config/x86.cfg
===
--- config/x86.cfg	(revision 54567)
+++ config/x86.cfg	(working copy)
@@ -16,6 +16,9 @@
 # The directory boot screens for syslinux will go in.
 BOOT_SCREEN_DIR = 
 
+# Location for Xen example configuration.
+XENCFG = $(SOME_DEST)/$(EXTRANAME)xm-debian.cfg
+
 # Compress binaries to save more space.
 # Doesn't really save much since we gzip the image later though.
 .PHONY: arch_tree
@@ -291,3 +294,9 @@
 	if [ -n "$(SPLASH_PNG)" ]; then \
 		cp $(SPLASH_PNG) $(TEMP_NETBOOT_DIR)/$(BOOT_SCREEN_DIR)/splash.png; \
 	fi
+
+.PHONY: xen_config
+xen_config:
+	install -m 644 boot/x86/xm-debian.cfg $(XENCFG)
+	update-manifest $(XENCFG) $(MANIFEST-XENCFG)
+
Index: boot/x86/xm-debian.cfg
===
--- boot/x86/xm-debian.cfg	(revision 0)
+++ boot/x86/xm-debian.cfg	(revision 0)
@@ -0,0 +1,182 @@
+#  -*- mode: python; -*-
+#
+# Example Python setup script for Debian guest installation.
+#
+#
+# Standard options are configured as normal. Only a subset are included below.
+# See /usr/share/doc/xen-utils-common/examples for full examples.
+#
+# After standard options are configure use
+#xm create xm-debian.cfg install=true"
+# to start the Debian Installer.
+#
+# In the installation case the following additional variables exist:
+# install-arch: which architecture to install. e.g. i386 or amd64
+# install-suite: which Debian version to install. e.g. lenny or sid
+# install-mirror: which Debian mirror to use
+#   e.g. http://ftp.uk.debian.org/debian
+# install-installer: where to obtain the Debian Installer bits, by
+#   default these are located under install-mirror. To use a nightly
+#   snapshot: http://people.debian.org/~joeyh/d-i/images/daily/
+# install-extra: extra command line arguments
+#
+
+
+#
+# Standard variables
+
+# Initial memory allocation (in megabytes) for the new domain.
+memory = 128
+
+# A name for your domain. All domains must have different names.
+name = "ExampleDomain"
+
+# 128-bit UUID for the domain.  The default behavior is to generate a new UUID
+# on each call to 'xm create'.
+#uuid

location of etch-n-half netboot-images

2008-07-24 Thread Franklin PIAT

Hello,

By chance, do you already know what will be the URL for etch-n-half
netboot image ?

This is for di-netboot-assistant's di-source.list.

Franklin




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

Bug#492086: partman: menus are very slow

2008-07-24 Thread John Reiser

Joey Hess wrote:

> Conclusion 2: Benchmark before optimising. In this case, trying to
> optimise away the wrong system calls is a waste of time.

The benchmark code and measurements [snipped] are not a good comparison
with the actual environment of low-memory mode.  In particular, the use of
swap space is likely in low memory mode, but almost certainly not present
in the measurements reported above.  Any actual use of swap space (or paging)
will tend to increase the delay, and increase the relative advantage
of avoiding fruitless searching.

> PS: Reordering PATH to put /usr/bin first and omit /usr/local/bin would
> be the easy way to optimise this, IF searching the path were actually
> a significant time sink. However, it does not appear to be.

It takes a minute or so to change partman by adding something such as
"export PATH=/bin".  If the searching in partman becomes faster by >= 0.2
second per run, and if partman is run some thousands of times in the future
life of the installer, then that is a net savings, and not a waste.  Perhaps
the intended claim was, "I'd rather spend my time doing something with a
larger payoff."  So would the humans who use partman.

Consider this shell code:
-
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binPATH=/bin \
busybox sh -c '
  for i in 0 1 2 3 4 5 6 7 8 9
  do
for j in 0 1 2 3 4 5 6 7 8 9
do
  for k in 0 1 2 3 4 5 6 7 8 9
  do
cat /dev/null
  done
done
  done
'

which runs in 22.2 seconds on my NSLU2 for 1000 executions of "cat /dev/null"
in an environment much more similar to real partman than previous benchmarks.
Changing to "PATH=/bin " runs in 21.5 seconds, which is 0.7 seconds faster.
Altering the search path does achieve measured savings.

> PPS: Actually _eliminating_ calls to cat and other binaries in partman would
>  of course help. A partman written in C should be 100 to 1000 times as
>  fast as the current one.

The original bug report contains two further paragraphs which give specific ways
to avoid fork+exec:
   Second, use a shell builtin if possible.  [ $(< file) ]
   Third, use shell text strings where possible.
  [ PM':'$dir':'default_response=$( ... ) ]
"$(< file)" turns out not to work on various shells other than bash.
The use of non-literal variables was panned by Frans Pop as being too obscure,
although there are projects which use them.  [Look at libtool to see some
mind-boggling obscurity in shell programming.]

However, there is another shell builtin which does input without fork+exec,
namely 'read'.  If the replies are restricted to be only one line, then:
   read  < $dir/default_response
   default_response="$REPLY"
achieves the same effect as
   default_response=$(cat $dir/default_response)
but without requiring fork+exec.  So 'read' looks like a promising replacement.

-- 

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

Re: [PATCH] RAID10 and RAID6

2008-07-24 Thread Ryan Niebur

oops, I meant to send this to debian-boot.

On Thu, Jul 24, 2008 at 02:59:17PM -0700, Ryan Niebur wrote:
> On Thu, Jul 24, 2008 at 09:45:26PM +0200, Frans Pop wrote:
> > One more...
> > 
> > Patch 1:
> > + let SELECTED++
> > 
> > I don't think we use that syntax anywhere else in D-I, at least I cannot 
> > remember seeing it. Please use 'SELECTED=$(($SELECTED + 1))' instead.
> 
> The code that I took out was using 'let SELECTED++', and so is the rest of 
> mdcfg.sh, so that's what I used.
> But I changed it in my new patches.
> 
> On Thu, Jul 24, 2008 at 09:39:15PM +0200, Frans Pop wrote:
> > +   # Loop until at least one device has been selected for RAID 1
> > 
> > Comment is incorrect. We want only 1 device, not "at least". So it should 
> > be: "# For RAID 1 only one device can be selected"
> > 
> 
> The code tests to make sure that it's greater than 1 and less than or equal 
> to the number of devices you want.
> 
> The rest of the changes (and the debconf template error Christian pointed 
> out) are fixed in these new patches.
> 
> -- 
> _
> Ryan Niebur
> [EMAIL PROTECTED]

-- 
_
Ryan Niebur
[EMAIL PROTECTED]
From 5169863b855c702c05e7d4b01581fe4ccf11ecb4 Mon Sep 17 00:00:00 2001
From: Ryan Niebur <[EMAIL PROTECTED]>
Date: Sun, 20 Jul 2008 00:14:17 -0700
Subject: [PATCH] reuse code

---
 packages/mdcfg/mdcfg.sh |  242 +--
 1 files changed, 65 insertions(+), 177 deletions(-)

diff --git a/packages/mdcfg/mdcfg.sh b/packages/mdcfg/mdcfg.sh
index 37a1f09..f0758b3 100755
--- a/packages/mdcfg/mdcfg.sh
+++ b/packages/mdcfg/mdcfg.sh
@@ -103,12 +103,12 @@ md_createmain() {
 		fi
 
 		case "$RAID_SEL" in
-		RAID5)
-			md_create_raid5 ;;
-		RAID1)
-			md_create_raid1 ;;
+		RAID5|RAID1)
+			md_create_array "$RAID_SEL" ;;
 		RAID0)
 			md_create_raid0 ;;
+		*)
+			return 1 ;;
 		esac
 	fi
 }
@@ -199,228 +199,116 @@ md_create_raid0() {
 		  -n $SELECTED $RAID_DEVICES
 }
 
-md_create_raid1() {
+md_create_array(){
 	OK=0
 
-	db_set mdcfg/raid1devcount 2
+	LEVEL=${1#RAID}
 
-	# Get the count of active devices
-	while [ $OK -eq 0 ]; do
-		db_input critical mdcfg/raid1devcount
-		db_go
-		if [ $? -eq 30 ]; then
-			return
-		fi
-
-		# Figure out, if the user entered a number
-		db_get mdcfg/raid1devcount
-		RET=$(echo $RET | sed -e "s/[[:space:]]//g")
-		if [ "$RET" ]; then
-			let "OK=${RET}>0 && ${RET}<99"
-		fi
-	done
-
-	db_set mdcfg/raid1sparecount "0"
-	OK=0
-
-	# Same procedure as above, but get the number of spare partitions
-	# this time.
-	# TODO: Make a general function for this kind of stuff
-	while [ $OK -eq 0 ]; do
-		db_input critical mdcfg/raid1sparecount
-		db_go
-		if [ $? -eq 30 ]; then
-			return
-		fi
-		db_get mdcfg/raid1sparecount
-		RET=$(echo $RET | sed -e "s/[[:space:]]//g")
-		if [ "$RET" ]; then
-			let "OK=${RET}>=0 && ${RET}<99"
-		fi
-	done
-
-	db_get mdcfg/raid1devcount
-	DEV_COUNT="$RET"
-	db_get mdcfg/raid1sparecount
-	SPARE_COUNT="$RET"
-	REQUIRED=$(($DEV_COUNT + $SPARE_COUNT))
-
-	db_set mdcfg/raid1devs ""
-	SELECTED=0
-
-	# Loop until at least one device has been selected
-	until [ $SELECTED -gt 0 ] && [ $SELECTED -le $DEV_COUNT ]; do
-		db_subst mdcfg/raid1devs COUNT "$DEV_COUNT"
-		db_subst mdcfg/raid1devs PARTITIONS "$PARTITIONS"
-		db_input critical mdcfg/raid1devs
-		db_go
-		if [ $? -eq 30 ]; then
-			return
-		fi
-
-		db_get mdcfg/raid1devs
-		SELECTED=0
-		for i in $RET; do
-			DEVICE=$(echo $i | sed -e "s/,//")
-			let SELECTED++
-		done
-	done
-
-	# Add "missing" for as many devices as weren't selected
-	MISSING_DEVICES=""
-	while [ $SELECTED -lt $DEV_COUNT ]; do
-		MISSING_DEVICES="$MISSING_DEVICES missing"
-		let SELECTED++
-	done
-
-	# Remove partitions selected in raid1devs from the PARTITION list
-	db_get mdcfg/raid1devs
-
-	prune_partitions "$RET"
-
-	db_set mdcfg/raid1sparedevs ""
-	SELECTED=0
-	if [ $SPARE_COUNT -gt 0 ]; then
-		FIRST=1
-		# Loop until the correct number of devices has been selected.
-		# That means any number less than or equal to the spare count.
-		while [ $SELECTED -gt $SPARE_COUNT ] || [ $FIRST -eq 1 ]; do
-			FIRST=0
-			db_subst mdcfg/raid1sparedevs COUNT "$SPARE_COUNT"
-			db_subst mdcfg/raid1sparedevs PARTITIONS "$PARTITIONS"
-			db_input critical mdcfg/raid1sparedevs
-			db_go
-			if [ $? -eq 30 ]; then
-return
-			fi
-
-			db_get mdcfg/raid1sparedevs
-			SELECTED=0
-			for i in $RET; do
-DEVICE=$(echo $i | sed -e "s/,//")
-let SELECTED++
-			done
-		done
-	fi
-
-	# The number of spares the user has selected
-	NAMED_SPARES=$SELECTED
-
-	db_get mdcfg/raid1devs
-	RAID_DEVICES=$(echo $RET | sed -e "s/,//g")
-
-	db_get mdcfg/raid1sparedevs
-	SPARE_DEVICES=$(echo $RET | sed -e "s/,//g")
-
-	MISSING_SPARES=""
-
-	COUNT=$NAMED_SPARES
-	while [ $COUNT -lt $SPARE_COUNT ]; do
-		MISSING_SPARES="$MISSING_SPARES missing"
-		let COUNT++
-	done
-
-	# Find the next available md-number
-	MD_NUM=$(grep ^md /proc

Re: [PATCH] RAID10 and RAID6

2008-07-24 Thread Ryan Niebur

On Thu, Jul 24, 2008 at 09:39:15PM +0200, Frans Pop wrote:
> On Sunday 20 July 2008, Ryan Niebur wrote:
> > here are the patches
> 
> Other than the comments below and final testing this looks ready for 
> committing to me.
> 

yay!

> Please also test creating (and deleting) multiple RAID devices in the 
> same "configure RAID" session, for example RAID1 for /boot + RAID5 for 
> LVM + RAID 1 for swap + RAID0 for /home/media (or whatever).
> 
> 

Deleting the 2 raid arrays I already had and then partitioning like this:

RAID5 -> ext3 -> /
RAID1 -> ext2 -> /boot
RAID0 -> LVM -> reiserfs -> /home

Worked fine.

-- 
_
Ryan Niebur
[EMAIL PROTECTED]


signature.asc
Description: Digital signature

Bug#492086: partman: menus are very slow

John Reiser wrote:
> The benchmark code and measurements [snipped] are not a good comparison
> with the actual environment of low-memory mode.  In particular, the use of
> swap space is likely in low memory mode, but almost certainly not present
> in the measurements reported above.  Any actual use of swap space (or paging)
> will tend to increase the delay, and increase the relative advantage
> of avoiding fruitless searching.

Partman runs before swap is available. Also, the kernel is unlikely to
ever swap out its filesystem cache and syscall handlers.

> It takes a minute or so to change partman by adding something such as
> "export PATH=/bin".  If the searching in partman becomes faster by >= 0.2
> second per run, and if partman is run some thousands of times in the future
> life of the installer, then that is a net savings, and not a waste.  Perhaps
> the intended claim was, "I'd rather spend my time doing something with a
> larger payoff."  So would the humans who use partman.

No, my point is that it's pointless to nibble away at optimising
something in 1% increments. Instead find the actual large timesinks, and
optimise those. Also, work with real-world numbers, not guesses.

(BTW, I forgot to CC you, but AFAICS your numbers in #492077 are off by
several orders of magnitude.)

> Consider this shell code:
> which runs in 22.2 seconds on my NSLU2 for 1000 executions of "cat /dev/null"
> in an environment much more similar to real partman than previous benchmarks.
> Changing to "PATH=/bin " runs in 21.5 seconds, which is 0.7 seconds faster.
> Altering the search path does achieve measured savings.

Actually, the result is similar to that of my C-based tests. I
measured an added 0.14 seconds per cat invocation due to PATH;
on the same hardware with your test I get a value of 0.20.

> The original bug report contains two further paragraphs which give specific 
> ways
> to avoid fork+exec:
>Second, use a shell builtin if possible.  [ $(< file) ]
>Third, use shell text strings where possible.
>   [ PM':'$dir':'default_response=$( ... ) ]
> "$(< file)" turns out not to work on various shells other than bash.
> The use of non-literal variables was panned by Frans Pop as being too obscure,
> although there are projects which use them.  [Look at libtool to see some
> mind-boggling obscurity in shell programming.]
> 
> However, there is another shell builtin which does input without fork+exec,
> namely 'read'.  If the replies are restricted to be only one line, then:
>read  < $dir/default_response
>default_response="$REPLY"
> achieves the same effect as
>default_response=$(cat $dir/default_response)
> but without requiring fork+exec.  So 'read' looks like a promising 
> replacement.

Or one could teach busybox shell to jump to the in-busybox
implementations of cat and all other busybox commands, thereby
eliminating every exec in partman except for those needed to run
subshells. (It'd still have to fork, but linux can fork very fast, and
most shell tricks above involve a fork due to the use of subshells.)

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#492086: partman: menus are very slow

2008-07-24 Thread John Reiser

Joey Hess wrote:

>>Consider this shell code:
>>which runs in 22.2 seconds on my NSLU2 for 1000 executions of "cat /dev/null"
>>in an environment much more similar to real partman than previous benchmarks.
>>Changing to "PATH=/bin " runs in 21.5 seconds, which is 0.7 seconds faster.
>>Altering the search path does achieve measured savings.
> 
> 
> Actually, the result is similar to that of my C-based tests. I
> measured an added 0.14 seconds per cat invocation due to PATH;
> on the same hardware with your test I get a value of 0.20.

I'm glad that you agree, because my results show that changing $PATH is
a 3.2% improvement for an environment quite similar to partman:
 ((22.2 - 21.5) / 22.2) = 0.0315
This is not "orders of magnitude" away from reality.
An speed improvement of 3.2% for very low implementation cost
is a much better than no improvement at all.

> Or one could teach busybox shell to jump to the in-busybox
> implementations of cat and all other busybox commands, thereby
> eliminating every exec in partman except for those needed to run
> subshells. (It'd still have to fork, but linux can fork very fast, and
> most shell tricks above involve a fork due to the use of subshells.)

There was a "Hamilton C shell" for OS/2 that used builtin versions
of cat, cp, mv, ln, etc.  That shell ran rings around any other
with respect to execution speed of the typical shell script.

Partman runs very slowly.  It reflects poorly on debian-installer.
There are two implementable ideas that avoid fork+exec without requiring
a near-total re-implementation: non-literal variables, and 'read'.
"$(< file)" might be fixable in ash.  The bash shell directly supports
text menus with
 select name [ in word ] ; do list ; done
which apparently is not yet so portable to other shells.

Action, anybody?

-- 

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

Bug#492086: partman: menus are very slow

John Reiser wrote:
> Partman runs very slowly.  It reflects poorly on debian-installer.

Humans percieve interactive things as "slow" if they take longer than
approximatly 0.1 seconds to respond. Increasing the speed of partman by
less than 50% is not going to yield a difference that is percievable to
humans. "slow" == "slow".

> There are two implementable ideas that avoid fork+exec without requiring
> a near-total re-implementation: non-literal variables, and 'read'.

I mentioned a third one, that's easier to implement and test than either
of those (only needs a small modification to busybox, which already has
an option that does something very similar). Once someone has actually
implemented and tested it, or any other optimisation idea against the
actual code, and has actual numbers, we could think about actually applying
that optimisation.

-- 
see shy jo

signature.asc
Description: Digital signature

Bug#492086: partman: menus are very slow