Bug#2086: installation bugs/inadequacies
Hello Debian debuggers, I gave my first try to Debian after installing Slackware systems for nearly 2 years. Although I did prefer the Debian directory structure and help files I remain rather disappointed with the rest. The following applies to my trial with v0.93R6 on a 133MHz, 32Mb PCI with EIDE HD machine. * The base disks do not contain vi. This is unacceptable. * I definitely did not read all READMEs but, well, I had dd the debian 1440 base disks directly without gunzipping them beforehand. Debian was not able to recognize them :-( * Debian did not recognize my D-Link DE-530CT ethernet card with the de-4x5 driver (Slackware has no problem with this). * Ahhh, I had left out the PPP option and the whole system stayed hanging at boot-up trying to initialise a serial connection. Debian is silly... * Debian should check for the existence and show its contents to the user of /etc/init.d/network before updating. Debian appended data to the file and screwed things up... * Debian should ask from the start what keyboard I use and react accordingly . (Hint: Slackware does that, why not Debian?) * It was not possible to format a diskette using the installation program :-( Overall: I haven't been much further than base installation (I hoped I could ftp the rest of Debian to the root directory before going on). The installation program interface looks nice and clean but has a long way to go before being as convenient as Slackware's Setup. Cheers, -T.Netter CNRS National Center for Scientific Research, France
Re: binary-alpha and binary-sparc directories
Raul Miller wrote lately: > > Ian Murdock: >I doubt there'll be a substantial number of architecture-neutral >packages; we can either copy or link them into all of the trees. > > I suppose this depends on what you mean by substantial... Here's a > list of packages that appear to be architecture-neutral, by cursory > examination on my system. > any package which needs to be compiled is of course not arch-independent. on my system here (sunos, not debian ;-)) at least the following are partially compiled: > ii dvips5.58f 2TeX DVI-driver for Postscript > ii fort77 1.6 1An f2c front end to make it look like a > compile > ii makeidx 2.12 Makeindex, a general purpose index processor > ii metafont 2.71 2Metafont - TeX's font engine > ii xdvi 1.8f 2A TeX DVI-previewer for X11 the following is even in the source not arch-independent: > ii syslinux 1.20 0Boot disk creator. of the following i don't know (now) which files are included. some files which i call auxilary files (eg the string pool) are also arch-dependent, but they might not be included in this package. > ii mflib 1.0 5Auxiliary files to run Metafont > ii texlib 1.0 4Auxiliary Files to run TeX bye jjm -- Juergen Menden | Disclaimer: The opinions expressed by me, tel:+49 (89) 2051 - 2387 +---+ are (usually) not the opinions e-mail: [EMAIL PROTECTED] | of anyone else on this planet. Hi! I'm a .signature virus! Add me to your .signature and join in the fun!
Bug#2085: /usr/lib/termcap/l/linux kbs Capname definition questioned
PACKAGE: ncurses3.0 VERSION: 1.9.8a-3 I noted some problems in the ae.rc file in the ae-493-9.deb package I just uploaded after rebuilding it and several other packages for ncurses3.0 compatability. In checking into this, I came across an apparent problem with /usr/lib/terminfo/l/linux. In /usr/lib/kbd/keytables/us.map, I see the following: keycode 14 = Delete Delete control keycode 14 = BackSpace alt keycode 14 = Meta_Delete and: keycode 83 = KP_Period altgr control keycode 83 = Boot control alt keycode 83 = Boot and: keycode 111 = Remove altgr control keycode 111 = Boot control alt keycode 111 = Boot and: string Remove = "\033[3~" Keycode 14 is produced by the key I'd call "backspace". Keycode 83 is produced by the Keypad Period (also DEL) key. Keycode 111 is produced by the Delete key. I have no problem with the Keycode 83 and 111 keys, but I do have a problem with the Keycode 14 key. On initial login with no special stty setup done, "stty -a" reports that the special char for erase is set to ^?. That works OK, and is compatable with the above. Pressing the "backspace" key deletes one char to the left. However, "infocmp linux" reports that kbs=^H. Considering the Keycode 14 assignments, it's necessary to press either Control-H or Control-Backspace for a program using terminfo with TERM=linux to see the kbs Capname code. It seems reasonable to me that pressing just the backspace key without the control key should produce the kbs Capname code. This suggests that either us.map (and, probably *.map) should be changed or that /usr/lib/terminfo/linux should be changed. Since the keytable maps impact much more than terminfo, it looks to me as if /usr/lib/terminfo/linux should be changed from kbs=^H to kbs=^?. Or am I missing something which should be obvious to me? [EMAIL PROTECTED] (Bill Mitchell)
Bug#2084: BUG: time conversion in trn
Hello, there is a bug in trn, also present in the upstream version. By now most people will have discovered it as it started on 1 Januari. There is a bug in the NNTP time conversion which causes trn to think there are a lot of new newsgroups every time it starts up. I've fixed it for now - the real fix would be to use the ANSI mktime() function instead. I think it is the package maintainers task to report this to Wayne Davidson? --- nntp.c.ORIG Tue Jan 2 23:29:37 1996 +++ nntp.c Wed Jan 3 11:23:53 1996 @@ -319,7 +319,7 @@ for (month--; month; month--) day += maxdays[month]; -ss = year-1970) * 365 + (year-1968)/4 + day - 1) * 24L + hh) * 60 +ss = year-1970) * 365 + (year-1969)/4 + day - 1) * 24L + hh) * 60 + mm) * 60 + ss; return ss; -- Miquel van| Cistron Internet Services --Alphen aan den Rijn. Smoorenburg, | mailto:[EMAIL PROTECTED] http://www.cistron.nl/ [EMAIL PROTECTED] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)
sysvinit-2.58-1 uploaded [elf]
Date: 02 Jan 96 22:58 UT Source: sysvinit Binary: sysvinit Version: 2.58-1 Description: sysvinit: System-V-like Init. Priority: Medium Changes: New Maintainer New upstream version (well, this _is_ the upstream version) .deb binaries built as ELF sulogin included Files: -rw-r--r-- 1 miquels staff 77366 Jan 2 22:20 sysvinit-2.58-1.tar.gz -rw-r--r-- 1 root staff 45775 Jan 2 22:10 sysvinit-2.58-1.deb e581101e4a5cd6611c4acd9f61e2c336 sysvinit-2.58-1.tar.gz f043a8af4d51cb0ae486b5a4c13fda25 sysvinit-2.58-1.deb -- Miquel van| Cistron Internet Services --Alphen aan den Rijn. Smoorenburg, | mailto:[EMAIL PROTECTED] http://www.cistron.nl/ [EMAIL PROTECTED] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)
Bug#2083: machine hangs when ftping large file
The problem is due to your Intel Etherexpress. That card is _evil_. They are to slow for fast LANs and get out of sync. I tried to use one (given as a loan) for some months last year, There were zillions of similar bug reports on comp.os.linux.networking. While I agree that this answer is unsatisfactory as the system shouldn't hang, all I can recommend is to simply get a new card. I switched to a supercheap NE2000 clone that can be had for 30-35 US. And I have no problem at all. Not one byte lost. -- Dirk Eddelb"uttel http://qed.econ.queensu.ca/~edd
Bug#2069: GNU last doesn't use ut_addr
[EMAIL PROTECTED]: > I have reported this to the upstream maintainer. He promised me new acct code > (last is part of acct) about six months ago, so don't hold your breath. How about using last from util-linux? It has the standard BSD copyright, there are no patent issues that I know of, it knows about ut_addr, and even comes with a man page :-). Is the GNU last better? Why? Regards, Marek
Bug#2069: GNU last doesn't use ut_addr
You ([EMAIL PROTECTED]) wrote: > > Marek> Is the GNU last better? Why? > > We went through this before when I split last from the acct package to have a > single last package for the /base/ section. Some people where proposing to > use the BSD one, others recommended to keep the GNU last, and so we did. Take > your pick. The discussion should be in the mailing list list archive. There is a last with the GNU copyright in sysvinit. It isn't compiled and installed by default, but it is small and fast. -- Miquel van| Cistron Internet Services --Alphen aan den Rijn. Smoorenburg, | mailto:[EMAIL PROTECTED] http://www.cistron.nl/ [EMAIL PROTECTED] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)
Bug#2083: machine hangs when ftping large file
>The network card is an Intel Etherexpress 16. This is the problem right here. The Intel driver, when confronted with a large file being transferred over a local subnet on a fast (P5) system, will spool a zillion messages to your syslog (as the errors mount) and then fall over. I have verified this with both Slackware and Debian. Solution: Get a new Ethernet card, or a slower machine. Something like the BOCA BocaLan PCI with the AMD Lance is nice. Mike. -- "I thought I'd something more to say."
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
Bug#2069: GNU last doesn't use ut_addr
Miquel van Smoorenburg writes: Miquel> There is a last with the GNU copyright in sysvinit. It isn't Miquel> compiled and installed by default, but it is small and fast. That sounds good to me. As your sysvinit package is part of every Debian installation, we could use this 'last' binary and drop the last package derived from acct. Comments, anyone? -- Dirk Eddelb"uttel http://qed.econ.queensu.ca/~edd
Bug#2069: GNU last doesn't use ut_addr
Marek Michalkiewicz writes: Marek> [EMAIL PROTECTED]: Dirk> I have reported this to the upstream maintainer. He promised me new Dirk> acct code (last is part of acct) about six months ago, so don't hold Dirk> your breath. Marek> How about using last from util-linux? It has the standard BSD Marek> copyright, there are no patent issues that I know of, it knows about Marek> ut_addr, and even comes with a man page :-). The usual answer: if you want something that isn't there, you will have to package it yourself. Marek> Is the GNU last better? Why? We went through this before when I split last from the acct package to have a single last package for the /base/ section. Some people where proposing to use the BSD one, others recommended to keep the GNU last, and so we did. Take your pick. The discussion should be in the mailing list list archive. -- Dirk Eddelb"uttel http://qed.econ.queensu.ca/~edd
Bug#2087: ppmforge seg faults
Package: pbmplus Version: 10dec91 Rev 2 ppmforge -stars produces an image which appears to be truncated, then stops with a Segmentation fault error. Example: % ppmforge -stars 0 > junk ppmforge: planet: -seed 1357751156 -dimension 2.40 -power 1.20 -mesh 256 ppmforge: -inclination 18 -hour 12 -ice 0.40 -glaciers 0.75 ppmforge: -stars 0 -saturation 125. Segmentation fault This error appears to be independent of the numeric option given to stars. That is, the program also segfaults with "-stars 100". If one then attempts to show the output image with 'xv', the result is an error message "junk: file appears to be truncated". Despite this, xv succeeds in showing that part of the image which is not truncated (which is 98% of it). Two other options fail in the same way: ppmforge -clouds ppmforge -planet The portion of the image which is being truncated can be illustrated fairly dramatically using: ppmforge -clouds | xv -root -quit - On the other hand, this succeeds: ppmforge -stars Interestingly, this is the only one of the options which produces only black and white output. This system has: === ii base0.93.6 13 Debian Base System Miscellaneous Files ii image 1.2.13 5Linux kernel binary image. ii ldso1.7.10 1The Linux dynamic linker, library and utilities ii libc4.6.27 6The Linux C library. ii pbmplus10dec91 2An extended portable bitmap toolkit. ii xlib 3.1.2 2XFree86 3.1.2 shared libraries. ii xs3 3.1.2 1XFree86 3.1.2 S3 server. ii xv 3.10a 1Interactive image display for the X Window Syst === Susan Kleinmann [EMAIL PROTECTED]
Bug#2085: usr/lib/termcap/l/linux kbs Capname definition questioned
In my ncurses program with keypad() and meta() TRUE, I think backspace came through as key code 127, and DEL came through as the symbolic key name KEY_DC. I think this supports your argument, but I can't say I've looked at this at all deeply. Bruce -- Bruce Perens <[EMAIL PROTECTED]> Pixar Animation Studios Toy Story: > US$150M domestic box office receipts so far.
Re: binary-alpha and binary-sparc directories
[This goes to debian-devel only.] Raul Miller writes: Raul> It does look like dvips was superceeded by some other package, and Raul> that it did originally have some executables in it. Nils switched to the upstream convention of reflecting the 'k' for Karl Berry's kpathsea in the package name. I had moaned about this weeks ago. You have to manually delete dvips after installing dvipsk, xdvi after xdvik etc. A "Conflicts:" in debian.control might have helped here. Or a new "Replaces:" field. Raul> /usr/bin/fort77 is a perl script, the only other things I see in this Raul> package are a man page and a copyright statement. Since I have f2c Raul> on my system as a separate package, I'd guess that fort77 has also Raul> been superceeded... Nope. f2c is a pain as far as the interface is concerned. fort77 is a pretty little perl beauty that gives it an f77-like interface so that you can seamlessly use Makefiles that assume you have f77. (I also linked it to f77.) [...] -- Dirk Eddelb"uttel http://qed.econ.queensu.ca/~edd
Bug#2083: machine hangs when ftping large file
> 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. I've a dirt-cheep (ie, I got it for free) NE2000 clone with a UMC chip on it. Over unloaded ethernet, I can send at about 1200-1300 k/sec (the theoretical max of ethernet), but only recieve at 500 or so (can't win em all, I guess). I've a P-120, and the card is 16 bit ISA. - John Larkin
dpkg Replaces: field (was Re: binary-alpha and binary-sparc directories)
'[EMAIL PROTECTED] wrote:' > > Raul Miller writes: > Raul> It does look like dvips was superceeded by some other package, and > Raul> that it did originally have some executables in it. > >Nils switched to the upstream convention of reflecting the 'k' for Karl >Berry's kpathsea in the package name. > >I had moaned about this weeks ago. You have to manually delete dvips after >installing dvipsk, xdvi after xdvik etc. A "Conflicts:" in debian.control >might have helped here. Or a new "Replaces:" field. Yes, this seems to me a good idea. Conflicts involves too much administrator intervention. Ian, can we have this feature in dpkg? -- Christopher J. Fearnley|UNIX SIG Leader at PACS [EMAIL PROTECTED] (finger me!)|(Philadelphia Area Computer Society) http://www.netaxs.com/~cjf |Design Science Revolutionary ftp://ftp.netaxs.com/people/cjf|Explorer in Universe "Dare to be Naive" -- Bucky Fuller |Linux Advocate
Bug#2089: lrzsz hangs
Package: lrzsz
Version: 0.11
If the connection closes while lrz is downloading a file, lrz will hang.
This happens because the maintainer of the package commented out all of the
calls to signal(). I fixed the declarations of the signal handlers instead.
I'll append my patches. Thanks in advance for integrating them. I would
offer to take over the package, but I don't really use it and don't have
time to read the source code of dpkg/dselect. (Is there any documentation
yet?)
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
*** lrz.c.~1~ Sun Jul 17 08:29:48 1994
--- lrz.c Sat Dec 9 00:36:51 1995
***
*** 131,143
#include "zm.c"
int tryzhdrtype=ZRINIT; /* Header type to send corresponding to Last rx
close */
!
! alrm()
{
! longjmp(tohere, -1);
}
/* called by signal interrupt or terminate to clean things up */
bibi(n)
{
if (Zmodem)
--- 131,148
#include "zm.c"
int tryzhdrtype=ZRINIT; /* Header type to send corresponding to Last rx
close */
! #ifdef LINUX
! void
! #endif
! alrm(int signum)
{
! longjmp(tohere, signum);
}
/* called by signal interrupt or terminate to clean things up */
+ #ifdef LINUX
+ void
+ #endif
bibi(n)
{
if (Zmodem)
***
*** 240,246
}
vfile("%s %s for %s\n", Progname, VERSION, OS);
mode(1);
! #ifndef LINUX
if (signal(SIGINT, bibi) == SIG_IGN) {
signal(SIGINT, SIG_IGN); signal(SIGKILL, SIG_IGN);
}
--- 245,251
}
vfile("%s %s for %s\n", Progname, VERSION, OS);
mode(1);
!
if (signal(SIGINT, bibi) == SIG_IGN) {
signal(SIGINT, SIG_IGN); signal(SIGKILL, SIG_IGN);
}
***
*** 248,254
signal(SIGINT, bibi); signal(SIGKILL, bibi);
}
signal(SIGTERM, bibi);
! #endif
if (wcreceive(npats, patts)==ERROR) {
exitcode=0200;
canit();
--- 253,259
signal(SIGINT, bibi); signal(SIGKILL, bibi);
}
signal(SIGTERM, bibi);
!
if (wcreceive(npats, patts)==ERROR) {
exitcode=0200;
canit();
***
*** 574,582
fprintf(stderr, "Readline:TIMEOUT\n");
return TIMEOUT;
}
! #ifndef LINUX
signal(SIGALRM, alrm); alarm(n);
! #endif
Lleft=read(iofd, cdq=linbuf, Readnum);
alarm(0);
if (Verbose > 5) {
--- 579,587
fprintf(stderr, "Readline:TIMEOUT\n");
return TIMEOUT;
}
!
signal(SIGALRM, alrm); alarm(n);
!
Lleft=read(iofd, cdq=linbuf, Readnum);
alarm(0);
if (Verbose > 5) {
*** lsz.c.~1~ Sun Jul 17 08:29:57 1994
--- lsz.c Sat Dec 9 00:46:35 1995
***
*** 145,150
--- 145,153
jmp_buf intrjmp; /* For the interrupt on RX CAN */
/* called by signal interrupt or terminate to clean things up */
+ #ifdef LINUX
+ void
+ #endif
bibi(n)
{
canit(); fflush(stdout); mode(0);
***
*** 157,165
exit(128+n);
}
/* Called when ZMODEM gets an interrupt (^X) */
! onintr()
{
! signal(SIGINT, SIG_IGN);
longjmp(intrjmp, -1);
}
--- 160,171
exit(128+n);
}
/* Called when ZMODEM gets an interrupt (^X) */
! #ifdef LINUX
! void
! #endif
! onintr(int signum)
{
! signal(signum, SIG_IGN);
longjmp(intrjmp, -1);
}
***
*** 333,339
mode(1);
- #ifndef LINUX
if (signal(SIGINT, bibi) == SIG_IGN) {
signal(SIGINT, SIG_IGN); signal(SIGKILL, SIG_IGN);
} else {
--- 339,344
***
*** 342,348
if ( !Fromcu)
signal(SIGQUIT, SIG_IGN);
signal(SIGTERM, bibi);
- #endif
if ( !Modem2) {
if (!Nozmodem) {
--- 347,352
***
*** 840,849
}
}
!
! alrm()
{
! longjmp(tohere, -1);
}
--- 844,855
}
}
! #ifdef LINUX
! void
! #endif
! alrm(int signum)
{
! longjmp(tohere, signum);
}
***
*** 867,875
if (Verbose>5) {
fprintf(stderr, "Timeout=%d Calling alarm(%d) ", timeout, c);
}
! #ifndef LINUX
signal(SIGALRM, alrm); alarm(c);
! #endif
c=read(iofd, byt, 1);
alarm(0);
if (Verbose>5)
--- 873,881
if (Verbose>5) {
fprintf(stderr, "Timeout=%d Calling alarm(%d) ", timeout, c);
}
!
signal(SIGALRM, alrm); alarm(c);
!
c=read(iofd, byt, 1);
alarm(0);
if (Verbose>5)
***
*** 1236,1254
c = getinsync(1);
goto gotack;
case XOFF: /* Wait
beware sysvinit 2.58 installation
Hi! 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. Helmut -- Helmut Geyer[EMAIL PROTECTED]
Re: binary-alpha and binary-sparc directories
Juergen Menden: any package which needs to be compiled is of course not arch-independent. on my system here (sunos, not debian ;-)) at least the following are partially compiled: > ii dvips5.58f 2TeX DVI-driver for Postscript > ii fort77 1.6 1An f2c front end to make it look like a > ii makeidx 2.12 Makeindex, a general purpose index proce > ii metafont 2.71 2Metafont - TeX's font engine > ii xdvi 1.8f 2A TeX DVI-previewer for X11 ... It does look like dvips was superceeded by some other package, and that it did originally have some executables in it. [All I have on my system from dvips is a copyright statement and some .tex files]. makeidx, metafont and xdvi also seem to be mere stubs of packages on my system. /usr/bin/fort77 is a perl script, the only other things I see in this package are a man page and a copyright statement. Since I have f2c on my system as a separate package, I'd guess that fort77 has also been superceeded... I think this is a bug in the debian packaging mechanisms. The current mechanism presumes that files of the same name are drop-in replacements for each other. It currently manages the archive by removing all references to a file but the most recent package to provide the file. This was conceived of as a way of managing packages which are partially provided for on the base disks. However, a better way of managing base packages is to record the partial installation of the packages and mark them with a suitable status code (for example, "unpacked"). Then, when they're installed "for real" dpkg can treat these the same as any other incomplete package installation. For the more general case of packages which inadvertently provide the same facilities, when one of the packages is removed the other may become nonfunctional. It's perfectly all-right for the most recent package to be installed to provide the files for an ambiguous case. But, the fact that another package needs the file should also be recorded. Only one package can have supplied the physical instance of the file, but the file might be included with more than one package. Or, perhaps it would be simpler for dpkg to protest and refuse to install a package if it has a file-overlap with another package? Either way, the present behavior invites errors. -- Raul
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.
Bug#2088: README.fdisk gone missing.
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: 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
FTP site performance low
Is there any prediction how long the FTP site will be bombarded by people retrieving netscape? Is this going to be a regular occurrance? It's perhaps a bit too slow for mirror scripts to run well. Performance from here seems to be about 1K/second or less. Thanks Bruce -- Bruce Perens <[EMAIL PROTECTED]> Pixar Animation Studios Toy Story: > US$152M domestic box office receipts so far.
Bug#2090: no "uncompress" in gzip package
Package: gzip Version: 1.2.4-6 uncompress should be a link to gunzip, as many programs (such as w3.el) as well as users expect to be able to run uncompress on *.Z files. (gunzip handles this fine, it's just a matter of naming...) I'm using debian 0.93r6.
Re: FTP site performance low
On Wed, 3 Jan 1996, Bruce Perens wrote: > Is there any prediction how long the FTP site will be bombarded by people > retrieving netscape? Is this going to be a regular occurrance? It's perhaps > a bit too slow for mirror scripts to run well. Performance from here seems > to be about 1K/second or less. Well limits were just droped since we are close to school starting again. Well netscape corp screwed me with politics and listed me in their mirror listings. Well there used to be more mirrors but it seems that we are one of three listed now. And until beta 5 or release version are out I can not get out of their list. And I can not remove their software until this happens. So for now please use a mirror. Or get the files during the day when there is fewer users. -- Matthew S. Bailey 107 Emmons Hall Central Michigan University Mt. Pleasant, MI 48858 [EMAIL PROTECTED] ... Any resemblance between the above views and those of my employer, my terminal, or the view out my window are purely coincidental. Any resemblance between the above and my own views is non-deterministic. The question of the existence of views in the absence of anyone to hold them is left as an exercise for the reader. The question of the existence of the reader is left as an exercise for the second god coefficient. (A discussion of non-orthogonal, non-integral polytheism is beyond the scope of this article.)
New expect package
Date: 04 Jan 96 03:17 UT Source: expect Binary: expect Version: 5.18.1-1 Description: expect: The expect/expectk programs and libraries. Priority: Low Changes: Updated to new upstream version. . Converted to ELF. Files: -rw-rw-r-- 1 root src391071 Jan 3 21:16 expect-5.18.1-1.tar.gz -rw-rw-r-- 1 root src 1556 Jan 3 21:17 expect-5.18.1-1.diff.gz -rw-r--r-- 1 root src367400 Jan 3 21:16 expect-5.18.1-1.deb 938c64ad8afaaac8cd6e81d16c0bd33b expect-5.18.1-1.tar.gz 8a3ca0378c75b79f20f1fa9280c85f2c expect-5.18.1-1.diff.gz 7a6680b826b44271313413f009708635 expect-5.18.1-1.deb -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
