Re: 1.3 installation report.
At 02:09 PM 18/05/97 -0500, Guy Maor wrote: >This might be because the + entry is not at the end? (5634, 8734) I >plan to release a new passwd package today which fixes this. I'm pretty sure I tried putting +:: in both /etc/passwd and /etc/shadow - still no success there I think. -- Karl Ferguson Tower Networking Pty Ltd Tel: +61-8-9456- [EMAIL PROTECTED] t/a STAR Online Services Fax: +61-8-9455-2776 [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: crons scripts should report status info in the mail
> "Kevin" == Kevin Dalley <[EMAIL PROTECTED]> writes: Kevin> "Karl M. Hegbloom" <[EMAIL PROTECTED]> writes: >> Q: Is anyone using `autoconf`? I wonder if it's worth learning >> to use, and what people use it for. (I've barely glanced over >> the manuals for it, so far.) Kevin> Use autoconf with automake. It's much easier to use the Kevin> two in combination. If you feel daring, use the automake Kevin> in experimental. It is better thought out, but it is still Kevin> officially beta. Uhhh... oops. I typed `autoconf`, when what I meant was `cfengine`. -- Karl M. Hegbloom <[EMAIL PROTECTED]> http://www.inetarena.com/~karlheg Portland, OR USA Debian GNU 1.2 Linux 2.1.36 AMD K5 PR-133 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report.
Karl Ferguson <[EMAIL PROTECTED]> writes: > At 02:09 PM 18/05/97 -0500, Guy Maor wrote: > >This might be because the + entry is not at the end? (5634, 8734) I > >plan to release a new passwd package today which fixes this. > > I'm pretty sure I tried putting +:: in both /etc/passwd and /etc/shadow > - still no success there I think. But is the last line in the file? Guy -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dpkg verify mode for security?
And dont forget debmake's debsums command to check the integrity of a package build with debmake. On Tue, 13 May 1997, Jim Pick wrote: > > > Hi, > > > > I was asking over Linux-ISP about doing cleanup after breakins and got > > many "use tripwire" answers, and one which says that RPM has a verify > > mode which checks for files which were changed since they were > > installed. Can the dpkg maintainers consider adding such a feature > > for Debian? > > > > Chees, > > > > --Amos > > Check out Klee Diene's dpkgcert package (in experimental). You might have to > write to him to find out where to get the certificates that go along > with it. It really helped me recover from drive corruption. > > Cheers, > > - Jim > > -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report.
At 10:07 PM 18/05/97 -0500, Guy Maor wrote: >But is the last line in the file? Certainly is. I just saw someone post on a 'login' bug that they couldn't log in as anyone except for root because of the passwd file being mode 600 - this isn't the case for me. the daemon.log reports this: May 19 11:14:03 aurora sshd[6413]: log: Connection from 203.22.233.1 port 1023 May 19 11:14:04 aurora sshd[6413]: log: Rhosts authentication refused for karl: bad modes for /home/karl/.rhos ts May 19 11:14:06 aurora sshd[6413]: fatal: Connection closed by remote host. When I try to log in in my normal account. /home is nfs mounted from another server, so what I tried to do was unmount /home and leave the default 'karl' account there and I got this error: May 19 11:17:00 aurora sshd[6433]: log: Connection from 203.22.233.1 port 1023 May 19 11:17:03 aurora sshd[6433]: fatal: Connection closed by remote host. I ran sshd in debug mode and got this: log: Connection from 203.22.233.3 port 1022 debug: Client protocol version 1.5; client software version 1.2.20 debug: Sent 768 bit public key and 1024 bit host key. debug: Encryption type: idea debug: Received session key; encryption turned on. debug: Attempting authentication for karl. debug: Trying rhosts with RSA host authentication for root debug: RhostsRSA authentication failed for 'karl', remote 'root', host 'orion.tower.net.au'. debug: Password authentication for karl failed. fatal: Connection closed by remote host. So, I cannot figure this out - it's baffling me, I *know* I can login alright and I'm fingerable. -- Karl Ferguson, Tower Networking Pty LtdTel: +61-8-9456-[EMAIL PROTECTED] t/a STAR Online ServicesFax: +61-8-9455-2776[EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
libc6 migration -- xlib
Is there a web page or other document that explains what our strategy for libc6 is? I'm not talking about random comments on the list, I mean something nailed down that I can refer to... In particular, I've got a few issues to work out. 1) libgdbm -- libc6 includes libdb, and therefore gdbm is supposed to be unnecessary. If this is true, it needs to be written down, so I can point people at it -- otherwise, I need a strategy for renaming the package (since there needs to be a libgdbm.so for libc5 and a seperate one for libc6... the former isn't changing, obviously; how do we change the latter so that "-lgdbm" still works for users building against it? [since db can't read gdbm files, that *will* continue to happen.]) 2) X -- a full release of X requires tk41-dev to build XF86Setup (it uses the static lib, so the end-user doesn't need it.) But tk41-dev probably won't be available for libc6 until I release X. Ooops :-) I can hand-release xlib6-dev by itself, (into experimental, perhaps?) so that someone can build the tk packages... or I can build that particular lib by hand until then (but then would still have to leave X in experimental unless I took over the package, eww.) And what *do* I name things? I'd guess that xlib6 is untouched, the version built with libc6 gets called xlib6-libc6 (eww), I release an alt-xlib6-dev that replaces and provides xlib6-dev (which alt-libc5 doesn't?) and then xlib6-dev can be the new version? Am I missing anything? 3) can I drop the a.out-only "dlltools" package now? :-) 4) does anyone who uses gnat (I'll ask again later, I probably won't even try that rebuild until 3.10 or later comes out) care if I just shove gnat along to purely libc6-based? _Mark_ <[EMAIL PROTECTED]> The Herd of Kittens A Debian Maintainer -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: crons scripts should report status info in the mail
-BEGIN PGP SIGNED MESSAGE- Karl M. Hegbloom <[EMAIL PROTECTED]> writes: > Since the output from cron jobs is mailed anyhow, as it should be, I > think that all cron scripts should report in as they are run, and > that this should be made a standard. Here's why. If you've ever administered over 100 machines, getting cron output mailed to root for anything and everthing gets really old fast. Most people use procmail (or some other filter) to make it manageable, but at that point, why not just log it? Only errors (as opposed to spurious stdout and stderr messages) should be reported in the mail. It might also pay to offer a "log errors instead of mailing them" option (plus a few corollary options) for the base-system root cron jobs. Dan -BEGIN PGP SIGNATURE- Version: 2.6.3 Charset: noconv iQCVAwUBM3/svakybebRDjw1AQHdaAP9HxBT4fKDFGmoYWDHdzo7bGvm+N5j9317 AbtKqUPyMjpmY6G3an6q6SV97xBf3i2z9KvrwVXZucALs26jaGIhnonks/ZT58oQ gcygMg2+pai6b6A6WLX7+C7IMUcVqu8NHS2QPu973HuHJBSAffZE+/padAFd91zO x+yK9tnC9OU= =wcxd -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report.
> 2. I installed shadowing as it suggested - started installing packages > merrily. I also installed and configured NIS - however, I cannot log in > any in my personal account - though I can finger anyone without trouble. I > deinstalled shadow by doing a shadowconfig off and that still didn't fix > the problem. I'm not sure what to put this down to, any suggestions? (I > can log in as root via ssh fine). Can you use any yp commands ? For instance does this work: ypcat passwd I noticed after upgrading a client's system to 2.0.30 that this command died halfway through the first time it was run after stopping and restarting nis. After running the ypcat once it would then claim that the server was down until nis is restarted. This made it impossible to log into the system, so I had to boot of a rescue disk and remove the + entry from /etc/passwd. Once that was done I logged in and found the ypcat problem --- going back to 2.0.29 fixed it. I've not had chance to track it down any more than that. Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 migration -- xlib
On May 19, Mark W. Eichin wrote > Is there a web page or other document that explains what our strategy > for libc6 is? I'm not talking about random comments on the list, I > mean something nailed down that I can refer to... yes, we need that ! > 1) libgdbm -- libc6 includes libdb, and therefore gdbm is > supposed to be unnecessary. IIRC libgdbm is no longer developed, because even the author saw that libdb was better, and that there was no reason for double work. > 2) X -- a full release of X requires tk41-dev to build > XF86Setup (it uses the static lib, so the end-user doesn't need it.) does it need tk41 or will it go woth any version of tk ? i hate to have tk4.0 4.1 4.2 and 8.0a2 installed on my system. > alt-xlib6-dev should packages named alt-lib-dev or altlib-dev ? a good documentation what we should do and what we shouldn't do would be great. and maybe a timeline or so would also help. (and advices like : "hey, now you should be able to compile lib xxx as libc6 binary, since the basic lib yyy you need is now available as libc6 binary" could maybe also help). regards, andreas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: rm -r * and the default prompt
Nicolás Lichtmaier <[EMAIL PROTECTED]> writes: > Be prepared to receive lots of messages saying things like "unix is for > real men that can look manpages set their own prompts" and "we shouldn't > make any decision about the system's look and feel, the sysadm should"... > The kind of decisions that keep newbie Linux users away from Debian... I don't think Debian is really aiming at newbies. (RedHat is) Debian is aiming at the power user or admin type -- the people that already know Unix. Debian is wonderful for people like that -- you get the raw power of Unix with the most tedious tasks conveniently automated via the package manager. I don't think that we should go around changing defaults like prompts just to be more friendly to newbies. If we want to be friendly to newbies, we can write an X configurator like RedHat; but I don't think that's what we want. Just my two cents... -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: list of bashisms
In article <[EMAIL PROTECTED]>, Andy Mortimer <[EMAIL PROTECTED]> writes: > There has just been a long list of bugs against packages using `bashisms' > in their scripts, and I can certainly remember this issue coming up > before. But I don't know about anyone else, but I certainly have no idea > what features are available in the `original sh'. Lots. The small handful of features that are in bash and not in ksh93 should not be used, but I can't see any reason to stay compatible with ten year old versions of sh when the posix standard isn't exactly new anymore.
Re: list of bashisms
I would imagine that the sensible approach would be to script only with features found in both ash and bash. This would also make you ksh safe if someone were to propigate the susV stupidity of installing ksh as sh. Costa From: [EMAIL PROTECTED] (Mark Baker) Subject: Re: list of bashisms To: debian-devel@lists.debian.org Date: Mon, 19 May 1997 13:41:19 +0100 In article <[EMAIL PROTECTED]>, Andy Mortimer <[EMAIL PROTECTED]> writes: > There has just been a long list of bugs against packages using `bashisms' > in their scripts, and I can certainly remember this issue coming up > before. But I don't know about anyone else, but I certainly have no idea > what features are available in the `original sh'. Lots. The small handful of features that are in bash and not in ksh93 should not be used, but I can't see any reason to stay compatible with ten year old versions of sh when the posix standard isn't exactly new anymore. . -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] . -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: list of bashisms
Andy Mortimer <[EMAIL PROTECTED]> writes: > > There has just been a long list of bugs against packages using `bashisms' > > in their scripts, and I can certainly remember this issue coming up > > before. But I don't know about anyone else, but I certainly have no idea > > what features are available in the `original sh'. On May 19, Mark Baker wrote > Lots. The small handful of features that are in bash and not in ksh93 should > not be used, but I can't see any reason to stay compatible with ten year old > versions of sh when the posix standard isn't exactly new anymore. If scripts require bash features, they should be written #!/bin/bash, there's plenty of performance reasons to use something other than bash for /bin/sh -- Raul -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 migration -- xlib
> IIRC libgdbm is no longer developed, because even the author saw that > libdb was better, and that there was no reason for double work. Nice theory; however, db can't read gdbm files, nor does it provide the gnu-specific version of the interface... so the existing gdbm will be needed provided indefinitely. > does it need tk41 or will it go woth any version of tk ? > i hate to have tk4.0 4.1 4.2 and 8.0a2 installed on my system. It doesn't need *any* version of tk installed by the *end user*. It needs tk41-dev installed by the X maintainer, in order to build the package... but it only uses the static library. > should packages named alt-lib-dev or altlib-dev ? That's a good first question; maybe it should be lib-altdev, like libc5 uses? (I don't care that much, I just want to get it nailed down...) > great. and maybe a timeline or so would also help. Indeed... especially if the goal is to have this all done for 2.0... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: rm -r * and the default prompt
> If we want to be friendly to newbies, we can write an X configurator > like RedHat; but I don't think that's what we want. I've heard rumors of this, but not seen it -- how does it differ from XF86Setup (not xf86config, which is probably what the debian old-timers think of, but the new tk-based config tool that comes with xfree86 3.2?) And what's is license? Any reason we can't bpackage it too, at least as an option? _Mark_ <[EMAIL PROTECTED]> The Herd of Kittens Debian X Maintainer -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
RFC: Kernel-package: Please add the '.config' file in the binary package
I initialy reported this problem as a RFE for the kernel-package,
but Manoj (and I tend to agree) thinks it should be discussed here first.
My point was the kernel package should also install the .config file used
to build the kernel for further reference (as getting the exact config to
report a kernel bug for example). I proposed to have this file installed
as "/boot/config-2.x.y". (Like we already install
"/boot/{vmlinuz,System.map}-2.x.y".
Manoj's point was that this .config file is already installed as
"/usr/doc/kernel-image-2.x.y/config". It's not IMHO the best possible
location since the doc directory is rather intended for global
information about the package. Also, I think the expected place
(following the "least astonishment principle") should be /boot:
A new user of Debian will probably not think that this file can be in
/usr/doc, but would probably look into /boot.
Comments? Suggestions? Objections?
NB: the FSSTND does not currently specify this file, but I think it's
worth to ask this issue to be considered for the coming FHS.
--
.signature en greve!
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: rm -r * and the default prompt
On 18 May 1997, John Goerzen wrote: > > Be prepared to receive lots of messages saying things like "unix is for > > real men that can look manpages set their own prompts" and "we shouldn't > > make any decision about the system's look and feel, the sysadm should"... > > The kind of decisions that keep newbie Linux users away from Debian... > I don't think Debian is really aiming at newbies. (RedHat is) Debian > is aiming at the power user or admin type -- the people that already > know Unix. Debian is wonderful for people like that -- you get the > raw power of Unix with the most tedious tasks conveniently automated > via the package manager. I don't think that we should go around > changing defaults like prompts just to be more friendly to newbies. > If we want to be friendly to newbies, we can write an X configurator > like RedHat; but I don't think that's what we want. I don't agree. Most people that adopt Linux come from DOS. Linux is expanding the UNIX users base. I come from DOS-OS/2 too. I used Slackware, and I changed because it was a mess. Current newbies that start with RH won't change to Debian, they don't need to. And those newbies learn, become `RH-gurus' and sit quietly at home waiting for a commercial corporation to handle their OS =). I also think that we should try to aim to the bigger amount of targets that we can... So I say: PS1="[\\u] \\h:\\w\\$ " =D -- Nicolás Lichtmaier.- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: rm -r * and the default prompt
> So I say: PS1="[\\u] \\h:\\w\\$ " =D Too long. But better than nothing. --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: rm -r * and the default prompt
On May 19, Christoph Lameter wrote > > So I say: PS1="[\\u] \\h:\\w\\$ " =D > > Too long. But better than nothing. PS="[EMAIL PROTECTED]:\\w\\$ " ? 2 charaters shorter... :-) regards, andreas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Problems with the current source packaging scheme
On Mon, 12 May 1997, Lars Wirzenius wrote: > At least the following have been pointed out as problems with > the current (source) packaging scheme. I'm not commenting > on what the proper solution to each problem is, and I wish > no-one else would, either, just so that we could, for once, > avoid the Debian-typical design-by-mail-flood. :) > > I _do_ ask everyone to add things to the list (via private mail > to me -- I'll summarize -- or on this list). Or point out non-problems, > of course. > > * .orig.tar.gz gets separated from .dsc and .diff.gz, and may get lost > > * upstream sources not preserved bit-for-bit; need to be repackage, which > can destroy upstream digital signatures, and makes it more difficult to > check that .orig.tar.gz and upstream sources are the same > > * no automated way to check .orig.tar.gz files against upstream distribution > (located on well known web sites), or upstream digital signature, if any > > * no way to automatically retrieve the upstream source package, or its > updates OK, similar to these three - no option to retrieve the upstream source from a closer mirror (or CD-ROM!). For example, I have a *very* local mirror of the GNU sources, and a couple of CD-ROMS of them, so it would be handy if I could download everything else. > * no dependencies for source packages I'd like to add here that we need two types of dependencies - on *source* packages, and on *binary* packages. And some others:- * No "dpkg-ftp/dselect" type thing for getting/installing sources * No standard location to install sources (/usr/src structure should probably be made policy) * No provision for building multiple binary packages from one source installation easily (i.e. VPATH builds). An example of this is, say I have the binutils source in /usr/src/debian/binutils-2.8, and I want to build binutils for m68k in ~/binutils-m68k, and for i486 in ~/binutils-i386. This is currently possible for the configure script and the upstream Makefiles for the most part, just not for the debian bits and pieces. * No easy provision for an essentially binary-only package, e.g. quake, where upstream source aren't provided - the source pkg is almost identical to the binary pkg - they should be in the same package probably. Another example - in my file-rc package, the debian/rules file does not do *anything* for build, and for binary, just copies stuff into the right place. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: crons scripts should report status info in the mail
Karl M. Hegbloom: > Since the output from cron jobs is mailed anyhow, as it should be, I > think that all cron scripts should report in as they are run, and that > this should be made a standard. Here's why. I think what we need is a more intelligent run-parts, for use with the cron jobs, that examines the output of each script it runs, and if there is any output, prefaces it with the name of the script. So if a cron script fails with an error message, you will be able to tell which script it was. -- See shy Jo. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: rm -r * and the default prompt
Too long when displayed. Not too long when specified. Wit the hostname and the current directory I already run into more than 80 characters at times. On Mon, 19 May 1997, Andreas Jellinghaus wrote: >On May 19, Christoph Lameter wrote >> > So I say: PS1="[\\u] \\h:\\w\\$ " =D >> >> Too long. But better than nothing. > >PS="[EMAIL PROTECTED]:\\w\\$ " ? >2 charaters shorter... :-) > >regards, andreas > > > --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
HD-failure - unable develop debian
Hi all! Friday evening my HD crashed as full suprise for me. Fortunatly, My /home was not on the broken disk, but in any case my computer rather unusable until I get a replacement HD (And a backup device - I guess you don't believe how useful it is until...). However, I'm busy with my studies for next two weeks, so I don't really have time to re-setup my system, meaning that I'll be kinda away. So if anything critical appears on my packages, feel free to fix it. Riku Voipio -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Kernel-package: Please add the '.config' file in the binary package
Hi, My 2 cents: I think I agree with Vincent Renardias ; the kernel configuration file really belongs in /boot. However, I do not feel comfortable taking unilateral decisions about something as touchy as /boot (some people require thin root partitions). Are there any objections to moving the file into /boot? manoj -- "I don't know that atheists should be considered citizens, nor should they be considered patriots. This is one nation under God." George Bush in Free Inquiry magazine, Fall 1988 Manoj Srivastava mailto:[EMAIL PROTECTED]> Mobile, Alabama USAhttp://www.datasync.com/%7Esrivasta/> -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: rm -r * and the default prompt
On Mon, 19 May 1997, Christoph Lameter wrote: > > So I say: PS1="[\\u] \\h:\\w\\$ " =D > Too long. But better than nothing. It isn't too long...! [nick] newton:~/src/deb/lftp-0.11.1$ [nick] newton:~/src/deb/lftp-0.11.1$ [nick] newton:~/src/deb/lftp-0.11.1$ ls Or the other version: [EMAIL PROTECTED]:~/src/deb/lftp-0.11.1$ [EMAIL PROTECTED]:~/src/deb/lftp-0.11.1$ [EMAIL PROTECTED]:~/src/deb/lftp-0.11.1$ _ Note that the first is much more readable...! The worst prompt I've ever seen is the once included in RH... With only the last component of the directory... =/ Something like... newton [debian] $ _ (but.. what if you are in different debian directories (src packages) in each vt?) Anyway, I know that all this discussion is useless because the prompt will remain with $ _ =/ -- Nicolás Lichtmaier.- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Kernel-package: Please add the '.config' file in the binary package
On May 19, Manoj Srivastava wrote > My 2 cents: I think I agree with Vincent Renardias ; the > kernel configuration file really belongs in /boot. However, I do not > feel comfortable taking unilateral decisions about something as > touchy as /boot (some people require thin root partitions). > > Are there any objections to moving the file into /boot? [EMAIL PROTECTED]:[~] >ls -l /usr/src/linux/.config -rw-r--r-- 1 root root 3789 Apr 10 23:31 /usr/src/linux/.config At less than 4kB per .config file, no objections from me (and I have /boot on a separate, small partition). If kernel-package is going to be modified to install .config under /boot, could /sbin/installkernel (from debianutils) be modified to do the same? (For people who don't use kernel-package, like me.) Christian pgpy5SRgkpSgu.pgp Description: PGP signature
