Re: Turbo Vision non-free? (Was Re: Another packages wishlist)
It seems like they've given up their rights by calling it public domain in a public forum... Debian needs a lawyer for things like this. Regards Jeff On Thu, Mar 16, 2000 at 04:51:51PM -0800, Jakob 'sparky' Kaivo wrote: Damian M Gryski [EMAIL PROTECTED] writes: Turbo Vision is non-free? From http://community.borland.com/article/0,1410,17285,00.html (last modified Sept 01/99) quote Question: Where can I find the public domain version of Turbo Vision? Answer: It can be found at ftp.inprise.com/pub/borlandcpp/devsupport/archive/turbovision/ /quote Is Borland's page wrong? You should mail them and get an official answer. (Isn't a FAQ on their site official enough?) It certainly isn't public domain. From one file (tview.cpp, inside source.zip, inside tv.cpp): /* * Turbo Vision - Version 2.0 * * Copyright (c) 1994 by Borland International * All Rights Reserved. * */ That's about as non-free as you can get.
Re: Communicator - glibc2.1 breakage
I've always had strange problems with Navigator Communicator for Linux, but I can't say that glibc2.1 has made it any worse for me. It works just as poorly as it always has. It hangs a lot, crashes too often, etc. I wouldn't have much hope for a stable, full-featured browser until Mozilla appears. Who knows -- maybe Opera will be here first. Opera is certainly a great browser on the Windows platform, as long as you don't mind paying for it. KDE has a decent free browser that seems a lot more stable than Netscape, but without some of the perks -- Java/Javascript, etc. I use Lynx/SSL for most of my browsing. The speed grabs me. Regards Jeff On Fri, May 14, 1999 at 03:59:59AM +0200, Martin Bialasinski wrote: Hi, we all know that netscape communicator is fscked up with glibc2.1 :-( (bus error when closing windows or with long credentials, hanging and killing X when closed in this stage etc.) Now Red Hat 6.0 ships with glibc2.1. I just checked dejanews and couldn't find any problems reported by Red Hat users. Maybe I used the wrong keywords, but if Red Hat has a working cludge, someone should take a look at how they solved the problem. And we should bug Netscape as well to fix the thing for glibc2.1 I know one (more?) fellow developer works for netscape. Maybe you could contact someone? Ciao, Martin
Re: What Bruce had to say about non-Pixar names. Re: what's after slink
On Sat, Oct 17, 1998 at 09:57:50PM +0100, Dave Swegen wrote: On Sat, 17 October 1998 11:10:10 -0400, Dirk Eddelbuettel wrote: john I'd still like to use penguins. Indeed, that was the best proposal yet. Cool, a linux named Opus. Can it get better? Chilly Willy was another famous cartoon penguin. Regards, Jeff -- It's time to close windows and open source. Linux is a trademark of Linus Torvalds.
Re: IA32 vs i386
On Thu, Oct 15, 1998 at 02:09:23PM -0700, Kenneth Scharf wrote: The intel version of debian packages are in some directory path downstream from ../../i386/.. and the package names also carry i386. While this is technically correct, it can be missleading to some that the package only runs on an 80386 cpu. The current name for the cpu family from intel (and clones) that are derived from the 386 is IA32. (and intel's next family will be called IA64). Should the package and directory names be changed from i386 to IA32? We're following the industry convention. It might be more appropriate to use x86, but other IA32 CPU's are a superset of the 386. I think it would be much more confusing to the average user to see IA32. Nobody other than Intel seems to refer to the architecture as IA32. I'd say that 386 is the least misleading. It also leaves the possibility for a Debian distribution with packages optimized for (and possibly requiring) newer x86 chips. Regards, Jeff
Re: Debian logo
On Sat, Oct 10, 1998 at 02:43:05AM +0200, Marcus Brinkmann wrote: I would prefer a new logo, too. We shouldn't draw it. We should run a gimp contest. They produced the Gnome logo, and there are artists as well as designer. They'll come up with a good, inspiring logo, I'm sure. We should vote the winner. Ideally, we need a version of the logo that can be reproduced in one or two colors. That way it can go directly on a CD or be printed inexpensively. Full-color printing can be rather expensive. Someone should write a proposal to be voted on when the constition is in place. Maybe I'll do it. Please contact me if you want to work with me on the exact wording. How did we arrive at the current logo? My memory stinks. Bruce made the decision after unfruitful efforts on the logo pages. Ah. :-) Regards, Jeff -- It's time to close windows and open source. Linux is a trademark of Linus Torvalds.
Re: suggestion - AntiVir for Linux
On Fri, Oct 09, 1998 at 04:48:26AM -, Robert Woodcock wrote: Just out of curiosity would anyone be interested in a mcafee virusscan installer package in slink contrib? I have everything created, the only thing I'd have to work on would be upstream upgrades (it currently doesn't handle this at all) and then I'd write an intent to package and upload it. I looked at this yesterday. It appears to be an a.out executable. I don't have a.out/libc4 anymore, and I suspect I'm not alone. Are you aware of a newer version? It would be nice to have a virus scanner on my Linux machine, since I receive a lot of Windoze e-mail attachments and have several Samba shares. Regards, Jeff -- It's time to close windows and open source. Linux is a trademark of Linus Torvalds.
Re: X window logo
On Fri, Oct 09, 1998 at 01:57:20PM -0700, Chris Waters wrote: Last time I checked, the license for the logo didn't allow its use in a package (which I complained about, so maybe that's not true any more). I tried to do this myself, and found that the logo was unrecognizable when shrunk down that small. The lines are too thin, and critical detail gets lost. RH's logo is actually a lot cleaner and more elegant (IMO) than Debian's. I'd vote for a new logo if I thought anyone would listen to me. I'd prefer a new logo as well (with no offense intended toward the kind person who created the current one!) But I can't draw, so I guess I should shut up. :-) How did we arrive at the current logo? My memory stinks. Regards, Jeff -- It's time to close windows and open source. Linux is a trademark of Linus Torvalds.
Re: Why is dosemu in contrib?
On Thu, Apr 30, 1998 at 10:08:59AM -0700, David Welton wrote: On Thu, Apr 30, 1998 at 01:05:19PM -0400, Stephen Carpenter wrote: That might not put it in contrib isn't there a Free version of DOS that someoen other than Micro$loth made? i fsomething like that works with DOSemu... Caldera makes one, but it's not Open Source. Last I checked, Dosemu came with FreeDOS, which AFAIK is Open Source. It's not 100% working, but it's good enough to get most users up and running, and they can re-sys their drive with real DOS if they want it. Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NPR piece on Linux
Anyone have a digitized copy of this? :) Thanks, Jeff On Wed, Apr 08, 1998 at 05:58:26PM -0400, Dale Scheetz wrote: OK, it has played here in the East. Those of you out west still have some time to find a radio ;-) I think it is the second piece on All Things Considered after the news. This was a very good presentation for a public forumn. They pointed to all the right facts; talked about Linux clusters outperforming supercomputers, along with the fact that nothing M$ produces come close to the perfomance. They let Linus have a lot of personal air time, and he said all the right things (of course). Even Richard S. got a spoken line or two. I was impressed by the factual quality of the presentation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Where's the SCSI support in Debian?
On Wed, Dec 10, 1997 at 07:02:05AM +1100, Lawrence wrote: Does that mean that Debian cann't be installed easily on a machine with a Buslogic FlashPoint PT and no IDE disks? I'm going to buy a SCSI adapter to replace the old AHA-1542CF I have right now, and based on a recommendation on debian-user I'm going for the FlashPoint... and I think many people on that list may be influenced by that recommendation, too. Is this going to change soon... I mean, 2.0 is still months away, and it kind of scares me to think of many users facing way till 2.0 I am using Buslogic MultiMaster BT958 UW scsi card and have no problem installing Debian 1.3, I don't need to compile the kernel to install it, though I did that because of the latest buslogic driver. However, your card is not a FlashPoint and does not require special support. I have a BT948 and it works as well. But the BT930 and others do not work without special support. The BT930 and other FlashPoint cards are fantastic cards. I hope people don't avoid them because of the Debian support issue. I also hope that Debian 2.0.32 disks are made that correct this oversight. Thanks, Jeff -- Please reply to me using planetfall.com (jeff@). On the side of the software box, in the System Requirements section, it said Requires Windows 95 or better. So I installed Linux. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#2092: procps needs an update for kernels 1.3.53
Note that current 1.3.x kernels seem to have everything in /proc/ksyms, instead of just one page. Using that information, psupdate and System.map are completely unnecessary. Jeff
Re: Bug#2083: machine hangs when ftping large file
Solution: Get a new Ethernet card, or a slower machine. Something like the BOCA BocaLan PCI with the AMD Lance is nice. Beware: the BocaLan PCI cards have a design flaw which can cause big problems as well. The Allied Telesyn PCI card uses the same chip but is unaffected. I'd also _highly_ recommend the DEC PCI cards, and also the Kingston PCI cards. The Kingston cards use the DEC ethernet chip, work with the DE4X5 driver, and cost $60-$70. Not bad for 1MB/sec transfers. Jeff
Re: Bug#2088: README.fdisk gone missing.
This has been reported before -- the bug is still outstanding for several reasons, but I will fix it in the next ELF release. The future of the current version of fdisk seems to be somewhat questionable, especially now that Bruce is working on a front-end for fdisk 3.0. I suppose we'll probably retain this one in some shape or form just to keep familiar users happy. In any case, I expect to release a new version of miscutils this weekend, depending on my health after some minor surgery on Friday. :) Thanks, Jeff Package: miscutils Version: 1.3-5 The BUGS section of the manpage for fdisk: Although this man page (written by [EMAIL PROTECTED]) is poor, there is excellent documentation in the README.fdisk file (written by [EMAIL PROTECTED]) that should always be with the fdisk distribution. If you cannot find this file in the util-linux-* directory or with the fdisk.c source file, then you should write to the distributor of your version of fdisk and complain that you do not have all of the available documentation. I cannot find README.fdisk anywhere: % dpkg --search fdisk miscutils: /usr/man/man8/fdisk.8 miscutils: /usr/man/man8/cfdisk.8 miscutils: /sbin/cfdisk miscutils: /sbin/fdisk Matt Birkholz [EMAIL PROTECTED] Finger [EMAIL PROTECTED] for PGP 2.6.2 Public Key ID = 74305425 Key Fingerprint = B3 34 FB 3E 3C FE E8 57 AA B4 B2 95 A7 C0 1E AF
Re: beware sysvinit 2.58 installation
Something similar happened last time I upgraded init -- to Bruce's ELF version. Shouldn't packages doing stuff like that do some postinst _after_ rebooting the machine? They could just add an rc file that removes itself once it executes. Thanks, Jeff Helmut Geyer [EMAIL PROTECTED] wrote: There is a small problem with the new sysvinit (2.58-1) suite. Once you have installed it, you can't shutdown/reboot/halt the system as these use a different way of communicating than the 2.57* init (a FIFO, no longer a file). So please make copies of the old init,shutdown, halt and reboot programs and reboot right after installing sysvinit 2.58. After rebooting, you can delete the old files.
Re: Bug#2086: installation bugs/inadequacies
I'll throw in some comments of my own. :) * The base disks do not contain vi. This is unacceptable. I'm also irritated by this. Also, we should have a rescue disk of some sort that has fsck. * Debian did not recognize my D-Link DE-530CT ethernet card with the de-4x5 driver (Slackware has no problem with this). This has been reported several times. The de4x5 driver does not work as a module without some parameters. There is no way to pass these parameters from /etc/modules. Please: The de4x5 driver should not be provided as a module. Unless, of course, someone wants to fix the PCI probing so it works as a module. Doing so is completely safe, but for some reason the driver won't do it. Thanks, Jeff
Re: Bug#2063: scsi driver sequence unreasonable
In article [EMAIL PROTECTED] you wrote: : It doesn't really matter if a 152X gets detected before a high-power : whiz-bang SCSI-matic 2010 PCI adapter, because you can still put root : on any SCSI controller you like. You are correct, of course, Jeff, but the problem with having a card like a 15[12]X recognized first is that if you have machines like mine, which all have one fast controller that's always there and has the root on it, and you then stick 1510's in from time to time when you need to temporarily hang an external disk chassis on, or put a tape drive on, or something else that is transitory, you have to go through contortions to boot because what normally would be the 0th SCSI controller isn't any more, though it may be again shortly. Agreed, that's a problem. Moving the probes around doesn't really solve it: someone switching to Debian from Slackware will find their SCSI controllers detected in reverse order, for example. It's a no-win situation. This seems unfortunate. The other OS's I've had experience with (and there are many on the list) always made it possible to either nail down hard where the root disk was going to be, physically, or they sequenced driver discovery correctly to handle this case. None have been perfect for all cases, but all treated my needs better than Linux currently does. You're onto something here. I wonder how difficult it would be to add something to the partition tables to nail down drives to devices. Windows NT, for example, does _something_ when you run it's fdisk program that lets you re-order drives. We'd need to extend the kernel for this, and fdisk and cfdisk would need to be updated. I'm not up for the kernel work required, but since I have the dubious distinction of fdisk maintainer, I would be willing to work on that part. :) Are there any kernel hackers lurking about that might have an idea as to how difficult a project this would be? Does the Linux RAID stuff already have provisions for this? I'm not going to get upset no matter what Simon decides to do, because I suspect I'll be building custom kernels for most of my machines no matter what, but I wanted to make sure that the silliness of the current approach in my eyes got registered someewhere and fed back upstream. I'm not running Debian kernels either. PPP 2.2.X is still broken, for example, and I don't want to be forced to use it. 2.1.2d works just fine in a stock 1.2.13 kernel. Thanks, Jeff
Re: Bug#2063: scsi driver sequence unreasonable
I think the real solution lies elsewhere; I am developing a configuration tool which will allow us to choose the order of the devices without editing hosts.c. It may take some time to surface and you may beat me to it, but that's OK. I'm not sure if that's the right solution either. I think we need a way to nail devices down when partitioning disks. We could just assign each partition a 1-byte ordering number. Partitions with a '0' would get detected first, '1' second, etc... Partitions with the same number would be detected on a device-order basis, the way things work now. Does anyone know how NT does this? I guess I could play around with it and see what Norton Disk Doctor turns up. Thanks, Jeff
Re: Bug#2063: scsi driver sequence unreasonable
IMHO, the fewer changes between Debian's kernels and the upstream ones, the better... You are right, of course. I changed it in 1.3.47 and the DPT (has NOTHING to do with the AHA drivers) and the Buslogic are at the top. What other AHA-compatible do we have that should move? I a mopen for suggestions. I don't see why we should move any of them. They're arranged in the order they are in for two reasons: 1) to prevent probing problems (i.e. BusLogic must come before Adaptec 154x), and 2) to allow the more popular and/or problematic cards to come first. It doesn't really matter if a 152X gets detected before a high-power whiz-bang SCSI-matic 2010 PCI adapter, because you can still put root on any SCSI controller you like. If there is a _really_ good reason to change the probe order, we should discuss it on the kernel and scsi channels, and get it changed in the upstream source. Remember: if you move probes around, earlier probes have a chance of putting hardware in an unusable state, preventing later probes from succeeding. Besides, with the nice support that Adaptec gives Linux users we should really re-locate the drivers to /dev/null anyway, but the Linux developer supporting these things IS a nice guy, so... Adaptec provides free programming information on the 154X and 174X series, as well as the AIC-6X60 chips (152X), so be nice... I'm not thrilled with their policy on current products, but they're still excellent products. :) Merry Christmas! Jeff
Re: Bug#2065: single user isn't
This has been reported before as a bug. This time I just thought i'd chime in and say me too. Thanks, Jeff Package: base Version: 0.93.6-13 It is utterly unreasonable for the system to try and do fsck's when the system is booted with 'linux single'. The whole point of a single user boot is that something is wrong that needs reasoned attention from a system adminitrator. A single-user boot should do absolutely *nothing* that isn't required to drop the system admin into a shell. This caused me considerable grief when one of the disks on my system was starting to fail, and I was desperately trying to extract a few critical files that had been updated since the last backup. The cycle was to boot, snag a few files before the disk warmed up and failed, then power down to let things cool off, then repeat. The insistence of the system on doing fsck's at every boot made this a much less productive process per unit time than it could/should have been. Bdale
Re: dip/CSLIP trouble (again)
See if it works OK in non-compressed mode. I think the compression module is buggy at the moment. That will probably go away once Simon, our new kernel maintainer, is up to speed. It's a little less dain-bramaged, but it still doesn't work. It's just not executing ifconfig or route for some reason. Jeff
Re: coming soon
Bruce Perens writes: From: Ian Jackson [EMAIL PROTECTED] 1. The initrunlevel file is moving to /etc from /var/log. /var/run, surely ? /var/run is possibly in a mounted filesystem. Init breaks if it can't find this file. I've been thinking about using a named pipe so that it will work with a read-only root. You can't change run-levels if you can't write this file. Isn't it just as likely that /var/log will be on a mounted filesystem? (In fact /var is a separate filesystem on mine.) In fact, isn't /etc guaranteed to be on the root filesystem? I don't see how a system can boot without it. Why move initrunlevel at all? I think other distributions will leave it in /etc. Jeff
Bug#2002: Missing manpages
On Mon, 11 Dec 1995, Owen S. Dunn wrote:
Package: diff
Version: 2.7
Revision: 5
This package provides no man pages for any of diff, diff3, sdiff, or
cmp.
Too true. It comes with info pages, which are not at all the same thing.
I think the current custom is to leave bug reports about this particular
issue open, so I'm not closing this one. I doubt, however, that I'll get
around to writing a man page and contributing it upstream in hopes that
it'll be picked up.
I wrote Patrick Volkerding about this a few months ago. I've attached
a piece of our correspondence.
I think it would be great if we could add these manpages. Something
is better than nothing. I can't stand `info'. :)
Jeff
From [EMAIL PROTECTED] Mon Oct 16 17:01:10 1995
Return-Path: [EMAIL PROTECTED]
Received: from mhd1.moorhead.msus.edu (mhd1.moorhead.msus.edu [199.17.81.1]) by
router.patch.net (8.6.12/8.6.12) with SMTP id RAA16018 for [EMAIL PROTECTED];
Mon, 16 Oct 1995 17:01:10 GMT
Received: by mhd1.moorhead.msus.edu; (5.65/1.1.8.2/09Oct95-1257PM)
id AA07115; Mon, 16 Oct 1995 12:03:59 -0500
Date: Mon, 16 Oct 1995 12:03:59 -0500 (CDT)
From: Patrick J. Volkerding [EMAIL PROTECTED]
To: Jeff Noxon [EMAIL PROTECTED]
Subject: Re: GNU wonders where you got diff.1?
In-Reply-To: [EMAIL PROTECTED]
Message-Id: [EMAIL PROTECTED]
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: RO
On Mon, 16 Oct 1995, Jeff Noxon wrote:
The author of GNU diff, the Debian diff maintainer, and myself are all
wondering where you got the diff manpage. It's not part of the GNU diff
distribution, and the author says he can't recall there ever being
a GNU diff manpage... Yet you have one. :)
Any idea where it came from? Do you have nroff source?
I got 'em from FreeBSD. Jordan Hubbard told me they needed manpages for
cmp, diff, diff3, and sdiff, so they wrote ones. You guys are also
welcome to use them.
Take care,
Pat
begin 644 manpages.tar.gz
M'XL(`./@C```^U:W/;[EMAIL PROTECTED],':5K/$CD^Q.;K:N+L);]F6KR1/
MDAU/52@)LKBA2`T?L75K?_R[@;XD!6_)G9FML2JQ)1(`-V-1O?I1D.CV;RY
M^]WC7KL[.\^?/=/?:;IVEOYJ_6)G9U_KYSN[N_L[/S[;^Y^O%B[SN]\\AT
M\96GF9]H_5T2Q]E-[]WV_$]Z-\W=#N[EMAIL PROTECTED]6WOW;7U\T\/_?=OC_
M?857_C*8MTS%R;*4AU/=(:/9U'PV21IDWHF[8?!I,XB0*_J74K##5WF.K$
MI;Y;,9-ZH;^Z$T2/4H'AN-OV.3H)QGB3Q3*?Q)+OT$X.G498$PSS#DRS6
M!R;Y9$*ST,,%]TCU:!1GH,$[H1FAP@/M1^-[XD:I[D07061`9P--
M1B45/3,.4ADDB-NEJ@*0(53(R_,TPB/QDH'[EMAIL PROTECTED]WSB
M3#!P-1)0Q/MY/,@HPHGR?QYV!,+$S]C(FQ$87P;1!7$X#JA1RMU0PYG)
M?N(/N\TEZECDEBP6W`Q*\EF/LBE?OUA_)DV6GD7G!%1:,3`.O0-(A.J1^
MRI9Q3I9'44^L',)PIO7=%`Q9$8LC!;R.Y#W2-1H8=1U-8Y'^0RZZ+NY
M^P'3$N.%1,_\#KEAVDI?IXWZKG*B/WWV1=]?0YQ(:=R`QH!;]*7$^-G
M.529II_4A)`V'`:ZPAC:68@OEICQ1Y^B^#(TXPM#'?]DEU7`A$)V7@
MA?G8E+UB=7PV83P'#\/%]37'/93KKEN$Q)ED*7E.HJ35!A^UM0G)F!)47^1
M/S,KUG,[EMAIL PROTECTED](N%:J(Q'AJ2$IB:Q5B=EKFEE;Y2'9=Z71N
M1K2HT#:@Y9;0HID8:6IFSNQ)6^]ONYW7P_M7H=C?O37O=G[[!SJ`\^X%'
M]SIO.B#OFZ='.IV]V30\P[.!MU7W_\V.JCP???TR/NJW7R07?G_8Z_;[N
M]K1W?'KDH2/TWN=#+Q.'Q;DI'UT=NB=O(LSP;[EMAIL PROTECTED]
MKC?5W=?ZN--KO\7'UH%WY`T^,$FOO$)C?:`[;T::LW\-IG1ZV/CWKG7;[
MTAVQ=NCUVTM[[AS//JG6!HW?D9G.G^V];148U5=%7C]*`#(EL'1](9CP1.
M#[U[EMAIL PROTECTED]'^HX:NG_::7MTTWG?`3.MWH[;??^;\SO(2'W-UAZ[CU
M!OQMWB(:S$O[K-Y)I([EMAIL PROTECTED]X'?VFVSWLU\8H-_I_RU._V7^JC;
M9ZF=]3L-C#)H,0'H!B+#8]P?G/4]%IYW,NCTFG`Z][LL4]O[EMAIL PROTECTED];PO-
M#UG2W1-FX+J]CY0QR03GHB?O[EMAIL PROTECTED])%67(O$T8$VP/NKO(JQH50!Q5^
M]4GGS9$'T;[]+1+/;WS^ITMS)O7IQ\?I=ZX.P8BHD#=7);T(3ZSV
M7NO6X\D6]?AC[T/:L[W=?5?^L_=9.0;DFZ/J?S?_:AR^\M?F[MZTQF
M+?W\A^_B$M7S.Q_M\\,OJY\_.'F6X?G^I=UQBA?G^J1U#*TYF6GTA;]C
MV(#9G`Q3=AGK21`::W_X:1[VO?ZY:[EMAIL PROTECTED];K^_R_WO\'%^E
MGX+YKB[O][BWPTZ_W?-X-A7!#G2H8;)#,[EMAIL PROTECTED]'\$Z+N;BL\ET`MH
MB1?S,$L5+!-]!-+QGXRUC`R\SQKJH,%K-+$QSL-([EMAIL PROTECTED]
M]K+^TCM`PF$Y,T^,[EMAIL PROTECTED]CK*9T/85_C\RVDPFMJ$O8,U,9$)3Q
M:)0GQA0!AI'B98Z33.:@B^EUO,KQT27[``,ZP2Q(T$AEI-*CYFGAN72J:
M^I_](/2'H8''.0CU=N9?Z.W+8(S6D]_4$TOX[E2ITD0904[CHO-,8SQS`^W
MO\L3`8Q]]]L,5[HXS@[EMAIL PROTECTED]):]--T9JQP`2F+)7Q;M%;R+LEP1K
M\B32YBK(%8LRS'%4;A`)YVP8%48)+B77#`2$!UCA*)*#[N*3=]3T\F:0
MWLAZ(5,1*#E4IZ?41_%I3S45`E*8,'[EMAIL PROTECTED]?TJDH9)`AEP0!+75-H
MY*$$Y+((R8D[?=/PH\Y[FJLYNB7ZM.\ZZFY\FT31;B![EMAIL PROTECTED]'
MF2B!KT/C\S?/^YP:.A$Z^_[Y0C6)ANG5$TDT+%7(([EMAIL PROTECTED]O,LXKG
[EMAIL PROTECTED]@%J`2X+=,][28Z*V4MQ_`7080GZJ5$B4*%6I',BBZU7;[EMAIL
PROTECTED]
MPHV*OF'`UU28.#0!TI(N+N7:2JR4HGRJ*GDXT#Q('F+`8PXP;A6RX8B7
[EMAIL PROTECTED],\*5/BQ7:3M6ADVGM'[EMAIL PROTECTED]@B;N)G$C;=$0G_?
M52WH)+P_(HEL!I.]K33T:VC?EUW\LT;M00?=AGPPTO36`7VOUX#Q7S3!$
M+V[EMAIL PROTECTED]^*-?J:WYXC%]YM[BO4VV`6FNI;AZ#KZQMI%/G0Z.?^SM__C
MWO,B_[/S;%_KW9W=9R_6^9^GN)H#($CO]6N8F(V]O=3,0INZ(TW)V=Z$,=A
M6KN'$7DKJ)#-TODVS#*\;=76#4UV21:VA'?5B#B`;^M?K$8Y5=VQ=ML/K.8
[EMAIL PROTECTED]/TEUD;#T,J796@JIHVJ6JD*5PXE_MWKN2%U4[7$]=B(
[EMAIL PROTECTED];L5(*BHS5Y3H\,[EMAIL PROTECTED]:K,ZW-TIB
M?Z0:[EMAIL PROTECTED]:SAG$TZ:2GD37:[H(;[EMAIL PROTECTED]@'^O3[EMAIL
PROTECTED]]
MO\MIG)H*YT$JWHXD4!%/@T'5YP#`E7($E.,C%Q_%T79)#+_)1!QL^]1VP
Bug#1978: man: default pager should be less
For a more functional presentation of the manual, I'd convert the manual pages to HTML on the fly, and read them with lynx or another web browser. I think this would be much more useful with the info pages. Info is just as intuitive as vi (that is, not at all) and I think that makes it a bad format to store documentation in. I believe there is already a program to do info-html, but if I recall it uses 10's to 100's of megabytes of VM to do its job. Not exactly a well-written program... :) Any programmers out there itching for something to write? Jeff
Re: ncurses build options...
On Fri, 8 Dec 1995, Jeff Noxon wrote: If the ncurses guys are going to keep blowing off binary compatibility, then perhaps we should not mess with ncurses at all. I suspect, especially now that we've got the package load spread around more, that Debian will be able to keep up. I'm just concerned that this is a losing battle. It might be fine for static libraries, but for shared libraries to be effective they need to remain compatible from one version to the next. Well, it's supposed to be faster, and, of course, BSD curses is no longer supported. I don't think BSD curses really needs support. I wish it wasn't such a pain to support two curses implementations at once. (It's a nightmare) As for faster, it is somewhat, but it's also a lot buggier at the moment. That doesn't necessarily excuse any of this mind you --- I've been on the ncurses list for all of a day and a half and I'm already hearing about 1.9.8 which apparently has some showstopper bugs that were reported but not fixed in time for the release. I have several months of the ncurses list archived. If anyone is interested in having a copy of the archive, please let me know how to deliver it. :) I suspect that the distributed packaging responsibility will make it unlikely that it will get that bad --- one or two versions, maybe, tops. Hmm. I'll be happy if we can just get a stable version, I suppose. This is going to be a big problem for Linux binary compatibility between distributions. Jeff
Re: ncurses build options...
ncurses-developer: static, debugging and profiling libraries (all in /usr/lib) Do we really need/want debugging and profiling libraries? No other packages currently provide these. I think the debug libraries, at least, are very useful to have. This is a package for developers, after all. :) Jeff
Re: -O2 or -O3 ?
Does anyone disagree with Brian White ? If not I'll change the guidelines back to recommending -O2. I don't disagree with Brian but am not sure he's adequately proven his point. He's only told us about what he found when compiling afio. Wouldn't it be wise to compare -O2 to -O3 on several (larger) packages before the guidelines are modified? I think function inlining is something that should be done only for performance-critical applications. The average debian package doesn't fit into that category. If you -O3 everything, you'll get bigger executables, you'll need more memory to run them in, and you'll need bigger hard drives to store them on. I wouldn't be surprised at all if they actually ran *slower* because more memory was being eaten up by useless inlining. People with 4MB and 8MB machines have the most to lose here. Let's save -O3 for packages that can benefit from it, like X servers and math applications. Jeff
Re: Bug#1895: run-parts does not run scripts without #!/...
Could I ask a favor that run-parts *skips* directories rather than reporting component /etc/cron.*/RCS is not an executable plain file. It's annoying that way... Thanks, Darren [EMAIL PROTECTED] http://www.daft.com/~torin/[EMAIL PROTECTED] [EMAIL PROTECTED] Absolutely. Jeff
Re: miscutils snag/questions for all
Bruce Perens wrote: As a rule of thumb, if you can get a program from the most-upstream source - for example the person who contributed it to BOGUS instead of BOGUS, get it from that source. That sounds fair. Unfortunately, some utilities (like fdisk) seem to be maintained (recently) only in util-linux. With BSD-derived programs, it seems obvious what to do. With Linux- specific utilities, things get somewhat complicated. Do we really want programs like fdisk to evolve differently in different distributions? If the answer is 'yes', then I would like to have an fdisk program that works like the one that comes with DOS. Then everyone would know what to do with it. :) But seriously, what's the best way to deal with linux-specific utilities? Are we content to let Debian diverge onto its own path, or are we committed to keeping things like 'fdisk' consistent among distributions? And what about all the bug fixes the util-linux team has put in fdisk? [Hint: there are quite a few, and I have limited resources when it comes to testing major changes to a package like that...] I asked Rik if he would add me to the util-linux developers' mailing list. (Answer: it's only for util-linux [BOGUS?] developers.) Too bad. He did seem pleased that someone working on Debian contacted him, but right away we got dangerously close to a religious war about how Linux distributions should be. It's a mess. I wish that all of the programs we need from util-linux were distributed separately, that way we could package them individually. I'd prefer to split util-linux into smaller packages, if you have time to do that. I'd prefer it that way. I'll work on it. If anyone else has any comments, please send me a note. Thanks, Jeff
Re: Bug#1895: run-parts does not run scripts without #!/...
Ian Jackson writes: The whole design of system() in Perl isn't conducive to good error-trapping. I suppose it might be better to use fork oneself. Jeff (you're the maintainer of this package, aren't you?) - would you like me to send you an update that uses fork directly and produces an error message in this case ? My plan is to rewrite run-parts in C or C++. However, I probably won't have that done until next weekend. I've never done any perl programming before, so i'd like to avoid making changes to the perl script unless you think this bug is urgent enough to warrant it. This still doesn't resolve the problem with --test listing scripts without #!. Any clever solutions to that one? :) Thanks, Jeff
Re: bogo-1.2-1 released
With all due respect, I fail to see any value in being able to calculate BogoMips from the command line. The uptime command provides accurate system load information in a much more useful format. The BogoMips calculation just wastes CPU cycles, which is certainly not something you would want to do on a heavily loaded system. The BogoMips calculation was only intended to calibrate delay loops in the kernel. Regards, Jeff fleabag cat /proc/cpuinfo | grep BogoMips BogoMips: 33.55 No - the /proc/cpuinfo doesnt get updated as the time goes by. It only get's updated at system boot up and wont update until you reboot again. This utility measures the BogoMips at any time by simply typing bogomips - for instance if your computer was doing something heavy then your load would be 30 25 20 etc instead of 33.55. It effectively runs the exact same thing at boot up time at the command line prompt.
Re: Bug#1895: run-parts does not run scripts without #!/...
I think I am going to rewrite run-parts in C. I don't know perl and don't have the time to learn it just to fix run-parts. :) Jeff Harald Schueler writes (Bug#1895: run-parts does not run scripts without #!/...): Package: miscutils Version: 1.3-5 Run-parts does not run scripts not beginning with #!/... This may not be a bug, but it should be documented. run-parts --test, however, displays _all_ scripts, which is rather confusing, and not a test at all. It does run them - or try to, anyway. It invokes `system' in Perl. Unfortunately Perl does the wrong thing when you say $foo='./t'; system($foo './u'); if ./t isn't a proper executable script. IMO it should produce a message to stderr, but it doesn't. Instead $? is set to 62580 and no message is produced. Ian.
Re: Bug#1896: fsck won't go because of elf?
I think we need to make ELF part of the kernel for Debian-1.0. It doesn't make sense to have it as a module anymore. Jeff Package: e2fsprogs Version: 1.01? During boot up the harddisk is checked before the modules (binfmt_elf) are loaded. The fsck/e2fsck utility is elf dependend but can't run without the module being loaded. -- Erick [EMAIL PROTECTED] +31-10-4635142 Department of General Surgery (Intensive Care) University Hospital Rotterdam NL
