Bug#1988: New version of fort77 uploaded
Package: fort77 Version: 1.6 I have just uploaded version 1.7 of the fort77 driver script to sunsite's Incoming. This fixes a couple of minor bugs with the -b, -v and -V options, which weren't passed everywhere, or weren't passed correctly. -- Thomas Kvnig, [EMAIL PROTECTED], [EMAIL PROTECTED] The joy of engineering is to find a straight line on a double logarithmic diagram.
Bug#1989: mmap bug?
Package: kernel Version: ? The sources I'm using form libdb contain a patch that says: + * The Linux kernel mmap() semantics are broken : + * + * Under Linux, read only private mappings cause write only and read/write + * opens to fail with errno=ETXTBSY. Shared read only mappings should work + * fine though, but I'm not familiar enough with the code to ascertain that + * a MAP_SHARED mapping would be safe so I use the non-mmap'd version + * instead. I'd like to remove this patch if it is not needed anymore. Ray -- Cyberspace, a final frontier. These are the voyages of my messages, on a lightspeed mission to explore strange new systems and to boldly go where no data has gone before.
Re: ncurses build options...
If the ncurses guys are going to keep blowing off binary compatibility, then perhaps we should not mess with ncurses at all. I'm not really sure where the big 'push' to move to ncurses came from (on linux-gcc), and I don't see how it is any better (at this point) than BSD curses. At least BSD curses isn't changing anymore. I've been using ncurses for about 8 months now, and so far keeping up and dealing with bugs has been quite a nightmare. BSD curses isn't as sophisticated, but it usually works. I don't want to end up with a Debian system littered with 7 different ncurses libs, all incompatible. There must be a Better Way. Jeff > ncurses1.9.8 will be released really soon now and contains: > dist.mk == > # If a new ncurses has an incompatible application binary interface than > # previous one, the ABI version should be changed. > VERSION = 1.9.8 > SHARED_ABI = 2.2
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 not really sure where the big 'push' to move to ncurses came from > (on linux-gcc), and I don't see how it is any better (at this point) than > BSD curses. At least BSD curses isn't changing anymore. Well, it's supposed to be faster, and, of course, BSD curses is no longer supported. 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. My intention is not to necessarily slavishly track the software --- I mean, I may do it for testing purposes and the like, but I am more than willing to act as a filter for the distribution so it won't necessarily have to upgrade constantly to new versions of questionable stability. > I don't want to end up with a Debian system littered with 7 different > ncurses libs, all incompatible. There must be a Better Way. I suspect that the distributed packaging responsibility will make it unlikely that it will get that bad --- one or two versions, maybe, tops. At least with Debian it'll be easy to ferret extraneous packages out and remove them with confidence that nothing will break (ah the wonder of automated dependency checking). Mike. -- "I'm a dinosaur. Somebody's digging my bones."
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...
On Thu, 7 Dec 1995, David Engel wrote: > > ncurses2-1.9.7a-1.deb will be the shared library package. It is ncurses2 > > because the major portion of the soname is 2. It will depend on libc5 and > > ncurses-base. > This should be ncurses21-* (or ncurses2.1-*). As was already noted, > the major version for the current ncurses is really 2.1. FYI, with > ELF shared libraries, the major version if effectively defined by the > soname when the library is built. Someone else (Ray?) pointed out that ELF uses the soname, so I got this. > > 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? > If we support multiple shared library versions, we should allow users > to install the -dev package for any of them. Of course, they should > only be allowed to have one of them installed at any one time. > I chose to put the major versions in the package names for my Tcl/Tk > packages (tcl74-deb and tk40-dev) for two reasons. First, it makes it > much more obvious for users which -dev package goes with which runtime > package. Second, the ftp administrator will be less likely to > accidentally delete the -dev packages for older, but still supported, > versions if they have different package names from the new ones. 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 'DEPENDS' in ncurses-dev, but I don't see that it's superior technically (and it does seem a little less prone to confusion), so I'll do this. Mike. -- "I'm a dinosaur. Somebody's digging my bones."
Re: ncurses build options...
On Fri, 8 Dec 1995, Jeff Noxon wrote: > 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. :) How big is 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. Well, the one good thing (that I think was more-or-less forced on the ncurses people) is that the maintainers are choosing the soname, so we dont' have to worry about different distributions using different sonames for the same library. Mike. -- "I'm a dinosaur. Somebody's digging my bones."
Re: ncurses build options...
From: Jeff Noxon <[EMAIL PROTECTED]> > perhaps we should not mess with ncurses at all. BSD curses does not provide the form and menu interfaces. I am using these (and possibly the pad and panel interfaces, that's undecided) to implement a new installation program. It would be a lot more difficult without them. Thanks Bruce -- Visit the "Toy Story" Web Page! http://www.toystory.com
Unanswered problem reports
The following problem reports have not yet been marked as `taken up' by a message to [EMAIL PROTECTED] OVER 10 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Package maintainer 379 mount Repeatable mount(1) problem wi Bruce Perens <[EMAIL PROTECTED]> OVER 9 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Package maintainer 416 wenglish perl doesn't flush output auto [EMAIL PROTECTED] (Robinson, 421 term unreasonable restriction on te Jim Robinson <[EMAIL PROTECTED] 563 tartar -x fails to overwrite or c Ian Murdock <[EMAIL PROTECTED] 579 image (?) missing /usr/man/man8 manpages Bruce Perens <[EMAIL PROTECTED]> OVER 8 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Package maintainer 660 gdbGDB gets address of structure Ian Murdock <[EMAIL PROTECTED] 662 procps top doesn't behave sensibly if Ian Murdock <[EMAIL PROTECTED] 691 textutils textutils package, fmt(1) prog Ian Murdock <[EMAIL PROTECTED] 702 findutils locate crash with large db Ian Murdock <[EMAIL PROTECTED] 710 xs3X server problem with hardware (unknown -- `xs') 713 mh mh should pause after printing Jim Robinson <[EMAIL PROTECTED] 723 xconfigX server default configuration (unknown -- `xconfig') 725 xbase twm places windows incorrectly Stephen Early <[EMAIL PROTECTED] 729 procps Bizarre corrupted output from Ian Murdock <[EMAIL PROTECTED] 731 ncursesncurses wgetnstr doesn't work (unknown -- `ncurses') 740 xbase xclock leaves `droppings' in i Stephen Early <[EMAIL PROTECTED] 746 cpio mt doesn't support setblk (and Ian Murdock <[EMAIL PROTECTED] 759 kbd, xbase /usr/bin/X11/showfont conflict Ian Murdock <[EMAIL PROTECTED] 773 xbase xmh falls over if mh is not in Stephen Early <[EMAIL PROTECTED] 775 xbase twm reports errors on incorrec Stephen Early <[EMAIL PROTECTED] 783 tartar --same-order doesn't work Ian Murdock <[EMAIL PROTECTED] 784 manpages Infelicities in fopen manpage Ian Murdock <[EMAIL PROTECTED] 785 cpio mt problemsIan Murdock <[EMAIL PROTECTED] 786 syslogdsyslogd gone awol Martin Schulze <[EMAIL PROTECTED] OVER 7 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Package maintainer 797 (base) /etc/termcap console keydefs f (unknown) 798 svgalibsvgalib gets control key mucke Ted Hajek <[EMAIL PROTECTED] 808 emacs Info anchors not active in ema Ian Murdock <[EMAIL PROTECTED] 817 tartar -T /dev/null extracts whol Ian Murdock <[EMAIL PROTECTED] 818 bash bash builtin `echo' doesn't ch Ian Murdock <[EMAIL PROTECTED] 819 tartar should have null-separated Ian Murdock <[EMAIL PROTECTED] 820 tcsh tcsh builtin `echo' doesn't ch Andrew Howell <[EMAIL PROTECTED] 821 shellutils /bin/echo doesn't check write Ian Murdock <[EMAIL PROTECTED] 822 tartar -t doesn't check write err Ian Murdock <[EMAIL PROTECTED] 824 cpio cpio should have non-verbose, Ian Murdock <[EMAIL PROTECTED] 825 trntrn warning messages corrupt t Ian Jackson <[EMAIL PROTECTED] 827 libc or sh who reports wrong hostname (wa Ian Murdock <[EMAIL PROTECTED] 835 sysklogd syslogd dies, leaves system un (unknown -- `sysklogd') 836 (base) Possible bugs in termcap syste (unknown) 841 ncursesdselect from dpkg 0.93.34 says (unknown -- `ncurses') 844 manpages readdir(3) should document str Ian Murdock <[EMAIL PROTECTED] 845 manpages access(2) is ambiguous Ian Murdock <[EMAIL PROTECTED] 850 indent [indent] option mentioned in d [EMAIL PROTECTED] (Bill 853 shellutils `nice' does not do anythingIan Murdock <[EMAIL PROTECTED] 857 gs_bothgs (2.6.1pl4-4) doesn't use /e (unknown -- `gs_both') 860 mount `only root can mount' can mean Bruce Perens <[EMAIL PROTECTED]> 864 make make gets MAKEFLAGS wrong Ian Murdock <[EMAIL PROTECTED] OVER 6 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Package maintainer 887 xarchieR6 xarchie barfs when ftp closes (unknown -- `xarchier') 889 info Info 3.1-6 Ian Jackson <[EMAIL PROTECTED] 902 lprlpr can't print a PostScript f Peter Tobias <[EMAIL PROTECTED] 903 (base) /dev miscellaney (unknown) 911 libc libc causes rsh to fail on com Ian Murdock <[EMAIL PROTECTED] 918 miscutils mkboot and image packages Bruce Perens <[EMAIL PROTECTED]> 923 xbase xdm failed with `unknown sessi Stephen Early <[EMAIL PROTECTED] 927 ncurses? dselect display bug(unknown -- `ncurses') 932 pine Pine over-encodes files and au Ted Hajek <[EMAIL PROTECTED] 933 pine Pine wants to post my email re Ted Hajek <[EMAIL PROTECTED] 934 pine Pine `Full Header
Re: ncurses build options...
> On Fri, 8 Dec 1995, Jeff Noxon wrote: > > 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. :) > > How big is it? 1.3MB uncompressed, 450K gzipped. Jeff
Bug#1990: netstd doesnt restart other daemons.
Package: netstd Version: 1.24-1 Hi.. While installing netstd 1.24-1 it asked me if I wished to install a new /etc/init.d/netstd_nfs - I said ok to that. However since I run NFS etc it didn't take into account to leave the entry for rpc.nfsd/mountd daemons uncommented so that they would start again. I therefor had to re-run rpc.mountd/nfsd at the prompt to continue. 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: dpkg-nondebbin and improper system installation
A number of people have attempted or succeeded in using
dpkg-nondebbin or a dpkg compiled on their local systems to install
Debian without using the bootstrap floppies. As far as I am aware,
this will yield a system that is broken in various ways (non-debian
files in the system directories, things not configured, etc.). At
the very least we should discourage this procedure.
I'm just catching up on my email, but I might not be able to get all
the way caught up today. So, I'm going to reply to this one without
catching up on the discussion:
What I hope to enable is a mechanism to migrate existing systems to
debian systems. This is not (and cannot) be an automatic procedure.
But, that doesn't mean we can't build tools for the migration.
In particular, I'd like to have a routine which looks for certain
signatures of a debian system and recommends action based on what it
(doesn't) find.
As a first step, I guess I'd look for the /var/lib/dpkg/{*,*/*} files
that should be present on a debian system, and recommend that the
requisite base packages be installed if they're missing. [With,
presumably, big warnings that this will involve manual configuration
work on the part of the installer, and it would be much cleaner and
easier to start afresh.]
--
Raul
Bug#1978: man: default pager should be less
Something ought to be done though, since more(1) can't be made to go backwards through manpages. This is rather a serious deficiency. Perhaps /bin/pager, done by update-alternatives ? Hmm, not too good. Another option might be to have man point more at the catman file rather than at a pipe. more can go backwords if it's given a seekable file. -- Raul
1.0 on Infomagic CD
Someone told me that Infomagic has announced a CD containing Debian 1.0, available in about a week. This would be a real disaster, since 1.0 is far from ready for anyone but a developer to use it. I will contact Infomagic, and I think we'd better write an announcement to linux-announce after that if they've already mastered the CD. I think also it's time to put non-released systems under password access. Thanks Bruce -- Visit the "Toy Story" Web Page! http://www.toystory.com
Re: 1.0 on Infomagic CD
> Someone told me that Infomagic has announced a CD containing Debian 1.0, > available in about a week. This would be a real disaster, since 1.0 is far > from ready for anyone but a developer to use it. I will contact Infomagic, > and I think we'd better write an announcement to linux-announce after that > if they've already mastered the CD. > > I think also it's time to put non-released systems under password access. I was going to suggest with all these people querying about 1.0 that we have an an account on ftp.debian.org with access to debian-1.0 directory so we lock out normal public ftp access. I myself have noticed quite a few people coming in and nabbing 1.0 packages thinking that they were the ones to use (IGNORING the README-USE-0.93 stuff etc) only to find that they couldnt use it and come back to get the 0.93 packages. I'm not sure about mirrors though, I guess we'll have to lock them out as well because of the same reason - seems a pitty really. I also feel that with 1.0 and all the new developers (myself included) that all the normal users out there that would like to use 1.0 because of all the new packages in there. However, if we dont leave open 1.0 to people who arent devolpers (but wish to test and find bugs for us) then what are we to do? ...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: 1.0 on Infomagic CD
PLEASE DON'T POST TO PUBLIC FORUMS ABOUT THIS ISSUE. PLEASE LEAVE THAT UP TO IAN MURDOCK AND MYSELF. WE SHOULD HAVE ONE COHERENT STATEMENT ON THIS, WHICH MEANS ONE PERSON GETS TO MAKE THAT STATEMENT. I spoke with Kim at Infomagic. Yes, they've pressed a CD with 1.0 on it, along with other distributions. Joel (also of Infomagic) will be calling me back later, and I'll have to speak with Ian Murdock (anyone have his new phone number - he moved last week). Then we will write an announcement to debian-announce and linux-announce to make it clear that this is development software and not suited for a non-debian-developer to install. I think they meant well, but putting someone's software on a CD without telling them is dumb. However, it won't help Debian if we make a lot of noise about it in a negative way. 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. Thanks Bruce -- Visit the "Toy Story" Web Page! http://www.toystory.com
Bug#1978: man: default pager should be less
> "Raul" == Raul Miller <[EMAIL PROTECTED]> writes: Another option might be to have man point more at the catman file rather than at a pipe. more can go backwords if it's given a seekable file. IMHO, the problem is with "more" not with "man". One must not try to adapt a good program just to make it work together with a deficient one (still IMHO, of course). -- Raul (Sorry for my somewhat big signature, I can't resist) -- * *.* *#* *O* **o *@ **.* *.%.#.* O Tannenbaum, o Tannenbaum, *.#+*.#+*.* wie gruen sind deine Blaetter... ^v*-:*=-* *#=.* *o-:*+#* @+.*$v^*.* *%&-=#%.-%*O:[EMAIL PROTECTED] *+* Feliz Ano Novo. [EMAIL PROTECTED]:.*-=#o** |||Schoenes Neues Jahr. ||| :-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-Happy New Year. v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^ Emilio C. Lopes FINPE, Instituto de Fisica E-mail: [EMAIL PROTECTED] Universidade de Sao Paulo Phone: (55)(11) 818-6724 (Voice) Caixa Postal 66318 (55)(11) 818-6715 (Fax) 05389-970 Sao Paulo - SP BRAZIL
Re: 1.0 on Infomagic CD
From: [EMAIL PROTECTED] (Karl Ferguson) > I also feel that with 1.0 and all the new developers (myself included) that > all the normal users out there that would like to use 1.0 because of all the > new packages in there. However, if we dont leave open 1.0 to people who > arent devolpers (but wish to test and find bugs for us) then what are we to > do? We should have the developmental stuff available via a separate login. We can give that login out very freely, but we have to make it known when we give it out that it's not for CD, etc. If we change the password every few months, we can assure ourselves that the people who have legitimate access to it understand its status. Bruce -- Visit the "Toy Story" Web Page! http://www.toystory.com
Re: debian-1.0 availability
>I was going to suggest with all these people querying about 1.0 that we have >an an account on ftp.debian.org with access to debian-1.0 directory so we >lock out normal public ftp access. I myself have noticed quite a few people >coming in and nabbing 1.0 packages thinking that they were the ones to use >(IGNORING the README-USE-0.93 stuff etc) only to find that they couldnt use >it and come back to get the 0.93 packages. Perhaps just naming it "development" (instead of that being a link to debian-1.0) would suffice. "stable" would remain a link to the latest release. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Bug#1991: gnuplot has no 'fig' or 'bfig' terminal
Package: gnuplot Version: 3.5 Revision: 3 gnuplot's term.h has the define for FIG commented out. So no 'fig' or 'bfig' terminals for the portable fig graphics language can be generated. That's a pity as Debian has the xfig and transfig packages to use fig graphics. It compiles fine with FIG defined. -- Dirk Eddelb|ttelhttp://qed.econ.queensu.ca/~edd
Re: ncurses build options...
> > > 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. >[...] > This is going to be a big problem for Linux binary compatibility between > distributions. Seems that dpkg should presently be able to handle this, as far as package installation goes, via the dependency mechanism, presuming that the distribution includes all the version-numbered ncurses libraries which are still package dependency targets, and packages are careful about declaring dependencies on them. (H.. MSDOS filenaming for the multiple ncurses libs will need to include versioning info). It seems to me that the the sequence would go something like this: 1. User initially installs debain-x.y-z, including one or more essential version numbered ncurses libs, and packages depending on various of these libs. 2. Package upgrades remove dependencies on some of these installed ncurses libs, as packages migrate to newer versions. User probably uses naked dpkg to install upgrades, because dselect [I]nstall is very slow when installing individual packages. 3. User somehow (how?) becomes aware that some of his installed ncurses libs have become free of dependencies. 4. User says something like "dpkg --remove --force-essential list_of_libs". Libraries in list_of_libs which are free of dependencies are removed. Libraries in list_of_libs which are not free of dependencies are not removed. I don't really like the idea of users needing to use dpkg --force-things routinely, though. Perhaps this should be front-ended through dselect. There might be a new section for essential libs, and dselect could try to remove any of those which are free of dependencies during periodic user system housekeeping. Note that there's at least one tool, cfengine, which can be used to automate housekeeping such as this. I've seen another tool, Linuxconf, recently announced in c.o.l-announce which might be used as well. If housekeeping like this is done periodically, it might remove the need for the user to become aware of ncurses libs which have become dependency-free.
Re: debian-1.0 availability
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. -- Robert Leslie [EMAIL PROTECTED]
ncurses out within the hour...
I'll be uploading the new shared-lib ELF ncurses package(s) within the hour (just as soon as I rebuild the dist files to get rid of a few spurious nohup.out files I left behind...). I think I've got all bases covered, but I'd certainly not mind having a few especially adventurous souls looking at it before it's moved into public view. In addition to the standard tests, I've compiled ncftp to use it and it seems to behave exactly like the one built with the slightly older static libs. Nevertheless, I suppose that maintainers of ncurses-dependent packages might want to only make revised packages available on an experimental basis for a week or so. Or we could just plunge right in feet-first. :-) Mike. -- "I'm a dinosaur. Somebody's digging my bones."
ftp arrangement changed
I took it upon myself to move debian-1.0 to ALPHA-TEST/debian-1.0 and make the "development" symbolic link point at that. I'm sorry about what this will do to the mirror sites, and I'm sorry to mess with the FTP arrangement, which isn't my job. Thanks Bruce -- Visit the "Toy Story" Web Page! http://www.toystory.com
Re: debian-1.0 availability
Robert Leslie writes: Robert> I don't know about other mirrors, but AFAICT tsx-11.mit.edu Robert> doesn't even carry the 0.93R6 release any more. It only offers Robert> debian-1.0. It's getting jucier by the minute: This domain has a local wuarchive mirror. Wuarchive mirrors tsx-11, along with sunsite, in systems/linux. And systems/linux/tsx-11/distributions/debian/debian-1.0/sources is empty !!! -- Dirk Eddelb|ttelhttp://qed.econ.queensu.ca/~edd
bumping the version number
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. I still haven't heard from Ian Murdock, who is moving his residence and no doubt busy. Does anyone have a way for me to reach him? Bruce -- Visit the "Toy Story" Web Page! http://www.toystory.com
Re: bumping the version number
> 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. Sound like a good idea, however, I would go one step further and remove the version number completely (and possibly go with a code name) until we are close to actually releasing. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Re: ncurses for ELF released
I wrote: > I've been waiting for this, waiting, waiting, and now it's out! Hmm, that's the first time an autoreply has gone back to the list instead of the original author. Guess it'll teach me to check twice.. :) Jeff
Re: bumping the version number
Yes, a code name would be a good idea. Let's hold off on that until Ian Murdock can do it - I've stuck my neck out enough today. Thanks Bruce -- Visit the "Toy Story" Web Page! http://www.toystory.com
Re: bumping the version number
Bruce Perens writes: Bruce> Yes, a code name would be a good idea. Let's hold off on that until Bruce> Ian Murdock can do it - I've stuck my neck out enough today. We could also "hide" in private/project. -- Dirk Eddelb|ttelhttp://qed.econ.queensu.ca/~edd
Default organization: is there a site config file?
Hi, I am in the process of packaging dist-3.60, and one of the config parameters is the organization of the local site (one of the suggested locations: /etc/organization). I rooted around on my machine, and discovered the file /etc/news/organization, which was presumably put there by trn or friends. It seems to me that this information is not news specific (mailers could utilize it too), so should this file be installed instead in /etc, also, which package should take responsibility? I could add a postinst script for dist which checks for the presence of /etc/organization, or else ask the user and set it up for them (maybe use /etc/news/organization if that exists), if that is OK for the interim. manoj -- "It's when they say 2 + 2 = 5 that I begin to argue." Eric Pepke Manoj Srivastava Systems Research Programmer, Project Pilgrim, Phone: (413) 545-3918A143B Lederle Graduate Research Center, Fax: (413) 545-1249 University of Massachusetts, Amherst, MA 01003 <[EMAIL PROTECTED]> http://www.pilgrim.umass.edu/%7Esrivasta/>
Re: debian-1.0 availability
> [wuarchive] systems/linux/tsx-11/distributions/debian/debian-1.0/sources > is empty !!! I thought the GPL only required you to provide the sources _when_someone_asks_for_them_. We did learn a lesson today. Thanks Bruce -- Dirk Eddelb|ttelhttp://qed.econ.queensu.ca/~edd -- Visit the "Toy Story" Web Page! http://www.toystory.com
Re: 1.0 on Infomagic CD
Perhaps we should adopt a different naming convention for unreleased versions. E.g. instead of 1.0, call it 0.93+0.07, or 0.9x-unstable. -- Raul
Re: 1.0 on Infomagic CD
Another possibility is to have an unreadable directory named 1.0, with instructions in the README file on how to navigate through it. The idea being, if you don't read the instructions you don't see the files. -- Raul
Bug#1978: man: default pager should be less
Emilio C. Lopes: IMHO, the problem is with "more" not with "man". One must not try to adapt a good program just to make it work together with a deficient one (still IMHO, of course). This is more a matter of interface definition than anything else. more can go backwards only on seekable files. less (and any other view that lets you go backward on a non-seekabe file) works by making an extra internal copy of the file. Since man already is perfectly equipped to provide a seekable file, it seems that taking advantage of this would be a good idea, both in terms of efficiency and in terms of flexibility. -- Raul
