Well.
Anyone want to venture any opinions?
Mike.
--- Begin Message ---
Jesse Thilo writes:
> On Thu, May 29, 1997 at 09:18:48PM -0400, T.E.Dickey wrote:
> > > To the terminfo.src maintainer,
> > c'est moi
>
> Since when? (Seriously)
Mr. Dickey appears to have decided that hijacking one projec
[EMAIL PROTECTED] (Bruce Perens) writes:
> Any new work I do will use slang rather than ncurses.
Can't say as I'd blame you.
RMS has stepped in. I can't quite decide if that's likely to foster
resolution or small-arms usage.
Mike.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "uns
ation disks.
+
--- ncurses-4.1.orig/debian/changelog
+++ ncurses-4.1/debian/changelog
@@ -0,0 +1,45 @@
+ncurses (4.1-1) unstable; urgency=low
+
+ * New upstream version. Removed deb-files.
+
+ -- Michael Alan Dorman <[EMAIL PROTECTED]> Wed, 7 May 1997 16:39:28 -0400
+
+ncurses (4.0-1) unst
Galen Hazelwood <[EMAIL PROTECTED]> writes:
> Michael Alan Dorman wrote:
> > RMS has stepped in. I can't quite decide if that's likely to foster
> > resolution or small-arms usage.
> Stepped in on whose side?
No ones in particular, though I suspect ESR could se
"Eric S. Raymond" <[EMAIL PROTECTED]> writes:
> Michael Alan Dorman wrote:
> >ESR has, IMHO, decided to start a pissing match about ncurses
> >development. I have no desire to participate or watch.
> Mr. Dorman's opinion is understandable but mistaken.
Alt
Jim Pick <[EMAIL PROTECTED]> writes:
> Debian is getting more consistent on this all of the time.
> Obviously, we weren't too consistent when ncurses got into the
> distribution, with a license that doesn't permit modifications. It
> looks like it was introduced very early in the history of Debian
Brian White <[EMAIL PROTECTED]> writes:
> But your promise in not the point. The author wants this promise
> from everybody. It's the best way to be assured that improvements
> get distributed to everyone and not just a select group.
What if the author decides to not accept a change?
Say the au
Michael Meskes <[EMAIL PROTECTED]> writes:
> Am I correct that libnet-perl supersedes libnet? If so libnet should be
> removed from the archive.
You are correct.
Mike.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROT
Rob Browning <[EMAIL PROTECTED]> writes:
> Does anyone know of any document comparing comparing sendmail, exim,
> and qmail. The recent discussions and some upcoming installs here
> have made me start contemplating the issue again.
I don't think there's a FAQ, and I don't think it could be object
Tim Cutts <[EMAIL PROTECTED]> writes:
> qmail is supposed to be more secure. Theoretically, exim's design
> allegedly means there might be some security issues, but none have
> been found yet. There has been argument about this ad nauseam on
> the exim-users mailing list.
qmail also has stronger
I'm officially orphaning ncftp and glimpse, for a couple of reasons.
The biggest is that I haven't used either in quite a long time---I'm
now an extraordinarily happy lftp user, and I long ago became fed up
with glimpse's sorry excuse for boolean searching and switched to (the
now free) swish.
Th
In building a couple of perl extensions for Debian the other day, I
noticed that the version on the axp produced a dependency on the
loader and libc.
When I moved the same source over to my i386, I was told that the
resulting shared object was statically linked.
After a bit of puttering around, I
-maintainer-releases suggested code changes.
Policy people? Any suggestions?
Mike.
--- Begin Message ---
Michael Alan Dorman <[EMAIL PROTECTED]> writes:
> Sven Rudolph <[EMAIL PROTECTED]> writes:
> > Michael Alan Dorman <[EMAIL PROTECTED]> writes:
> > > This is s
Philip Hands <[EMAIL PROTECTED]> writes:
> Is there an automatic way of setting the current version of a package into
> the
> Depends (a la ${shlibs:Depends}) ?
Not totally automatic, but you could probably do something in
debian/rules to sed (or, if you're me, perl) it out of the changelog,
and
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
> libmime-base64-perl is a new package. I sent email to its maintainer about
> how and why it is bigger/better/a possible replacement for mine, but I have
> yet to hear from him. Michael ?
Sorry, been away for a week.
libmime-base64-perl implements a
Christian Schwarz <[EMAIL PROTECTED]> writes:
> On 17 Dec 1997, James Troup wrote:
> [snip]
> > If the binary changes, the version number should change.
>
> Completely agreed. Everything else will only result in a big mess.
>
> I'll check our how I can make policy more clearly on this point and
>
fs server included
with current netstds. Newer versions correct some of the problems,
but, as of week-before-last, not all.
Could this be your problem?
Mike.
--
Michael Alan Dorman | E-Mail: [EMAIL PROTECTED]
Network Administrator | Phone: (305) 284-2463
Un
s the things totally external to the package and
sources that were installed at the time.
Mike.
--
Michael Alan Dorman | E-Mail: [EMAIL PROTECTED]
Network Administrator | Phone: (305) 284-2463
University of Miami School of Law | Fax: (305) 284-
issed something, someone please let me know.
Mike.
--
Michael Alan Dorman | E-Mail: [EMAIL PROTECTED]
Network Administrator | Phone: (305) 284-2463
University of Miami School of Law | Fax: (305) 284-3753
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e
James Troup <[EMAIL PROTECTED]> writes:
> Michael Alan Dorman <[EMAIL PROTECTED]> writes:
> > If I've missed something, someone please let me know.
> from hamm/contrib/Packages:
Thanks, James, I guess I must have looked at the available list on my
alpha, not for i3
o proxy from multiple servers while presenting a unified list
of newsgroups), so I may well do this instead of nntpcache.
I don't suppose anyone has packaged it yet? :-)
Mike.
--
Michael Alan Dorman | E-Mail: [EMAIL PROTECTED]
Network Administrator |
re welcome.
Looks good to me.
Mike.
--
Michael Alan Dorman | E-Mail: [EMAIL PROTECTED]
Network Administrator | Phone: (305) 284-2463
University of Miami School of Law | Fax: (305) 284-3753
--
TO UNSUBSCRIBE FROM THIS MAILING LIST:
t; only).
The latest libwww-perl should be out there, although there are
apparently some problems getting libmime-base64 out of incoming.
I'll try and expedite this.
Mike.
--
Michael Alan Dorman | E-Mail: [EMAIL PROTECTED]
Network Administrator | Ph
[EMAIL PROTECTED] (Ian Jackson) writes:
> The third member of [EMAIL PROTECTED] is Michael Alan Dorman. I
> haven't seen much from him recently (most recent message from him on
> debian-devel on the 30th of March). Michael, are you there ? Are you
> planning to put out a new
Bdale Garbee <[EMAIL PROTECTED]> writes:
> The bzip2 tool is vastly less well deployed than gzip, so you'd be
> making it much harder for folks not running Debian boxes to play.
> You would also have to add bzip2 to the base/essential list in
> Debian, and it's not clear to me that having two compr
James Troup <[EMAIL PROTECTED]> writes:
> Michael Alan Dorman <[EMAIL PROTECTED]> writes:
> > Might I suggest that using it for source packaging would be
> > appropriate, though?
> By recompressing things in bzip2, you lose the ability to use pristine
> upstream s
Hamish Moffatt <[EMAIL PROTECTED]> writes:
> Also, lintian has two errors with it (manpage not compressed, old-fsf-address)
> but there are no bugs filed. It doesn't include the debian changelog
> in /usr/doc/mingetty, either (lintian doesn't seem to notice?). I may do
> another upload to fix these
Gnus lives a life of its own outside the various Emacsen. There
seemingly isn't a version in a released Emacs package that isn't
superseded nearly immediately.
Furthermore, there is a new release with some features I'm interested
in having access to.
Therefore I intend to package it separately,
Paul Slootman <[EMAIL PROTECTED]> writes:
> So, I'm still undecided as to whether 2.0 should go out for Alpha.
> Anyone else have opinions?
I think we should leave it out of 2.0, with the caveat that we should
nevertheless start referring to it as a full-fledged port---and once
we get further
"Darren/Torin/Who Ever..." <[EMAIL PROTECTED]> writes:
> Sorry, I mis-stated the question. Why does libnet-perl depend on
> data-dumper in base. I thought we (as in debian-devel) had discussed
> not asking the libnet-perl configuration questions during install.
> Since Net::Config is the only pla
Hamish Moffatt <[EMAIL PROTECTED]> writes:
> Is there an alpha machine with accounts available so that we i386
> maintainers could try doing alpha compiles ourselves?
No. The machines that most alpha developers have available are either
not well connected, in environments that require more securit
Bdale Garbee <[EMAIL PROTECTED]> writes:
> I'd like to propose that if a non-i386 architecture has a reasonable
> installation process and base archive, plus .deb's for all packages
> marked as 'standard' or higher in the i386 tree (modulo obvious
> exceptions like lilo), that it be considered read
James Troup <[EMAIL PROTECTED]> writes:
> Michael Alan Dorman <[EMAIL PROTECTED]> writes:
> > [ ... ] ld.so doesn't apply [ ... ]
> Upgrade your quinn-diff :-) From 0.31's ChangeLog.main :-
Yeah, but I've been meaning to feed back my changes in one block
Bdale Garbee <[EMAIL PROTECTED]> writes:
> As maintainer of gzip for Debian, I do not agree that having gzip
> fork a bzip2 when it sees a bzip2 magic number is a good idea. If
> we want to support multiple compression engines, I believe this
> should be handled in dpkg-source.
I agree entirely.
Falk Hueffner <[EMAIL PROTECTED]> writes:
> I cannnot quite understand that. gunzip already supports five or six
> different formats, so why not add another one? gunzip *is* designed to
> support multiple compression engines.
Not as external programs.
Mike.
--
To UNSUBSCRIBE, email to [EMAIL P
On Tue, 28 Nov 2006 08:53:23 +0200
Fabian Fagerholm <[EMAIL PROTECTED]> wrote:
> Hi everyone,
Hi, Fabian,
> If you've been using cyrus-sasl2, please consider spending an hour or
> so upgrading to version 2.1.22.dfsg1-4 (currently in unstable),
> testing, and submitting bug reports indicating suc
On Tue, 28 Nov 2006 07:58:12 -0500
Michael Alan Dorman <[EMAIL PROTECTED]> wrote:
> Anyway, that install went fine. I hope today to install it on my
> primary mail server which has postfix and cyrus-imapd-2.2, both
> authenticating against an LDAP db, installed; that shou
John Goerzen <[EMAIL PROTECTED]> writes:
> I would do this regardless of who the maintainer was. I seem to recall
> possibly doing it for some Perl HTML package that was in a similar
> situation to Bacula in the late 90s, but I can't really remember. I'm
> sure you could dig up links.
It was the
David Goodenough <[EMAIL PROTECTED]> writes:
> So are we getting close to the point where you will build gnucash-sql?
The SQL backend is known to suffer from neglect, it's probably not a
good thing to start encouraging people to use at this time. I gather
that the gnucash developers intend to add
cyrus-sasl2 is an important package, and according to p.q.d.o, it's
been nearly two years since Dima Barsky last made a release. In the
intervening time there have been numerous NMUs, but no one has claimed
ownership, and it currently has 5 RC bugs, 39 important/normal ones,
etc.
I other words, t
James Westby <[EMAIL PROTECTED]> writes:
> This has come up a couple of times recently. If you want to help out
> you should subscribe to that mailing list, and get yourself added to
> the alioth project and then coordinate your work with them.
Thanks for the pointer. I don't see them making a re
Package: base
After an uneventful install, I logged in to find that /etc/services has
apparently been overlooked.
I realize that there was some discussion as to whether or not it actually
belonged in netbase, but it has to be a zillion times more relevant to the
base installation than, say, smb.
Package: base
Rebooting my system from the 9/27 boot/root menu gets some dismaying
messages and invariably cause a kernel error. I think it's an OOPS ---
I'm not 100% clear on the difference between an OOPS and a PANIC.
8<
_setutent: Can't open utmp file: no such file or directory
_setu
Package: minicom
Version: 1.6
I know this one isn't likely to get fixed before the drop-dead, but for
the record, minicom depends on ncurses-runtime.
If the original maintainer has abandoned this package (and it seems he
has), I'm willing to take it over, though there's no chance I'll get it
don
Package: miscutils
The /sbin/installkernel that is in the miscutils package on the September
30 basedisks makes a reference to "./mkboot". This is a problem since
mkboot now resides in /usr/sbin.
Mike.
--
"And I swear that I don't have a gun."
I can think of a couple of reasons that bin86 might not be in the
true-blue depends for the source package, but I'd think it'd at least be
"recommended" since you can't compile a new kernel without it.
Mike.
--
"And I swear that I don't have a gun."
Package: fvwm
Version: 1.24r
Revision: 6
The system.fvwm pretty much requires m4 (you get errors in your
~/.xsession-errors, not to mention the fact that it's basically unusable)
but it's not even recommended by the package.
Mike.
--
"And I swear that I don't have a gun."
On Tue, 3 Oct 1995, Michael E. Deisher wrote:
> Does anyone know why "get dirname.tar" has been disabled on the ftp
> site.
I would guess because a .notar file has (or had) been created in /debian.
Mike.
--
"And I swear that I don't have a gun."
On Wed, 4 Oct 1995, Ian Murdock wrote:
> Has anyone gotten ppp 2.2 to work?
It has been shown to work on 1.2.XX. I've not done it.
> I finally got it to compile, after realizing that I had to install a
> few replacement kernel headers. Why are these kernel headers not in
> the standard distribu
On Fri, 20 Oct 1995, Bernd S. Brentrup wrote:
> (ii) Distributing the Program on a CD-ROM, provided that the files
> containing the Program are reproduced entirely and verbatim on such
> CD-ROM, and provided further that all information on such CD-ROM be
> redistributable for non-commercial p
Package: ppp
Revision: 2.2-1
/etc/init.d/ppp still sources /etc/init.d/functions which, I believe, was
decided to be a no-no, since start-stop-daemon subsumed all of its
functionality, and since any script that uses it is effectively disabled
from command-line use because /etc/init.d/functions ch
Well, I've decided to return to Matt Porters' previous split between
minicom and lrzsz.
One side-effect of this is that I need to make the updated lrzsz package
conflict just with minicom-1.71-[1..2] (the ones that included lrzsz). I
can't seem to make it do so. I've tried specifying:
CONFL
> "Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
Ian> `|' is not allowed in conflicts; `,' is used to mean OR.
It would be nice if CONFLICTS and the other fields used the same
notation for OR/AND, instead of being in direct apposition.
Could the current behavior be gradually phased out
On Sat, 28 Oct 1995, Ian Jackson wrote:
> #define _PATH_DEFPATH"/usr/local/bin:/usr/bin:/bin:."
>
> This should read "/usr/local/bin:/bin:/usr/bin", without the "."
> entry. Quite apart from the security implications, teaching new users
> always to run their programs with "./foo" will stop
On Sat, 28 Oct 1995, Bill Mitchell wrote:
> On Sat, 28 Oct 1995, Michael Alan Dorman wrote:
> > > This should read "/usr/local/bin:/bin:/usr/bin", without the "."
> > While we're at it, would it be appropriate to have xdm also set this as
> > the
On Sun, 29 Oct 1995, Karl Ferguson wrote:
> Now, it wont quit at the point - it goes on to finish. But when booting the
> kernel I get this error:
>
> unregister_netdev: device 'ppp0' unlinked
> unregister_netdev: device 'ppp1' unlinked
> unregister_netdev: device 'ppp2' unlinked
> unregister_netd
On Tue, 31 Oct 1995, David Engel wrote:
>First, I prefer to go with unmodified, upstream source. Second, I
>really mean unmodified, i.e.. the Debianizing script (or whatever) must
>take care of unpacking into subdirectories, if necessary.
I'll go further and say that I think that any approach t
On Tue, 31 Oct 1995, Bruce Perens wrote:
> The second file is an executable script that performs the actual
> extraction, creating a subdirectory under the current directory
> and moving files as necessary. Its name is EXTRACT, and it must have
> execute permissions set.
Bi
On Thu, 16 Nov 1995, Brian Hutchinson wrote:
> Has anyone setup a PPP server under Debian?
> I tried a few times with R5 without much luck.
I set one up under R5. I'm looking to redo some of that work because the
pppd in R6 should be able to act without a getty on the serial port which
means yo
On Fri, 17 Nov 1995, J.H.M.Dassen wrote:
> Since 1.0 is going to be ELF (meaning that all its binaries will be ELF, and
> that it compiles for ELF by default), with backward compatibility to compile
> and run a.out binaries, new packages are being made, that put their ELF stuff
> in the standard
On Fri, 17 Nov 1995, David Engel wrote:
> The kernel can still be compiled in a.out format. The a.out
> development tools aren't completely going away. They just won't be
> the default. If you really want to compile 1.2.13 in ELF format, I
> suggest you politely request Linus to update it one la
There seems to be some problem(s) with the 'linux' entry in the terminfo
database. I recompiled minicom to use it (figured I'd get the ELF version
out of the way) and now all of the dialogs are broken --- specifically, I
get extraneous `1m` strings in unusual places.
This doesn't happen if I ru
> The new X packages that I hope to release before Christmas will be ELF,
> compiled from the XFree86-3.1.2S sources rather than from the binaries
> distributed by XFree86.
If you're looking for input, I might request that you release two
versions of the Mach32 Server --- one that is just like
I seem to remember that Ian Murdock gave up these packages. I don't
remember hearing of anyone picking them up.
If they're not already claimed, I would be interested in taking them over.
In fact, I've got gcc 2.7.2 already packaged up (Ian Murdock's diffs to
2.6.3 applied flawlessly over 2.7.2
On Fri, 1 Dec 1995, David Engel wrote:
> > If they're not already claimed, I would be interested in taking them over.
> > In fact, I've got gcc 2.7.2 already packaged up (Ian Murdock's diffs to
> > 2.6.3 applied flawlessly over 2.7.2).
> ELF or a.out? I think Siggy (?) may have claimed gcc and p
On Wed, 6 Dec 1995, Raul Miller wrote:
> I wasn't thinking about anything specific... I was just worrying about
> potential configurations with no /usr partition.
> I probably shouldn't have even mailed the original message.
No, I think it's a valid question to bring up---I was just confused about
On Thu, 7 Dec 1995, Ian Jackson wrote:
> Michael Alan Dorman writes ("Bug#1984: dpkg won't install cdtool"):
> > Try doing a --purge first. I was having a similar problem and that
> > solved it.
> > I just assumed it was my system, but apparently not.
>
On Thu, 7 Dec 1995, J.H.M.Dassen wrote:
> I don't see the necessity of this. Take bash for instance: it uses
> readline, which uses ncurses.
Taking this to its logical absurdity, we get: "Let's just require that
everything be on one big hard drive so it's all in the root partition so
we don't ha
On Thu, 7 Dec 1995, David Engel wrote:
> > So far I have been unable to find a copy of the patch that lets you fall
> > back to another directory. However, support is already in there to allow
> I don't know that the patch even exists anymore. However, a quick and
> dirty hack is only a two line
OK, here's what I think I've come up with:
ncurses-runtime:
shared libraries (in /lib)
looks for files first in /etc/terminfo then /usr/lib/terminfo
has linux as compiled in fall-back.
terminfo manipulation programs
man pages for the program
On Thu, 7 Dec 1995, David Engel wrote:
> This will be necessary -- the ncurses developers have already changed
> the shared library version number once since they introduced shared
> library support and have indicated they won't hesitate to do so again.
I wondered at the fact that soname was .2.1.
On Thu, 7 Dec 1995, Ian Jackson wrote:
> That all sounds reasonable. I take it that the terminfo manipulation
> programs and the manpages are small enough that having them installed
> on every system is not a problem (ncurses-runtime will be an essential
> package).
Actually, they're going into a
On Thu, 7 Dec 1995, Ian Jackson wrote:
> That sounds like the same bug.
> I'm worried about it, but I don't have enough to go on.
I'll see if I can re-create it. I'll mention that I _may_ have done the
first installation of cdtool with 1.0.6, but then you warned people away
from it and I grabbed
On Thu, 7 Dec 1995, Ian Jackson wrote:
> > ncurses-term-1.9.7a-1.deb will contain the monolithic set of terminfo
> > files. It depends on the lockstep revision of ncurses-base (since we
> > might move a few more things out of term and into base as they seem
> > appropriate -- getting out of syn
On Thu, 7 Dec 1995, roro wrote:
> Contrary to libc5, where the soname is libc.so.5, an therefore
> libc.so.5.0.0 until libc.so.5.2.16 are interchangeble (or was supposed
> to be) ncurses has the soname libncurses.so.2.x. ncurses2 has no meaning
> if the ABI between libncurses.so.2.0 and libncurse
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 real
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 ver
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 th
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
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 <[EMAI
On Sat, 9 Dec 1995, David Engel wrote:
> 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 install
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
On Sat, 9 Dec 1995, Matthew Bailey wrote:
> 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 f
On Sun, 10 Dec 1995, roro wrote:
> Minor doc-bug in ncurses-1.9.8a/debian.README:
> ncurses21 should read ncurses3.0
Blast, I thought I had parameterized that _everywhere_. Oh, well. It's
fixed.
> I hope ncurses3.0 will be a stabile ABI, since a lot of packages depends
> on it.
That's why I
On Sun, 10 Dec 1995, roro wrote:
> 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?
No, it isn't. They are supposed to be totally disconnected. Thanks
On Sun, 10 Dec 1995, David Engel wrote:
> The -dev package provides virtual ncurses-dev package but it also
> needs to conflict with it.
Oops. You told me that. Done.
> The symlinks for lib*.so are in the runtime package. They should be
> in the -dev package.
Makes sense. Done.
> The shared
On Sun, 10 Dec 1995, Stephen Early wrote:
> > I think ncurses wins an award for "most packages from one source archive."
> ...soon to be trumped by X, which is currently generating 24 packages
> from one source archive.
Forgot about that one --- the whole group come from just the one source
pac
On Sun, 10 Dec 1995, Bill Mitchell wrote:
> Package installation succeeded without my removing ncurses-runtime
> or ncurses-developer. How are users to users know that they should
> remove these?
With so many variables to juggle, I missed one. Taken care of in -2,
which also addresses all of th
On Sun, 10 Dec 1995, David Engel wrote:
> I have been told that this is undesirable for some autoconfed programs
> with emacs being the most notable example. I don't remember all of
> the details but it has to do with forcing autoconf to use the
> curses/termlib interface to ncurses instead of the
On Sun, 10 Dec 1995, Chris Fearnley wrote:
> It doesn't make sense to me. I thought that the runtime package would
> include all of the shared libraries that other programs might need.
It does.
> Isn't that what lib*.so provide, the shared libraries? And the
> symlinks are used by ld.so, no? O
I'm now uploading ncurses-1.9.8a-2 & co. It is also available for ftp
from lot49.med.miami.edu:/pub/linux/ until it gets cleared at
ftp.debian.org.
Please don't release any packages that depend on this for a couple of days
at least. Anyone who's seeing problems with the current package, please
On Sun, 10 Dec 1995, Michael Alan Dorman wrote:
> I'm now uploading ncurses-1.9.8a-2 & co. It is also available for ftp
> from lot49.med.miami.edu:/pub/linux/ until it gets cleared at
> ftp.debian.org.
I forgot to mention that you will almost certainly have to use 'dpkg
ncurses for ELF is still not quite ready for public consumption. Anyone
who downloads it and installs it should be prepared for possible bumps in
the road. I think they're all taken care of, but even so, be prepared.
In addition to the fact that it's still getting some of the kinks worked
out,
On Sun, 10 Dec 1995, Bruce Perens wrote:
> Making the parent directory unreadable caused mirror programs to not mirror
> that directory. They might mirror the symlink, but it won't do much good.
Although they could mirror if they had a special userid/password (as I
believe has been set up)---they
On Wed, 13 Dec 1995, David Engel wrote:
> The easiest solution I came up with was to only run ldconfig from
> postinst scripts and not from postrm scripts. The only disadvantage I
> can see from doing this is that a stale link and an outdated entry in
> ld.so.cache may get left behind if the packa
A few relatively minor changes.
Date: 14 Dec 95 01:39 UT
Source: ncurses
Binary: ncurses-base ncurses-bin ncurses-term ncurses3.0 ncurses3.0-dev
Version: 1.9.8a-3
Description:
ncurses-base: Video terminal manipulation: Minimum set of terminals
ncurses-bin: Video terminal manipulation: associa
Well, actually, all he did was suggest an excellent solution for something
that had been bothering me about the ncurses packages:
When installing ncurses-base, you have to do all sorts of special things
using dpkg to get dpkg to pretend that you're not messing things up by
removing ncurses-runti
On Thu, 14 Dec 1995, J.H.M.Dassen wrote:
> > Moved /lib/libncurses.so to /usr/lib/libncurses.so.
> Mike, I'm not too happy with this. This prevents libreadline.so from
> using it, and thus prevents bash from using the shared libreadline.
> Can you explain why you moved it?
Sorry, let me explain:
Package: fileutils-3.12
Revision: 3
The package seems to contain ELF executables, yet does not depend upon libc5.
Mike.
--
"I'm a dinosaur. Somebody's digging my bones."
On Sat, 16 Dec 1995, Michael K. Johnson wrote:
> All the other Linux distributions are going to /etc/rc.d/* because
> that's what comes with the svinit package. It works very well; in
> practice I've found that it's one of the things that I like better
> about my Red Hat system than my Debian syst
1 - 100 of 192 matches
Mail list logo