Re: Help With Custom Deb Package
Alex Samad wrote: Hi I am in the process of rebuilding one of my servers and I thought hey why not build a package, that links all the other packages I need, and the corresponding configuration files. I am guessing this has been thought of before but haven't seen anything for it, so I thought I would come to the list (tried debian-user first but realised that might have been the wrong place to ask the question) I am having a look at debhelper, debian policy and maint-guide. for example for server test.acme.com I was going to create a package test.acme.com and making it dependant on the required packages (I can specific a base minimum). Any one else done this, what hurdles might I face ? How am i going to handle 2 packages owning a file, for example for bind and my custom package and the file /etc/bind/named.conf ??? I have come across the replaces option for file handling I think, although now I am thinking that i should really just replace the files in the postinst scripts, after backing up the files into /var/backup My other thought aswell is that i need to use pre-depends on all the packages that I want, so that they are in place and configured before my packages tried to do any thing ? Comments/ thoughts ? I did this for Ubuntu clients some time ago. The principle is identical though, and I suggest you have a look at it, and maybe ask me questions would you have some. http://apt.bxlug.be/ubuntu/dupedi/ Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Running x86-64 debian inside i386 pbuilder on AMD64
Le vendredi 25 août 2006 à 11:09 +0200, Sander Marechal a écrit : > Martin Wuertele wrote: > > * Sander Marechal <[EMAIL PROTECTED]> [2006-08-25 07:39]: > > > >> Matthias Julius wrote: > >>> pbuilder create --debootstrapopts --arch=amd64 > >> It didn't work after all. I got a kernel running, but debootstrap > >> doesn't want to cooperate. It quits with an error that it cannot find a > >> script. It takes a random string from the pbuilder configuration and > >> tries lo look for a script at that place instead of > >> /usr/lib/pbuilder/scripts. Weird. > > > > debootstrap in such environments works fine on debian etch and debian sid > > systems and with a the debootstrap from backports.org even on debian > > sarge systems. > > Maybe my debootstrap is simply too old. I'll compare versions. > > >> I think I'm going to take the easy way out and install a minimal dapper > >> 64 in a small partition and use that to build amd64 binaries. > > > > If you look for support of ubuntu you have come to the wrong place. > > http://www.ubuntu.com/support looks more appropriate. > > Hehe, you guys know far more than they do. They told me it wasn't > possible to simply replace my k7 kernel with an amd64-k8 kernel untill I Those kernels are 64-bits compiled with (only) 32-bits userland support. > said "But I am running it right now and it works!". Let alone that they > knew anything about amd64 pbuilder on a 32-bit system. > > Last question: How do the debian build servers do it? Do they have a > build server for every architecture or is everything cross-compiled with > architecture specific toolchains? In Debian, by policy, every architecture is built on a native machine. There is no cross-compilation involved. There would probably be lots of problems with builds where some compiled-code would be needed to run on an incompatible architecture. For i386 and AMD64, on the contrary, there would be no problem. > Thanks for all the help so far! -- Jérôme Warnier <[EMAIL PROTECTED]> BeezNest
Re: Cleaning /var/lib/dpkg/available
Le mercredi 14 juin 2006 à 14:03 +0200, Daniel Kobras a écrit : > dpkg --forget-old-unavail Well, no, it doesn't help. -- Jérôme Warnier <[EMAIL PROTECTED]> BeezNest
Re: Kernel bootsplash without recompiling
Le mercredi 14 juin 2006 à 13:41 +0200, Paul van der Vlis a écrit : > Hello, > > I don't like the fact that I need to recompile the kernel to get a > bootsplash. I don't ask for a bootsplash by default, but I would like a > way to enable it with a standard kernel. > > For many many people all these boot-messages are confusing. For me this > is really an important point in using Debian for "normal people". > > Is there a good reason not to include the bootsplash? > > Who is making the dicision in questions like this? Linus Torvalds, most probably. I imagine the code is not judged portable or clean enough to be included by default in the kernel. > How can I ask for such a dicision? Linus Torvalds himself, or the other core kernel hackers. This is not really a Debian stuff. Hope it helps > With regards, > Paul van der Vlis. -- Jérôme Warnier <[EMAIL PROTECTED]> BeezNest
Cleaning /var/lib/dpkg/available
Hi, I've been upgrading my machines since Woody to Sarge, then to Etch. Now, my /var/lib/dpkg/available are huge (15MB), and it seems they never get cleaned. How am I supposed to clean them? Isn't there any automated tools in Debian to do that? Thanks -- Jérôme Warnier <[EMAIL PROTECTED]> BeezNest
Re: Debian Light Desktop - meta package
Le mercredi 07 juin 2006 à 19:04 +0200, Hendrik Sattler a écrit : > Am Mittwoch, 7. Juni 2006 15:21 schrieb Axel Beckert: > > I have a laptop with a GD 7543 chip. And I won't throw away a working > > laptop just because its graphics card isn't supported and can't be > > exchanged either. > > What about using the vesa of fbdev drivers? Maybe slow but working. I would have suggested that too, but you were quicker. ;-) Not sure it would be necessarily slower, though. > HS
Re: Debian Light Desktop - meta package
Le mercredi 07 juin 2006 à 02:15 +0200, Axel Beckert a écrit : > Hi! > > > I'm creating a meta package for install a lite desktop for old > > machines with poor hardware. > > Hey, that's a really cool idea! Debian is one of the last modern (and > not specialised) Linux distribution feasible for old and slow > hardware, especially old PCs. But Sarge already made a big step away > from old PCs (e.g. by dropping XFree86 3.3 and requiring 32 Megs of > RAM for installation -- Woody needed only 12 Megs) so I'm really happy > to see that others try to take the cudgels for Debian on old hardware > too. [..] > Since one of the points, why I like Debian, is its huge package > variety (so there's nearly always also a low end software for the > desired purpose) and since Woody runs fine on most of those boxes, I > was perfectly fine with that. Now since Woody runs out of security > support, I installed Sarge on a Pentium 90 with 76 MB of RAM and a 1,5 > GB big but bad performing HD. I general it runs fine, but X took a > while (the graphics card is no more supported in XFree 4.x and there > no more supported in Sarge) to get it running. To my knowledge, at some point, the XFree86 Team treated the no-longer-existing-in-4.x drivers as bugs. They requested anybody who noticed that its graphics card worked with previous versions of XFree86 but no longer with 4.x to submit a bug and it would be fixed. Are you sure your card is not simply managed by another driver now (split or merging of drivers)? [..] > And then there are the real low end browsers like Dillo and the Links > family (links, links2, elinks, etc.) as well the pure text browsers as > lynx and w3m. But there you have to lower your sights regarding the > rendering quality respective rendering features (no CSS there, etc.). Dillo doesn't support CSS either, I think. [..] Most recent software also have more configuration items available, and you can often trim down their requirements using them. Regards
Re: Release Date Update
Le lundi 20 mars 2006 à 17:39 -0600, Ron Johnson a écrit : > On Mon, 2006-03-20 at 23:15 +, Colin Watson wrote: > > On Mon, Mar 20, 2006 at 02:51:25PM -0800, Mark Shuttleworh wrote: > > > > (In case it wasn't clear, this wasn't Mark Shuttlewor*t*h posting. > > Please don't feed the troll.) > > Even so, are his points valid? Why would Ubuntu choose to release Dapper Drake, which is their first entreprise-grade version (so said them), on 1st June then? ;-)
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Le lundi 20 février 2006 à 11:56 +0100, Hendrik Sattler a écrit : > Am Montag, 20. Februar 2006 11:11 schrieb Jérôme Warnier: > > [..] > > > > > Ndiswrapper probably is better compared to such drivers than to wine > > > or dosemu. > > > > I'm sorry, but Wine and Dosemu can run free softwares (respectively for > > Windows and DOS), so they are not unuseful without proprietary > > softwares. > > Read again, that's just what I said in the part that you deleted. Well, I read it again, and I'm sorry to say that I did not understand that from your wording. Also, not breaking lines and having that strange reply format renders it much more difficult to read. But anyway, the essential is that we mean the same. > HS
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
[..] > Ndiswrapper probably is better compared to such drivers than to wine > or dosemu. I'm sorry, but Wine and Dosemu can run free softwares (respectively for Windows and DOS), so they are not unuseful without proprietary softwares. I can't think of any free NDIS driver, but if such thing exists, NDIS-wrapper should be allowed in main without any problem. [..] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Obsolete packages in Experimental
Le vendredi 20 janvier 2006 à 15:04 +0100, Michal Politowski a écrit : > On Fri, 20 Jan 2006 10:34:11 +0100, Jérôme Warnier wrote: > [...] > > BTW, is there a way to list all packages in experimental? > > aptitude search '~Aexperimental' > > > Or even better: a list of all packages already installed on my system > > which have an experimental version? > > aptitude search '~i~Aexperimental' > > Also > aptitude search '~S~i~Aexperimental' > will find packages where the installed version is the one in experimental. Thanks a lot
Re: Obsolete packages in Experimental
Le vendredi 20 janvier 2006 à 14:17 +, Paul Brossier a écrit : > On Fri, Jan 20, 2006 at 04:09:28AM -0600, Peter Samuelson wrote: > > > > [Jérôme Warnier] > > > Or even better: a list of all packages already installed on my system > > > which have an experimental version? > > > > There might be a better way, but assuming you have experimental in your > > sources.list... > > > > aptitude search ~Aexperimental | grep ^i Right, and if the second character on the line is a B, that means this packages is already from experimental. So you could filter the ones you could still upgrade with: aptitude search ~Aexperimental | grep ^i|grep -v ^iB Thanks > ciao, piem
Re: Obsolete packages in Experimental
Le jeudi 19 janvier 2006 à 16:38 +, Adam D. Barratt a écrit : > On Thursday, January 19, 2006 11:35 AM, Jérôme Warnier > <[EMAIL PROTECTED]> wrote: > > > After the last update of OOo in Sid (aka Unstable), I wonder if it is > > generally considered acceptable to keep obsolete packages in > > experimental (currently, Sid has 2.0.1-2 and Experimental 2.0.1-1). > > Further to other answers, in this particular case you were about six and a > half hours out of date ;-) You were right. It is out of experimental now. BTW, is there a way to list all packages in experimental? Or even better: a list of all packages already installed on my system which have an experimental version? I would like to see which ones are available. > = > [Date: Wed, 18 Jan 2006 21:06:31 -0800] [ftpmaster: Ryan Murray] > Removed the following packages from experimental: > [...] > openoffice.org |2.0.1-1 | source, i386, powerpc, sparc > openoffice.org-base |2.0.1-1 | i386, powerpc, sparc > [...] > openoffice.org-writer |2.0.1-1 | i386, powerpc, sparc > [...] > --- Reason --- > [rene] NVIU > -- > = > > (i.e. rene, the archive "cruft remover" flagged the experimental packages > for removal as there was a newer version in unstable). > > Cheers, > > Adam
Re: Obsolete packages in Experimental
Le jeudi 19 janvier 2006 à 12:43 +0100, Frank Lichtenheld a écrit : > On Thu, Jan 19, 2006 at 12:35:45PM +0100, Jérôme Warnier wrote: > > After the last update of OOo in Sid (aka Unstable), I wonder if it is > > generally considered acceptable to keep obsolete packages in > > experimental (currently, Sid has 2.0.1-2 and Experimental 2.0.1-1). > > > > If not, is there a way to remove packages from Experimental? > > If the (source) packages have the same names as the packages in > unstable they will get removed semi-automatically by the ftp-masters > so just wait for it. They have the same name. I guess it will be removed soon then. > If they have different names, I think a bug report against > ftp.debian.org is needed. Thanks
Obsolete packages in Experimental
After the last update of OOo in Sid (aka Unstable), I wonder if it is generally considered acceptable to keep obsolete packages in experimental (currently, Sid has 2.0.1-2 and Experimental 2.0.1-1). If not, is there a way to remove packages from Experimental? Regards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Emphasize teams, not packages
[..] > Future A: > > There are now 10,000 DD's and over 100,000 packages, most nobody uses, they > are just there because they were needed by people who wanted to become DD's. > Now that they are, those unused packages are ignored. A major upload > occures and now there are 30,000 bugs on the BTS. Over 10,000 remain for > months on these packages nobody cares about. The media speculates Debian > will never again be stable, look at the bugs!!! Those who want to be DD's > scramble for even more pointless packages, even more future bugs that will But why would you want to become a DD if you are not willing to maintain a package. Debian is just about maintaining packages. I agree there are other ways to contribute to Debian, but not much which do not involve being responsible for a package. I'm not a DD, and would like to become one to vote in some cases and to help more effectively in some (rare) cases. I already have a package which I maintain in the archive (and), mostly because I needed it, and it was being orphaned (well, to tell the truth, it was not maintained for a long time despite several important bugs), so I contacted the maintainer and took it over. But this is not my main contribution to Debian, I propose patches and close bugs for many packages I personally use or need for customers, and this is not recognized currently as sufficient for becoming a DD... and I'm not the only one. > be ignored. People that do wan to fix some bugs won't know how and will > apply for help from those who know nothing about their package and could > care less. The bugs remain. This DD goes MIA in frustration. [..] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#346606: ITP: personalbackup -- Company-wide solution for backing up machines and shares.
Le lundi 09 janvier 2006 à 02:27 +0100, Kim Kuylen a écrit : > Package: wnpp > Severity: wishlist > Owner: Kim Kuylen <[EMAIL PROTECTED]> > > * Package name: personalbackup > Version : 1.0.1-1 > Upstream Author : Name <[EMAIL PROTECTED]> > * URL : > http://users.skynet.be/linuxtuxie/debian/personalbackup_1.0.1-1_i386.deb This URL should be the upstream project URL. [..]
No 2.6 kernels for 586 in Sarge and up
I wonder why there is no 2.6 kernel package for 586 in Sarge while there is for 2.4? I can find 386-486-686 and k7, but no 586. Regards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#341894: ITP: pessulus -- lockdown editor for GNOME
Le dimanche 04 décembre 2005 à 11:25 +0100, Jérôme Warnier a écrit : > Le samedi 03 décembre 2005 à 21:23 -0200, Guilherme de S. Pastore a > écrit : > > Em Sáb, 2005-12-03 às 22:54 +0100, Jerome Warnier escreveu: > > > Package: wnpp > > > Severity: wishlist > > > Owner: Jerome Warnier <[EMAIL PROTECTED]> > > > > > > > > > * Package name: pessulus > > > > Sorry I didn't open an ITP for it, but I really intended it to be on the > > archive already. It's been packaged on the Debian GNOME Team svn > > repository for almost a month now. > > > > May I take the ownership of this ITP? > Of course. > I also already packaged it myself some weeks ago. > Sources package are available at http://apt.bxlug.be/sarge/sources > (don't be fooled by the 'sarge', the package has been made on Sid). It > may need some basic cleaning, but is otherwise ok. Any news on this? You didn't answer, and Pessulus is not yet in Sid, nor in experimental. Please take also into account Thomas Viehmann's comment on adding the term "kiosk" to the description. > > Cheers, Happy New Year!
Re: Bug#341894: ITP: pessulus -- lockdown editor for GNOME
Le samedi 03 décembre 2005 à 21:23 -0200, Guilherme de S. Pastore a écrit : > Em Sáb, 2005-12-03 às 22:54 +0100, Jerome Warnier escreveu: > > Package: wnpp > > Severity: wishlist > > Owner: Jerome Warnier <[EMAIL PROTECTED]> > > > > > > * Package name: pessulus > > Sorry I didn't open an ITP for it, but I really intended it to be on the > archive already. It's been packaged on the Debian GNOME Team svn > repository for almost a month now. > > May I take the ownership of this ITP? Of course. I also already packaged it myself some weeks ago. Sources package are available at http://apt.bxlug.be/sarge/sources (don't be fooled by the 'sarge', the package has been made on Sid). It may need some basic cleaning, but is otherwise ok. > Cheers,
Re: Prendre le MTU correct du serveur DHCP sous Debian
[..] Sorry, wrong mailing-list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Prendre le MTU correct du serveur DHCP sous Debian
(Évidemment, ça s'applique aussi à Ubuntu ou aux autres distributions qui utilisent dhclient aka dhcp-client) Disclaimer: Ceux qui ne travaillent pas dans un des bureaux de BeezNest ne savent probablement pas de quoi il s'agit, mais les autres comprendront toute l'importance de ce mail. J'ai un peu réfléchi aux critères de recherche, et j'ai trouvé ceci: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=309205 Il suffisait d'y penser... Il faut évidemment que le serveur DHCP soit aussi configuré correctement, mais ça c'est le problème de votre serviteur. Il suffit donc d'éditer le fichier /etc/dhclient.conf pour décommenter les lignes suivantes et ajouter "interface-mtu" à la fin: #request subnet-mask, broadcast-address, time-offset, routers, # domain-name, domain-name-servers, host-name; devient dès lors request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name, interface-mtu; Et le client DHCP va alors prendre son MTU du serveur, ou retombera par défaut sur 1500 (pour de l'ethernet ou assimilé) si le serveur n'annonce rien à ce sujet.
Re: RFC: A new video-related section
> > By the way debedit spew some debugging output at me and seems also a bit > > laggy. Is it still beta? (: > I was unable to find debedit, are you speaking about debtags-edit? I am Yes, he was talking about debtags-edit, as the mail he replies to states. > not sure if it is still beta, but it is under development by Enrico. And > the version number suggests that it is not stable yet. > Note that Enrico will hold a talk about debtags at the Debconf. > > > Greetings Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#292831: udev: udev prevents X from beeing started
Le lundi 31 janvier 2005 à 08:58 +, David Pashley a écrit : > On Jan 31, 2005 at 04:46, Hamish Moffatt praised the llamas by saying: > > On Mon, Jan 31, 2005 at 05:31:03AM +0100, Joey Hess wrote: > > > Marco d'Itri wrote: > > > > My package works as designed, but let me know if you can design > > > > something better. > > > > > > Oh, so it's udev that's responsible for what IIRC is a race that can > > > cause X to not see the ps/2 mouse if the module is loaded as part of X's > > > setup? Nice design. :-P > > > > > > FWIW, we have worked around this bug in d-i unstable for at least i386 > > > and amd64 by always putting psmouse in /etc/modules. > > > > I did an amd64 install last week from the (then) current install image > > and didn't end up with psmouse in /etc/modules; I added it by hand when > > I found that udev was preventing X from starting. :-( > > > > I am yet to submit a report; my bad. > > > Surely the solution is for hotplug/discover to load it during bootup. > Could hotplug use mdetect? IIRC, mdetect does not support devfs, and devfs is still in use in the installer, right?
Re: Bug#290421: ITP: zeiberbude -- A program for administering internet cafes.
Le vendredi 14 janvier 2005 à 01:55 +0100, Robert Millan a écrit : > Package: wnpp > Severity: wishlist > > * Package name: zeiberbude > Version : 2.0.4 > Upstream Author : Christian Toepp <[EMAIL PROTECTED]> > * URL : http://zeiberbude.sourceforge.net/ > * License : GPL > Description : A program for administering internet cafes. > > The package is made and ready for upload. You can find a copy at: > > http://people.debian.org/~rmh/zeiberbude/ > > Btw, I'm looking for a way to integrate zbdesk (the client) as a startup > script. zbdesk is a simple X client that locks the X server and can be > controlled remotely by zeiberbude. It relies on an already-running X, and > it doesn't start other X clients whatsoever (just locks and unlocks), so it > can't just be run from an init.d script. Any suggestion? >From a script in /etc/X11/Xsession.d, maybe? Try to create a new script there.
Re: PHP application packaging policy/best practice?
Le samedi 08 janvier 2005 à 18:32 -0500, sean finney a écrit : > hi there, > > On Sat, Jan 08, 2005 at 03:05:15PM +0100, Jérôme Warnier wrote: > > > Any thoughts? > > I collected some interesting Debian packaging Web Applications policy > > drafts some time ago: > > http://glasnost.beeznest.org/articles/184 > > to throw another link out: > > http://people.debian.org/~seanius/policy/ You obviously didn't take a look at my page. :-P This link is the first one on my list. > right now, there's a heck of a lot more work done on the > database-specific aspect of web-applications, though it's my > intention to eventually cover the whole gamut. > > my two recommendations are to use /usr/share/$pkg (or a subdir) for > the application pages, and don't modify configuration files of other > packages. > > > sean >
Re: PHP application packaging policy/best practice?
Le vendredi 07 janvier 2005 à 14:19 +0100, Kees Leune a écrit : > Hi, > > I am preparing an ITP for a PHP application that is currently under > development at my place of employment. While thinking about packaging > it, I was wondering if there is any PHP application policy or best > practice. I am now leaning to a setup as follows: > > /usr/lib/appname/php Publicly loadable PHP pages > /usr/lib/appname/libIncluded PHP libraries (not reachable via httpd) > /var/lib/appname Persistant data > /etc/appname/appname.cfg Configuration > /etc/appname/apache.conf Apache configuration (symlink from > /etc/apache/conf.d) > > Note that I chose /usr/lib over /usr/share because according to the > FHS, /usr/share is meant for "all read-only architecture independent > data files". Although PHP files are read-only and architecture > indepedent, I consider them as programs. > > Any thoughts? I collected some interesting Debian packaging Web Applications policy drafts some time ago: http://glasnost.beeznest.org/articles/184 I accept any comments, especially improvements of course. > -Kees
Re: Next reboot script execution framework
Le dim 03/10/2004 à 19:26, David Goodenough a écrit : > On Sunday 03 October 2004 16:54, Jérôme Warnier wrote: > > Is there a framework for executing once a script at next reboot in > > Debian (Sarge|Sid)? Any idea of a "clean" way to do it? > > > > Thanks > > One comment, it is rather "Not the Linux Way(TM)" to expect > reboots. Only things like changing the kernel should need a > reboot. Well, let me explain then: I'm working on a customized Debian distro, and on a replication engine (Replicator) for machines. I would like some things to happen next time the machine is powered on, because the people who install it would like to have to wait the less possible. I imagined that we would finish the installation (probably unattended) and the system would reboot at the end (because 1/ there *is* probably a newer kernel, and for whatever reason, 2/ GDM does not start automatically after being installed). I would like the system to do things in the background at next reboot, like running prelink, scrollkeeper-rebuilddb, updatedb, ... You get the idea... > David -- Jérôme Warnier Consultant BeezNest http://beeznest.net
Re: Strange behaviour at kernel upgrade
Le sam 09/10/2004 à 16:29, Wouter Verhelst a écrit : > On Sat, Oct 09, 2004 at 12:48:23PM +0200, Jérôme Warnier wrote: > > I got this strange behaviour on Sid today while upgrading > > kernel-image-2.6.8-1-686. Notice on the log that I answered "n" to "Do > > you want to stop now? [Y/n]", and it aborted just like if I answered > > "y". > > > > The only thing noticeable is that I took a long time (a few minutes) to > > answer. I suspect there should be no timeout in this case. > > > > I just wanted to let you know, just in case. > > > > > > > > Preparing to replace kernel-headers-2.6.8-1 2.6.8-3 (using > > .../kernel-headers-2.6.8-1_2.6.8-4_i386.deb) ... > > Unpacking replacement kernel-headers-2.6.8-1 ... > > Preparing to replace kernel-headers-2.6.8-1-686 2.6.8-3 (using > ^ > Notice the extra space here. It appears you inadvertently hit the space > bar while you were doing something else. As a result, you had that space > in your input buffer, so when you hit enter, it was the space, rather > than the 'n', which was processed. As this script interprets everything > which is not 'n' as the default value, it bailed out. You're perfectly right. This is just a problem of the input checking being really too weak. If you are all aware of it, I don't mind. -- Jérôme Warnier Consultant BeezNest http://beeznest.net
Strange behaviour at kernel upgrade
I got this strange behaviour on Sid today while upgrading kernel-image-2.6.8-1-686. Notice on the log that I answered "n" to "Do you want to stop now? [Y/n]", and it aborted just like if I answered "y". The only thing noticeable is that I took a long time (a few minutes) to answer. I suspect there should be no timeout in this case. I just wanted to let you know, just in case. Preparing to replace kernel-headers-2.6.8-1 2.6.8-3 (using .../kernel-headers-2.6.8-1_2.6.8-4_i386.deb) ... Unpacking replacement kernel-headers-2.6.8-1 ... Preparing to replace kernel-headers-2.6.8-1-686 2.6.8-3 (using .../kernel-headers-2.6.8-1-686_2.6.8-4_i386.deb) ... Unpacking replacement kernel-headers-2.6.8-1-686 ... Preparing to replace kernel-image-2.6.8-1-686 2.6.8-3 (using .../kernel-image-2.6.8-1-686_2.6.8-4_i386.deb) ... You are attempting to install an initrd kernel image (version 2.6.8-1-686) This will not work unless you have configured your boot loader to use initrd. (An initrd image is a kernel image that expects to use an INITial Ram Disk to mount a minimal root file system into RAM and use that for booting). As a reminder, in order to configure LILO, you need to add an 'initrd=/initrd.img' to the image=/vmlinuz stanza of your /etc/lilo.conf I repeat, You need to configure your boot loader -- please read your bootloader documentation for details on how to add initrd images. If you have already done so, and you wish to get rid of this message, please put "do_initrd = Yes" in /etc/kernel-img.conf. Note that this is optional, but if you do not, you will continue to see this message whenever you install a kernel image using initrd. Do you want to stop now? [Y/n]n Ok, Aborting dpkg: error processing /var/cache/apt/archives/kernel-image-2.6.8-1-686_2.6.8-4_i386.deb (--unpack): subprocess pre-installation script returned error exit status 1 Regards -- Jérôme Warnier Consultant BeezNest http://beeznest.net
