Re: Considerations for lilo removal
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 had since Woody. I have lilo for the systems where I want /boot to be on LVM. What would you do for those installs ? Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
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 systems I have that are still on lilo are installations of > > Debian I have had since Woody. > > I have lilo for the systems where I want /boot to be on LVM. > What would you do for those installs ? > 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. William signature.asc Description: This is a digitally signed message part
Re: Considerations for lilo removal
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_devmapper.dpatch #! /bin/sh -e ## ## All lines beginning with `## DP:' are a description of the patch. ## DP: Patch to make lilo understand device-mapper block devices. ## DP: Bug#229932 I also like and use this feature. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
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 considered a bug, not a feature. > > lilo-22.8$ head debian/patches/01_devmapper.dpatch > #! /bin/sh -e > ## > ## All lines beginning with `## DP:' are a description of the patch. > ## DP: Patch to make lilo understand device-mapper block devices. > ## DP: Bug#229932 > 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 spans multiple PVs, and you will see lilo fail to boot the system correctly. If /boot happens to be on a single PV, then it will work, but it is still not guaranteed. William signature.asc Description: This is a digitally signed message part
Re: Considerations for lilo removal
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 /boot spans multiple PVs, and you will see > lilo fail to boot the system correctly. > > If /boot happens to be on a single PV, then it will work, but it is > still not guaranteed. I think most lvm configurations are this way, so it works for most people using lvm && lilo. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
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 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_devmapper.dpatch > > #! /bin/sh -e > > ## > > ## All lines beginning with `## DP:' are a description of the patch. > > ## DP: Patch to make lilo understand device-mapper block devices. > > ## DP: Bug#229932 > > > > 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 spans multiple PVs, and you will see > lilo fail to boot the system correctly. > > If /boot happens to be on a single PV, then it will work, but it is > still not guaranteed. Il will only work if all extents containing initramfs and kernel are contiguous and ordered on the physical volume. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
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 spans multiple PVs, and you will see > lilo fail to boot the system correctly. > > If /boot happens to be on a single PV, then it will work, but it is > still not guaranteed. 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's a full replacement available. regards, Jörg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
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. 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_devmapper.dpatch >> > #! /bin/sh -e >> > ## >> > ## All lines beginning with `## DP:' are a description of the patch. >> > ## DP: Patch to make lilo understand device-mapper block devices. >> > ## DP: Bug#229932 >> > >> >> 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 spans multiple PVs, and you will see >> lilo fail to boot the system correctly. >> >> If /boot happens to be on a single PV, then it will work, but it is >> still not guaranteed. > > Il will only work if all extents containing initramfs and kernel are > contiguous and ordered on the physical volume. > > Mike Why? Lilo looks up the block addresses of the file on the disk. Having the LV fragmented into several segments is no different from having the file fragmented in the filesystem. Having /boot be on a single PV, preferably the one with the bootblock should be totally sufficient. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
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 will get the original kernel after a few minutes without asking a local hand to push the reset button. Until Grub has something similar, removing Lilo entirely seems like a bad idea to me. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
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.
Re: Considerations for lilo removal
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 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. The only bug there is imho is that the condition does not get detected and reported properly (patched lilo shoud be on mentors). The simple solution to is to not stuff so many modules into the initramfs. Using only needed modules reduces my initramfs by a factor of 3. So there is still a big margin for growth. And there are systems where grub simply doesn't work for some screwed up reason or another and a lot of people that prefer it. Removing it just because it has an avoidable size limit seems like a bad idea. > 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. > > It seems like moving to grub for everything may be a good choice on the > archs where lilo is used. > > If we do not need lilo, then I will file a RM bug in the next couple of > weeks. > > William MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
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 me to upgrade a kernel on remote servers, knowing that > if the upgrade fails, I will get the original kernel after a few minutes > without asking a local hand to push the reset button. > > Until Grub has something similar, removing Lilo entirely seems like a > bad idea to me. grub> savedefault --default=2 --once Now, maybe debian just needs a nice wrapper around this. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
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 the upgrade fails, I will get the original kernel after a few minutes > > without asking a local hand to push the reset button. > > grub> savedefault --default=2 --once > > Now, maybe debian just needs a nice wrapper around this. grub-reboot 2 -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#486425: ITP: bomstrip -- strip Byte-Order Marks from UTF-8 text files
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 languages got me wondering. Apparently the same program is implemented in all these languages. But you only need one to get the desired functionality. Also, I see the sed variant is just a one-liner. Perhaps it is better if this functionality is merged with a package like coreutils or recode, if it is not already there someway. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Considerations for lilo removal
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 <[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_devmapper.dpatch > >> > #! /bin/sh -e > >> > ## > >> > ## All lines beginning with `## DP:' are a description of the patch. > >> > ## DP: Patch to make lilo understand device-mapper block devices. > >> > ## DP: Bug#229932 > >> > > >> > >> 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 spans multiple PVs, and you will see > >> lilo fail to boot the system correctly. > >> > >> If /boot happens to be on a single PV, then it will work, but it is > >> still not guaranteed. > > > > Il will only work if all extents containing initramfs and kernel are > > contiguous and ordered on the physical volume. > > > > Mike > > Why? Lilo looks up the block addresses of the file on the disk. Having > the LV fragmented into several segments is no different from having > the file fragmented in the filesystem. AFAIK, lilo only stores the start of initrd and kernel images in CHS form. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
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: Bug#486425: ITP: bomstrip -- strip Byte-Order Marks from UTF-8 text files
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, Python, Ruby, sed, > > Unlambda > > All these programming languages got me wondering. Apparently the same > program is implemented in all these languages. But you only need one to > get the desired functionality. Also, I see the sed variant is just a > one-liner. Perhaps it is better if this functionality is merged with a > package like coreutils or recode, if it is not already there someway. As the author writes on his website, the whole point of the bomstrip project being a collection of implementations is more of a social / political goal of "spreading the word", showing how easy it is, bringing attention to the broken UTF-8 text files that some programs generate, and so on. IMHO, the distribution also servers as a nice way to demonstrate a simple (well, admittedly, a *very* simple :)) task done in various languages. Hm. Okay, so maybe the two command-line utilities and the collection might be separated. IMHO, the collection *is* still useful on its own :) If others share this opinion, I may either create two separate packages, or just remove the command-line utilities and file a wishlist bug against coreutils or textutils or something like that. How does that strike you? What do others think? G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Do you think anybody has ever had *precisely this thought* before? pgpxEyG93VM0B.pgp Description: PGP signature
Re: "cupsys" renamed to "cups", please adjust your (build-)depends
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 compatible again with all the >> upstream documentation out there, unbreaks the LSB printer driver >> packages from openprinting.org, reduces confusion with users, and >> finally makes the libraries Policy compliant (SONAME == package name). >> Please see http://bugs.debian.org/482296 for details. > > How about using this transition to move some binaries between package > boundaries? Especially having some programs with generic names in -client and > some in -bsd seem to be a problem for some users (like #405827). > > I do not think having lp and lpr in different packages can cause any > good (and the same for lprm and cancel and so on). But lpr and lprm aren't commands mentioned in the POSIX standard. The POSIX standard knows only the lp command. Schöne Grüße, Jörg. -- > Definiere ‚Demokratie‘ … … eine Mehrheit beweist einer Minderheit, dass Widerstand zwecklos ist. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
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 on the bug report shows the same. > >OTOH, aren't most of these choosing lilo over grub only doing so by >habit ? no. i for one detest grub, wholeheartedly. please don't remove lilo. regards az -- + Alexander Zangerl + DSA 42BD645D + (RSA 5B586291) So what if I have a fertile brain? Fertilizer happens. -- Larry Wall signature.asc Description: Digital Signature
Re: Considerations for lilo removal
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. Debian Etch installs lilo without choice if XFS is used, so there should be a number of systems still using lilo for good reason. > If we do not need lilo, then I will file a RM bug in the next couple of > weeks. i still prefer lilo for systems on raid1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
-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
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
Re: Considerations for lilo removal
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: bits/news from the users of Debian?
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 infrastructure, I'd love to hear from you. I am using Debian ARM === 1) on a selfmade table PC which is currently ARM1136 based but will switch to ARM1176 based one with 600MHz from Freescale or Samsung. 2) on 4 embedded System using the NXP LH7A4xx (ARM922T based) which control my Toaster, my Bakeoven, a Solarcharger and a 24V DC Power- Distribution Systel SPARC = 1) eigth SS10/512 2) three SS20 3) one U20 i386 1) Workstat.: VIA EPIA LN1EAG 2) Laptop 1: IBM ThinkPad 570 (with working Lucen WinModem) 3) Laptop 2: Acer Aspire 1350 Servers running on VIA EPIA LN1EAG with 1GByte of memory: 4) Server 1: nfs-kernel-server, apache2, php5 5) Server 2: courier, procmail, fetchmail, spamassassin, clamav-ng 6) Server 3:postgresql 7) Server 4: POT, ISDN, ADSL, SDSL, SkyDSL, GSM/GPRS/EDGE/UMTS/HSDPA 8) Server 5: cups 9) Server 6: syslog-ng 10) Server 7: apache2, php5, amd64 = 1) Develstat.: Dual Opteron 280Running Xen with Sarge, Etch, Lenny and Sid > When replying, tell me anything you want to, but if you can't think of > anything, here are some ideas to get you started: > > What are you using Debian for? Office, Server, Development > Do you have a project (big or small) made with Debian you'd like to show > off? Even if you think its trivial or uninteresting, we want to hear > about it! Using Debian for keeping track of your socks might seem > uninteresting to you, but... Since end of 2007 I am switchingmore or less back to my "Electronic Engineer" and develop hardware which does not need ANY proprietary software. My OWN requirement is: "Developing Hardware which fit the DFSG." No Software outside of "main" required since all my own software is under GNU GPL version 3. > What cool package(s) are you using? Did you > buy a beverage for a Debian contributor at DebConf? Are you using > packages from a general area of Debian (science, games, development, > servers)? What about Debian do you think needs changing - do you have > any specific gripes? In the last years Debian tend to support mor in more Gnome and KDE apps and droping support for Non-Bloat-Ware installations which make Debian more in more uninstallable without recompiling tonns of packages. > Is there a specific package that needs to be > maintained better? One of the packages is "gksu" which now (since Etch) sucks OVER 50 MByte of useless packages. > Do you have the popularity-contest package installed > and working? If not, why not? Yes on all of my machines... Since I build my OWN Debian-Install-CDs with only Packages I use (arround 1056 total plus -dev packages) it is a "must". to get my own packages pushed into "lower" CD-Numbers... ;-) Note: I have Build three 650 MByte CD's for ARM, i386 and amd64 and all three CD's have left many space for further packages... But I have my OWN Debian mirror @home and normaly use only the Debian-Net-Install-CD. > Are you missing certain packages that are > not available in Debian, were removed from Debian or are not available > in the last stable release (etch)? Why are you using Debian rather than > RHEL/Fedora/CentOS, Gentoo, Ubuntu, MacOS or Windows (or the other way > around)? DFSG !!! Note 1: Several times I have complaint about missing documentation and forgotten, I do not use "contrib" and "non-free". ;-) Note 2: I am rewriting (since two years) "bash-doc"... > Are you making a living using or customising or deploying > Debian? Yes, I am Debian GNU/Linux Consultant in Strasbourg and Linux-Developer. > What are your plans for using Debian in the future? Make it better. After geting a new Appartement or something like this I will continue to work on my own software and enhancements and like to see some of it in Debian and of course, becoming a "Debian Maintainer" at least for my own packages... > Did your > Debian wishlist for 2007 come true? Yesno... Yes: Debian is better then before No: Debian force users to much into bloatware (KDE/GNOME) which IS GOOD for BEGINNERS but not professionels... > What is your Debian wishlist for > 2008? Building Dual-Packages 1) 2) -bloatwaresupport e.g. 1) gksu 2) gksu-gnome > What does Debian mean to you? Mostly: "Freedom total" > In what ways do you or do you intend > to contribute to Debian and free software in general? 1) Coding Add-Ons/Plugins 2) create enhancements to existing software. 3) writ
Re: Considerations for lilo removal
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 such, the behaviour is still undefined. > > > > Consider a situation where /boot spans multiple PVs, and you will see > > lilo fail to boot the system correctly. > > > > If /boot happens to be on a single PV, then it will work, but it is > > still not guaranteed. > > 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's a full > replacement available. Lilo is already removed from testing and will not be in lenny until somebody steps up and cares for it. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
(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
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 stock Debian kernel, AIUI. Looks like a grave bug to me. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
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's a full replacement available. > > Lilo is already removed from testing and will not be in lenny until > somebody steps up and cares for it. Really that is not serious. The RC bug is a side effect as explained before, and just for that the package is removed while it is still part of the installer and very important to *many* users, without even communicating about it. I'm really disapointed of such a irresponsive behaviour. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
(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: Re: Considerations for lilo removal
> 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 way (in non-expert mode at least) without prompts, so many people will have this configuration and lilo without being aware that it is invalid. A proper migration away from lilo is necessary, rather than just dropping it. -- Jon Dowland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#486470: ITP: peak-linux-driver -- PEAK-System CAN-bus interface driver source
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 Lang: C Description : PEAK-System CAN-bus interface driver source This package provides the kernel driver source code for CAN-bus interface products from PEAK-System. These allow communication with the Controller Area Network through standard PC-buses, such as USB, PCI etc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
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 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 considered a bug, not a feature. >> >> > >> >> > lilo-22.8$ head debian/patches/01_devmapper.dpatch >> >> > #! /bin/sh -e >> >> > ## >> >> > ## All lines beginning with `## DP:' are a description of the patch. >> >> > ## DP: Patch to make lilo understand device-mapper block devices. >> >> > ## DP: Bug#229932 >> >> > >> >> >> >> 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 spans multiple PVs, and you will see >> >> lilo fail to boot the system correctly. >> >> >> >> If /boot happens to be on a single PV, then it will work, but it is >> >> still not guaranteed. >> > >> > Il will only work if all extents containing initramfs and kernel are >> > contiguous and ordered on the physical volume. >> > >> > Mike >> >> Why? Lilo looks up the block addresses of the file on the disk. Having >> the LV fragmented into several segments is no different from having >> the file fragmented in the filesystem. > > AFAIK, lilo only stores the start of initrd and kernel images in CHS > form. > > Mike That would require them to be continious and they often aren't. Afaik lilo stores an array of extents (location, size). The number of extens is limited but certainly > 1. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
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's broken on amd64 for the stock Debian kernel, AIUI. > Looks like a grave bug to me. It also means that it is not broken for testing as that has 2.6.24. And it means that it is not broken for i386 users. Sounds to me that it is still useful for most users, so severity important, not RC. Especially given that it is not the default bootloader. You can argue this from various sides, but IMO a removal from testing was very much the wrong action to take by RMs. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Considerations for lilo removal
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 more flexible and generally useful but I would retain lilo as an optional package at least. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
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 > without asking a local hand to push the reset button. > > Until Grub has something similar, removing Lilo entirely seems like a > bad idea to me. grub does have that. man grub-reboot. Boot a specific entry next time but only once. I think it is a debian specific patch and not a generic grub feature. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
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. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
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 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.
FWIW, I use lilo, and I have no plans to change that. I'm not seeing any
problems with it, but then the installed kernels are all locally built and
don't use init{rd,ramfs}.
--
| Darren Salt| linux or ds at | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Buy local produce. Try to walk or cycle. TRANSPORT CAUSES GLOBAL WARMING.
A memorandum is written not to inform the reader, but to protect the writer.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
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 free of bugs, all my partitions are usually reiserfs and on a hard reset grub stupidly comes up with "GRUB Error 16: Inconsistent filesystem structure". You might see it differently, by in my opinion this is a grave bug as well. So why not also to remove grub ;) Sorry, I don't know if there is a debian bug report, the ubuntu bug description is here: https://bugs.launchpad.net/grub/+bug/64928 > > 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. I still use lilo on all of my systems. > > It seems like moving to grub for everything may be a good choice on the > archs where lilo is used. > > If we do not need lilo, then I will file a RM bug in the next couple of > weeks. Next problem with grub, grub can't read links, but always needs to update the menu.lst. In my previous work group we have a laptop chroot for updates. We then rsync from this chroot to the laptops and as last step only call 'lilo' to update to the recent kernel. For some laptops there are exceptions, however, and not the generic kernel is installed. With simple links and calling lilo these exceptions can be easily handled, with grubs menu.lst this would required full parsing of that file - the script probably would be 10x larger only for this stupid menu.lst parsing. So I quite disagree to remove lilo. Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
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 better, we shouldn't force our preferences on people. GRUB and LILO fall into the category of Gnome vs. KDEeverybody has an opinion on what they like best. It doesn't nessicarily mean that one is really that much better than the other. David Bernd Schubert wrote: 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 free of bugs, all my partitions are usually reiserfs and on a hard reset grub stupidly comes up with "GRUB Error 16: Inconsistent filesystem structure". You might see it differently, by in my opinion this is a grave bug as well. So why not also to remove grub ;) Sorry, I don't know if there is a debian bug report, the ubuntu bug description is here: https://bugs.launchpad.net/grub/+bug/64928 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. I still use lilo on all of my systems. It seems like moving to grub for everything may be a good choice on the archs where lilo is used. If we do not need lilo, then I will file a RM bug in the next couple of weeks. Next problem with grub, grub can't read links, but always needs to update the menu.lst. In my previous work group we have a laptop chroot for updates. We then rsync from this chroot to the laptops and as last step only call 'lilo' to update to the recent kernel. For some laptops there are exceptions, however, and not the generic kernel is installed. With simple links and calling lilo these exceptions can be easily handled, with grubs menu.lst this would required full parsing of that file - the script probably would be 10x larger only for this stupid menu.lst parsing. So I quite disagree to remove lilo. Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Non-free question regarding upstream releasing different binary-only tarballs for different architectures
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 handle this, currently - I've been using ia32-libs for x64... but with the new tarball, I don't know if I can do this. I'm also pretty sure that the licence doesn't let me do a "tarball-in-tarball" thing (orig.tar.gz has to stay the same) Any thoughts? signature.asc Description: This is a digitally signed message part
Re: Considerations for lilo removal
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 bootable by lilo due to the 8MiB boundry in liloconfig. An upload is already prepared to do exactly this, and is pending a merge with some translation updates which have not all been received yet. At that point, an upload will hit incoming and a fixed lilo will hit Debian in time for Lenny's freeze (whenever that may be). On another note, if you want to improve the translations for lilo in Lenny, you have 4 days to get them into the upload that will be made. * Possibly revisit this issue if this outcome is not enough for Lenny+1. We will probably be revisiting this issue because working around bugs is not really the greatest way of handling them. By then, it is hopeful that grub or grub2 can be adapted to handle any missing features not provided already. Thank you all for your feedback, it has been helpful for determining how to handle the situation. William signature.asc Description: This is a digitally signed message part
Re: future of esound
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 upstream. Then how about starting a campaign to get applications that currently use it to build without enabling support for it? Is that even feasible? I would expect at least some applications to have config switches that enable/disable it. Probably too late to do that for lenny, but it would be good to start on it early afterwards. > For the record, Ryan Murray isn't a Canonical employee. My mistake then. And my apologies for that. > Also, the last upstream update was done by a community member who > screwed it up pretty severely (he dropped all the Debian and Ubuntu > patches). Yeah, I saw some comments about that in your changelog entries. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Considerations for lilo removal
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 from. > Although I use GRUB my self, why should we remove a > useful package that is being used? Most importatly bacause LILO is lacking maintainence. When facing lack of manpower, something needs to be done. Eliminating duplicate functionality is one way to reduce maintainence burden without sacrificing overall set of features provided to endusers. As a bonus it allows making documentation shorter as you don't need to explain to new users which choice to select under which circumstances, it could allow making debian-installer simpler and thus more robust. The alternative is to find someone who will to fix the bugs in LILO. > GRUB and LILO fall into the category of Gnome vs. KDE > everybody has an opinion > on what they like best. It doesn't nessicarily mean that one is really > that much better than the other. It's not as black and white as you claim - removing LILO would not lead to the logical conclusion that we should drop gnome or KDE. There are many cases where having multiple choices is advantageous, cases of mediocre tools with superior alternatives and large grey and unclear area on between. Grub and Lilo do a simple well defined task. It's much more muddier for Desktop enviroinments, MTA's, editors or version managment software. Picking up the best one is hard, and dropping other doesn't make any sense when multiple of the tools are in active development and maintainence. Back to topic, I do not agree on the way Release team removed LILO from lenny without warning. It also seems that grub/grub2 is not really in any better condition than lilo - both have RC bugs... Cheers, Riku [1] http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html signature.asc Description: Digital signature
Re: Considerations for lilo removal
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 subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
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. > > --Mike Bird > > Ultimately the issue is that initramfs-tools now uses MODULES="most" instead of MODULES="dep". In the pending upload, liloconfig will advise changing the config file for initramfs-tools to restore the old behaviour to create an initrd which will fit in the 8MiB boundary. I suspect the reason why nobody considered this to be a problem is because Grub is already running in 32bit mode by the time the kernel is loaded and booted. But I could be wrong. After all, I don't speak for the initramfs-tools developers. William signature.asc Description: This is a digitally signed message part
Please connect with me :)
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.reunion.com/showInviteRegistration.do?unsub=true&uid=265213543&[EMAIL PROTECTED] Reunion.com - Find Everyone from Your Past. You have received this e-mail because a Reunion.com Member sent an invitation to this e-mail address. For assistance, please refer to our FAQ or Contact Us. http://help.reunion.com/selfhelp?lid=2 Our Address: 2118 Wilshire Blvd., Box 1008, Santa Monica, CA 90403-5784
Re: Considerations for lilo removal
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 really need lilo to fail there, which means a non-zero exit code. I guess that will also affect package upgrades, but IMO that's a good thing as otherwise the warning may just be lost in the general package installation noise. If you wish to discuss this further, feel free to contact the D-I team on the debian-boot list. Cheers, FJP signature.asc Description: This is a digitally signed message part.
compiling xf4vnc fails but file is there
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.debian.org/search?searchon=contents&keywords=pixman.h&mode=path&suite=testing&arch=amd64). I'm new to compiling and confused because of the output, which is visible: "-I/usr/include/pixman-1" Can you help me please? Best regards, Sladan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: compiling xf4vnc fails but file is there
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 installed in > "/usr/include/pixman-1/pixman.h" > (http://packages.debian.org/search?searchon=contents&keywords=pixman.h&mode=path&suite=testing&arch=amd64). > > > > I'm new to compiling and confused because of the output, which is > visible: "-I/usr/include/pixman-1" > Can you help me please? This list is not for general compiling help, please ask on [EMAIL PROTECTED] Thanks, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
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 source code is in debian, although it misses the hook for the initramfs decompression as bzip2. -- ESC:wq -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
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]
ATTN: SIR/MADAM
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-701-113-0253 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
* 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 information (it seems that you've isolated the bug). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-free question regarding upstream releasing different binary-only tarballs for different architectures
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 for i386. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
* 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 by default. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
