Bug#1978: man: default pager should be less
It is ultimately a user choice whether less or more is used by the manual pager. The only reason more is used as the default is because it's a required component of the base system. Less is twice the size of more, which is why more is in the base system rather than less. I suspect that more could be taught to back up easily enough. I was surprised to find that less has more options than ls, and if you read its manual page it looks as if it is intended to emulate an editor. 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. Thanks Bruce -- Visit the Toy Story Web Page! http://www.toystory.com
Where 1.0 is
It is now back in ftp://ftp.debian.org/debian/ALPHA-TEST/debian-1.0 . However, ALPHA-TEST is now unreadable to foil the mirror sites. You know the drill to get through it. I think Matt Bailey moved it, but I wish he'd provided us a way to get at it in its new location before he did that. People are working on ELF tonight. Thus, I took the liberty of putting it back. I have taken enough liberties today for the entire rest of the month. Someone please find Ian. Thanks Bruce -- Visit the Toy Story Web Page! http://www.toystory.com
Bug#1992: w has invalid option
Package: procps Version: 0.97-4 Hi.. With the manual page for w it talks about the option -n, however the -n option fails with w at the prompt - hence: [EMAIL PROTECTED]:12:~] w -n w: illegal option -- n usage: w: [ -hi ] [user] [EMAIL PROTECTED]:12:~] Regards, ...Karl -- | PO Box 828 Office: (09)316-3036 Fax: (09)381-3909 |OWER INTERNET SERVICES Canning Bridge After Hours: 015-779-828 WA, 6153 Sales Support: [EMAIL PROTECTED] Internet Service Providers and Networking Solutions
re:Where 1.0 is
It is now back in ftp://ftp.debian.org/debian/ALPHA-TEST/debian-1.0 . However, ALPHA-TEST is now unreadable to foil the mirror sites. Will this become readable once it is decided that this is for-sure its final resting place? Having mirror sites include 1.0 (if they desire) is, IMO, a good idea as it makes getting it easier for those of us that want it and reduces the load on ftp.debian.org. I find my local mirror invaluable and several of us depend upon it for fast access to the 1.0 tree. I think that having it under an ALPHA directory is enough warning to everyone not to use it unless they know what they are doing? You know the drill to get through it. Actually, I don't. smile Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: Where 1.0 is
On Fri, 8 Dec 1995, Bruce Perens wrote: It is now back in ftp://ftp.debian.org/debian/ALPHA-TEST/debian-1.0 . However, ALPHA-TEST is now unreadable to foil the mirror sites. You know the drill to get through it. I think Matt Bailey moved it, but I wish he'd provided us a way to get at it in its new location before he did that. People are working on ELF tonight. Thus, I took the liberty of putting it back. I have taken enough liberties today for the entire rest of the month. Someone please find Ian. I moved it because all the mirror sites were sucking it down, I wanted a solution before this was retreived(SP?) by every site on the net again just incase it was going back to its original spot. The symlinks that were there can cause mirror sto go nuts. Atleast bruce set it so world could not read it. -- 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.)
Re: 1.0 on Infomagic CD
On Fri, 8 Dec 1995, Bruce Perens wrote: [...] We can't put stuff like this where just anybody can download it any longer. Especially, we can't do that and call it 1.0. This isn't entirely Infomagic's fault, in my opinion. I suggested some time ago to call the directories: release-0.93/ not-released-1.0/ Maybe it was not such a bad idea...
Re: 1.0 on Infomagic CD
On Sat, 9 Dec 1995, Fernando Alegre wrote: release-0.93/ not-released-1.0/ The whole problem is nothing more than hindsite now, so lets drop it an update of whats is going to happen is forth coming. -- 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.)
Infomagic and 1.0
Since Infomagic has pressed the CDs, I wonder if it'd be possible to get them to include an insert with distributed CDs explaining the situation. Otherwise CD buyers are going to be put off debian when they try it from the CD. Just a thought. [EMAIL PROTECTED] (Bill Mitchell)
1.0 and package announcements
If package uploads are going to go into 1.0 and not 0.93, and if we're going to take steps to privatize 1.0, perhaps we should stop posting announcements of package uploades to debian-changes. Actually, I think the changes files should be uploaded, and appropriate public package announcements made from the distribution site when the packages are moved into public view. [EMAIL PROTECTED] (Bill Mitchell)
Re: ncurses build options...
ncurses-bin-1.9.7a-1.deb will contain the terminfo database manipulation files. It will depend on ncurses2. It should also depend on libc5. I've been going on the assumption that since it's dependent upon ncurses21, which is in turn dependent on libc5, that dpkg/dselect would DTRT. Is this wrong, or is just recommended that we be paranoid? Nevermind me. I was thinking about the hopefully unlikely case where libc6 suddenly came out and we had to rebuild ncurses21 with it. I eventually realized that if that did happen, we would just use a new major number and package name. So when tcl 7.5 comes out, you'll make tcl75-dev conflict with tcl74-dev? That makes fine sense. I was planning on doing this with Yes, but not directly. The way I did it was to have tcl74-dev both provide and conflict with the virtual package tcl-dev. When tcl75-dev comes out, it will do the same thing. This has the advantage of only allowing one tcl*-dev package to be installed at a time without having to explicitly conflict with every other package. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Re: Infomagic and 1.0
On Sat, 9 Dec 1995, Bill Mitchell wrote: Since Infomagic has pressed the CDs, I wonder if it'd be possible to get them to include an insert with distributed CDs explaining the situation. Otherwise CD buyers are going to be put off debian when they try it from the CD. Really they should destroy them! but I am only dreaming. Their covers should atleast be changed to say Alpha 1.0 of debian or some such. Or just remove the debian name from the all together and just leave it on the rom for those adventurous(SP?) types... Bill: I will fix the upload permission as soon as I talk to Ian M. he seems to be all but off the face of the earth. -- 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.)
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: 1.0 on Infomagic CD
Surprisingly, they stopped their mirror on November 18, before we'd put all of the README.DONT.USE.THIS files and so on in place. If they'd seen that file they probably would not have copied the archive. I think having an ALPHA-TEST subdirectory is sufficiently clear. Bruce -- Visit the Toy Story Web Page! http://www.toystory.com
Bug#421: unreasonable restriction on term
Return-Path: [EMAIL PROTECTED] Tue, 19 Sep 1995 14:31:41 +0200 Date: Tue, 19 Sep 1995 14:31:41 +0200 From: [EMAIL PROTECTED] (Sven Rudolph) Message-Id: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Bug#421: unreasonable restriction on term You already changed the DEPENDS to RECOMMENDED, so the problem is solved and you should close the bug. (It might make sense to invent a name for a dialer virtual package, but you have to ask debian-devel about it.) Please write me if you believe that I got somthing wrong. Sven -- Sven Rudolph ([EMAIL PROTECTED]); WWW : http://www.sax.de/~sr1/
Bug#1994: Lynx License
The DRAFT Lynx license would let us distribute with no problem. We just have to urge them to move it from draft to actual status. Bruce -- Visit the Toy Story Web Page! http://www.toystory.com
Re: debian-1.0 availability
Dear Robert Leslie! }I don't know about other mirrors, but AFAICT tsx-11.mit.edu doesn't even carry }the 0.93R6 release any more. It only offers debian-1.0. I have just looked at sunsite. I thought they carry the whole tree, but they don't. They only offer 0.93*. That's ok. Regards, Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / Es braucht dann allerdings Tage, bis jemand / / sehr lange Ohren bekommt. -- Lutz Donnerhacke zu Spamcancels /
manpages-1.8 .tar.gz .diff.gz
Good morning folks, I took over the manpages package, but I can't find these files anywhere. I only see a .deb package. Could someone please send me these files. Thanks. Have a pleasant day, Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / +49-441-777884 * LoginPasswd: nuucp * Index: ~/ls-lR.gz / / This copy of Netscape has expired. -- Netscape / /Ein weiterer Grund Mosaic zu benutzen. :-( /
Bug#1995: run-parts on laptops
Package: miscutils Version: 1.3 Revision: 5 run-parts should probably not do what it normally does, when a laptop doesn't have AC power. This could be implemented with something along the lines of: die helpful message\n unless system grep 'AC: off line' /proc/apm 2/dev/null; Presumably, the helpful message would identify some option to use (e.g. manually) to get run-parts to do its thing even without external power. That is, there should be some option (or lack of option) for run-parts to run even without external power, and when run-parts shuts down for lack of power, it should document this option and the original argument. The logic here is that hard disk access on a laptop is very hard on the battery. Running find from cron.daily or cron.weekly could drain the battery entirely, leaving an unusable system. -- Raul
legal to export DES outside of the US via Canada? (fwd)
I was reading this tidbit of info and thought some of you might like it... Anyway to make our DES legal All I have to have is a canadian mirror site who will mirror EVERYTHING from the tree then all out of US mirror sites mirror from this point. This would fix our export problem without breaking any laws. YEAH! Canada is good for something :) *grin* Enjoy! --- Forwarded Message Subject: crypto software export Date: Fri, 08 Dec 1995 12:05:22 -0700 Precedence: bulk I just got confirmation from the Canadian government that free software is not controlled by any cryptographic export or usage laws in Canada. Yes, this means we're free to include any and all cryptographic stuff that we want in any place in the source tree, as long as licensing, patent, etc. issues are handled. The actual text of the law is being mailed to me. I'll be able to quote from it later if anyone wants further details. BTW, in a twist of law, when I asked about ITAR the gentleman said that ITAR doesn't enter into the picture at all. Apparently one could bring ITAR code into Canada, and the Canadian government has no law on the books to prevent it from being re-exported to the world. I'd always suspected this loophole; the fellow picked up rather quickly on what I was suggesting. and made it clear that there'd be no law to prevent one from doing so! (not that I want to re-export ITAR) --- End of Forwarded Message
announcing ncurses 1.9.8a (fwd)
Well, I figure all the work I did on 1.9.7a will apply to 1.9.8a. Also, Jeff, they're almost promising the ABI will quit changing! Mike. -- I'm a dinosaur. Somebody's digging my bones. -- Forwarded message -- Date: Fri, 8 Dec 1995 21:29:57 -0800 From: Zeyd M. Ben-Halim [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: announcing ncurses 1.9.8a I've uploaded version 1.9.8a of ncurses as ftp://ftp.netcom.com/pub/zm/zmbenhal/ncurses/ncurses-1.9.8a.tar.gz This essentially 1.9.8 + Tom's patches including my omission of TABSIZE. I had indicated to Eric and Tom that if I didn't hear from them by the end of last Sunday, I'd make 1.9.8 public. Unfortunately I put in my ftp directory and then had flakey net connections since during getting our office on the internet. I built 1.9.8a on Linux, AIX, and SunOS (with gcc) with no problems. The debian people have been bitching at the frequent changes in the shared library ABI and I understand their frustration. But I (we) never promised binary compatibility, just offering people the means of building shared libraries. People have to realize that Linux is NOT the only platform that ncurses is aimed at, nor am I the official ncurses keeper for Linux. I'm more than happy to take any input regarding the packaging of ncurses, but I can't cater to the whims of every Tom, Dick, and Harry. Distribution makers are free to re-package ncurses any way they see fit. The change to the ABI are forced by the nature of ncurses as a library that makes extensive use of macros, while trying to maintain compatibility with SVSR4 and XSI curses. 1.9.8a includes the major effort to conform and I have thus changed the ABI to 3.0, where I hope it will stay. I will try to restrain Eric from running amok through the public interface :-) I'll upgrading to ELF in the next week or so; that will allow me to get a better handle on the shared libraries under Linux. Enjoy, Zeyd
Re: bumping the version number
On Fri, 8 Dec 1995, Bruce Perens wrote: I think we should deprecate 1.0 and bump the version number to 1.1, so that authentic copies of the release are not confused with the one on the Infomagic CD. This is a good idea. Regarding the use of a code name for the release: Considering what's happened, that would be a good idea, too. I agree that development would be a good name. I wouldn't make the development release *too* hard to get to, as a few people have suggested doing. I think that having a separate login for getting it is excessive. It's in our best interest to make the development release as easy to get to as possible, so as many users (who all know what they're getting into!) can install it and help us make the released version more stable. I'd rather make it more obvious than we've been doing that 1.1 is a development, not a released, version. I think that renaming the place where it's stored on the FTP archive development and moving it to an unreadable directory (with the name of this unreadable directory named in a README file, after the disclaimers, warnings, etc.) is sufficient.
ncurses available on ftp.pixar.com
Since ftp.debian.org seems to still be having problems with people downloading new files, I'm putting a copy of ncurses-1.9.8a in ftp://ftp.debian.org/pub/bruce/Incoming, since a handful of people have contacted me since yesterday to ask if I could send them copies directly. I think ncurses wins an award for most packages from one source archive. Mike. -- I'm a dinosaur. Somebody's digging my bones.
Re: ncurses available on ftp.pixar.com
Another problem: ncurses-base-1.9.8a-1.deb should have a debian.preinst to kill the link etc/terminfo - ../usr/lib/terminfo provided by base-0.93.6. Or it is intended that these fall into /usr/lib/terminfo? And how to elegantly get rid of the huge /usr/lib/terminfo database w/o installing and purging? mfg Rolf Rossius
Re: ncurses available on ftp.pixar.com
On Sat, 9 Dec 1995, Michael Alan Dorman wrote: Since ftp.debian.org seems to still be having problems with people downloading new files, I'm putting a copy of ncurses-1.9.8a in ftp://ftp.debian.org/pub/bruce/Incoming, since a handful of people have contacted me since yesterday to ask if I could send them copies directly. I think ncurses wins an award for most packages from one source archive. Whoaaa now! there is a definite reason for this There is NO problem with uploads. The fact that I receive 10-5 mails a day to ftpadmin about corrupt files in private/project/Incoming made me opt for this method. This should be for INCOMING use only. the files will be available as soon as the ftp site maintainer moves them into the public trees. I don't even care if all he does is move them to a different tree like Arrived or some such. but Incoming is just that Incoming and should not be used for downloading. This has also come from the few pieces of software that have been uploaded to the directory that were far from free. So I am sorry some of you don't like this but this is the way it will have to be. Bruce doesn't allow for downloads from his Incoming tree either the last I knew. He had to move them out to a directory called Debian instead. Please do not upload to ftp.pixar.com unless there is an absolute need. -- 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.)
Re: Source package format - a simple proposal
On Sat, 9 Dec 1995, Ian Murdock wrote: On Mon, 27 Nov 1995, Bruce Perens wrote: From: Ian Jackson [EMAIL PROTECTED] 6a. No unnecessary up/down-loading by maintainers. Is this such a big issue? With your overseas FTP problems you can judge that, but I'd feel more confident if the maintainer uploaded the entire package as one piece. I agree. I think that providing patches only would be a bad idea, for reasons that have already been described here. I am strongly of the opinion that we should provide source packages in an easily-rebuildable form, without the need to apply patches and such. I like Ian Jackson's proposal. I liked it too. To recap what was proposed: + foo-1.2-5.debian-diff + foo-1.2.orig/foo.c + /foo.h + c This would be contained in a tarfile or somesuch. (actually, I'd rather see foo-1.2-5.debian-diff and foo-1.2.orig.tgz, but I'm not religious about that) foo-1.2-5.debian-diff would contain debianizing patches for the pristine upstream upstream sources which follow, with the patches being applied mechanically during unpacking of the debian source package. For debian-originated packages, foo-1.2-whatever.debian.diff might be a required component which could be empty of diffs, or might be optional (both alternatives have been mentioned). As regards the 6a question, it seems that the foo-1.2 package maintainer could upload foo-1.2-6.debian-diff, and processing on the distribution site could upgrade the foo-1.2-5 source package to foo-1.2-6 by replacing the diff component. Users would always download a complete package containing pristine upstream sources and debian-release-numbered debianizing diffs, with diffs to be mechanically applied on the user's machine during unpacking to produce debianized sources.
Re: ncurses available on ftp.pixar.com
On Sat, 9 Dec 1995, Michael Alan Dorman wrote: I think ncurses wins an award for most packages from one source archive. I'm not sure about that. I've had several instances of multiple rapid-fire uploads due to upload glitches and due to my own boneheaded errors 8^(.
Re: bumping the version number
On Sat, 9 Dec 1995, Bill Mitchell wrote: It seems like this will cause the mirrors carrying 1.0 to download the whole tree again. If we're going to do that, perhaps we should have the debian-development (or whatever) be the directory tree and debian-1.whatever be a symlink to it. That way, the next bump of the version number wouldn't cause massive downloading (or so I would think). just FYI that has already happened. All mirror sites have probably done the equivelant of an rm -rf debian-1.0 already since we moved the tree. This makes ftp.debian.org the only site for the 1.0 release now.
Re: ncurses available on ftp.pixar.com
On Sun, 10 Dec 1995, roro wrote: And how to elegantly get rid of the huge /usr/lib/terminfo database w/o installing and purging? Good point. This sounds like a serious user-upgrade issue. This looks like a dpkg-guru question.
