Bug#2002: Missing manpages

[Jeff Noxon]

> 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 about this particular
> issue open, so I'm not closing this one.  I doubt, however, that I'll get
> around to writing a man page and contributing it upstream in hopes that
> it'll be picked up.

I wrote Patrick Volkerding about this a few months ago.  I've attached
a piece of our correspondence.

I think it would be great if we could add these manpages.  Something
is better than nothing.  I can't stand `info'.  :)

Jeff

>From [EMAIL PROTECTED] Mon Oct 16 17:01:10 1995
Return-Path: [EMAIL PROTECTED]
Received: from mhd1.moorhead.msus.edu (mhd1.moorhead.msus.edu [199.17.81.1]) by 
router.patch.net (8.6.12/8.6.12) with SMTP id RAA16018 for <[EMAIL PROTECTED]>; 
Mon, 16 Oct 1995 17:01:10 GMT
Received: by mhd1.moorhead.msus.edu; (5.65/1.1.8.2/09Oct95-1257PM)
id AA07115; Mon, 16 Oct 1995 12:03:59 -0500
Date: Mon, 16 Oct 1995 12:03:59 -0500 (CDT)
From: "Patrick J. Volkerding" <[EMAIL PROTECTED]>
To: Jeff Noxon <[EMAIL PROTECTED]>
Subject: Re: GNU wonders where you got diff.1?
In-Reply-To: <[EMAIL PROTECTED]>
Message-Id: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: RO

On Mon, 16 Oct 1995, Jeff Noxon wrote:

> The author of GNU diff, the Debian diff maintainer, and myself are all
> wondering where you got the diff manpage.  It's not part of the GNU diff
> distribution, and the author says he can't recall there ever being
> a GNU diff manpage...  Yet you have one.   :)
>
> Any idea where it came from?  Do you have nroff source?

I got 'em from FreeBSD.  Jordan Hubbard told me they needed manpages for
cmp, diff, diff3, and sdiff, so they wrote ones.  You guys are also
welcome to use them.

Take care,

Pat

begin 644 manpages.tar.gz
M'XL(`"./@C```^U<:W/;[EMAIL PROTECTED],':5K/$CD^Q.;K:N+"L);]F6KR1/
MDAU/52@)LKBA2`T?L75K?_R>[@;XD!6_)G9FML2JQ)1(`-V-1O?I1D.CV;RY
M^]WC7KL[.\^?/=/?:;IVEOYJ_6)G9U_KYSN[N_L[/S[;^Y&^>O%B[SN]\\AT
M\96GF9]H_5T2Q]E-[]WV_$]Z-<\W=#N>[EMAIL PROTECTED]&6WOW;7U\T\/_?=OC_
M?857_C*8&MTS%R;*4AU/=(:/9U'PV21ID"WHF[8?!I,XB0*_J74K##5WF.K$
MI";Y;,9-ZH;^Z<$T2/4H'AN-OV.3H)>QGB3Q3*?Q)+OT$X.G498$PSS#DRS6
M!R;Y9$*ST,,%]T"C>U&:!1G>H,$[H1FAP<@/M1^-[<3(R_,TPB/QDH<'[EMAIL PROTECTED]&WQ&$87P;1!7$X#JA1RMU0PYG)
M?N(/N\TEZECDEBP6W`Q*"\EF/LBE?OUA_)D>V6GD7G!%<1:,3`.O0-(A.J1^
MRI&9Q3I9&'44^L',)"PIO7>=%`Q9$8LC!;R.>@OEICQ1Y^B^#(TXPM#'?]DEU7`A$)V&7@<
MA?G8E+UB=7PV83P'#\/%]37'/93KKE&N$Q)ED*7E.HJ35!A^UM0G)F!)47^1
M/S,KUG,[EMAIL PROTECTED](N&%:J(Q'AJ2$IB:Q5B=EKFEE;Y2>'9=Z71N
M1K2HT#:@Y9;0M7H=C?O37O=G[[!SJ`\^X&%'
M]SIO.B>#OFZ='.IV]V30\P[.!MU>7W_\V.JCP???TR/NJW7R07?>G_8Z_;[N
M]K1W?'KDH2/TW&N=#+Q.'Q;DI'UT=NB=O(&LSP;[EMAIL PROTECTED]>
MKC?5W=?ZN--KO\7'UH%WY`T^,$FOO<$)C?<:`[;T::LW\-IG1ZV>/CWKG7;[
MTAVQ=NCUVT[EMAIL PROTECTED]'^HX:NG_::7MTTWG?`3.MWH>&[;??^;\SO(2'W-UAZ[CU
M!OQMWB(:S$O[K-RU._V7^JC;
M9ZF=]3L-C#)H,0'H!B+#8]P?G/4]%IYW,NCT>F>G`Z][LL4]O>[EMAIL PROTECTED];PO-
M#UG2W1-F&X+J]CY0QR03GHB&?O>[EMAIL PROTECTED])%>67(O$T8<$VP/NKO(JQH50!Q5^
M]4GGS9$'T;<[]+1+/;WS^ITMS)O7IQ<\&?I=ZX.P><8BH"D#=7);T>(&3ZSV
M7NO6X<\>D6]?AC[T/:L[W=?<5?^L_=9.0;DFZ/J?S?_:&A&R^\M?F[MZTQF&
M+?W\A^<_B$M7S<.Q_M\\,OJY\_.'F6X?G^I=U>QBA?>G^J1U#*TYF6GTA;]C
MV(#9G`Q3=AGK21`:>:W_X:1[VO?ZY:[EMAIL PROTECTED];"K^_R_WO\'%^E
MGX+YKB[O][BWPTZ_W?-X-A7!#G2H8;)#,[EMAIL PROTECTED]'\$Z+N;BL\E$O8,U,9$<)3Q
M:)0G">QA0!AI'B<98Z33.:@B^EUO,KQT27[``,ZP2Q(T$AEI-*CYFGAN72J:
M^I_](/2'H8''.0CU=N9?Z.W+8(S6D]"_4$TOX[E2ITD0904[CHO-,8SQS`^W
M"O\L3&`8Q>]]]L,<5&[&HXS>@[EMAIL PROTECTED]):]--T9JQP`2F+)7Q;M%;R+LEP1K
M\B32YBK(%&8LRS'%4;A`)YVP8%48)+B77#`2$!UCA>*)*#[N*3=]3&T\F:0&
MWLAZ(5,1*#E4IZ?41_%I3S<45`E>*8,'"[EMAIL PROTECTED]"?TJDH9)`"AEP&0!+<75-H
MY*$$Y+((R8D[?=/PH\Y[FJLYNB<7ZM.\ZZFY\FT31;B&!"[EMAIL PROTECTED]'
MF2B!KT/C\SZ^_[Y0C6)ANG5$TDT+%7(([EMAIL PROTECTED]&O,LXKG<
[EMAIL PROTECTED]@%J`2X+=,]>[28Z<*V4MQ_`7080GZJ5$B4"*%6I',BBZU7;[EMAIL 
PROTECTED]
MPHV*OF'`UU2>8.#0!TI(N+N&7:2JR4HGRJ*GD"XT#Q('F+`8PXP;A6RM6ADVGM'[EMAIL PROTECTED]@B;N)G$>C;=$0G_?
M52WH>)+P_(HEL!I.]K33T:VC?EI%&/G0"Z.?^SM__C
MWO,B_[/S;%_KW9W=9R_6^9^GN)H#($CO]6N8F(V]O=3,"0INZ(TW)V=Z$,=A
M6KN'$7DKJ)#-TODVS#*\;=76#4UV21:V"A'?5B#B`;^M?K$8Y5=VQ=ML/K.8
[EMAIL PROTECTED]/TEUD;#T,J796@<"JIHVJ6JD*&5PXE_MWKN2%U4[7$]=B(
[EMAIL PROTECTED];L"5("*BHS5Y3H\,<[EMAIL PROTECTED]:AHL2M#!R%"$O:0^`I1GY
ME*)RWRO1*N(5$\S\.21/&3DP`IH^?N3ABDP9A3K\/M#D.#8L)^7/YX3#BR7L
[EMAIL PROTECTED]&[EMAIL PROTECTED]'[EMAIL PROTECTED]<#BN&Q/Y([EMAIL PROTECTED]<:#EB$.8/4%4=QJ\9M4N9!>%,'!HA8\ZI+\]F,TIXT
MA4#ZUKXX(?!,P5`6RN"/1F:>I4UU'%.JT[XV]3^+33*_Y0%0-O'!9#4<$)>8
M448$&R`[-([EMAIL PROTECTED]O,PAA1X55]ORHP>(Q()8%+K`Q6T;I;+
M`?&U_\E4I;\%^Q:1_D'[EMAIL PROTECTED](@OL0!_DFGT1[!2JL)]%C-)
M&WB$QZ,-T'7D"!\7M-C!_.$P,9\#7U"M(IR=1\%O.;,X":[LK`0)-\=*.DC\
MT2=#X6'O0&_J7T3_,-ZO>@LK8TRI>[O,P)Q=V<0K1V+7PDPHQ^`4[3V2/H?G
MJC^-+VG2Y=,F6

Re: bumping the version number

[Matthew Bailey]

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 all the work. This makes it so if the files get movedd around 
that the chroot() ALPHA-TEST that thes login does works correctly. If 
they use a mirror script that will get hidden/semi-hidden files then what 
good does making them that way. If I want to move around ALPHA-TEST to 
BETA-TEST then these people will have to download all of it again yet if 
they use my login then if I move the directory none of this can happen.



--
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#2002: Missing manpages

[Bill Mitchell]

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 about this particular
issue open, so I'm not closing this one.  I doubt, however, that I'll get
around to writing a man page and contributing it upstream in hopes that
it'll be picked up.

Re: bumping the version number

[Dirk . Eddelbuettel]

  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 an userid/password to mirror _all_ of ftp://ftp.debian.org/debian. 
Anon ftp is sufficient. 

If there is interest I can post my "ftp.debian.org" file for mirror.

--
Dirk Eddelb|ttelhttp://qed.econ.queensu.ca/~edd

Re: solving some of our FTP problems

[Dirk . Eddelbuettel]

  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 while, look for changes files, for
  Bdale> each one confirm the presence and integrity of the pieces mentioned
  Bdale> in the changes file, if all matches mv the files...  then delete
  Bdale> anything older than some threshold to keep Incoming from filling up
  Bdale> with aborted attempts, etc.

I'd love that feature too. But that either requires a damn good script, or
that everybody uses the same .changes format. 

Given that we had that a rather use- and resultless discussion about a "human
readable" vs "machine parsable" format, I am not sure whether we can arrive
there.

I like Bill's "dchanges" and use it. Do I dream when I think we could
establish the use of posting PGP signed dchanges output?

--
Dirk Eddelb|ttelhttp://qed.econ.queensu.ca/~edd

Bug#2004: /etc/init.d/nas doesn't work.

[Owen S. Dunn]

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}
tacitus:/etc/init.d#

Owen
--
Caius College, Cambridge CB2 1TA, UK   <[EMAIL PROTECTED]>
http://myrddin.chu.cam.ac.uk/users/osd1000/   <[EMAIL PROTECTED]>
`I wish it didn't have to end like that.'
  `It always ends. That's what gives it value.' --HCOL

Package Verification

[brian (b.c.) white]

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 (filesize) would be best as the file size would
allow a reasonable check on non-Debian systems and the 'md5sum' would
allow absolute verification before installation.

Example:
checksum: d14d384e0895986bc9f2b09f0a8b84fc (295393)

The reason for this is so programs like 'dftp' can verify that they
retrieved the packages correctly before attempting to install them.

Comments, anyone?

Brian
 ( [EMAIL PROTECTED] )

---
In theory, theory and practice are the same.  In practice, they're not.

Bug#2003: xon uses `hostname' rather than `hostname -f'

[Owen S. Dunn]

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 [EMAIL PROTECTED]
>
31c33
<   fullname=`hostname`
---
>   fullname=`hostname -f`
tacitus:~$

Owen
--
Caius College, Cambridge CB2 1TA, UK   <[EMAIL PROTECTED]>
http://myrddin.chu.cam.ac.uk/users/osd1000/   <[EMAIL PROTECTED]>
`I wish it didn't have to end like that.'
  `It always ends. That's what gives it value.' --HCOL

Bug#2002: Missing manpages

[Owen S. Dunn]

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't have to end like that.'
  `It always ends. That's what gives it value.' --HCOL

ftp.pixar.com Incoming closed

[Bruce Perens]

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

Bug#2001: Incorrect ownership of audio device files

[Owen S. Dunn]

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
/dev/midi01
/dev/dsp1
/dev/audio1
/dev/midi02
/dev/midi03

Owen Dunn
--
Caius College, Cambridge CB2 1TA, UK   <[EMAIL PROTECTED]>
http://myrddin.chu.cam.ac.uk/users/osd1000/   <[EMAIL PROTECTED]>
`I wish it didn't have to end like that.'
  `It always ends. That's what gives it value.' --HCOL

Re: 1.0 on Infomagic CD

[Richard Kettlewell]

>>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 see if I misread it
>the  first time through.
>
>The intended point of my suggestion, and you might have beaten me to
>this, was to have the real directory trees be named neutrally, so
>that their names wouldn't need to change, and use symlinks with
>meaningful names (which could be easily changed without causing
>massive re-mirroring) to point to them.

This is precisely what I suggested.

[..]

>>As to (2), I'm not convinced about hiding things; what we actually
>>want is for people to look in the right place for a stable version
>>without having to think about it.  If people actually want to live on
>>the bleeding edge, it shouldn't actually be any effort to do so - just
>>hard to do by accident.
>
>My suggestion, and the names I chose for illustration, was intended
>to show a structure which allowed that.  Unfortunately, I see that
>I inadvertantly left out a directory level in some of my illustrative
>namings.  Let me try again, with that mistake corrected (names shown
>below are intended to be illustrative.  perhaps there are better
>choices for the symlink names.  In any case, the symlink names would
>be changeable without causing massive re-mirroring.):
>
>   /debian/.hidden/debian-tree1/  # full 0.093 tree
>   /debian/.hidden/debian-tree2/  # full 1.1 tree
>   /debian/debian-stable -> /debian/.hidden/debian-tree1
>   /debian/debian-unstable -> /debian/.hidden/debian-tree2
>   /debian/debian-0.93 -> /debian/.hidden/debian-tree1
>   /debian/debian-1.1.alpha -> /debian/.hidden/debian-tree2
>
>Then, when 1.0 becomes the stable distribution, the symlinks
>could change to:
>
>   /debian/debian-stable -> /debian/.hidden/debian-tree2  # changed from tree1
>   /debian/debian-0.93 -> /debian/.hidden/debian-tree1  # might be deleted
>   /debian/debian-1.1 -> /debian/.hidden/debian-tree2
>
>And no re-mirroring need occur.

My comments about this remain as above.  My suggestion provides the
required functionality without creating `hidden' directories.

-- 
Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/

Re: bumping the version number

[Michael Alan Dorman]

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 would just have to do it in multiple
parts... 

Mike.
--
"I'm a dinosaur.  Somebody's digging my bones."

Re: Downloading from US sites

[Bruce Perens]

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

illegal uploads

[Bruce Perens]

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 into
the archive, but we can at least verify them and move them into a visible
holding area. 

Thanks

Bruce
--
Visit the "Toy Story" Web Page! http://www.toystory.com

Re: solving some of our FTP problems

[Bdale Garbee]

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, to their place in
: the archive.

Boy, this makes lots of sense.  I'd suggest a 'Pending' directory at the same
level as 'Incoming'.

This solves the problem, since Pending wouldn't allow uploads, and only things
that look like packages with changes files for which all the pieces look 
intact would be copied.  Scripting this doesn't seem hard, either... wake up
once in a while, look for changes files, for each one confirm the presence and
integrity of the pieces mentioned in the changes file, if all matches mv the
files...  then delete anything older than some threshold to keep Incoming from
filling up with aborted attempts, etc.

Bdale

Re: bumping the version number

[Bruce Perens]

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

most binary packages for one source

[Bruce Perens]

Wouldn't that honor go to X11?

Bruce
--
Visit the "Toy Story" Web Page! http://www.toystory.com

solving some of our FTP problems

[Bruce Perens]

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 hand. 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, to their place in
the archive.

Thanks

Bruce
--
Visit the "Toy Story" Web Page! http://www.toystory.com

Re: symlink in /usr/include (fwd)

[Bruce Perens]

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

Bug#2000: hello not elf

[David H. Silber]

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 H. Silber [EMAIL PROTECTED] Project: Debian GNU/Linux (dbackup)
   Wanted:  Spare time.

 Programmer for hire.

Re: Downloading from US sites

[Siggy Brentrup]

> "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 software for releasing. I am
perfectly aware of the fact that software in Incoming is not for
public use; in contrast to CD vendors I don't want to be the 1st to
the market for making money from unreleased software.

In this particular case I have to download megabytes of gcc & friends
to take over the packages I volunteered to maintain from David Engel
and am not willing to pay more than absolutely necessary for it. I
know you guys over there have local calls for free, so you probably
don't see the problem.

I don't yet know enough about administering an ftp site, just a
thought: when ftp'ing I sometimes see ident requests coming in from
the server. Is there a way to use this mechanism to make parts of the
server available only to developers or whomever you trust enough?

Greetings
  Siggy

PS: Things being as they are, I'll have to wait until David's work has
been moved to ALPHA-TEST, provided Sven mirrors that one.

-- 
email: [EMAIL PROTECTED]   // programmer/*nix admin for hire
   [EMAIL PROTECTED] \\  Opinions are strictly my own,
voice: +49-251-8619-99\\  everything else is GPLed
Mime(RFC1521) encoded messages welcome \\  http://coming.soon/

Re: debian-1.0 availability

[Michael K. Johnson]

[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 mirror. Wuarchive mirrors tsx-11, along
>with sunsite, in systems/linux. 
>
>And systems/linux/tsx-11/distributions/debian/debian-1.0/sources is empty !!!

As a tsx-11 admin, I can explain that this is because tsx-11 simply doesn't
have a lot of space.  Every time anything in debian changes, tsx-11's
disk fills up.  So we don't carry the source.  I imagine that Ted made
the same mistake as infomagic when he saw two distributions and the
disk filling up again.  Removing SLS only gave us 50MB of room...

michaelkjohnson

ncurses ELF status report

[Michael Alan Dorman]

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, there are at least two base packages that depend on the old
ncurses-runtime which you _must_ remove in order to install the latest
ncurses.

This probably won't break them --- I expect they were compiled to query
/etc/terminfo, and that contains the most common terminal definitions, so
they should be OK from a functional point of view.

The thing that bothers me is that I haven't been able to figure out an
upgrade path that won't require users to do some complicated stuff with
dpkg, because updates of those packages would require ncurses3.0, which
requires ncurses-base, which conflicts with ncurses-runtime, which is
required by the older versions of these packages. 

Thoughts?  Can dselect pull this off?

Mike.
--
"ncurses is my life."

Re: ncurses-1.9.8a ELF release

[David Engel]

> >> 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 provide, the shared libraries?  And the
> symlinks are used by ld.so, no?  On a disk tight system I don't want to
> have to install -dev just to run some packages built on ncurses.  Let me
> know if I what I'm missing here.

Mike already did a good job of answering this.  The only thing I'll
add is that ldconfig manages any links needed by ld.so.  For run-time
packages, all you have to do is install the libfoo.so.X.Y.Z files and
ldconfig will do the rest.

David
-- 
David EngelOptical Data Systems, Inc.
[EMAIL PROTECTED]  1101 E. Arapaho Road
(214) 234-6400 Richardson, TX  75081

Just FYI

[Matthew Bailey]

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 must need pacakge.

Hope this helps a bit..

--
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: newest ncurses

[Michael Alan Dorman]

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' on both ncurses-runtime and -developer, since 
the new packages now (correctly) conflict with the above, and some base 
packages depend on ncurses-runtime.

This may break those particular programs, since we have changed the 
search structure for terminfo entries in the new packages.  You can 
correct this by symlinking the entries under /etc/terminfo to 
/usr/lib/terminfo.

This will be done automatically in ncurses-term-1.9.8a-3.

Mike.
--
"I'm a dinosaur.  Somebody's digging my bones."

newest ncurses

[Michael Alan Dorman]

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
upgrade and see if the problem goes away.  I think I've tracked most
problems down.  It should upgrade cleanly, but it is having to swap a few
things around, so if it doesn't, please let me know immediately. 

One reported problem with the current version can be worked around:  if,
after installing the updates, infocmp tells you it can't find a certain
terminal definition (say, linux or vt100), try doing: 

TERMINFO=/etc/terminfo infocmp ...

This should take care of the problem.  Unfortunately, infocmp uses
different routines to try and locate terminfo entries, and will take
longer to patch than ncurses itself because it is much more convoluted.  

Cheers,

Mike.
--
"I'm a dinosaur.  Somebody's digging my bones."

Re: 1.0 on Infomagic CD

[Alvar Bray]

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]
Richard>1.0 -> Holborn
Richard>Holborn/[contains 1.0]

1.1 -> Mornington_Cresent.

(Sorry, might amuse the Brits though :)

alvar

-- 
Alvar Bray

Meiko LimitedPhone:+44 1454 616171 
650 Aztec West   Fax:  +44 1454 618188 
Bristol BS12 4SD E-Mail:   [EMAIL PROTECTED]   
England  WWW:  http://www.meiko.com

Via: Debian GNU/Linux from home.

Bug#1998: xypic-3.2-3 requires nonexistant packages.

[osiris]

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.deb
mflib-1.0-5.deb

Here's the results from a configure attempt:

dpkg --pending --configure
dpkg: dependency problems prevent configuration of xypic:
 xypic depends on texbin (>3.1415-5);
 however:
  Version of texbin on system is 3.1415-4 xypic depends on mfbin (>2.71-4);
 however:
  Version of mfbin on system is 2.71-3 xypic depends on mflib (>1.0-6);
 however:
  Version of mflib on system is 1.0-5
dpkg: error processing xypic (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 xypic

Thanks
--
Rob

Bug#1999: ncurses-1.9.8a-1 missing terminals

[Bill Mitchell]

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-in terminal definitions?
(I note that there ara variations on these names in /usr/lib/terminfo/)

[EMAIL PROTECTED] (Bill Mitchell)

Re: ncurses-1.9.8a ELF release

[Michael Alan Dorman]

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?  On a disk tight system I don't want to
> have to install -dev just to run some packages built on ncurses.  Let me
> know if I what I'm missing here.

Under ELF, the .so (rather than .so.X.X.X) file is _only_ used for 
compile/link.  Some portion of the .X.X.X segment is encoded into the 
executable (as the soname), and _that_ (.so.X, say) is what the 
executable looks for.  So (get it?), the .so files are only needed in -dev.

Mike.
--
"I'm a dinosaur.  Somebody's digging my bones."

Re: ncurses-1.9.8a ELF release

[Michael Alan Dorman]

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 (incomplete/buggy?)
> termcap interface.

That's what I remembered, and I'm going to leave it out.  It won't be a 
big deal to put in if it turns out we're both mistaken.

Jeff -- I would be more likely to consider this if we had some 
experimental evidence regarding whether your average autoconf'd program 
will DTRT.  I'm willing to try it myself with ncftp and anything else I 
compile that uses ncurses, but I don't think that's a big enough sample.

> > For the moment I guess I'll re-rename them in the prerm.
> Ian Jackson, are you there?  I'd *really* like to hear your opinions
> on this.

I still want to get -2 out today because there are a few small but 
potentially significant problems in -1.

Mike.
"I'm a dinosaur.  Somebody's digging my bones."

Re: upgrading to ncurses-1.9.8a (and subsequent)

[Michael Alan Dorman]

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 the questions I've seen so far (with the 
exception of Jeff Noxon's request that we provide a link to libtermcap.so 
which I seem to remember was determined to be an accident waiting to 
happen on linux-gcc a few months back --- someone please correct me if 
I'm mistaken).

This should be uploaded quite soon, just as soon as I do yet another 
check on the tweaks I put in today.

> /sbin/ldconfig: warning: can't open /usr/X11R5/lib (No such file or 
> directory), skipping

I do want to emphasize that I'm not responsible for the above...

Mike.
--
"I'm a dinosaur.  Somebody's digging my bones."

Bug#1997: ncurses linux terminal definition for kbs

[Bill Mitchell]

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 backspace key should be recognized as kbs, and the DEL key
as kdch1.

[EMAIL PROTECTED] (Bill Mitchell)

Bug#1996: ncurses terminal defs and infocmp

[Bill Mitchell]

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 directory
root:ae-493# ls /usr/lib/terminfo/l
la120  linux-nic  liswb  ln03-w luna
linux-mlisa   ln03   lprluna68k
root:ae-493# ls /usr/lib/terminfo/x
x10term   x1750 xerox-lm  xtalk xterm-pcolor
x1700 x820  xerox1720 xterm-boldxterms
x1700-lm  xenix xerox820  xterm-color
x1720 xerox xl83  xterm-nic

Suggest inclusion of terminal defs matching the compiled-in
fallbacks into /usr/lib/terminfo.

[EMAIL PROTECTED] (Bill Mitchell)

So are Incoming files permanently world unreadble?

[osiris]

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 them to be moved to development?

There have been a couple of times (in the recent past) when I had a
fairly urgent need for some of the Incoming stuff well before it was
moved into development.

Thanks
--
Rob

Re: ncurses-1.9.8a ELF release

[Chris Fearnley]

'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 that what lib*.so provide, the shared libraries?  And the
symlinks are used by ld.so, no?  On a disk tight system I don't want to
have to install -dev just to run some packages built on ncurses.  Let me
know if I what I'm missing here.

-- 
Christopher J. Fearnley|UNIX SIG Leader at PACS
[EMAIL PROTECTED] (finger me!)|(Philadelphia Area Computer Society)
[EMAIL PROTECTED] |Design Science Revolutionary
http://www.netaxs.com/~cjf |Explorer in Universe
"Dare to be Naive" -- Bucky Fuller |Linux Advocate

Re: 1.0 on Infomagic CD

[Bill Mitchell]

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 
suggestion, and can't go back to re-read it to see if I misread it
the  first time through.

The intended point of my suggestion, and you might have beaten me to
this, was to have the real directory trees be named neutrally, so
that their names wouldn't need to change, and use symlinks with
meaningful names (which could be easily changed without causing
massive re-mirroring) to point to them.

> As to (1), I think names are better than numbers for various reasons:
> it's easier to remember what they mean, and it gives us the option of
> choosing some cute theme.
 
I don't really have strong preferences at this point about what
meaningful names are chosen for the symlinks.

> As to (2), I'm not convinced about hiding things; what we actually
> want is for people to look in the right place for a stable version
> without having to think about it.  If people actually want to live on
> the bleeding edge, it shouldn't actually be any effort to do so - just
> hard to do by accident.

My suggestion, and the names I chose for illustration, was intended
to show a structure which allowed that.  Unfortunately, I see that
I inadvertantly left out a directory level in some of my illustrative
namings.  Let me try again, with that mistake corrected (names shown
below are intended to be illustrative.  perhaps there are better
choices for the symlink names.  In any case, the symlink names would
be changeable without causing massive re-mirroring.):

   /debian/.hidden/debian-tree1/  # full 0.093 tree
   /debian/.hidden/debian-tree2/  # full 1.1 tree
   /debian/debian-stable -> /debian/.hidden/debian-tree1
   /debian/debian-unstable -> /debian/.hidden/debian-tree2
   /debian/debian-0.93 -> /debian/.hidden/debian-tree1
   /debian/debian-1.1.alpha -> /debian/.hidden/debian-tree2

Then, when 1.0 becomes the stable distribution, the symlinks
could change to:

   /debian/debian-stable -> /debian/.hidden/debian-tree2  # changed from tree1
   /debian/debian-0.93 -> /debian/.hidden/debian-tree1  # might be deleted
   /debian/debian-1.1 -> /debian/.hidden/debian-tree2

And no re-mirroring need occur.

Re: ncurses-1.9.8a ELF release

[David Engel]

> > 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 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 (incomplete/buggy?)
termcap interface.

> > The runtime package installs the shared libraries as lib*.so.3.0.new
> > and then renames them to lib*.so.3.0 in the postinst script.  This is
> > fine for not disturbing running programs when the package is being
> > upgraded, but there is no provision for deleting the files when the
> > package is removed.  Again, I'd like to hear Ian Jackson's thoughts on
> > adding special installation support for shared libraries to dpkg.
> 
> For the moment I guess I'll re-rename them in the prerm.

Ian Jackson, are you there?  I'd *really* like to hear your opinions
on this.

David
-- 
David EngelOptical Data Systems, Inc.
[EMAIL PROTECTED]  1101 E. Arapaho Road
(214) 234-6400 Richardson, TX  75081

uploads (??)

[Bill Mitchell]

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)

upgrading to ncurses-1.9.8a (and subsequent)

[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 that they should
remove these?

"dpkg --install ncurses3.0-1.9.8a-1.deb" said:
Selecting previously deselected package ncurses3.0.
(Reading database ... 14325 files and directories currently installed.)
Unpacking ncurses3.0 (from ncurses3.0-1.9.8a-1.deb) ...
Setting up ncurses3.0 ...
/sbin/ldconfig: warning: can't open /usr/X11R5/lib (No such file or directory), 
skipping

[EMAIL PROTECTED] (Bill Mitchell)

Re: Downloading from US sites

[Bill Mitchell]

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 downloadable
holding area (Arrived (?)) where they stay until being moved into the
distribution.

> I am sorry to be an ass here but you have to understand these views.

I wouldn't characterize it that way at all.

Re: Downloading from US sites

[Matthew Bailey]

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 sorry but I don't need anymore complaints about corrupt files.
I also don't want the illegal software that has been uploaded lately to 
be mirrored to other sites. Please understand the problems involved here. 
Maybe the announcement should be uploaded instead of mailed and when the 
archive maintainer moves the file into public view then it will get 
mailed to the mailing list.

I am sorry to be an ass here but you have to understand these views. I am 
doing what is best for the University by not allowing for illegal 
software to be downloaded.



--
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

[Richard Kettlewell]

>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.093 tree
>   /debian/.hidden/debian-tree2/  # full 1.1 tree
>   /debian-stable -> /debian/.hidden/debian-tree1
>   /debian-unstable -> /debian/.hidden/debian-tree2
>   /debian-0.93 -> /debian/.hidden/debian-tree1
>   /debian-1.1.alpha -> /debian/.hidden/debian-tree2
>
>Then, when 1.0 becomes the stable distribution, the symlinks
>could change to:
>
>   /debian-stable -> /debian/.hidden/debian-tree2
>   /debian-devel -> /debian/.hidden/debian-tree2
>   /debian-0.93 -> /debian/.hidden/debian-tree1  # might be deleted
>   /debian-1.1 -> /debian/.hidden/debian-tree2
>
>Once a debian/.hidden/treeN tree is established, it should not be
>renamed.

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.

As to (1), I think names are better than numbers for various reasons:
it's easier to remember what they mean, and it gives us the option of
choosing some cute theme.

As to (2), I'm not convinced about hiding things; what we actually
want is for people to look in the right place for a stable version
without having to think about it.  If people actually want to live on
the bleeding edge, it shouldn't actually be any effort to do so - just
hard to do by accident.

-- 
Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/

Re: Downloading from US sites

[Sven Rudolph]

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 uploaded to ftp.debian.org as of yet.

Do you mean the files in the ALPHA-TEST directory or the ones in the
Incoming directory ?

The ALPHA-TEST ones will be available at every major Debian mirror,
but first the discussion around it must come to a result everyone
agrees on.

I could mirror Incoming too, but currently it is hidden below private
at ftp.debian.org and this makes mirroring a bit more difficult.

Would this help you ? 

Any thoughts on this ? Any objection against mirroring the Incoming
area ?

Sven
-- 
Sven Rudolph ([EMAIL PROTECTED]); WWW : http://www.sax.de/~sr1/

Re: symlink in /usr/include (fwd)

[Bill Mitchell]

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 subject?
> 
> The only problem I see would be if I upgrade my kernel from non-debian
> sources.  But then I'd be someone who knows what I'm doing, I suppose.

I don't think we can assume that all debian users wanting to build
alternate kernels will know what they're doing WRT debian-specific
quirkiness such as this.

> And what about systems with multiple kernel trees in /usr/src [...]?

User/developers who are not debian developers might well just un-tar
kernel sources from a non-debian source archive and manually change
the /usr/src/linux symlink according to what sources version they want
to work with at a particular time.

Re: 1.0 on Infomagic CD

[Bill Mitchell]

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 understand it, mirrors have some trouble with directories
> changing names; so what we really want is a solution that keeps
> directory names fixed.  The suggestion below suffers here in that when
> 1.0 is declared to be released, the directory has to change name from
> not-released-1.0 to release-1.0.
> 
> This could be solved with a symlink, obviously, but that still leaves
> a directory called `not-released-1.0' containing released software,
> which may be felt to be suboptimal.

I was thinking about this last night.  It seems to me that the root
of the problem is that we have directory trees containing multiple
distributions, have given those directories meaningful names, and those
meaningful names have been taken by some people to to have different
meanings than the meaning intended by the namer.  Superseding those
meaningful names with other names (which still have the possibility
of being misinterpreted) causes massive re-mirroring.

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.093 tree
   /debian/.hidden/debian-tree2/  # full 1.1 tree
   /debian-stable -> /debian/.hidden/debian-tree1
   /debian-unstable -> /debian/.hidden/debian-tree2
   /debian-0.93 -> /debian/.hidden/debian-tree1
   /debian-1.1.alpha -> /debian/.hidden/debian-tree2

Then, when 1.0 becomes the stable distribution, the symlinks
could change to:

   /debian-stable -> /debian/.hidden/debian-tree2
   /debian-devel -> /debian/.hidden/debian-tree2
   /debian-0.93 -> /debian/.hidden/debian-tree1  # might be deleted
   /debian-1.1 -> /debian/.hidden/debian-tree2

Once a debian/.hidden/treeN tree is established, it should not be renamed.

Downloading from US sites

[Siggy Brentrup]

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 as
5.24DM/MB next year, note that these are only local phone calls!

While I'm keen of contributing to the Debian project, I just can't
afford the phone bill at these transfer rates.

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 uploaded to ftp.debian.org as of yet.

I'm thinking of adding a 1G disk at my new provider's site to mirror
debian including the ALPHA-TEST subtree, but there are political
objections from an upstream site to make it publicly available (You
know who you are).

Your comments are welcome.

Thanks
  Siggy

-- 
email: [EMAIL PROTECTED]   // programmer/*nix admin for hire
   [EMAIL PROTECTED] \\  Opinions are strictly my own,
voice: +49-251-8619-99\\  everything else is GPLed
Mime(RFC1521) encoded messages welcome \\  http://coming.soon/

Re: symlink in /usr/include (fwd)

[James A. Robinson]

> 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 includes in
/usr/include will make it a bit of a pain in the ass for people who
want to upgrade their kernel without using Deb packages.  What is
Stallman's objection to the link anyway?


Jim

Re: 1.0 on Infomagic CD

[Richard Kettlewell]

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 directories:
>
>release-0.93/
>not-released-1.0/
>
>Maybe it was not such a bad idea...

If I might just stick my oar in on this one:

As I understand it, mirrors have some trouble with directories
changing names; so what we really want is a solution that keeps
directory names fixed.  The suggestion below suffers here in that when
1.0 is declared to be released, the directory has to change name from
not-released-1.0 to release-1.0.

This could be solved with a symlink, obviously, but that still leaves
a directory called `not-released-1.0' containing released software,
which may be felt to be suboptimal.

A common practice is to give unreleased products code names.
(Remember Cairo, Daytona, etc...?)  If we were to adopt this scheme
then the unreleased software would just be a directory with a
non-obvious name; each release would have a symlink containing the
version number added when it was actually released.

If the 0.93R6/1.0 situation were handled like this we'd have, before
the release:

0.93R6 -> Highgate
Highgate/   [contains 0.93R6]
Holborn/[contains what will be 1.0]

and after the release:

0.93R6 -> Highgate
Highgate/   [contains 0.93R6]
1.0 -> Holborn
Holborn/[contains 1.0]

No renaming needed, no misleading filenames ... to find out what
Highgate and Holborn were without going through symlinks you'd have to
read a README which would also warn you about installing unreleased
software.

This idea went down quite well when discussed off-line last night -
what does anyone else think?

-- 
Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/

Re: Infomagic and 1.0

[Matthew Bailey]

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 the list already. I am getting illegal 
software uploads into the Incoming directory nd many ccomplaints about 
the files being corrupt. Most of these corrupt files are just files that 
are being uploaded. 
We need to come up with a convention for handling this. Any Ideas..
right now the files are 0660 to prevent downloads of illegal software or 
partially uploaded software. they should be owned imurdock.debian but for 
some strange reason they are ending up imurdock.wheel I think.

If you can figure out how to get the permission to .debian inside my 
ftpaccess file then the buster login would be able to download them.


--
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: ncurses available on ftp.pixar.com

[Matthew Bailey]

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 bounced mail messages from [EMAIL PROTECTED] Oh well shit 
happens. Ian M. if you get this everything that I had mailed you has 
already been said on the devel list.. I was tring to get your opinion 
before I did such.

--
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: ncurses available on ftp.pixar.com

[Michael Alan Dorman]

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 
package, don't they?

I concede.

Mike.
--
"I'm a dinosaur.  Somebody's digging my bones."

Re: Infomagic and 1.0

[Ian Murdock]

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?

Re: ncurses available on ftp.pixar.com

[Stephen Early]

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

Re: ncurses-1.9.8a ELF release

[Michael Alan Dorman]

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 libraries for form, menu and panel are in /lib.  They
> should probably be in /usr/lib unless and until a boot-critical
> program needs them /lib.

Well, since _nothing_ needs them right now...Done.

> The symlink for libcurses.a is wrong.  It should point to libncurses.a.

Done.

> 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?

> The runtime package installs the shared libraries as lib*.so.3.0.new
> and then renames them to lib*.so.3.0 in the postinst script.  This is
> fine for not disturbing running programs when the package is being
> upgraded, but there is no provision for deleting the files when the
> package is removed.  Again, I'd like to hear Ian Jackson's thoughts on
> adding special installation support for shared libraries to dpkg.

For the moment I guess I'll re-rename them in the prerm.

Mike.
--
"I'm a dinosaur.  Somebody's digging my bones."

Re: ncurses available on ftp.pixar.com

[Michael Alan Dorman]

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 for 
pointing this out --- in the course of testing I had of course zapped my 
old ncurses a while ago.

-2 should be out soon.

> And how to elegantly get rid of the huge /usr/lib/terminfo database
> w/o installing and purging?

Well, you could first 'dpkg --purge ncurses-runtime'.  I don't know 
offhand what all is dependent upon ncurses-runtime at this point.

I realized that both ncurses-base and ncurses-term should conflict with
ncurses-runtime, and that ncursesX.X-dev should conflict with
ncurses-developer.  This _might_ make for some hairy dependency issues, 
but I don't think so --- nothing terribly big depends on either of those 
right now.

Mike.
--
"I'm a dinosaur.  Somebody's digging my bones."

Re: ncurses available on ftp.pixar.com

[Michael Alan Dorman]

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 went ahead and made the move.  ESR is saying that he doesn't 
expect anything but bugfixes from here on out.

Mike.
--
"I'm a dinosaur.  Somebody's digging my bones."

Re: ncurses available on ftp.pixar.com

[Michael Alan Dorman]

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 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. 

Oh.

Well, I (and a number of other people) missed the announcement of this 
change in policy.  Since it was well-known that ftp.debian.org had just 
been refurbished, I, at least, had assumed it was merely an oversight and 
was trying to compensate for it.

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. 

> Please do not upload to ftp.pixar.com unless there is an absolute need.

I'm not trying to bypass the COC here or anything, just trying to work 
around what I and several others perceived as a "glitch".

Mike.
--
"I'm a dinosaur.  Somebody's digging my bones."

Re: bumping the version number

[Alvar Bray]

>> 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 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.

Indeed - my mirror deleted the tree - fortunately I have a backup.

:)

alvar

-- 
Alvar Bray

Meiko LimitedPhone:+44 1454 616171 
650 Aztec West   Fax:  +44 1454 618188 
Bristol BS12 4SD E-Mail:   [EMAIL PROTECTED]   
England  WWW:  http://www.meiko.com

Via: Debian GNU/Linux from home.

Re: symlink in /usr/include (fwd)

[Chris Fearnley]

'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 my kernel from non-debian
sources.  But then I'd be someone who knows what I'm doing, I suppose.
And what about systems with multiple kernel trees in /usr/src --
wouldn't you want each to have it's own /usr/include updated by make
before each build?

A brief look at the kernel source didn't answer these questions for
me.  What does our kernel maintainer think.

-- 
Christopher J. Fearnley|UNIX SIG Leader at PACS
[EMAIL PROTECTED] (finger me!)|(Philadelphia Area Computer Society)
[EMAIL PROTECTED] |Design Science Revolutionary
http://www.netaxs.com/~cjf |Explorer in Universe
"Dare to be Naive" -- Bucky Fuller |Linux Advocate

Re: bumping the version number

[John T. Larkin]

> 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.  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.

Not quite right.  I've modified my mirror to account for the changes on
ftp.debian.org, and now have the entire tree under /debian (except for the
private stuff, of course).  I'm currently following the same procedures
ftp.debian.org is on their tree arrangements.  There is an ALPHA-TEST dir
unreadable by all, with a debian-1.0 dir right under it.  

What I don't understand, however, is why bother making ALPHA-TEST unreadable, 
if you have a symlink called 'development' that takes a user right to the 
hidden 'ALPHA-TEST/debian-1.0'.  IMHO, this defeats the purpose of insuring
that a person who is ftp-ing version 1.0 really knows what they're getting
into.

-- 
- John Larkin   
- [EMAIL PROTECTED]
- http://aij.st.hmc.edu/~jlarkin

Re: ncurses-1.9.8a ELF release

[David Engel]

> 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*.so are in the runtime package.  They should be
in the -dev package.

The shared libraries for form, menu and panel are in /lib.  They
should probably be in /usr/lib unless and until a boot-critical
program needs them /lib.

The symlink for libcurses.a is wrong.  It should point to libncurses.a.

There is no symlink for libcurses.so.  There should be one in the -dev
package.

The runtime package installs the shared libraries as lib*.so.3.0.new
and then renames them to lib*.so.3.0 in the postinst script.  This is
fine for not disturbing running programs when the package is being
upgraded, but there is no provision for deleting the files when the
package is removed.  Again, I'd like to hear Ian Jackson's thoughts on
adding special installation support for shared libraries to dpkg.

David
-- 
David EngelOptical Data Systems, Inc.
[EMAIL PROTECTED]  1101 E. Arapaho Road
(214) 234-6400 Richardson, TX  75081

Re: ncurses available on ftp.pixar.com

[roro]

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.
> 

On second thought -- not really.  The old ncurses-developer, and 
ncurses-runtime are not automatically superceded.  I could remove 
developer.  dpkg stopped me on removing runtime, because dependencies
to dialog and miscutils.  I compliled a new miscutils and kicked dialog.
Then I removed ncurses-runtime.  Now /use/lib/terminfo is no more.

Looks pretty cool.  OTOH, I should go to bed ...

mfg
Rolf Rossius
   

e2-2.0.beta-3 uploaded

[Bill Mitchell]

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
Source: e2
Binary: e2 
Version: 2.0.beta-3
Description: 
 e2: A text editor, patterned after the unix vi editor
Priority: Low
Changes: 
aout package
* Update from 2.0h beta to 2.0i beta
*
* This is a BETA TEST package
* It is being announced only to debian-devel at this time
*
* e2-2.0.beta is patterned after the vi editor, and provides
* several enhancements, among which are C language syntax
* hiliting and an X11 interface with clickpoint positioning,
* click & drag selection, html processing, and more.
*
* Please report bugs directly to the author at [EMAIL PROTECTED]
* The following is from the author's announcement.
  .
The biggest differences between this version (2.0i) and the previous
beta-test version (2.0h) are as follows...
  .
* The options which control the "c" display mode can now be set
  in your elvis.ini file or .exrc (elvis.rc for non-UNIX) file.
  .
* Added support for a "binary" option, so that binary files can
  be read and written.  Generally, the "binary" option is set
  in the "elvis.brf" file so it will be automatically set for each
  new buffer, before the buffer is loaded with data from the file.
  .
* Support for "wrapmargin" has been implemented in normal and
  c display modes.
  .
* In the "man" display modes, the .B and .I commands will now insert
  whitespace between arguments.  Previously they omitted whitespace
  like the .BI, etc. commands do.
  .
* Implemented abbreviations.
  .
* Fixed many bugs:
  * I fixed a bug in the handling of modifier keys, which should
make some non-U.S. keyboards work better.
  .
  * Fixed bugs in the :xit and :goto commands, and added the
:close command.
  .
  * I believe I have fixed that annoying bug which caused cw to
leave the old text and the terminating '$' in the buffer
even after ESC.
  .
  * Fixed some bugs in the visual ! command.
  .
* I've written most of the documentation.  The missing chapters are
  4 (ex mode), 8 (user interfaces), 9 (initialization & sessions),
  and 11 (error messages).
Files:
 -rw-rw-r--   1 root root   396979 Dec  9 10:14 e2-2.0.beta-3.tar.gz
 -rw-rw-r--   1 root root11770 Dec  9 10:14 e2-2.0.beta-3.diff.gz
 -rw-r--r--   1 root root   173336 Dec  9 10:13 e2-2.0.beta-3.deb
 beae85e141cd8547216d2fd166df9527  e2-2.0.beta-3.tar.gz
 e6cab0f6877290e640bdf221f221f0e8  e2-2.0.beta-3.diff.gz
 8bd3325f8de28a4be13bf4404f1c7d8a  e2-2.0.beta-3.deb

[EMAIL PROTECTED] (Bill Mitchell)