Bug#484121: tasksel: let's sync on the GNOME task

[Eric Dorland]

* Joey Hess ([EMAIL PROTECTED]) wrote:
> Eric Dorland wrote:
> > So the user agent thing is fairly well documented at
> > http://bugs.debian.org/399633, but basically it's our stand against
> > user-agent insanity. We could of course make it say Firefox easily,
> > but this certainly seems a bit defeatist.
> 
> s/defeatist/defeated/
> 
> I realized this battle was over when discussion on debian-user revieled
> that google maps behaved differently in firefox than iceweasel, because it
> used a firefox-UA specific test to enable a feature (closing the sidebar
> to make the map take up the full screen).
> 
> If the top website out there gets it "wrong", the battle is effectively 
> over; "right" or "wrong" no longer really matters (victors write history
> etc).

Well I think Google generally does treat the Iceweasel user agent
properly. Not everyone understands these issues as well as they
should, mistakes get made. I mean we could set the User-Agent to IE
like some other browsers do, that would make more sites work.
 
> > I think we should almost
> > certainly document the workaround better in the README.Debian. Of
> > course I highly respect Joey's opinion so I'm open to more
> > convincing. 
> 
> I'm afraid that documenting it in README.Debian won't help desktop users
> who just find that this strange "iceweasel" browser we install by
> default doesn't work on sites that firefox works on.

Could we do it in a more prominent perhaps?  


-- 
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]



signature.asc
Description: Digital signature

Bug#485790: generate separate /boot as workaround for buggy LBA48 ?

[Goswin von Brederlow]

Frans Pop <[EMAIL PROTECTED]> writes:

> On Friday 13 June 2008, Goswin von Brederlow wrote:
>> > Earlier instances of the same problem.  The 8 GiB barrier was because
>> > of the BIOS only issuing one 24-bit ATA command.  I'm not sure how
>> > common will the new limit be in comparison.
>>
>> As well as 518MB, 2GiB, 32GiB, 64GiB, 128GiB. PC BIOSes are just
>> riddled with those stupid problems.
>
> Yep.
>
>> >> I wonder what we should do about this:
>> >> - just always create a /boot partition when guided partitioning is
>> >> used
>>
>> There is only one reason to have a seperate /boot: / is crypted. And
>> then you always need one.
>
> And LVM when used with some/most bootloaders, and most RAID setups.

That falls under "all other cases" below.

>> In all other cases a small / partition is the superior solution imho.
>>
>> So my solution would be to default to a seperate small / partition at
>> the start of the disk unless crypted is selected and then start with a
>> small /boot.
>
> That may still not solve the problem for one important class of installs 
> though: dual boot systems where the size of $other_os partition + the / 
> partitions exceeds what the BIOS supports.

The margin between a 100MB /boot working and 300MB / not working is
negible. Actualy I only have 115MB used on / including /boot but then
I don't use the huge debian kernel.

>> The risk of detection problems certainly outweighs the drawbacks of
>> always having a small / or /boot.
>
> The disadvantage of that (assuming you want to avoid LVM) is that for a 
> really small / you'll need at least separate /var, /usr, /tmp, /srv 
> and /home partitions and then you have the question what the best 
> relative sizes are for that particular user.
>
> Here's a wild idea that could be used to work around that.
>
> Create two partitions: / and a partition e.g. "/media/multifs".
> And then bind mount all other partitions inside the second one.
>
> /etc/fstab would look something like this:
> 
> # /etc/fstab: static file system information.
> #
> #
> proc/proc   procdefaults0   0
> /dev/hda1   /   ext3errors=remount-ro 0   1
> /dev/hda3   /media/multifs  ext3defaults0   2
> /dev/hda5   noneswapsw  0   0
> /dev/hdc/media/cdrom0   udf,iso9660 user,noauto 0   0
> /dev/fd0/media/floppy0  autorw,user,noauto  0   0
>
> /media/multifs/home   /home   ext3bind0   0
> /media/multifs/srv/srvext3bind0   0
> /media/multifs/usr/usrext3bind0   0
> /media/multifs/var/varext3bind0   0
> /media/multifs/tmp/tmpext3bind0   0
> 
>
> I've tested this and it actually seems to work. If people like this idea, 
> all we'd need is to add support for it in partman :-)

It would be nice I guess. But I found that at some point or another I
always do need some lvm feature. And I've seen it happen often enough
on irc that someone needed to resize their partition. LVM just is the
best option. Someone that realy doesn't want it can probably bind
mount themself.

Maybe partman could support bind mounts without having an automatic
partitioning using them like above.

> One added advantage would be short fsck times for /.

Ideally / and /usr should be read-only. No fsck at all.

> Cheers,
> FJP

MfG
Goswin



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

Re: Considerations for lilo removal

[Frans Pop]

William Pitcock wrote:
> I am wondering if it is a good idea to remove lilo entirely. At the
> moment, lilo has been pulled from testing, and the code is in a shape

That's just great. That means that whoever did this just broke an option 
that's been available in Debian Installer since forever: to choose lilo 
as bootloader rather than grub. And it seems for no other reason than 
cosmetically bring the RC count down as the BR shows that testing 
currently is not affected (still has 2.6.24).

It really would be nice if the RT would would contact us (D-I team) before 
taking such actions, especially as we just had a fairly big discussion 
about a similar case. It can't be too hard to make the mental jump from
"$bootloader package" to "installation system".

> where a grave bug (bug #479607) is unlikely fixable without severe
> refactoring of the codebase.
 
> With grub being stable and grub2 approaching stability itself, do we
> really need lilo anymore? It's not even installed by default anymore,
> and the only systems I have that are still on lilo are installations of
> Debian I have had since Woody.

We still very regularly get installation reports where people use lilo 
rather than grub, so it must still have a fairly significant user base. I 
would say that the activity on the bug report shows the same.

Please keep the D-I team informed of where this is going.

TIA,
FJP


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

Bug#484121: tasksel: let's sync on the GNOME task

[Mike Hommey]

On Mon, Jun 16, 2008 at 04:29:43AM -0400, Eric Dorland wrote:
> * Joey Hess ([EMAIL PROTECTED]) wrote:
> > Eric Dorland wrote:
> > > So the user agent thing is fairly well documented at
> > > http://bugs.debian.org/399633, but basically it's our stand against
> > > user-agent insanity. We could of course make it say Firefox easily,
> > > but this certainly seems a bit defeatist.
> > 
> > s/defeatist/defeated/
> > 
> > I realized this battle was over when discussion on debian-user revieled
> > that google maps behaved differently in firefox than iceweasel, because it
> > used a firefox-UA specific test to enable a feature (closing the sidebar
> > to make the map take up the full screen).
> > 
> > If the top website out there gets it "wrong", the battle is effectively 
> > over; "right" or "wrong" no longer really matters (victors write history
> > etc).
> 
> Well I think Google generally does treat the Iceweasel user agent
> properly. Not everyone understands these issues as well as they
> should, mistakes get made. I mean we could set the User-Agent to IE
> like some other browsers do, that would make more sites work.
>  
> > > I think we should almost
> > > certainly document the workaround better in the README.Debian. Of
> > > course I highly respect Joey's opinion so I'm open to more
> > > convincing. 
> > 
> > I'm afraid that documenting it in README.Debian won't help desktop users
> > who just find that this strange "iceweasel" browser we install by
> > default doesn't work on sites that firefox works on.
> 
> Could we do it in a more prominent perhaps?  

Note that the about: page, which is the default home page in iceweasel,
contains a link to the README.Debian file.

Mike



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

Re: Considerations for lilo removal

[peter green]

I am wondering if it is a good idea to remove lilo entirely. At the
moment, lilo has been pulled from testing, and the code is in a shape

Can either version of grub handle all the cases that lilo can? for 
example can either of them handle the situation where root is on lvm and 
there is not a seperate /boot partition? last I checked d-i defaulted to 
lilo in that situation.


If not then removing lilo will leave d-i with no ability to install a 
bootloader in those situations and worse leave some users with no 
upgrade path.



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

Re: Considerations for lilo removal

[Mike Hommey]

On Mon, Jun 16, 2008 at 10:57:32AM +0200, Frans Pop wrote:
> We still very regularly get installation reports where people use lilo 
> rather than grub, so it must still have a fairly significant user base. I 
> would say that the activity on the bug report shows the same.

OTOH, aren't most of these choosing lilo over grub only doing so by
habit ?

Mike


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

Re: Considerations for lilo removal

[Frans Pop]

(Dropping d-release for this part of the discussion.)

On Monday 16 June 2008, Mike Hommey wrote:
> On Mon, Jun 16, 2008 at 10:57:32AM +0200, Frans Pop wrote:
> > We still very regularly get installation reports where people use
> > lilo rather than grub, so it must still have a fairly significant
> > user base. I would say that the activity on the bug report shows the
> > same.
>
> OTOH, aren't most of these choosing lilo over grub only doing so by
> habit ?

In some cases, probably. But as it requires some fairly specific actions 
in D-I, especially in the default mode, I would expect it to be a 
conscious choice in a lot of cases. I also remember a number of reports 
_requesting_ that we support installing lilo instead of grub...

And see also some of the other replies in this thread. AFAICT there is 
still a "real" demand for lilo.

And wasn't Linux (or free software if you prefer) at least partly about 
choice anyway?

AFAICT from a quick browse through the BR, the issue is only that the size 
of the initrd as generated by default by initramfs-tools with 2.6.25 has 
grown too large for lilo.
Does this mean that server setups that do not use an initrd at all or that 
have small, targeted initrds should no longer be allowed to use lilo?

Why not add a size check in lilo that just loudly bails out if the initrd 
is too large? As lilo has to be rerun anyway, that would at least inform 
users that there is a problem at kernel installation time instead of on 
the first reboot and they get a chance to correct things.


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

Re: Considerations for lilo removal

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/16/08 04:19, Mike Hommey wrote:
> On Mon, Jun 16, 2008 at 10:57:32AM +0200, Frans Pop wrote:
>> We still very regularly get installation reports where people use lilo 
>> rather than grub, so it must still have a fairly significant user base. I 
>> would say that the activity on the bug report shows the same.
> 
> OTOH, aren't most of these choosing lilo over grub only doing so by
> habit ?

Does it matter?

Debian doesn't just have one web broswer, one MUA, one IM app, one
scripting language, one word processor, one movie player, etc, etc,
etc.  So why should it only have one boot loader?

- --
Ron Johnson, Jr.
Jefferson LA  USA

"Kittens give Morbo gas.  In lighter news, the city of New New
York is doomed."
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkhWNnIACgkQS9HxQb37XmdjQACghOfpn0VHd4bTToJmCM2XCaBx
Sv8AoLQ+vE3tpCOKd0DkG6k5yFNLruXN
=fOMf
-END PGP SIGNATURE-


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

Re: Considerations for lilo removal

[Frans Pop]

(Dropping d-release again.)

On Monday 16 June 2008, peter green wrote:
> >> I am wondering if it is a good idea to remove lilo entirely. At the
> >> moment, lilo has been pulled from testing, and the code is in a
> >> shape
>
> Can either version of grub handle all the cases that lilo can?

D-I currently does indeed fall back to lilo for _all_ /boot on LVM cases.
When LVM is set up using guided partitioning D-I will always create a 
separate /boot partition though.

AFAIK grub (at least the default "legacy" version) also still has problems 
with / on XFS. That's the one other case where D-I automatically falls 
back to lilo.


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

Re: Testing transition for console-setup 1.24

[Otavio Salvador]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Christian Perrier <[EMAIL PROTECTED]> writes:

> console-setup is currently frozen because it provides a udeb.
>
> As the D-I beta2 is out and, anyway, console-setup's udeb is not used
> in D-I as of now, I think it's OK for it to enter testing.

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+ 

iEYEARECAAYFAkhWabQACgkQLqiZQEml+FU9XACgiaWGzkBL/jY3IkH6q+x+8Y9y
HSsAoK2GNOX5GfsjvCBPpZH59TU3So3d
=jgkA
-END PGP SIGNATURE-


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

Re: klibc 1.5.10

[Otavio Salvador]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

maximilian attems <[EMAIL PROTECTED]> writes:

> hello,
>
> please unblock klibc 1.5.10-1
>
> was 10 days in unstable without trouble and fixes some utils.
> no lib changes itself.
>
> hpa just pushed out 1.5.11, i'd like to upload that tomorrow
> as several more nice to have fixes in nfsmount + sh4 support
> + ext4dev fstype.

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+ 

iEYEARECAAYFAkhWag0ACgkQLqiZQEml+FWDmgCgrOgskGL8ndsfnxCNFGreZm/3
Me8AoKx9fkaJyLN8YneMTi1z6OznH4jD
=dQNM
-END PGP SIGNATURE-


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

Re: Bug#485655: debian-installer: The KDE images should use sudo too and configure KDE accordingly.

[Frans Pop]

reassign 485655 tasksel 2.74
thanks

On Monday 16 June 2008, Joey Hess wrote:
> It seems easier at the moment to add your code, and include it in the
> task than it does to change the default or remove the debconf use, and
> come up with a way to detect which tasks were installed[1].

Sounds good to me. I've committed the change in user-setup. Please close 
the BR with your tasksel change.

Cheers,
FJP

/me wonders what the [1] was supposed to refer to...


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

Processed: Re: Bug#485655: debian-installer: The KDE images should use sudo too and configure KDE accordingly.

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 485655 tasksel 2.74
Bug#485655: debian-installer: The KDE images should use sudo too and configure 
KDE accordingly.
Bug reassigned from package `debian-installer' to `tasksel'.

> 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#479781: Debootstrap

[Anders Winnberg]

I managed to install base system with ext2 file system instead of ext3. 
 However, during installation of GUI I got parity errors.  Looks like 
disk hardware problem.


Please close the bug report.
/Anders

--
Anders Winnberg   tel: +46 31 772 5533
Onsala Space Observatory  fax: +46 31 772 5590
SE-439 92 Onsala  e-mail: [EMAIL PROTECTED]
Sweden



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

Bug#479781: marked as done (Debootstrap)

[Debian Bug Tracking System]

Your message dated Mon, 16 Jun 2008 19:27:58 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Re: Bug#479781: Debootstrap
has caused the Debian Bug report #479781,
regarding Debootstrap
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.)


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

Package: installation-reports

Boot method: CD
Image version: i386 etch
Date: May 5, 2008

Machine: Compaq Presario 5670 (home computer from 1998)
Processor: Intel Pentium II 450 MHz
Memory: 384 MB
Partitions: IDE1 master (hda) -   8.0 GB ST38641A
 #1 primary   8.0 GB B K fat32 /windows
SCSI1 (0,0,0) (sda)  37.0 GB Seagate ST336918N
 #1 primary  57.5 MB   K ext3  /boot
 #5 logical 838.9 MB   F swap  swap
 #6 logical  36.1 GB   K ext3  /

Output of lspci -nn and lspci -vnn: ?

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

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

Comments/Problems: I partitioned the SCSI disk using Partition Magic.
During the installation I chose Manual partitioning and merely gave the
mount points for the two ext3-partitions (/boot and /).  During the 
"Install base system" I got the following error message:


Debootstrap warning:
Failure trying to run: chroot /target dpkg --force-depends --install
var/cache/apt/archives/base-files_4_i386.dev
var/cache/apt/archives/base-passwd_3.5.11_i386.deb

Next came the following explanation:

Base system installation error:
The debootstrap program exited with an error (return value 1).
Check /var/log/syslog or see virtual console 4 for the details.

When I hit left-alt/f4 I saw messages like:

debootstrap: /usr/sbin/debootstrap: 413
debootstrap: cannot create /target/debootstrap/debpaths: read-only file
system
debootstrap: tar: couldnt remove old file: read-only file system

All this is gibberish to me.  Could you please help?

--
Anders Winnberg   tel: +46 31 772 5533
Onsala Space Observatory  fax: +46 31 772 5590
SE-439 92 Onsala  e-mail: [EMAIL PROTECTED]
Sweden





--- End Message ---
--- Begin Message ---
On Monday 16 June 2008, Anders Winnberg wrote:
> I managed to install base system with ext2 file system instead of ext3.
>   However, during installation of GUI I got parity errors.  Looks like
> disk hardware problem.
>
> Please close the bug report.

Done. Thanks for letting us know.

Cheers,
FJP

--- End Message ---

Bug#486541: grub problem with debian-installer

[sigmaxc]

Package: installation-reports

Boot method: 
Image version: 
http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/iso-cd/
debian-testing-i386-netinst.iso (16-Jun-2008 11:14)
Date: 16-Jun-2008 18:00

Machine: Desktop PC (Mainboard Elitegroup K7S5A)
Processor:  Athlon XP-1700+
Memory:   768MB
Partitions: 
> fdisk -l /dev/hdb

Disk /dev/hdb: 40.0 GB, 40020664320 bytes
255 heads, 63 sectors/track, 4865 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot  Start End  Blocks   Id  System
/dev/hdb1   1 122  979933+  83  Linux
/dev/hdb2 123 487 2931862+  83  Linux
/dev/hdb3 609486534194352+   5  Extended
/dev/hdb4 488 608  971932+  82  Linux swap / Solaris
/dev/hdb5 6091094 3903763+  83  Linux
/dev/hdb610951459 2931831   83  Linux
/dev/hdb71460486527358663+  83  Linux

Partition table entries are not in disk order


Output of lspci -nn and lspci -vnn:

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

Initial boot:   [E]
Detect network card:[ ]
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:[ ]
Problem with boot, did not check the rest.


Comments/Problems:  PROBLEM WITH GRUB and multiple disks:  Error 15
* Status before: Debian Etch installation with RAID on /dev/hda and /dev/hdc, 
   working ok for months. /dev/hdd is DVD-ROM.
* Now: Netboot installation of fresh lenny debian-installer on additional 
harddisk /dev/hdb
   (installation did not touch hda and hdc;  grub was installed to MBR of hdb)
* partitioning of new installation:  /boot on hdb1, / (root directory) on hdb5

* PROBLEM on first reboot: chosen in BIOS to boot from IDE1 (=hdb)
Then the new Grub menu appears (fine), when entering stage 2:  "Error 15: File 
not found" (bad)
Extract from [hdb1] /grub/menu.lst:
   title   Debian GNU/Linux, kernel 2.6.24-1-486
   root(hd1,0)
   kernel  /vmlinuz-2.6.24-1-486 root=/dev/hdb5 ro quiet
   initrd  /initrd.img-2.6.24-1-486
* Booting old system and mounting hdb1 shows everthing is correctly in place.


* Some kind of (inconvenient) WORK-AROUND: change the above
line in file [hdb1] /grub/menu.lst to 
   root(hd0,0)
then shutdown, unplug hda and hdc disks, reboot. The BIOS now counts hdb as 
first disk,
booting from there. Now grub finds and boots the kernel. 


* MY THOUGHTS:  Though grub installation and menu.lst is correct, grub does not 
seem to
handle this situation of multiple disks correctly and misunderstands 'root 
(hd1,0)'.

-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger



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

Processed: Re: Bug#486541: grub problem with debian-installer

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 486541 grub-installer 1.32
Bug#486541: grub problem with debian-installer
Bug reassigned from package `installation-reports' to `grub-installer'.

> severity 486541 wishlist
Bug#486541: grub problem with debian-installer
Severity set to `wishlist' from `normal'

> tags 486541 wontfix
Bug#486541: grub problem with debian-installer
There were no tags set.
Tags added: wontfix

> retitle 486541 Grub fails after changing boot disk order in BIOS
Bug#486541: grub problem with debian-installer
Changed Bug title to `Grub fails after changing boot disk order in BIOS' from 
`grub problem with debian-installer'.

> 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#486541: grub problem with debian-installer

[Frans Pop]

reassign 486541 grub-installer 1.32
severity 486541 wishlist
tags 486541 wontfix
retitle 486541 Grub fails after changing boot disk order in BIOS
thanks

On Monday 16 June 2008, [EMAIL PROTECTED] wrote:
> Comments/Problems:
> * PROBLEM on first reboot: chosen in BIOS to boot from IDE1 (=hdb)

IMO this is not a Grub problem. You are effectively changing the order of 
your hard disks in the BIOS without telling the bootloader that you did 
so.

Your "workaround" is exactly the right solution for this.

I'm going to leave the report open, but doubt any further action will be 
taken on it.

Cheers,
FJP



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

Bug#486549: The single partition present on a CMS minidisk is not supported (s390/s390x only)

[Stephen Powell]

Package: partman-base
Version: 105

This bug applies only to the s390 and s390x architectures.

The single partition implicitly created on a z/VM minidisk by the CMS FORMAT 
command (and optionally, the CMS RESERVE command) is not recognized by partman. 
 mke2fs, mkswap, etc. recognize such a partition and are able to use it.  But 
partman does not.  I don't expect partman to be able to do anything with such a 
partition (such as create, move, resize, etc.) other than to recognize that it 
is there, delete it (if requested), optionally format it with mke2fs, mkswap, 
etc., if needed or requested, and to assign mount points to the partition 
(technically, to the file system on the partition, whether pre-existing or just 
created).

Note: partman should warn, if requested to delete such a partition, that if the 
partition is deleted it cannot be recreated again except by the CMS FORMAT 
command (and optionally, the CMS RESERVE command).


  



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

Re: klibc 1.5.10

[Pierre Habouzit]

On Mon, Jun 16, 2008 at 12:42:36AM +, maximilian attems wrote:
> hello,
> 
> please unblock klibc 1.5.10-1

done

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpr4Prc8AVTd.pgp
Description: PGP signature

Re: Testing transition for console-setup 1.24

[Pierre Habouzit]

On Sun, Jun 15, 2008 at 06:02:16PM +, Christian Perrier wrote:
> console-setup is currently frozen because it provides a udeb.
Done



-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp5C8zrhtrZM.pgp
Description: PGP signature

Processed: Re: Bug#486549: The single partition present on a CMS minidisk is not supported (s390/s390x only)

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> tag 486549 help
Bug#486549: The single partition present on a CMS minidisk is not supported 
(s390/s390x only)
There were no tags set.
Tags added: help

> severity 486549 wishlist
Bug#486549: The single partition present on a CMS minidisk is not supported 
(s390/s390x only)
Severity set to `wishlist' from `normal'

> 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#486549: The single partition present on a CMS minidisk is not supported (s390/s390x only)

[Frans Pop]

tag 486549 help
severity 486549 wishlist
thanks

On Monday 16 June 2008, Stephen Powell wrote:
> The single partition implicitly created on a z/VM minidisk by the CMS
> FORMAT command (and optionally, the CMS RESERVE command) is not
> recognized by partman.

Your request is no doubt completely valid, as is the one to extend zipl 
(#486526). However, you should be aware that the main challenge for the 
Debian s390 port is the current total lack of involvement from the 
s390-using community.

Effectively this probably means that unless you or someone else can 
motivate people who have an interest, the skills and access to hardware 
needed to implement the needed changes, it is very unlikely that any 
progress will be made. Therefore I'm tagging this bug report 'help'.

The Debian Installer team will of course be more than happy to help those 
people to get started and find their way in the D-I components and build 
system.

Cheers,
FJP


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

Bug#486558: installation-reports: strange (null) in URL for tasksel for automatic install

[Anders Andersson]

Package: installation-reports

Boot method: Netinstall CD (ISO)
Image version:
http://cdimage.debian.org/cdimage/lenny_di_beta2/i386/iso-cd/debian-LennyBeta2-i386-netinst.iso

Date: 2008-06-16
Machine: VirtualBox 1.6.2
Processor: Intel Core2 Quad Q9300 @ 2.5 GHz
Memory: 256MB
Partitions: root on 8GB /dev/hda1, swap on /dev/hda5

Output of lspci -nn and lspci -vnn:

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

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
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:  [E]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:

I tried the automatic install, and everything was fine until I got the 
following error: "Bad archive mirror".


Switching to console 4 with Alt-F4 I can see the following command 
trying to execute:

---
Jun 16 19:41:09 choose-mirror[29486]: DEBUG: command: wget -q 
http://ftp.debian.org(null)/dists/lenny/Release -O - | grep ^Suite: | 
cut -d' ' -f 2

---

If I test this in a new busybox console with a correct URL, without the 
'(null)' part, I can connect to the server and retreive a correct listing.




Hope this helps,
Anders



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

Re: Bug#486549: The single partition present on a CMS minidisk is not supported (s390/s390x only)

[Stephen Powell]

Thanks for your reply, Frans.  As for the enhancement requests for e2fsprogs 
and s390-tools to respect and support the RECOMP option of CMS minidisks, those 
are not distribution specific.  I would hope that they could be bumped 
upstream.  In theory, partman is not distribution-specific either, and, in 
theory, could also be bumped upstream.  However, if other distributions do not 
use partman in their installers or post-install packages, there may be little 
interest in the enhancement.

As for me, I am a z/VM Systems Programmer, I do have an interest, I do have 
some time, and I do have access to z/VM and mainframe hardware.  And I would be 
glad to assist you in testing.  What I don't have is expertise in C.  I can 
barely spell C.  My background is as a mainframe applications programmer and 
systems programmer, with IBM S390 assembler language programming skills, 
FORTRAN programming skills, and PL/I programming skills.  But C is another 
story.  So I can't code anything, probably, but I can serve as a resource for 
mainframe and z/VM information and I can probably help you test some things.  
Perhaps between the two of us we can work something out.

For what it's worth, the S390 Linux community is a vibrant one.  But most 
mainframe shops seem to run either Suse or Red Hat.  I'm playing around with 
Debian on S390 because that's what I run at home and that's what I know best.  
I'm going to be attending a class next week taught by IBM on how to install 
Linux on System z, and I'm sure that they will talk pretty much exclusively 
about Suse and Red Hat, both of which are commercial distributions and both of 
which are IBM "partners".  I've attended Linux for S390 install classes before, 
but it's been about five years and it's time for an update.  In the process of 
taking the class, I'm going to be privately trying to determine if there is any 
strategic advantage to those distros other than a support contract.

Let me know if there's anything I can do.


--- On Mon, 6/16/08, Frans Pop <[EMAIL PROTECTED]> wrote:

> From: Frans Pop <[EMAIL PROTECTED]>
> Subject: Re: Bug#486549: The single partition present on a CMS minidisk is 
> not supported (s390/s390x only)
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Date: Monday, June 16, 2008, 3:39 PM
> tag 486549 help
> severity 486549 wishlist
> thanks
> 
> On Monday 16 June 2008, Stephen Powell wrote:
> > The single partition implicitly created on a z/VM
> minidisk by the CMS
> > FORMAT command (and optionally, the CMS RESERVE
> command) is not
> > recognized by partman.
> 
> Your request is no doubt completely valid, as is the one to
> extend zipl 
> (#486526). However, you should be aware that the main
> challenge for the 
> Debian s390 port is the current total lack of involvement
> from the 
> s390-using community.
> 
> Effectively this probably means that unless you or someone
> else can 
> motivate people who have an interest, the skills and access
> to hardware 
> needed to implement the needed changes, it is very unlikely
> that any 
> progress will be made. Therefore I'm tagging this bug
> report 'help'.
> 
> The Debian Installer team will of course be more than happy
> to help those 
> people to get started and find their way in the D-I
> components and build 
> system.
> 
> Cheers,
> FJP


  


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

Processed: Re: Bug#480935: new syslinux floppy images

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 480935 rootskel-bootfloppy
Bug#480935: installationreport: floppy install 20080227 not working
Bug reassigned from package `syslinux' to `rootskel-bootfloppy'.

> retitle 480935 Explicit sanity checking needed for build-time problems?
Bug#480935: installationreport: floppy install 20080227 not working
Changed Bug title to `Explicit sanity checking needed for build-time problems?' 
from `installationreport: floppy install 20080227 not working'.

> tags 480935 - d-i
Bug#480935: Explicit sanity checking needed for build-time problems?
Tags were: d-i
Tags removed: d-i

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

Re: Bug#480935: new syslinux floppy images

[Frans Pop]

reassign 480935 rootskel-bootfloppy
retitle 480935 Explicit sanity checking needed for build-time problems?
tags 480935 - d-i
thanks

On Monday 16 June 2008, Holger Wansing wrote:
> > Holger: at least this means you can now test if the new syslinux
> > solves your boot problem; please try both the boot_* images in
> > floppy-2.6.24.
>
> I tried the boot images from
> http://people.debian.org/~fjp/tmp/d-i/floppy/.
>
> The 2.6.24 boot floppies (syslinux 3.63 and 3.70) worked well.
> Both behaved the same:
>   Loading linux - Success
>   Loading initrd - Success
>   Then was prompted for root floppy

OK. As it is unlikely that syslinux 3.63+dfsg-2 changed anything here the 
fact that _both_ images work for you means that this probably never was a 
syslinux problem after all, but more likely a klibc/rootskel mismatch or 
something similar.

Maybe we need to tighten version checks here and, if possible, code some 
explicit errors if things do not match. I also saw during my own tests 
today that things can fail rather badly and possibly too silently when 
there are mismatches.

Reassigning to rootskel-bootfloppy as that is the central component here.

Thanks for your testing. Also thanks to Daniel Baumann for his assistance 
with this issue, but then he did get some useful testing of the syslinux 
version in experimental out of it :-)

Cheers,
FJP


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

Bug#486558: installation-reports: strange (null) in URL for tasksel for automatic install

[Frans Pop]

reassign 486558 choose-mirror 2.24
severity 486558 important
tags 486558 confirmed
thanks

Thanks for the report.

On Monday 16 June 2008, Anders Andersson wrote:
> Comments/Problems:
> I tried the automatic install, and everything was fine until I got the
> following error: "Bad archive mirror".
>
> Switching to console 4 with Alt-F4 I can see the following command
> trying to execute:
> Jun 16 19:41:09 choose-mirror[29486]: DEBUG: command: wget -q
> http://ftp.debian.org(null)/dists/lenny/Release -O - | grep ^Suite: |
> cut -d' ' -f 2
>
> If I test this in a new busybox console with a correct URL, without the
> '(null)' part, I can connect to the server and retreive a correct
> listing.

I remember seeing a report about this before. I think I've now figured out 
what is going wrong.

There are two things interacting here.

Because we're running at critical priority, the country mirror list is 
never actually displayed and thus mirror/http/mirror never gets a value; 
it does have a default value: ftp.debian.org
This is in fact a very bad default as ftp.d.o only carries i386/amd64.

I wonder if we should set the first value of the country list as the 
selected value here. In most cases this will be a better "default" than 
the default at http/mirror, even if that's changed from ftp.d.o. 

We then get to validate_mirror(), which gets the "selected" mirror 
(ftp.d.o) and next calls 'mirror_root(mirror)'. The return value of that 
is set as directory. This must be the function that returns the "(null)" 
value and causes the incorrect wget later.

The cause for the null value seems to be that the entry for ftp.d.o in the 
mirror master list looks like this:
Site: ftp.debian.org
Alias: saens.debian.org
Alias: debian-mirror.cs.umn.edu
Type: Push-Primary
Archive-architecture: amd64 i386
X-Archive-http: /debian/
X-Archive-ftp: /debian/

The last two lines should not have the "X-" prefix! Essentially ftp.d.o 
does not have a "mirror_root" defined in the master list.

I'd appreciate some input how to deal with this and also if the needed 
changes could be made by someone with more C skills than I have.

Cheers,
FJP


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

Processed: Re: Bug#486558: installation-reports: strange (null) in URL for tasksel for automatic install

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 486558 choose-mirror 2.24
Bug#486558: installation-reports: strange (null) in URL for tasksel for 
automatic install
Bug reassigned from package `installation-reports' to `choose-mirror'.

> severity 486558 important
Bug#486558: installation-reports: strange (null) in URL for tasksel for 
automatic install
Severity set to `important' from `normal'

> tags 486558 confirmed
Bug#486558: installation-reports: strange (null) in URL for tasksel for 
automatic install
There were no tags set.
Tags added: confirmed

> 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#484121: tasksel: let's sync on the GNOME task

[Joey Hess]

Eric Dorland wrote:
> Well I think Google generally does treat the Iceweasel user agent
> properly.

Not in the case of maps.google.com, where the sidebar cannot be hidden
in iceweasel, can in firefox.

> > I'm afraid that documenting it in README.Debian won't help desktop users
> > who just find that this strange "iceweasel" browser we install by
> > default doesn't work on sites that firefox works on.
> 
> Could we do it in a more prominent perhaps?  

FWIW, I got from the README.Debian to #354622, but I was unable to from
there figure out how to quickly and easily change the user agent.

A more prominent thing might be a hyperlink directly to the relevant
about:config setting from the default start page .. or a pre-installed
user agent switcher that has firefox in it as an option. I think that
something like that would go a certian distance to making it accessible
to users, though it would still be a bother.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Considerations for lilo removal

[Brian May]

Frans Pop wrote:
AFAIK grub (at least the default "legacy" version) also still has problems 
with / on XFS. That's the one other case where D-I automatically falls 
back to lilo.
  

I think you mean /boot on XFS. Having / as XFS seems to work fine for me...

Brian May


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