Processed: ,

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> submitter 462691 !
Bug#462691: debian-installer: fails to partition hard drives on powermac g5
Changed Bug submitter from Ben Finney <[EMAIL PROTECTED]> to Ben Finney <[EMAIL 
PROTECTED]>.

> submitter 485984 !
Bug#485984: gnunet: Duplicate /var/logrotate.d/ configuration
Changed Bug submitter from Ben Finney <[EMAIL PROTECTED]> to Ben Finney <[EMAIL 
PROTECTED]>.
(By the way, that Bug is currently marked as done.)

> thanks
Stopping processing here.

Please contact me if you need assistance.

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


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

Bug#488706: 5.0beta2 netinst laptop Toshiba Tecra 8000 RTL-8169 ethernet PCMCIA not recognized

[Jean-Bernard Addor]

Thanks for your answer!

From memory, it detected the CD and after made a message (I remember
very well the message, I was really surprised) that it was not able to
detect the ethernet card. I continued and it blocked definitively when
it needed something it was not able to find on the CD. I tryed again
but I have not been able to even boot the kernel, I have the impression
the CD driver is finished (ie the computer).

Have a nice day,

Jean-Bernard

Le Mon, 30 Jun 2008 22:21:15 +0200,
Frans Pop <[EMAIL PROTECTED]> a écrit :

> On Monday 30 June 2008, Jean-Bernard Addor wrote:
> > Comments/Problems:
> > RTL-8169 ethernet PCMCIA not recognized, I had to stop install.
> > The laptop had etch already installed. CD-ROM is old and may have
> > problems.
> 
> Well, if you are installing from CD, the network card will not be
> detected until _after_ the CD has been detected and additional
> installer components have been loaded from the CD.
> 
> As you do not specify that that part happened correctly, I cannot
> tell if the network card detection really is an issue or not. AFAICT
> the driver for it should be available.
> 
> Please provide more details about what installation steps were
> executed and their result.



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

Re: Transition to parted 1.8

[Aníbal Monsalve Salazar]

On Mon, Jun 30, 2008 at 04:13:31PM +0200, Adeodato Simó wrote:
>> qtparted (Debian QA Group <[EMAIL PROTECTED]>) 
>still need a sourceful upload to build-depend on parted 1.8 instead of
>1.7

done!


signature.asc
Description: Digital signature

Bug#488424: should delete cached files that don't verify

[Joey Hess]

Frans Pop wrote:
> What about something like the attached (untested) patch?
> 
> It ensures that both the Release and Release.gpg files are always 
> downloaded.

That's perfectly reasonable. I think it's ok to not cache these even if
they are good, because it prevents running debootstrap later with an out
of date Release file

Thanks,

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Transition to parted 1.8

[Aníbal Monsalve Salazar]

On Tue, Jul 01, 2008 at 08:26:08AM +1000, Anibal Monsalve Salazar wrote:
>On Mon, Jun 30, 2008 at 04:13:31PM +0200, Adeodato Simó wrote:
>>> qtparted (Debian QA Group <[EMAIL PROTECTED]>) 
>>still need a sourceful upload to build-depend on parted 1.8 instead of
>>1.7
>
>done!

Please disregard that mail. I was reading 'gparted'.


signature.asc
Description: Digital signature

Bug#488267: Should add hostap modules

[Frans Pop]

On Monday 30 June 2008, Barry Tennison wrote:
> (1) In fact, this must be what happens with madwifi too: it always
> creates a sta interface athN, and I'm pretty sure there won't be a udev
> rule in systems without madwifi that makes any reference to athN
> interfaces.

Yes, there is. udev basically renames _any_ network interface...

> where something (hostap_pci?) has silently renamed eth1 to the ugly
> wlan0_rename.

No. *Any* renaming is done by udev and only by udev.

> So arguably it was not a good idea (indeed - a bug?) for udev to be
> told to rename wlan0 to eth1, and it would be better to stick with the
> driver-mandated wlanN names.

Udev got that idea from the installation where the driver assigned the 
eth1 name for the interface, so it tries to preserve that. And in fact it 
almost succeeds, were it not for the fact that it gets confused by the 
fact that the hostap driver creates two interfaces instead of just one.

Cheers,
FJP



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

Bug#488267: Should add hostap modules

[Frans Pop]

On Monday 30 June 2008, Barry Tennison wrote:
> After your modprobe remove&reload hostap_pci, the results were exactly
> as before: ifconfig -a had interfaces wifi0 and wlan0, and the last two
>
> rules in z25_persistent-net.rules had become:
> > # PCI device 0x1260:0x3873 (orinoco_pci)
> > SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:d0:59:bd:d5:c5",
> > ATTR{type}=1, NAME="eth1"
> >
> > # PCI device 0x1260:0x3873 (hostap_pci)
> > SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:d0:59:bd:d5:c5",
> > ATTR{type}=="1", NAME="wlan0"

Sorry, I'm a moron.

The correct line should be:
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:d0:59:bd:d5:c5", 
ATTR{type}=="1", NAME="eth1"

Change the second line to that and remove the third line. (Or remove the
second line and change wlan0 to eth1 in the third; same difference :-)

I have to check why the newly generated line gives "wlan0" instead of
"ethX" as I'd expected, but that's not that relevant for you.

Cheers,
FJP



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

Bug#488267: Should add hostap modules

[Barry Tennison]

I should have expanded the argument in two ways.  Building on:

I suppose this does make some kind of sense, as hostap_pci must in fact do (at 
least) two things in succession:
* create the master interface wifiN (where N=0 for us as it's the first such 
interface to be created)
* create an sta interface based on wifiN, and it chooses (hard-coded?) to call 
this wlanN

And if the installer used hostap_pci too, then presumably at install time, the device created would be wlan0. 


we have:

(1) In fact, this must be what happens with madwifi too: it always 
creates a sta interface athN, and I'm pretty sure there won't be a udev 
rule in systems without madwifi that makes any reference to athN interfaces.


(2) And in fact you can see the process happening in the (installed 
system) syslog extract I posted before:

Jun 28 08:08:46 obelix kernel: hostap_pci: Registered netdevice wifi0
Jun 28 08:08:46 obelix kernel: wifi0: Original COR value: 0x2
Jun 28 08:08:46 obelix kernel: prism2_hw_init: initialized in 204 ms
Jun 28 08:08:46 obelix kernel: wifi0: NIC: id=0x8013 v1.0.0
Jun 28 08:08:46 obelix kernel: wifi0: PRI: id=0x15 v1.1.0
Jun 28 08:08:46 obelix kernel: wifi0: STA: id=0x1f v1.4.3
Jun 28 08:08:46 obelix kernel: wifi0: defaulting to host-based encryption as a 
workaround for firmware bug in Host AP mode WEP
Jun 28 08:08:46 obelix kernel: wifi0: defaulting to bogus WDS frame as a 
workaround for firmware bug in Host AP mode WDS
Jun 28 08:08:46 obelix kernel: wifi0: Intersil Prism2.5 PCI: mem=0xe050, 
irq=9
Jun 28 08:08:46 obelix kernel: wifi0: registered netdevice wlan0
Jun 28 08:08:46 obelix kernel: orinoco 0.15 (David Gibson <[EMAIL PROTECTED]>, Pavel 
Roskin <[EMAIL PROTECTED]>, et al)
Jun 28 08:08:46 obelix kernel: orinoco_pci 0.15 (Pavel Roskin <[EMAIL PROTECTED]>, David Gibson 
<[EMAIL PROTECTED]> & Jean Tourrilhes <[EMAIL PROTECTED]>)


and a bit later, with nothing relevant in between


Jun 28 08:08:46 obelix kernel: udev: renamed network interface wifi0 to eth1


which implies that, in the presence of hostap_pci, (it or) orinoco_pci 
has (silently??) created the interface wlan0.


Later in that syslog, udev acts:

Jun 28 08:08:46 obelix kernel: udev: renamed network interface wifi0 to eth1


and the next relevant thing we get is

Jun 28 08:08:46 obelix kernel: prism2: wlan0_rename: operating mode changed 3 
-> 2


where something (hostap_pci?) has silently renamed eth1 to the ugly 
wlan0_rename.


So arguably it was not a good idea (indeed - a bug?) for udev to be told 
to rename wlan0 to eth1, and it would be better to stick with the 
driver-mandated wlanN names.


Barry



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

Bug#488424: should delete cached files that don't verify

[Frans Pop]

On Saturday 28 June 2008, Joey Hess wrote:
> If a Release file fails to verify because it is out of sync with the
> Release.gpg on one mirror, debootstrap will cache the file, and reuse
> it if it's run a second time, with a different mirror. Result is that
> the second mirror also appears to fail.
>
> debootstrap should delete cached files if they fail to verify. This
> may apply to downloaded debs, too.

What about something like the attached (untested) patch?

It ensures that both the Release and Release.gpg files are always 
downloaded.

AFAICT anything that is downloaded later gets checked using MD5SUMS or 
similar and old versions get deleted automatically if that is invalid.

Cheers,
FJP

Index: functions
===
--- functions	(revision 53808)
+++ functions	(working copy)
@@ -248,6 +248,7 @@
 
 get () {
 	# args: from dest [md5sum size] [alt {md5sum size type}]
+	# args: from dest nocache
 	local displayname
 	if [ "${2%.deb}" != "$2" ]; then
 		displayname="$(echo "$2" | sed 's,^.*/,,;s,_.*$,,')"
@@ -258,12 +259,15 @@
 	if [ -e "$2" ]; then
 		if [ "$3" = "" ]; then
 			return 0
-		fi
-		info VALIDATING "Validating %s" "$displayname"
-		if check_md5 "$2" "$3" "$4"; then
-			return 0
+		elif [ "$3" = nocache ]; then
+			rm -f "$2"
 		else
-			rm -f "$2"
+			info VALIDATING "Validating %s" "$displayname"
+			if check_md5 "$2" "$3" "$4"; then
+return 0
+			else
+rm -f "$2"
+			fi
 		fi
 	fi
 	if [ "$#" -gt 5 ]; then
@@ -441,7 +445,7 @@
 	if [ -n "$KEYRING" ]; then
 		progress 0 100 DOWNRELSIG "Downloading Release file signature"
 		progress_next 50
-		get "$m1/dists/$SUITE/Release.gpg" "$relsigdest" ||
+		get "$m1/dists/$SUITE/Release.gpg" "$relsigdest" nocache ||
 			error 1 NOGETRELSIG "Failed getting release signature file %s" \
 			"$m1/dists/$SUITE/Release.gpg"
 		progress 50 100 DOWNRELSIG "Downloading Release file signature"
@@ -460,7 +464,7 @@
 	local reldest="$TARGET/$($DLDEST rel "$SUITE" "$m1" "dists/$SUITE/Release")"
 	progress 0 100 DOWNREL "Downloading Release file"
 	progress_next 100
-	get "$m1/dists/$SUITE/Release" "$reldest" ||
+	get "$m1/dists/$SUITE/Release" "$reldest" nocache ||
 		error 1 NOGETREL "Failed getting release file %s" "$m1/dists/$SUITE/Release"
 
 	TMPCOMPONENTS="$(sed -n 's/Components: *//p' "$reldest")"


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

Bug#488267: Should add hostap modules

[Barry Tennison]

Frans Pop wrote:

Barry: a few requests.
1) What was the wireless interface called in the installer?
   You can probably tell from /var/log/installer/syslog.

eth1
You can check this from my original report (email of Fri, 27 Jun 2008
14:16:15 +0100 in bug 488267), and in the installer outputs I provided
in my email of Fri, 27 Jun 2008 18:15:56 +0100 (cat /proc/net/dev and
ifconfig while installer running)


That's not what I meant, but I probably was not clear enough.
I wanted to know what the name of the interface was when the driver loads 
it. What you list here could be _after_ it is renamed by udev.
So, you have to look in the installer's syslog for lines where you see the 
orinoco driver being loaded and how the interface is being referred to 
there. Possibly that is indeed eth1, but it is also possible that it's 
first something else and that you later see a line mentioning that udev 
renames it.


Apologies - you're right, I didn't understand that.
From the installer syslog, orinoco_csi creates eth1 directly and AFAICT 
udev doesn't touch it.

The relevant lines of the syslog look like this:

Jun 26 10:06:18 kernel: orinoco 0.15 (David Gibson <[EMAIL PROTECTED]>, Pavel Roskin 
<[EMAIL PROTECTED]>, et al)
Jun 26 10:06:19 kernel: orinoco_pci 0.15 (Pavel Roskin <[EMAIL PROTECTED]>, David Gibson 
<[EMAIL PROTECTED]> & Jean Tourrilhes <[EMAIL PROTECTED]>)
Jun 26 10:06:19 kernel: ACPI: PCI Interrupt :02:0b.0[A] -> Link [LNKD] -> GSI 
9 (level, low) -> IRQ 9
Jun 26 10:06:19 kernel: eth1: Hardware identity 8013::0001:
Jun 26 10:06:19 kernel: eth1: Station identity  001f:0003:0001:0004
Jun 26 10:06:19 kernel: eth1: Firmware determined as Intersil 1.4.3
Jun 26 10:06:19 kernel: eth1: Ad-hoc demo mode supported
Jun 26 10:06:19 kernel: eth1: IEEE standard IBSS ad-hoc mode supported
Jun 26 10:06:19 kernel: eth1: WEP supported, 104-bit key
Jun 26 10:06:19 kernel: eth1: MAC address 00:d0:59:bd:d5:c5
Jun 26 10:06:19 kernel: eth1: Station name "Prism  I"
Jun 26 10:06:19 kernel: eth1: ready
Jun 26 10:06:19 kernel: eth1: orinoco_pci at :02:0b.0
Jun 26 10:06:19 net/hw-detect.hotplug: Detected hotpluggable network interface 
eth0
Jun 26 10:06:19 net/hw-detect.hotplug: Detected hotpluggable network interface 
eth1


At that stage (while running the installer), 
/etc/udev/rules.d/z25_persistent-net.rules  contains the single rule for 
 eth1:

# PCI device 0x1260:0x3873 (orinoco_pci)
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:d0:59:bd:d5:c5", NAME="eth1"


The only vaguely relevant udev lines I could find in installer/syslog are:

Jun 26 10:13:20 in-target: Setting up udev (0.114-2) ...
Jun 26 10:13:20 in-target: /etc/udev/rules.d/z25_persistent-net.rules exists, 
persistent interface names
Jun 26 10:13:20 in-target: not saved.


---


2) Does the workaround described above work?




Ah, I see the error. Typo in my last mail. It should be "ATTR{type}=1" 
(and not "ATTRS"). Please try again with that.


When I rebooted to do this, to my slight surprise, I found that
~$ cat /etc/udev/rules.d/z25_persistent-net.rules 
# This file was automatically generated by the /lib/udev/write_net_rules

# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# PCI device 0x8086:0x1031 (e100)
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="08:00:46:77:ce:be", NAME="eth0"

# PCI device 0x1260:0x3873 (orinoco_pci)
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:d0:59:bd:d5:c5", ATTRS{type}=1, 
NAME="eth1"

# PCI device 0x1260:0x3873 (hostap_pci)
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:d0:59:bd:d5:c5", ATTR{type}=="1", 
NAME="wlan0"
Note that I had not hand installed the third rule, but had used the 
incorrect ATTRS in the hand installed second rule.  I guessed that the 
best thing to do was to correct ATTRS to ATTR and also delete the third 
rule (expecting it might be regenerated anyway).  So I did that 
(definitely deleting the third rule).


After your modprobe remove&reload hostap_pci, the results were exactly 
as before: ifconfig -a had interfaces wifi0 and wlan0, and the last two 
rules in z25_persistent-net.rules had become:

# PCI device 0x1260:0x3873 (orinoco_pci)
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:d0:59:bd:d5:c5", ATTR{type}=1, 
NAME="eth1"

# PCI device 0x1260:0x3873 (hostap_pci)
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:d0:59:bd:d5:c5", ATTR{type}=="1", 
NAME="wlan0"
which seem to me to be two rules trying to apply to the same device and 
data.


I did try to think of a new experiment, but couldn't see a useful one.

It seems to me that no, your workaround does not work as you wish; and 
that the hostap_pci module is writing the wlan0 rule into 
z25_persistent-net.rules
I suppose this does make some kind of sense, as hostap_pci must in fact 
do (at least) two things in succession:
* create the master interface wifiN (where N=0 for us as it's the first 
such interface 

Bug#488066: installation-reports

[Frans Pop]

Hi,

Sorry for the late reply to your report.

On Thursday 26 June 2008, Werquin Lucas wrote:
> I try to install Debian on a RAID 0, using the "install dmraid=true"
> command.
>
> Partition hard drives:  [E]
> -> Every partition seem to be created correctly, but finaly the SWAP
> fails. After that, the partition manager shows a pri/log ext3
> partition. I tried to delete this to retry the process.
> It fails because of "too much boot sectors" (as I try to remember).

How exactly did you do the partitioning? Did you try to use the "guided 
partitioning" option? If you did that, then the failure can be explained 
as it is just not supported.

You should use "manual" partitioning as described on this wiki page:
http://wiki.debian.org/DebianInstaller/SataRaid

Please try again using those instructions.

If you did follow those instructions, then please explain in more detail 
exactly what you did after starting partitioning and where things go 
wrong.

Cheers,
FJP



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

Bug#488111: support for installing GRUB without blocklists on GPT

[Frans Pop]

On Friday 27 June 2008, Robert Millan wrote:
> On Fri, Jun 27, 2008 at 12:57:31AM +0200, Frans Pop wrote:
> > On Thursday 26 June 2008, Robert Millan wrote:
> > > > Should the description "BIOS boot area:" not also mention grub in
> > > > some way? Something like "Reserve BIOS boot area for GRUB:"
> > > > (although that may already be a bit long for this dialog)?
> > >
> > > I don't think it's essential to mention GRUB; in theory, other
> > > bootloaders could want to replace GRUB in this partition whenever
> > > they're installed in MBR.
> >
> > OK. In that case I think "Reserve BIOS boot area:" would have my
> > vote.
>
> Here's a new patch with all the requested changes.

IMO this can be committed.

Cheers,
FJP

P.S. Please allow some time for reviews before pinging...



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

Bug#488706: 5.0beta2 netinst laptop Toshiba Tecra 8000 RTL-8169 ethernet PCMCIA not recognized

[Frans Pop]

On Monday 30 June 2008, Jean-Bernard Addor wrote:
> Comments/Problems:
> RTL-8169 ethernet PCMCIA not recognized, I had to stop install.
> The laptop had etch already installed. CD-ROM is old and may have
> problems.

Well, if you are installing from CD, the network card will not be detected 
until _after_ the CD has been detected and additional installer 
components have been loaded from the CD.

As you do not specify that that part happened correctly, I cannot tell if 
the network card detection really is an issue or not. AFAICT the driver 
for it should be available.

Please provide more details about what installation steps were executed 
and their result.



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

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

[Frans Pop]

On Monday 30 June 2008, Ventura wrote:
> ~ # wget http://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:
> ~ # wget http://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]

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

[Ventura]

Still trying to install Linux s/390 on Hercules emulator I get the
point of the problem. Now
I am trying to install from the debian repository at Internet.

The installation is stopping at this point:

Jun 30 19:11:28 choose-mirror[657]: DEBUG: command: wget -q
http://ftp.us.debian.org/debian//dists/etch/Release -O - | grep
^Suite: | cut -d' ' -f 2

I decide to do a test in the prompt of Linux 390 install and hit two
commands,
the first:

~ # wget http://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:
~ # wget http://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).

Thanks in advance,
Ventura


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

Bug#488267: Should add hostap modules

[Frans Pop]

(There's no need to CC me or Otavio when you reply. Just reply to the bug 
report.)

On Monday 30 June 2008, Barry Tennison wrote:
> Frans Pop wrote:
> I understand the complexity of the argument.
> I would just stress that from the "simple user" (including me) point of
> view, the key things are that

I have no disagreement with that. The only issue under discussion now is 
what the real source of the bug is.

> Therefore, it seems to me that the installer and the stock system have
> to be brought to the same state: if the standard (installed, lenny)
> system continues to do the renaming, then the installer must, however
> unfortunately, bend to concur, so that the newly installed system DOES
> bring up the interface.

Or: the program that is responsible for the the faulty renaming needs to 
be fixed. Especially as this not only affects new installations, but is 
also likely to affect upgrades (from Etch to Lenny for example).

> > Barry: a few requests.
> > 1) What was the wireless interface called in the installer?
> >You can probably tell from /var/log/installer/syslog.
>
> eth1
> You can check this from my original report (email of Fri, 27 Jun 2008
> 14:16:15 +0100 in bug 488267), and in the installer outputs I provided
> in my email of Fri, 27 Jun 2008 18:15:56 +0100 (cat /proc/net/dev and
> ifconfig while installer running)

That's not what I meant, but I probably was not clear enough.
I wanted to know what the name of the interface was when the driver loads 
it. What you list here could be _after_ it is renamed by udev.
So, you have to look in the installer's syslog for lines where you see the 
orinoco driver being loaded and how the interface is being referred to 
there. Possibly that is indeed eth1, but it is also possible that it's 
first something else and that you later see a line mentioning that udev 
renames it.

> > 2) Does the workaround described above work?
>
> As I have mentioned, my own workaround, with the system exactly as
> installed, is simply to edit /etc/network/interfaces with the global
> replace of eth1 by wlan0_rename (or whatever the installed system calls
> the interface).  IMHO, this is much simpler than editing udev rules
> (here be dragons!) and doesn't require a reboot.

Sure, but it does leave you with that ugly name and that name is very 
simply just wrong.

> However, I am much attracted by your workaround since it avoids the
> vastly ugly interface name wlan0_rename (!), and I'm glad to report
> that it did work - but see comment after next para.

Right.

> In a little more detail,
> * I edited /etc/udev/z25_persistent-net.rules to include the
> ATTRS{type}=1 phrase

You also added the extra comma, right?

> * I rebooted - could I have done less?

Yes, unloading and reloading the hostap module should have worked too:
# modprobe -r hostap_pci
# modprobe hostap_pci

> certainly, unsurprisingly, neither udevcontrol reload_rules nor
> /etc/init.d/udev restart had any visible effect

Right. As there are no hardware events, neither actually "does" anything.

> * after reboot, the key lines of ifconfig -a read:
> > wifi0 Link encap:UNSPEC  HWaddr 00-D0-59-BD-D5-C5-77-6C-[...]
> > wlan0 Link  encap:Ethernet  HWaddr 00:d0:59:bd:d5:c5
>
> (no mention of eth1 in ifconfig nor in /proc/net/dev nor in
> /sys/class/net/) and after an edit of /etc/network/interfaces, wlan0
> was successfully brought up.
> Do let me know if you want any more diagnostic info.

This _is_ surprising. I had expected wlan0 to be renamed to eth1.

Ah, I see the error. Typo in my last mail. It should be "ATTR{type}=1" 
(and not "ATTRS"). Please try again with that.
It does explain that there was no rename at all.

> PLEASE NOTE - sorry for stating the obvious - that this single change
> will not solve the original problem, because the interface was called
> eth1 by the installer, and /etc/network/interfaces was built
> accordingly, with eth1 not wlan0.  So the installer will need changing
> to use the same interface name as used by the (lenny-release) standard
> system.

Please don't worry about that. We're aware of how things fit together and 
will make sure that things end up consistently.

> > 3) Could you please provide the output of
> >$ udevinfo -a -p /sys/class/net/
> >where  is both of the interfaces you have in that
> > directory for your wireless.
>
> BEFORE doing the workaround as above in (2):
> (for your convenience, diff given after both outputs below)
>
> > ~$ udevinfo -a -p /sys/class/net/eth1
> >
> >   looking at device '/class/net/eth1':
> > KERNEL=="eth1"
> > SUBSYSTEM=="net"
[...]
> > ATTR{type}=="801"
> > ATTR{link_mode}=="0"
> > ATTR{address}=="00:d0:59:bd:d5:c5"
> > ATTR{broadcast}=="ff:ff:ff:ff:ff:ff"

OK. This is the original wifi0 interface. Note that it has ATTR{type} 
unequal to 1.

> > ~$ udevinfo -a -p /sys/class/net/wlan0_rename/
> >
> >   looking at device '/class/net/wlan0_rename':
> > KERNEL=="wlan0_rename"
> > SUBSYSTEM=

Bug#488544: marked as done (installation-reports: lenny beta2 report)

[Debian Bug Tracking System]

Your message dated Mon, 30 Jun 2008 21:35:54 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Re: Bug#488544: installation-reports: lenny beta2 report
has caused the Debian Bug report #488544,
regarding installation-reports: lenny beta2 report
to be marked as done.

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

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
488544: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488544
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: installation-reports
Severity: normal



-- Package-specific info:

Boot method: cd
Image version: Debian Installer lenny beta 2 
http://cdimage.debian.org/cdimage/lenny_di_beta2/i386/bt-dvd/ 09 Jun 2008
Date: 
25 Jun 2008 13:57:42

Machine: Compaq Presario SR1050NX
Partitions: 
fdisk -l

Disk /dev/hda: 200.0 GB, 200049647616 bytes
240 heads, 63 sectors/track, 25841 cylinders
Units = cylinders of 15120 * 512 = 7741440 bytes
Disk identifier: 0xa03fa03f

   Device Boot  Start End  Blocks   Id  System
/dev/hda1   1 584 4415008+  83  Linux
/dev/hda2 58583345859   8e  Linux LVM
/dev/hda48335   25841   132352920   83  Linux

Disk /dev/dm-0: 1568 MB, 1568669696 bytes
255 heads, 63 sectors/track, 190 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x

Disk /dev/dm-0 doesn't contain a valid partition table

Disk /dev/dm-1: 58.4 GB, 58426654720 bytes
255 heads, 63 sectors/track, 7103 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x

Disk /dev/dm-1 doesn't contain a valid partition table

** Note: /dev/hda4 not used during installation as it had an existing 
Debian Lenny system (with GRUB) installed.

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [E]
Detect CD:  [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Clock/timezone setup:   [O]
User/password setup:[O]
Install tasks:  [O]
Install boot loader:[ ]
Overall install:[O]

Comments/Problems: 

1. To set up pppoe, I used modules=ppp_udeb. It was not detected properly
although the fallback DHCP works.

2. Graphic capability was not detected correctly.  I ended up with 800x600
on 1680x1050 capable hardware.





I installed my first Debian system over 10 years ago and have done 
so many times since.  You've come a LONG WAY, Baby!

installgui worked even better than I expected. I'm sure context sensitive 
help is on somebody's wishlist.

partman is absolutely excellent.  Even making mistakes didn't bother it.

Most important, I had a completely functioning system, full GUI(xfce), 
and internet connection. I could have done a totally automatic install.

-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to [EMAIL PROTECTED]

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="5.0 (lenny) - installer build 20080522"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
umame -a: Linux qpg 2.6.24-1-486 #1 Thu May 8 01:29:10 UTC 2008 i686 unknown
lspci -knn: 00:00.0 Host bridge [0600]: nVidia Corporation nForce2 IGP2 
[10de:01e0] (rev a2)
lspci -knn: 00:00.1 RAM memory [0500]: nVidia Corporation nForce2 Memory 
Controller 1 [10de:01eb] (rev a2)
lspci -knn: 00:00.2 RAM memory [0500]: nVidia Corporation nForce2 Memory 
Controller 4 [10de:01ee] (rev a2)
lspci -knn: 00:00.3 RAM memory [0500]: nVidia Corporation nForce2 Memory 
Controller 3 [10de:01ed] (rev a2)
lspci -knn: 00:00.4 RAM memory [0500]: nVidia Corporation nForce2 Memory 
Controller 2 [10de:01ec] (rev a2)
lspci -knn: 00:00.5 RAM memory [0500]: nVidia Corporation nForce2 Memory 
Controller 5 [10de:01ef] (rev a2)
lspci -knn: 00:01.0 ISA bridge [0601]: nVidia Corporation nForce2 ISA Bridge 
[10de:0060] (rev a4)
lspci -knn: 00:01.1 SMBus [0c05]: nVidia Corporation nForce2 SMBus (MCP) 
[10de:0064] (rev a2)
lspci -knn: 00:02.0 USB Controller [0c03]: nVidia Corporation nForce2 USB 
Controller [10de:0067] (rev a4)
lspci -knn: Kernel driver in use: ohci_hcd
lspci -knn: Ker

Bug#488706: 5.0beta2 netinst laptop Toshiba Tecra 8000 RTL-8169 ethernet PCMCIA not recognized

[Jean-Bernard Addor]

Package: installation-reports

Boot method: network
Image version:
http://cdimage.debian.org/cdimage/lenny_di_beta2/i386/iso-cd/debian-LennyBeta2-i386-netinst.iso
Date: 2008-06-30

Machine: laptop Toshiba Tecra 8000
Processor: pentium2
Memory: 128M
Partitions: 
FilesystemType   1K-blocks  Used Available Use% Mounted on
/dev/hda1 ext376549056   7881108  64779420  11% /
tmpfstmpfs   63516 0 63516   0% /lib/init/rw
udev tmpfs   1024052 10188   1% /dev
tmpfstmpfs   6351612 63504   1% /dev/shm

Output of lspci -knn (or lspci -nn):
00:00.0 Host bridge [0600]: Intel Corporation 440BX/ZX/DX -
82443BX/ZX/DX Host bridge (AGP disabled) [8086:7192] (rev 03) 
00:04.0
VGA compatible controller [0300]: Neomagic Corporation NM2200
[MagicGraph 256AV] [10c8:0005] (rev 12) 
00:05.0 Bridge [0680]: Intel
Corporation 82371AB/EB/MB PIIX4 ISA [8086:7110] (rev 02) 
00:05.1 IDE
interface [0101]: Intel Corporation 82371AB/EB/MB PIIX4 IDE [8086:7111]
(rev 01) 
00:05.2 USB Controller [0c03]: Intel Corporation 82371AB/EB/MB
PIIX4 USB [8086:7112] (rev 01) 
00:05.3 Bridge [0680]: Intel Corporation
82371AB/EB/MB PIIX4 ACPI [8086:7113] (rev 02) 
00:09.0 Communication
controller [0780]: Toshiba America Info Systems FIR Port [1179:0701]
(rev 23) 
00:0b.0 CardBus bridge [0607]: Toshiba America Info Systems
ToPIC97 [1179:060f] (rev 05) 
00:0b.1 CardBus bridge [0607]: Toshiba
America Info Systems ToPIC97 [1179:060f] (rev 05) 
05:00.0 Ethernet
controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit
Ethernet [10ec:8169] (rev 10)

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[E]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:

RTL-8169 ethernet PCMCIA not recognized, I had to stop install.
The laptop had etch already installed. CD-ROM is old and may have
problems.



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

Bug#488544: installation-reports: lenny beta2 report

[Gerard MacNeil]

On Sun, 2008-06-29 at 23:04 +0200, Frans Pop wrote:

> > > That is the wrong syntax. It should be 'modules=ppp-udeb'.
> >
> > Wrong syntax, it was.  My failing eyesight, no doubt.
> 
> Care to retry with the correct syntax? I'd expect that to work.
> 
> If you break off the installation any time before confirming partitioning 
> changes, the retry won't affect the installation you've already done.


You are correct. It worked like a charm.  

Kudos to the Install Team.

Bug#488687: partman-crypto: Broken when using multiple disks

[Daniel Baumann]

Package: partman-crypto
Severity: serious

Hi,

using encrypted partitions with d-i in lenny beta2 as well as daily
images (20080630) is completely broken when creating multiple encrypted
partitions on more than one disk.

I can reproduce it on a couple of completely different machines with
always the same result. However, the last one I did had the following
partitioning layout:

/dev/hda1 /boot ext3
/dev/hda5 crypted random key
/dev/hda6 crypted passphrase
/dev/hda7 crypted passphrase

/dev/hdb1 crypted passphrase

as soon as you press the 'Configure encrypted volumes', d-i starts
creating the *first* and the *last* encrypted partitions, im my case
these are hda5_crypt and hdb1_crypt. those in between are skipped.
Running a 'Configure encrypted volumes' again, doesn't help much as it
messes arround again with the previous configured partitions and wants
to reformat them again and again.

Regards,
Daniel

-- 
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  [EMAIL PROTECTED]
Internet:   http://people.panthera-systems.net/~daniel-baumann/



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

Re: Transition to parted 1.8

[Aurélien GÉRÔME]

Hi,

On Mon, Jun 30, 2008 at 04:13:31PM +0200, Adeodato Simó wrote:
> >  gnu-fdisk (Aurélien GÉRÔME <[EMAIL PROTECTED]>)
> 
> still need a sourceful upload to build-depend on parted 1.8 instead of
> 1.7 (why, btw, is the SONAME embedded in the -dev package name?; we
> can't binNMU because of that).

Done.

Cheers,
-- 
 .''`.   Aurélien GÉRÔME
: :'  :
`. `'`   Debian Developer
  `- Unix Sys & Net Admin


signature.asc
Description: Digital signature

Bug#488267: Should add hostap modules

[Otavio Salvador]

Frans Pop <[EMAIL PROTECTED]> writes:

> On Monday 30 June 2008, Otavio Salvador wrote:
>> Frans Pop <[EMAIL PROTECTED]> writes:
>> > The workaround is still, as I wrote earlier, to remove the existing
>> > rename rule for the wifi interface in the z25 script and to let udev
>> > regenerate it.
>>
>> Adding the module would avoid the workaround. Seems better to me.
>
> The hostap module seems to provide something that is useless in the 
> context of D-I and bloats images. I don't think that's the correct way 
> to "solve" problems.
>
> P.S. Oneliners without any supporting argumentation are unlikely to 
> convince anyone.

It's not up to us, as d-i team, to decide about modules if they
provide or not something useful ... if it gets loaded on installed
system and it does affect the installation (as this does) I think we
ought to include it.

Otherwise, an option is to ask for kernel team to disable it on kernel
but if it's not going to be done (and I agree in it not being done) we
ought to not conflict with installed system.

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

Re: Unblocking pango1.0

[Otavio Salvador]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Adeodato Simó <[EMAIL PROTECTED]> writes:

> Hello.
>
> I inquired on IRC, but since I got no response... I need pango1.0 to
> migrate for a couple transitions, it is okay to migrate the udeb as
> well?

No objection

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

iEYEARECAAYFAkho+IsACgkQLqiZQEml+FVTBgCgjYTCPOfRcNR5JZR5w6sxW1TG
AKQAn3aTlHmIZ1go2JlpWmdi7NOctbKO
=iIht
-END PGP SIGNATURE-


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

Bug#488267: Should add hostap modules

[Barry Tennison]

Frans Pop wrote:
The workaround is still, as I wrote earlier, to remove the existing rename 
rule for the wifi interface in the z25 script and to let udev regenerate 
it.


I understand the complexity of the argument.
I would just stress that from the "simple user" (including me) point of 
view, the key things are that
(a) the installer installs a stock debian kernel and all packages 
(including udev) as if taken by apt from the standard repositories
(b) after the reboot at the end of the install (and subsequently), with 
the system as installed, the interface has been renamed to wlan0_rename
(c) (see also below) since DURING the install, the interface is called 
eth1, things like /etc/network/interfaces are set up with THAT interface 
name
(d) therefore, sailing through the install, there's a very ugly 
occurrence, namely, on the first reboot, the installed system won't 
bring up the wireless net connection.


Therefore, it seems to me that the installer and the stock system have 
to be brought to the same state: if the standard (installed, lenny) 
system continues to do the renaming, then the installer must, however 
unfortunately, bend to concur, so that the newly installed system DOES 
bring up the interface.



Barry: a few requests.
1) What was the wireless interface called in the installer?
   You can probably tell from /var/log/installer/syslog.


eth1
You can check this from my original report (email of Fri, 27 Jun 2008 
14:16:15 +0100 in bug 488267), and in the installer outputs I provided 
in my email of Fri, 27 Jun 2008 18:15:56 +0100 (cat /proc/net/dev and 
ifconfig while installer running)



2) Does the workaround described above work?


As I have mentioned, my own workaround, with the system exactly as 
installed, is simply to edit /etc/network/interfaces with the global 
replace of eth1 by wlan0_rename (or whatever the installed system calls 
the interface).  IMHO, this is much simpler than editing udev rules 
(here be dragons!) and doesn't require a reboot.
However, I am much attracted by your workaround since it avoids the 
vastly ugly interface name wlan0_rename (!), and I'm glad to report that 
it did work - but see comment after next para.


In a little more detail,
* I edited /etc/udev/z25_persistent-net.rules to include the 
ATTRS{type}=1 phrase
* I rebooted - could I have done less? certainly, unsurprisingly, 
neither udevcontrol reload_rules nor /etc/init.d/udev restart had any 
visible effect

* after reboot, the key lines of ifconfig -a read:
wifi0 Link encap:UNSPEC  HWaddr 00-D0-59-BD-D5-C5-77-6C-00-00-00-00-00-00-00-00  
wlan0 Link encap:Ethernet  HWaddr 00:d0:59:bd:d5:c5  
(no mention of eth1 in ifconfig nor in /proc/net/dev nor in 
/sys/class/net/) and after an edit of /etc/network/interfaces, wlan0 was 
successfully brought up.

Do let me know if you want any more diagnostic info.

PLEASE NOTE - sorry for stating the obvious - that this single change 
will not solve the original problem, because the interface was called 
eth1 by the installer, and /etc/network/interfaces was built 
accordingly, with eth1 not wlan0.  So the installer will need changing 
to use the same interface name as used by the (lenny-release) standard 
system.




3) Could you please provide the output of
   $ udevinfo -a -p /sys/class/net/
   where  is both of the interfaces you have in that directory
   for your wireless.


BEFORE doing the workaround as above in (2):
(for your convenience, diff given after both outputs below)


~$ udevinfo -a -p /sys/class/net/eth1

Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/class/net/eth1':
KERNEL=="eth1"
SUBSYSTEM=="net"
DRIVER==""
ATTR{addr_len}=="6"
ATTR{iflink}=="3"
ATTR{ifindex}=="3"
ATTR{features}=="0x0"
ATTR{type}=="801"
ATTR{link_mode}=="0"
ATTR{address}=="00:d0:59:bd:d5:c5"
ATTR{broadcast}=="ff:ff:ff:ff:ff:ff"
ATTR{carrier}=="1"
ATTR{dormant}=="0"
ATTR{operstate}=="unknown"
ATTR{mtu}=="1500"
ATTR{flags}=="0x1003"
ATTR{tx_queue_len}=="1000"

  looking at parent device '/devices/pci:00/:00:1e.0/:02:0b.0':
KERNELS==":02:0b.0"
SUBSYSTEMS=="pci"
DRIVERS=="hostap_pci"
ATTRS{vendor}=="0x1260"
ATTRS{device}=="0x3873"
ATTRS{subsystem_vendor}=="0x1468"
ATTRS{subsystem_device}=="0x0201"
ATTRS{class}=="0x028000"
ATTRS{irq}=="9"
ATTRS{local_cpus}=="ff"
ATTRS{modalias}=="pci:v1260d3873sv1468sd0201bc02sc80i00"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}==""

  looking at parent device '/devices/pci:00/:00:1e.0':
KERNELS==":00:1e.0"
SUBSYSTEMS=="pci"
DRIVERS==""
ATTRS{vendor}=="0x8086"
ATTRS{device

Bug#488267: Should add hostap modules

[Frans Pop]

On Monday 30 June 2008, Otavio Salvador wrote:
> Frans Pop <[EMAIL PROTECTED]> writes:
> > The workaround is still, as I wrote earlier, to remove the existing
> > rename rule for the wifi interface in the z25 script and to let udev
> > regenerate it.
>
> Adding the module would avoid the workaround. Seems better to me.

The hostap module seems to provide something that is useless in the 
context of D-I and bloats images. I don't think that's the correct way 
to "solve" problems.

P.S. Oneliners without any supporting argumentation are unlikely to 
convince anyone.



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

Bug#482411: marked as done ([win32-loader] [INTL:tr] Turkish translation)

[Debian Bug Tracking System]

Your message dated Mon, 30 Jun 2008 17:43:10 +0300
with message-id <[EMAIL PROTECTED]>
and subject line done
has caused the Debian Bug report #482411,
regarding [win32-loader] [INTL:tr] Turkish translation
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.)


-- 
482411: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482411
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: win32-loader
Severity: wishlist
Tags: l10n patch

Turkish translation of win32-loader is attached. I committed it to SVN days ago,
but D-I translation status page shows it untranslated. So please include Turkish
translation. (Of course use SVN version if you can)

Thanks
# Turkish messages for Debian-Installer Loader.
# Copyright (C) 2003, 2004 Software in the Public Interest, Inc.
# This file is distributed under the same license as Debian-Installer Loader.
#
# Recai Oktaş <[EMAIL PROTECTED]>, 2007.
# Mert Dirik <[EMAIL PROTECTED]>, 2008.
#
msgid ""
msgstr ""
"Project-Id-Version: Debian-Installer Loader\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2008-05-01 10:40+0200\n"
"PO-Revision-Date: 2008-05-22 18:30+0200\n"
"Last-Translator: Mert Dirik <[EMAIL PROTECTED]>\n"
"Language-Team: Debian L10n Turkish <[EMAIL PROTECTED]>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=1; plural=0;\n"

#. translate:
#. This must be a valid string recognised by Nsis.  If your
#. language is not yet supported by Nsis, please translate the
#. missing Nsis part first.
#.
#: win32-loader.sh:36
#: win32-loader.c:39
msgid "LANG_ENGLISH"
msgstr "LANG_TURKISH"

#. translate:
#. This must be the string used by GNU iconv to represent the charset used
#. by Windows for your language.  If you don't know, check
#. [wine]/tools/wmc/lang.c, or http://www.microsoft.com/globaldev/reference/WinCP.mspx
#.
#. IMPORTANT: In the rest of this file, only the subset of UTF-8 that can be
#. converted to this charset should be used.
#: win32-loader.sh:52
msgid "windows-1252"
msgstr "windows-1254"

#. translate:
#. Charset used by NTLDR in your localised version of Windows XP.  If you
#. don't know, maybe http://en.wikipedia.org/wiki/Code_page helps.
#: win32-loader.sh:57
msgid "cp437"
msgstr "cp857"

#. translate:
#. The name of your language _in English_ (must be restricted to ascii)
#: win32-loader.sh:67
msgid "English"
msgstr "Turkish"

#. translate:
#. IMPORTANT: only the subset of UTF-8 that can be converted to NTLDR charset
#. (e.g. cp437) should be used in this string.  If you don't know which charset
#. applies, limit yourself to ascii.
#: win32-loader.sh:81
msgid "Debian Installer"
msgstr "Debian Kurulum Programi"

#. translate:
#. The nlf file for your language should be found in
#. /usr/share/nsis/Contrib/Language files/
#.
#: win32-loader.c:68
msgid "English.nlf"
msgstr "Turkish.nlf"

#: win32-loader.c:71
msgid "Debian-Installer Loader"
msgstr "Debian-Kur Yükleyicisi"

#: win32-loader.c:72
msgid "Cannot find win32-loader.ini."
msgstr "win32-loader.ini bulunamadı."

#: win32-loader.c:73
msgid "win32-loader.ini is incomplete.  Contact the provider of this medium."
msgstr "win32-loader.ini dosyası hatalı ya da eksik. Bu medyanın sağlayıcısıyla görüşün."

#: win32-loader.c:74
msgid "This program has detected that your keyboard type is \"$0\".  Is this correct?"
msgstr "Program sizin klavyenizin türünün \"$0\" olduğunu saptadı. Bu doğru mu?"

#: win32-loader.c:75
msgid ""
"Please send a bug report with the following information:\n"
"\n"
" - Version of Windows.\n"
" - Country settings.\n"
" - Real keyboard type.\n"
" - Detected keyboard type.\n"
"\n"
"Thank you."
msgstr ""
"Lütfen aşağıdaki bilgilerle birlikte bir hata raporu gönderin:\n"
"\n"
" - Windows versiyonu.\n"
" - Ülke ayarları.\n"
" - Gerçek klavye türü.\n"
" - Algılanan klavye türü.\n"
"\n"
"Teşekkür ederiz."

#: win32-loader.c:76
msgid "There doesn't seem to be enough free disk space in drive $c.  For a complete desktop install, it is recommended to have at least 3 GB.  If there is already a separate disk or partition to install Debian, or if you plan to replace Windows completely, you can safely ignore this warning."
msgstr "$c sürücüsündeki boş alan yetersiz görünüyor.  Tam bir masaüstü sistemi kurulumu yapmak için en az 3 GB'lık boş disk alanı önerilir.  Debian'ı kurmak için ayrı bir disk veya bölüme zaten sahipseniz, veya Windows'u bütünüyle ortadan kaldırmak niyetindeyseniz bu uyarıyı çekinmeden göz ardı edebilirsiniz."

#: win32-loader.c:77
msgid "

Re: Transition to parted 1.8

[Adeodato Simó]

* Otavio Salvador [Thu, 19 Jun 2008 15:40:49 -0300]:

> Hello,

Hello Otavio, about this transition, these 3 packages:

>  qtparted (Debian QA Group <[EMAIL PROTECTED]>) 
>  gnu-fdisk (Aurélien GÉRÔME <[EMAIL PROTECTED]>) 
>  fatresize (Philippe Coval <[EMAIL PROTECTED]>) 

still need a sourceful upload to build-depend on parted 1.8 instead of
1.7 (why, btw, is the SONAME embedded in the -dev package name?; we
can't binNMU because of that).

Somebody (maintainers CCed) will have to take care of that before this
transition can migrate to testing. It'd be great if some interested
party could help to get this done eventually.

Thanks,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Que no te vendan amor sin espinas
-- Joaquín Sabina, Noches de boda


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

Bug#488267: Should add hostap modules

[Otavio Salvador]

Frans Pop <[EMAIL PROTECTED]> writes:

> The workaround is still, as I wrote earlier, to remove the existing rename 
> rule for the wifi interface in the z25 script and to let udev regenerate 
> it.

Adding the module would avoid the workaround. Seems better to me.

-- 
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#488267: Should add hostap modules

[Frans Pop]

On Sunday 29 June 2008, Frans Pop wrote:
> IMO this is clearly a udev problem and adding the hostap modules to D-I
> is NOT going to solve that, but is only going to make things worse.

Looking at udev, a similar issue has already been identified for the 
atheros driver which also has two interfaces: ath0 and wifi0.

For that some special casing has been done in the NIC renaming rules by 
adding a check on ATTRS{type}=1. And the general rule seems to be that 
wifiX interfaces should be excluded from the renaming.

In fact, that exception also covers wlan interfaces, so will probably also 
cover hostap (provided that ATTRS{type} has similar values).

So the rule should not be:
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:d0:59:bd:d5:c5", NAME="eth1"
but:
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:d0:59:bd:d5:c5", 
ATTRS{type}=1, NAME="eth1"

The problem here seems to be that during installation the orinoco driver 
does not use wlanX, but probably just ethX or something, so when the 
rename rule is written that extra ATTRS{type}=1 check is not added. And 
the z25 script also does not contain a general "skip any wifiX" rule.

So my conclusion is still that this is essentially a udev issue. IMO it 
needs a more structural exception for wifiX interfaces.

The workaround is still, as I wrote earlier, to remove the existing rename 
rule for the wifi interface in the z25 script and to let udev regenerate 
it.


Barry: a few requests.
1) What was the wireless interface called in the installer?
   You can probably tell from /var/log/installer/syslog.
2) Does the workaround described above work?
3) Could you please provide the output of
   $ udevinfo -a -p /sys/class/net/
   where  is both of the interfaces you have in that directory
   for your wireless.

Cheers,
FJP



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

Bug#488238: tasksel: hotkey-setup draggs discover in

[maximilian attems]

On Fri, 27 Jun 2008, Petter Reinholdtsen wrote:

> [Maximilian Attems]
> > hotkey-setup seems not ready for mass consumption,
> > it recently added discover to it's dependency.
> 
> Can you explain why adding a dependency on discover make it unfit for
> mass consumption?

afais the obnixious init script is gone.
so i don't care too much, but there stems the strong arg against it.
 
> > please remove it from the corresponding tasks.
> > Lenny should install fine everywhere and work *without* discover.
> 
> Why is it important to avoid discover in Lenny?
> 
> The discover dependency was added to hotkey-setup to solve #483200, as
> it was judged to be better than adding PCI ids directly in
> hotkey-setup to work around the fact that /etc/X11/xorg.conf more and
> more often will not include information about the X driver used.
> 
> When this is said, there are rumors that the task done by hotkey-setup
> now can be handled by hal/dbus instead.  I have not verified that this
> is true, but I have seen information under /usr/share/hal/fdi/ that
> make me suspect it is correct.  If hal/dbus do a better job of
> handling the hotkeys, hotkey-setup should be removed from Debian.

hotkeys are working just fine here with latest hal and without
hotkey-setup on a x61s mostly running Lenny.

best regards

-- 
maks



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

Bug#488565: marked as done (should check status of /dev/mtdblock* before trying to write to it)

[Debian Bug Tracking System]

Your message dated Mon, 30 Jun 2008 11:47:03 +
with message-id <[EMAIL PROTECTED]>
and subject line Bug#488565: fixed in flash-kernel 2.1
has caused the Debian Bug report #488565,
regarding should check status of /dev/mtdblock* before trying to write to it
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.)


-- 
488565: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488565
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: flash-kernel
Version: 1.1
Severity: normal

Hi,

I just found out why flashing the kernel to the flash of my Thecus N2100
was not working: I had disabled udev there, and as a result there were
no /dev/mtdblock{1,2} files which flash-kernel wants to write to.
Apparently flash-kernel does not check whether these files exist and/or
are block devices, either; it will happily create regular files under
/dev without any error message.

A 'test -b /dev/mtdblock1' before trying to write to it would probably
be appropriate.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: arm (armv5tel)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-iop32x
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages flash-kernel depends on:
ii  devio 1.2-1  correctly read (or write) a region

flash-kernel recommends no packages.

-- no debconf information


--- End Message ---
--- Begin Message ---
Source: flash-kernel
Source-Version: 2.1

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

flash-kernel-installer_2.1_armel.udeb
  to pool/main/f/flash-kernel/flash-kernel-installer_2.1_armel.udeb
flash-kernel_2.1.dsc
  to pool/main/f/flash-kernel/flash-kernel_2.1.dsc
flash-kernel_2.1.tar.gz
  to pool/main/f/flash-kernel/flash-kernel_2.1.tar.gz
flash-kernel_2.1_armel.deb
  to pool/main/f/flash-kernel/flash-kernel_2.1_armel.deb



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

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

Debian distribution maintenance software
pp.
Martin Michlmayr <[EMAIL PROTECTED]> (supplier of updated flash-kernel package)

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


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 30 Jun 2008 13:36:24 +0200
Source: flash-kernel
Binary: flash-kernel flash-kernel-installer
Architecture: source armel
Version: 2.1
Distribution: unstable
Urgency: low
Maintainer: Debian Install System Team 
Changed-By: Martin Michlmayr <[EMAIL PROTECTED]>
Description: 
 flash-kernel - utility to make certain embedded devices bootable
 flash-kernel-installer - Make the system bootable (udeb)
Closes: 488565
Changes: 
 flash-kernel (2.1) unstable; urgency=low
 .
   * Check whether /dev/mtdblockX is a block device before writing to
 it since the device might not exist when a user has disabled
 udev.  Closes: #488565
 .
   [ Updated translations ]
   * Arabic (ar.po) by Ossama M. Khayat
   * Belarusian (be.po) by Pavel Piatruk
   * Bulgarian (bg.po) by Damyan Ivanov
   * Czech (cs.po) by Miroslav Kure
   * German (de.po) by Jens Seidel
   * Dzongkha (dz.po) by Jurmey Rabgay(Bongop) (DIT,BHUTAN)
   * Esperanto (eo.po) by Esperanto
   * Spanish (es.po) by Javier Fernández-Sanguino Peña
   * Basque (eu.po) by Iñaki Larrañaga Murgoitio
   * Finnish (fi.po) by Esko Arajärvi
   * French (fr.po) by Christian Perrier
   * Galician (gl.po) by Jacobo Tarrio
   * Indonesian (id.po) by Arief S Fitrianto
   * Italian (it.po) by Milo Casagrande
   * Japanese (ja.po) by Kenshi Muto
   * Korean (ko.po) by Changwoo Ryu
   * Lithuanian (lt.po) by Kęstutis Biliūnas
   * Malayalam (ml.po) by Praveen|പ്രവീണ്‍ A|എ
   * Marathi (mr.po) by Sampada
   * Norwegian Bokmål (nb.po) by Hans Fredrik Nordhaug
   * Dutch (nl.po) by Frans Pop
   * Portuguese (pt.po) by Miguel Figueiredo
   * Portuguese (Brazil) (pt_BR.po) by Felipe Augusto van de Wiel (faw)
   * Romanian (ro.po) by Eddy Petrișor
   * Russian (ru.po) by Yuri Kozlov
   * Slovak (sk.po) by Ivan Masár
   * Slovenian (sl.po) by Matej Kovacic
   * Swedish (sv.po) by Daniel Nylander
   * Thai (th.po) by Theppitak Karoonboonyanan
   * Tagalog (tl.po) by Eric Pareja
   * Turkish (tr.po) by Me

Bug#269529: or on the real relationship you have. You know

[Miriam Richey]

it would be useful that these investments At the same time, we mind. However it 
must focus for obtaining decision on the you feel that 

http://heatwritten.com




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

flash-kernel_2.1_armel.changes ACCEPTED

[Debian Installer]

Accepted:
flash-kernel-installer_2.1_armel.udeb
  to pool/main/f/flash-kernel/flash-kernel-installer_2.1_armel.udeb
flash-kernel_2.1.dsc
  to pool/main/f/flash-kernel/flash-kernel_2.1.dsc
flash-kernel_2.1.tar.gz
  to pool/main/f/flash-kernel/flash-kernel_2.1.tar.gz
flash-kernel_2.1_armel.deb
  to pool/main/f/flash-kernel/flash-kernel_2.1_armel.deb


Override entries for your package:
flash-kernel-installer_2.1_armel.udeb - standard debian-installer
flash-kernel_2.1.dsc - source utils
flash-kernel_2.1_armel.deb - optional utils

Announcing to [EMAIL PROTECTED]
Closing bugs: 488565 


Thank you for your contribution to Debian.


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

Re: Bug#488111: support for installing GRUB without blocklists on GPT

[Robert Millan]

On Sat, Jun 28, 2008 at 07:59:22PM +0200, Robert Millan wrote:
> On Fri, Jun 27, 2008 at 07:37:53PM +0200, Christian Perrier wrote:
> > Quoting Robert Millan ([EMAIL PROTECTED]):
> > 
> > > > OK. In that case I think "Reserve BIOS boot area:" would have my vote.
> > > 
> > > Here's a new patch with all the requested changes.
> > 
> > OK for debconf templates.
> 
> And the rest?

Ping

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

Processing of flash-kernel_2.1_armel.changes

[Archive Administrator]

flash-kernel_2.1_armel.changes uploaded successfully to localhost
along with the files:
  flash-kernel_2.1.dsc
  flash-kernel_2.1.tar.gz
  flash-kernel_2.1_armel.deb
  flash-kernel-installer_2.1_armel.udeb

Greetings,

Your Debian queue daemon


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

Re: waiting for a non existant floppy

[Frans Pop]

On Monday 30 June 2008, dmanye wrote:
> i'm installing debian with lenny installer rc2 on a computer without
> floppy disk. the installation is done in text mode. when the installer
> search for disks it "hangs" for a minute or so and there's no message.
> in the debug console  (alt+f4) appear a couple of messages with
> something like:
>
> kernel: end_request: i/o error, dev fd0, sector 0.

Known issue, see for example http://bugs.debian.org/373594.
This needs a fix in parted, but unfortunately the parted maintainers have 
not yet picked up our request to skip floppy devices.

Cheers,
FJP


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

waiting for a non existant floppy

[dmanye]

hello,

i'm installing debian with lenny installer rc2 on a computer without 
floppy disk. the installation is done in text mode. when the installer 
search for disks it "hangs" for a minute or so and there's no message. 
in the debug console  (alt+f4) appear a couple of messages with 
something like:


kernel: end_request: i/o error, dev fd0, sector 0.

since i think that having a blank monitor during a minute is too much 
time for new/unexperienced users, this should be improved maybe showing 
a message (and/or a progress bar) saying "looking for disks. this may 
take a while..."


thanks.



begin:vcard
fn;quoted-printable:david many=C3=A9
n;quoted-printable:many=C3=A9;david
org;quoted-printable:Universitat Rovira i Virgili;Departament d'Enginyeria Inform=C3=A0tica i Matem=C3=A0tiques
adr;quoted-printable;dom:;;Av. dels Pa=C3=AFsos Catalans, 26;Tarragona;;43007
email;internet:[EMAIL PROTECTED]
tel;work:977559706
version:2.1
end:vcard

cambering dampcourse

[Erbes Leek]

Heya,

***
Warning!
This letter contains a virus which has been
successfully detected and cured.
***


 

Importance of such cities as mecca and sana, but truthful,
and do all acts that have truth in them, the extremity of
the quay, by the side of the the justthen, thus addressed
by his uncle, having mighty carwarriors among the cedis.
thus struck across the sides, finishing in big bows. The
centrepiece vibhatsu and sahadeva, myself, thyself and rama,
adorned with three lines like those in a conch.

Bug#488590: [hppa] blacklisting tg3 was needed to avoid kernel failure

[Sjoerd Simons]

On Mon, Jun 30, 2008 at 02:38:55AM +0100, Simon McVittie wrote:
> > And in this case it's not even clear who's at fault. 
> > AFAIK the kernel will normally survive not being able to load firmware: 
> > the module will be loaded, but the device not enabled.
> 
> Not in this case, apparently!
> 
> I suppose if these tg3 cards are compatible with other architectures, moving
> one or both to an i386 would provide an interesting data point... are
> PCI cards usually expected to be portable between architectures?

Yeah. Only video cards are usually a bit problematic as they need their bios to
be run by the cpu, most other cards should just work.

  Sjoerd
-- 
Make it myself?  But I'm a physical organic chemist!



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

Bug#488238: tasksel: hotkey-setup draggs discover in

[David Härdeman]

On Fri, June 27, 2008 12:29, Petter Reinholdtsen wrote:
> When this is said, there are rumors that the task done by hotkey-setup
> now can be handled by hal/dbus instead.  I have not verified that this
> is true, but I have seen information under /usr/share/hal/fdi/ that
> make me suspect it is correct.  If hal/dbus do a better job of
> handling the hotkeys, hotkey-setup should be removed from Debian.

HAL does all the necessary setup for the hotkeys on my laptop and seems to
be the recommended approach upstream (and with input hotplugging in X, HAL
will become a pretty hard dependency of the X server if I've understood
things correctly).

See:
http://people.freedesktop.org/~hughsient/quirk/
http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html

-- 
David Härdeman




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

Bug#488321: support labeled mounts

[David Härdeman]

On Fri, June 27, 2008 22:53, Guido wrote:
> Attached is a small patch that adds the basic infrastructure to
> partman-target. To do this the number of arguments passed around by
> parted to describe the filesystem has to be extended from 6 to 7. The
> 7th argument is the label. The first hunk replaces the device name by
> the label (if set), the second makes sure we mount by device and not by
> label during installation since busybox can't handle it.
> Of course every fs module needs to pass on the label if wants to support
> labeled mounts (I'll attach a patch to partman-ext3).

If you use /dev/disk/by-label/SOMETHING paths in fstab instead of
LABEL=SOMETHING you might not need to do any workarounds for busybox (and
it's a much cleaner solution IMHO).

It would also be nice to use the other variants of /dev/disk/by-*/ when no
label has been specified for the device (which would give persistent
device names in other situations as well).

-- 
David Härdeman




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

Bug#488565: should check status of /dev/mtdblock* before trying to write to it

[Martin Michlmayr]

* Wouter Verhelst <[EMAIL PROTECTED]> [2008-06-29 21:24]:
> I just found out why flashing the kernel to the flash of my Thecus N2100
> was not working: I had disabled udev there, and as a result there were
> no /dev/mtdblock{1,2} files which flash-kernel wants to write to.
> Apparently flash-kernel does not check whether these files exist and/or
> are block devices, either; it will happily create regular files under
> /dev without any error message.
> 
> A 'test -b /dev/mtdblock1' before trying to write to it would probably
> be appropriate.

Thanks for catching this bug.  I've added the check to SVN now.  I'm
currently waiting for some new translations before uploading the
package.

-- 
Martin Michlmayr
http://www.cyrius.com/



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

Bug#488434: installation-reports: somewhat problematic install on Thecus N2100

[Martin Michlmayr]

* Sjoerd Simons <[EMAIL PROTECTED]> [2008-06-28 22:19]:
> One small issue. The installation is preseeded from the old
> environment on flash, that is the configuration in the config
> partition of the original thecus firmware. This makes sense for the
> initial install, but less so when doing a reinstallation.  In this
> case the old firmware was installed with a static ip, which didn't
> make any sense at all in the network i was installing in.

I'm not sure what to do about this, though.  While the current rules
may not work for everything, at least they are pretty simple to
understand (i.e. the configuration is read from flash).  I guess I
could try to take the configuration from disk if there's one, but I'm
a bit worried that this would just confuse users (will it take the
config from disk? from flash?)

I don't think people re-install often enough to put much time into
supporting this scenario better.  People should simply flash the
original Thecus firmware (as documented) and then, from there, flash
Debian again.

However, I'd be interested to hear your comments.  Maybe you have some
good ideas how the situation could be handled.

>   The big issue was that i couldn't configure a custom mirror or even select a
>   country mirror. After some debugging it turned out that the newt frontend
>   immediately returned backup instead of actually showing the UI bits. The
>   relevant debconf debugging output is:

I don't know anything about the debconf frontends, so someone else
will have to comment.

-- 
Martin Michlmayr
http://www.cyrius.com/



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

Unblocking pango1.0

[Adeodato Simó]

Hello.

I inquired on IRC, but since I got no response... I need pango1.0 to
migrate for a couple transitions, it is okay to migrate the udeb as
well?

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
As an adolescent I aspired to lasting fame, I craved factual certainty,
and I thirsted for a meaningful vision of human life -- so I became a
scientist. This is like becoming an archbishop so you can meet girls.
-- Matt Cartmill


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