* Mike Bird
| FWIW, adding "-9" to the gzip in mkinitramfs gives a
| 0.5% saving, which may help with some marginal cases.
Re-adding -9 to the update-initramfs call makes update-initramfs take
about three times as long to run on this system, so at least I would
rather not have that switched on b
On Tue, Jun 17, 2008 at 3:36 AM, Martin Meredith <[EMAIL PROTECTED]> wrote:
> Any thoughts?
Not sure if dak/buildds can handle this, but what about multiple
source packages?
Something like unrar-nonfree-64 producing rar binary package for amd64
and unrar-nonfree-32 producing rar binary package f
* William Pitcock:
> 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
> where a grave bug (bug #479607) is unlikely fixable without severe
> refactoring of the codebase.
BTW, the bug report lacks this infor
I am Barrister John Benson from The United Kingdom. I was given your contact by
my late client, Dr. Maurice Wohl. Please get back to me as soon as possible. I
have an important message for you.
Regards,
Barrister John Benson
John Benson Chambers, Liverpool.
Email:[EMAIL PROTECTED]
Phone:+44-
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 t
On Monday 16 June 2008 22:58:34 Mike Bird wrote:
> OTOH using bzip2 instead of gzip saves 10.5% but I have
> no idea how much work it would take to support bzip'd
> initrd's.
If you need to change gzip to $another_compressor, I would go lzma, it
compresses better than gzip and the kernel module
Hi,
On Tue, Jun 17, 2008 at 12:35:57AM +0200, Sladi wrote:
> I want to try xf4vnc but compiling (make install) the xserver fails
> because it won't find pixman.h. All other parts compile fine though.
> (http://xf4vnc.sourceforge.net/modular.html)
>
> I use Debian Lenny AMD64 and the file is in
Hi,
I want to try xf4vnc but compiling (make install) the xserver fails
because it won't find pixman.h. All other parts compile fine though.
(http://xf4vnc.sourceforge.net/modular.html)
I use Debian Lenny AMD64 and the file is installed in
"/usr/include/pixman-1/pixman.h"
(http://packages.d
William Pitcock wrote:
> * Cope with the growing initramfs issue as best we can, e.g. by
> displaying a warning to the user that the kernel may not be bootable by
> lilo due to the 8MiB boundry in liloconfig.
Having only a warning is not sufficient for the use of lilo in new
installations! We rea
Hi,
I looked for you on Reunion.com, but you weren't there. Please connect with me
so we can keep in touch.
-Kathy
Do You Know Kathy?
YES - Connect with Kathy, and see who's searching for you
http://www.reunion.com/showInviteRegistration.do?uid=265213543
NO - I don't know Kathy
http://www.reunio
Hi,
On Mon, 2008-06-16 at 13:58 -0700, Mike Bird wrote:
> FWIW, adding "-9" to the gzip in mkinitramfs gives a
> 0.5% saving, which may help with some marginal cases.
>
> OTOH using bzip2 instead of gzip saves 10.5% but I have
> no idea how much work it would take to support bzip'd
> initrd's.
>
FWIW, adding "-9" to the gzip in mkinitramfs gives a
0.5% saving, which may help with some marginal cases.
OTOH using bzip2 instead of gzip saves 10.5% but I have
no idea how much work it would take to support bzip'd
initrd's.
--Mike Bird
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a su
On Mon, Jun 16, 2008 at 11:12:53AM -0400, David Duggins wrote:
> I would also have to say that the Linux Community has always been about
> freedom and choice.
Not everyone agrees[1] about the choice part.
Having one well working tool is better than having multiple mediocre,
buggy tools to choose
Hi Martin,
Thanks for replying.
Martin Pitt wrote:
> esound should *so much* die completely. It has very poor sound quality
> (huge A/V desync when playing videos, etc.), very poor code quality
> (it causes complete desktop locks very often, due to not being thread
> safe), and is abandoned upstr
Hi,
On Mon, 2008-06-16 at 00:31 -0500, William Pitcock wrote:
> [a lot of stuff]
As many people have brought up usecases not covered by alternatives, the
plan seems to be:
* Cope with the growing initramfs issue as best we can, e.g. by
displaying a warning to the user that the kernel may not be
Hi there.
I currently maintain rar and unrar-nonfree in debian.
When uscanning for the latest version of rar - it started to download
the x64 version, which I haven't seen before.
Anyway - It seems that upstream are now packaging a i386 binary, and an
x64 binary.
I'm not too sure how I should h
I would also have to say that the Linux Community has always been about
freedom and choice. Although I use GRUB my self, why should we remove a
useful package that is being used? Wouldn't that take away from the
freedom just a bit? Just because you might not like it, or like another
program
William Pitcock wrote:
> Hi,
>
> 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
> where a grave bug (bug #479607) is unlikely fixable without severe
> refactoring of the codebase.
Well, grub is also not
I demand that Frans Pop may or may not have written...
> William Pitcock wrote:
[snip]
>> 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 installa
Francesco P. Lovergine writes:
> I had at least a couple of boxes in the past where grub were problematic
> and I used the old good linux loader.
When I installed Lenny on this AMD64 box (ASUS A8V-XE) a few weeks ago Grub
was unable to boot it. I had to go back and reinstall, selecting Lilo.
--
On Mon, Jun 16, 2008 at 11:54:52AM +0300, Shachar Shemesh wrote:
> Lilo has one killer feature that is totally missing from GRUB - the -R
> option. It allows me to upgrade a kernel on remote servers, knowing that
> if the upgrade fails, I will get the original kernel after a few minutes
> withou
On Mon, Jun 16, 2008 at 12:31:49AM -0500, William Pitcock wrote:
>
> If we do not need lilo, then I will file a RM bug in the next couple of
> weeks.
>
I had at least a couple of boxes in the past where grub were problematic
and I used the old good linux loader. I generally agree that grub is
m
Michael Banck wrote:
> On Mon, Jun 16, 2008 at 11:03:10AM +0200, Goswin von Brederlow wrote:
>> I don't really see this as a bug, certainly not as grave. The problem
>> seems to be that lilo simply can't handle large images and the default
>> ramdisk just has now hit that limit on amd64.
>
> So it
Mike Hommey <[EMAIL PROTECTED]> writes:
> On Mon, Jun 16, 2008 at 10:53:22AM +0200, Goswin von Brederlow wrote:
>> Mike Hommey <[EMAIL PROTECTED]> writes:
>>
>> > On Mon, Jun 16, 2008 at 02:27:11AM -0500, William Pitcock wrote:
>> >> Hi,
>> >>
>> >> On Mon, 2008-06-16 at 07:20 +, Sune Vuorel
Package: wnpp
Severity: wishlist
Owner: Teemu Ikonen <[EMAIL PROTECTED]>
* Package name: peak-linux-driver
Version : 6.7
Upstream Author : PEAK System-Technik GmbH <[EMAIL PROTECTED]>
* URL : http://www.peak-system.com/linux/
* License : GPL-2+
Programming La
> That doesn't strike me as a valid configuration. Infact,
> it shouldn't work with lilo because lilo wants /boot to be
> on a real device. The fact that it does should be
> considered a bug, not a feature.
Valid or not, the installer actually gives you lilo if you
configure the partitions this wa
(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 cu
Le Monday 16 June 2008 12:03:09 Michael Banck, vous avez écrit :
> > On some of my boxes all filesystems are on LVMs and the Debian installer
> > used lilo to boot the systems. It would be nice if these systems can
> > still be used with future Debian versions. Please remove lilo only if
> > there'
On Mon, Jun 16, 2008 at 11:03:10AM +0200, Goswin von Brederlow wrote:
> I don't really see this as a bug, certainly not as grave. The problem
> seems to be that lilo simply can't handle large images and the default
> ramdisk just has now hit that limit on amd64.
So it's broken on amd64 for the st
(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
On Mon, Jun 16, 2008 at 09:37:34AM +0200, Joerg Platte wrote:
> Am Montag, 16. Juni 2008 schrieb William Pitcock:
> Hi,
>
> > That patch only makes lilo map LVMs to an appropriate physical device.
> > It does not guarantee that you will be able to boot off of an LV on a
> > physical volume. As suc
Hello Paul and *,
Unfortunately I have found your message very late...
Let us begin:
Am 2008-03-30 21:51:14, schrieb Paul Wise:
> If you are using Debian on your phone, embedded computer, laptop,
> desktop, server, network, telecommunications equipment or other part of
> your information infrast
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 no
Hi,
On Mon, 2008-06-16 at 19:27 +1000, Alexander Zangerl wrote:
> please don't remove lilo.
It certaintly won't be happening in lenny. This may be revisited in
lenny+1 though.
William
signature.asc
Description: This is a digitally signed message part
-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
William Pitcock <[EMAIL PROTECTED]> writes:
> 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.
Deb
On Mon, 16 Jun 2008 11:19:03 +0200, Mike Hommey writes:
>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
Hallo Bernhard,
Bernhard R. Link <[EMAIL PROTECTED]> wrote:
> * Martin Pitt <[EMAIL PROTECTED]> [080612 18:04]:
>> after many years of calling our CUPS package "cupsys" it has finally
>> be renamed to the proper upstream name "cups", including init scripts,
>> library packages, etc. This makes us
On Mon, Jun 16, 2008 at 10:55:47AM +0200, Guus Sliepen wrote:
> On Mon, Jun 16, 2008 at 03:08:02AM +0300, Peter Pentchev wrote:
>
> > * Package name: bomstrip
> > Programming Lang: Awk, Brainf*ck, C, C++, Forth, Haskell, OCaml, Ook!,
> > Pascal, PHP, Perl, PostScript, Pyt
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 the
On Mon, Jun 16, 2008 at 10:53:22AM +0200, Goswin von Brederlow wrote:
> Mike Hommey <[EMAIL PROTECTED]> writes:
>
> > On Mon, Jun 16, 2008 at 02:27:11AM -0500, William Pitcock wrote:
> >> Hi,
> >>
> >> On Mon, 2008-06-16 at 07:20 +, Sune Vuorela wrote:
> >> > On 2008-06-16, William Pitcock <[
On Mon, Jun 16, 2008 at 03:08:02AM +0300, Peter Pentchev wrote:
> * Package name: bomstrip
> Programming Lang: Awk, Brainf*ck, C, C++, Forth, Haskell, OCaml, Ook!,
> Pascal, PHP, Perl, PostScript, Python, Ruby, sed,
> Unlambda
All these programming lang
On Mon, Jun 16, 2008 at 11:04:35AM +0200, Mike Hommey wrote:
> On Mon, Jun 16, 2008 at 11:54:52AM +0300, Shachar Shemesh wrote:
> >>
> > Lilo has one killer feature that is totally missing from GRUB - the -R
> > option. It allows me to upgrade a kernel on remote servers, knowing that
> > if
On Mon, Jun 16, 2008 at 11:54:52AM +0300, Shachar Shemesh wrote:
> William Pitcock wrote:
>>
>> It seems like moving to grub for everything may be a good choice on the
>> archs where lilo is used.
>>
> Lilo has one killer feature that is totally missing from GRUB - the -R
> option. It allows m
William Pitcock <[EMAIL PROTECTED]> writes:
> Hi,
>
> 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
> where a grave bug (bug #479607) is unlikely fixable without severe
> refactoring of the codebase.
I d
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
William Pitcock wrote:
It seems like moving to grub for everything may be a good choice on the
archs where lilo is used.
Lilo has one killer feature that is totally missing from GRUB - the -R
option. It allows me to upgrade a kernel on remote servers, knowing that
if the upgrade fails, I wi
Mike Hommey <[EMAIL PROTECTED]> writes:
> On Mon, Jun 16, 2008 at 02:27:11AM -0500, William Pitcock wrote:
>> Hi,
>>
>> On Mon, 2008-06-16 at 07:20 +, Sune Vuorela wrote:
>> > On 2008-06-16, William Pitcock <[EMAIL PROTECTED]> wrote:
>> > > That doesn't strike me as a valid configuration. Inf
Am Montag, 16. Juni 2008 schrieb William Pitcock:
Hi,
> That patch only makes lilo map LVMs to an appropriate physical device.
> It does not guarantee that you will be able to boot off of an LV on a
> physical volume. As such, the behaviour is still undefined.
>
> Consider a situation where /boot
On Mon, Jun 16, 2008 at 02:27:11AM -0500, William Pitcock wrote:
> Hi,
>
> On Mon, 2008-06-16 at 07:20 +, Sune Vuorela wrote:
> > On 2008-06-16, William Pitcock <[EMAIL PROTECTED]> wrote:
> > > That doesn't strike me as a valid configuration. Infact, it shouldn't
> > > work with lilo because l
On 2008-06-16, William Pitcock <[EMAIL PROTECTED]> wrote:
> That patch only makes lilo map LVMs to an appropriate physical device.
> It does not guarantee that you will be able to boot off of an LV on a
> physical volume. As such, the behaviour is still undefined.
>
> Consider a situation where /bo
Hi,
On Mon, 2008-06-16 at 07:20 +, Sune Vuorela wrote:
> On 2008-06-16, William Pitcock <[EMAIL PROTECTED]> wrote:
> > That doesn't strike me as a valid configuration. Infact, it shouldn't
> > work with lilo because lilo wants /boot to be on a real device. The fact
> > that it does should be c
On 2008-06-16, William Pitcock <[EMAIL PROTECTED]> wrote:
> That doesn't strike me as a valid configuration. Infact, it shouldn't
> work with lilo because lilo wants /boot to be on a real device. The fact
> that it does should be considered a bug, not a feature.
lilo-22.8$ head debian/patches/01_d
Hi,
On Mon, 2008-06-16 at 09:08 +0200, Romain Beauxis wrote:
> Le Monday 16 June 2008 07:31:49 William Pitcock, vous avez écrit :
> > 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 syst
Le Monday 16 June 2008 07:31:49 William Pitcock, vous avez écrit :
> 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
55 matches
Mail list logo
