> On Mon, 11 Dec 1995, Owen S. Dunn wrote:
> > Package: diff
> > Version: 2.7
> > Revision: 5
> >
> > This package provides no man pages for any of diff, diff3, sdiff, or
> > cmp.
>
> Too true. It comes with info pages, which are not at all the same thing.
>
> I think the current custom is to leav
On Sun, 10 Dec 1995 [EMAIL PROTECTED] wrote:
>
> If there is interest I can post my "ftp.debian.org" file for mirror.
>
> --
> Dirk Eddelb|ttel
> http://qed.econ.queensu.ca/~edd
>
I prefer that they use the extra accounts instead of a single file that
will do al
On Mon, 11 Dec 1995, Owen S. Dunn wrote:
> Package: diff
> Version: 2.7
> Revision: 5
>
> This package provides no man pages for any of diff, diff3, sdiff, or
> cmp.
Too true. It comes with info pages, which are not at all the same thing.
I think the current custom is to leave bug reports abou
Michael Alan Dorman writes:
Michael> Although they could mirror if they had a special userid/password
Michael> (as I believe has been set up)---they would just have to do it in
Michael> multiple parts...
As the maintainer of the mirror package, I am happy to confirm that you do
not need
Bdale Garbee writes:
Bdale> This solves the problem, since Pending wouldn't allow uploads, and
Bdale> only things that look like packages with changes files for which all
Bdale> the pieces look intact would be copied. Scripting this doesn't seem
Bdale> hard, either... wake up once in a
Package: nas
Version: 1.2p2
Revision: 1
The script /etc/init.d/nas to start and stop the Network Audio System
doesn't work, merely providing usage messages...
tacitus:/etc/init.d# nas start
Usage: /etc/init.d/nas {start|stop}
tacitus:/etc/init.d# nas stop
Usage: /etc/init.d/nas {start|stop}
tacit
I'd like to suggest another field to be automatically added to the
"Packages" files that exist at the top of each hierarchy in the
distribution. I'd like to see a "Checksum:" field that can be used to
verify the correct download of these packages. I think including both
an 'md5sum' and a (filesiz
Package: xbase
Version: 3.1.2
The xon in this package tries to use `hostname' to obtain your
machine's FQDN, rather than `hostname -f'.
The following diff shows the difference (usr/local/bin/xon is my fixed
version):
tacitus:~$ diff /usr/X11/bin/xon /usr/local/bin/xon
4a5,6
> # Fixed 06/12/95 [E
Package: diff
Version: 2.7
Revision: 5
This package provides no man pages for any of diff, diff3, sdiff, or
cmp.
Owen
--
Caius College, Cambridge CB2 1TA, UK <[EMAIL PROTECTED]>
http://myrddin.chu.cam.ac.uk/users/osd1000/ <[EMAIL PROTECTED]>
`I wish it didn
I have removed the Incoming directory from ftp.pixar.com . The files
there still exist in ftp://ftp.pixar.com/pub/bruce/Debian . I'll delete
them after about 1 week.
Thanks
Bruce
--
Visit the "Toy Story" Web Page! http://www.toystory.com
Package: base
Version: 0.93.6
The base package creates a group `audio' with GID 29 in /etc/group,
yet the following audio-related device files are set to be owned by
group 55, which is unmentioned in /etc/group :
/dev/mixer
/dev/midi00
/dev/sequencer
/dev/dsp
/dev/audio
/dev/sndstat
/dev/mixer1
/
>>That's essentially identical to what I was proposing with just two
>>practical differences: (1) it uses numbers rather than names and (2)
>>it goes to more effort to hide things.
>
>May be. I'm afraid I too-hurriedly deleted the message with your
>suggestion, and can't go back to re-read it to
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
I personally don't have any objection to the software being distributed
from other sites as long as it has words like ALPHA-TEST in its pathname.
Bruce
--
Visit the "Toy Story" Web Page! http://www.toystory.com
Matt,
I think we can fight the "juarez" folks by making an automatic mechanism
to verify uploads against the .changes file and move them into a visible
area. If we want to verify the ID of the uploader we can have them PGP-sign
the .changes file. I think Ian wants to be the one to move the file in
In article <[EMAIL PROTECTED]> you wrote:
: I think we should arrive at a happy medium - uploads
: are verified against their .changes file and moved into an accessable
: area that is not their final resting place. Ian can then move them, with
: the confidence that their integrity has been checked,
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.
Bruce
--
Visit the "Toy Story" Web Page! http://www.toystory.com
Wouldn't that honor go to X11?
Bruce
--
Visit the "Toy Story" Web Page! http://www.toystory.com
Everybody has problems with truncated uploads, etc. Generally they can't
fix them by themselves. I wanted to repair this by automating the FTP
archive process to check against the changes file and then move the file
into place. Ian Murdock objected to this as he wanted to manage the FTP
archive by
The symbolic link makes life slightly easier for those of us who
need to maintain multiple kernel versions. However, I don't feel
strongly about it and I'm not the kernel maintainer any longer.
Thanks
Bruce
--
Visit the "Toy Story" Web Page! http://www.toystory.com
Package: hello
version: 1.3-4
Since ``hello'' is our reference package, it would be nice if the version
under the 1.? hierarchy had an ELF exacutable. It would also allow one
to use the package to confirm that a system is ready for elf executables
before replacing something essential.
--
David
> "Matt" == Matthew Bailey <[EMAIL PROTECTED]> writes:
Matt> I am sorry to be an ass here but you have to understand
Matt> these views. I am doing what is best for the University by
Matt> not allowing for illegal software to be downloaded.
The point isn't downloading illegal softw
[EMAIL PROTECTED] writes:
>
> 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 m
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,
> >> The symlinks for lib*.so are in the runtime package. They should be
> >> in the -dev package.
> >
> >Makes sense. Done.
>
> 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.
> Isn't that what lib*.so
I have just created an Outgoing directory which has everything from the
Incoming directory in it.
These files are downloadable the files that go into incoming are still
set 0660.
I will move files into the Outgoing directory when I see a medium/urgent
tag in the change file. Or a developer mus
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
--purge --force-depends'
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
Richard>0.93R6 -> Highgate
Richard>Highgate/ [contains 0.93R6]
Richard>Holborn/[contains what will be 1.0]
Richard> and after the release:
Richard>0.93R6 -> Highgate
Richard>Highgate/ [contains 0.93R6]
Package: xypic
Version: 3.2-3
Trying to configure xypic on a debian-1.0 (i.e. ALPHA) system fails
due to dependencies on texbin, mfbin, and mflib packages newer than
the ones currently available.
These seem to be the currently available (development) packages:
texbin-3.1415-4.deb
mfbin-2.71-3.de
PACKAGE: ncurses
VERSION: 1.9.8a-1
root:beav-140# ./beav Makefile
Unknown terminal type xterm!
root:beav-140# TERM=vt102
root:beav-140# ./beav Makefile
Unknown terminal type vt102!
root:beav-140# TERM=vt100
root:beav-140# ./beav Makefile
Unknown terminal type vt100!
Weren't these to be compiled-
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
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, 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
PACKAGE: ncurses
VERSION: 1.9.8a-1
An attempt to use the kbs capability in a linux VC failed.
My BS key produces ^?, not ^H, and the compiled-in linux terminal
definition seems to have kbs set ti ^H (infocmp linux doesn't
work, so I can't check, but ctrl-h acts like the BS key should).
IMO, the
PACKAGE: ncurses
VERSION: 1.9.8a-1
root:ae-493# infocmp linux
infocmp: couldn't open terminfo file /usr/lib/terminfo/l/linux.
root:ae-493# infocmp xterm
infocmp: couldn't open terminfo file /usr/lib/terminfo/x/xterm.
root:ae-493# ls /usr/lib/terminfo-l
ls: /usr/lib/terminfo-l: No such file or dir
I used to get the latest packages from Incoming, since it was often a
while before they were moved from Incoming to the development tree.
Now that the permissions are set so that none of these are world
readable (I assume because of the corrupted files complaints), is my
only recourse to wait for
'Michael Alan Dorman wrote:'
>
>> The symlinks for lib*.so are in the runtime package. They should be
>> in the -dev package.
>
>Makes sense. Done.
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.
Isn't tha
On Sun, 10 Dec 1995, Richard Kettlewell wrote:
> That's essentially identical to what I was proposing with just two
> practical differences: (1) it uses numbers rather than names and (2)
> it goes to more effort to hide things.
May be. I'm afraid I too-hurriedly deleted the message with your
s
> > There is no symlink for libcurses.so. There should be one in the -dev
> > package.
>
> OK. Jeff Noxon mentioned that a link for libtermcap.so might also be in
> order---thoughts?
I have been told that this is undesirable for some autoconfed programs
with emacs being the most notable exampl
Is it OK to upload to debian-devel now? I uploaded an e2 package
update last night. Do I need to redo it? Can I start uploading
package updates to use elf ncurses?
[EMAIL PROTECTED] (Bill Mitchell)
Is the procedure for upgrading an ncurses installation inherited
from 0.93R6 to ncurses-1.9.8a intuative and correct for non
debian-developers? (note -- I'm using dpkg-1.0.5).
Package installation succeeded without my removing ncurses-runtime
or ncurses-developer. How are users to users know th
On Sun, 10 Dec 1995, Matthew Bailey wrote:
> If you want an OUTGOING then someone will have to create one by manually
> moving the files from Incoming over to OUTGOING.
Sounds reasonable to me. Files get uploaded to Incoming, and then
either moved directly or (my preference) moved into a downl
On Sun, 10 Dec 1995, Sven Rudolph wrote:
> Any thoughts on this ? Any objection against mirroring the Incoming
> area ?
Yes! Incoming is what it stands for INCOMING.
If you want an OUTGOING then someone will have to create one by manually
moving the files from Incoming over to OUTGOING.
I am s
>It seems to me that a solution might be to put our real directory
>trees in a hidden subdirectory with a neutral name, to name those
>trees neutrally, and then to have meaningfully named (and easily
>changed) symlinks pointing to them: Something like:
>
> /debian/.hidden/debian-tree1/ # full 0.
In article <[EMAIL PROTECTED]> Siggy Brentrup <[EMAIL PROTECTED]> writes:
> Some weeks ago I suggested decentralization of ftp.debian.org using
> rdist to keep sites in sync. While the problem has been taken care of
> for uploading, I don't know of a mirror where I can find packages
> freshly uplo
On Sun, 10 Dec 1995, Chris Fearnley wrote:
> 'Ian Murdock wrote:'
> >
> >How about installing the kernel headers directly in /usr/include,
> >rather than linking them into /usr/src? I always assumed this was
> >standard kernel practice. Apparently, I was wrong. Are there any
> >opinions on the
On Sun, 10 Dec 1995, Richard Kettlewell wrote:
> >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.
> >[...]
> As I
Hi all,
finally I have got my network connection up to speed with accepable
transfer rates when connected to european sites and I'm trying hard to
download David's work from ftp.ods.com, but at about 100 cps this is a
pain in the ...
With current phone rates that's 3.35DM/MB and will be as high a
> How about installing the kernel headers directly in /usr/include,
> rather than linking them into /usr/src? I always assumed this was
> standard kernel practice. Apparently, I was wrong. Are there any
> opinions on the subject?
I doubt it would affect a lot of people. But putting the includ
Fernando Alegre writes:
>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 directori
On Sat, 9 Dec 1995, Ian Murdock wrote:
> On Sat, 9 Dec 1995, Matthew Bailey wrote:
>
> > 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.
>
> I'm here--what do you need to talk to me about?
>
Well everything has been on th
On Sun, 10 Dec 1995, Michael Alan Dorman wrote:
>
> I apologize for my gaffe. Obviously I should pay better attention to my
> mail, since it seems I glossed over the announcement of the change in
> policy.
You didn't miss any mail, I had mailed Ian M. to tell him about this but
I just got 5 b
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 Sat, 9 Dec 1995, Matthew Bailey wrote:
> 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.
I'm here--what do you need to talk to me about?
On Sun, 10 Dec 1995, Michael Alan Dorman 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.
Steve
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, 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, 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 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
>> 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. be a symlink to it. That way, the next bump of
>> the version number wou
'Ian Murdock wrote:'
>
>How about installing the kernel headers directly in /usr/include,
>rather than linking them into /usr/src? I always assumed this was
>standard kernel practice. Apparently, I was wrong. Are there any
>opinions on the subject?
The only problem I see would be if I upgrade m
> 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. be a symlink to it. T
> Having said all that, there's the .changes file for 1.9.8a:
Hi Mike,
I got your latest packages from ftp.pixar.com. All in all, things
look good. Here are my initial findings.
The -dev package provides virtual ncurses-dev package but it also
needs to conflict with it.
The symlinks for lib*
On Sat, 9 Dec 1995, Bill Mitchell wrote:
>
> 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.
>
O
This is another update of the beta-test next-generation elvis
vi clone.
The author has asked that this not yet be made widely available.
Please put it in project/private/BETA. Interested debian maintainers
are invited to download it and provide feedback to the author.
Date: 09 Dec 95 18:14 UT
S
66 matches
Mail list logo
