Re: TclX package again

[Philippe Troin]

On Tue, 20 Aug 1996 09:51:39 CDT David Engel ([EMAIL PROTECTED]) 
wrote:

> Note: I'm copying this to debian-devel to get feedback on my response
> to Philippe's question #3.  If you do respond, please include a direct
> response to me in addition to the list.  I was inadvertantly dropped
> from debian-devel three weeks ago and no amount of trying on my or
> Bruce's parts has been able to get me back on the list.

Can anyone put me on the list too ? In the meantime can you post 
followups to my address as well as the list, please...

> Philippe Troin writes:
> > 1) When compiling (make -f debian.rules) Tcl (needed to build tclX, 
> > what a shame that you need the tcl/tk source tree), I have errors 
> > in tclPosixStr.c about a case having same value (EDEADLOCK and 
> > EDEADLK are both defined and have the same value). Fixed by adding 
> > an #if EDEADLOCK != EDEADLK.
> > Did you recompile it lately ?
> 
> I'm aware of the problem, but haven't had time to fix it yet.

It's a two lines fix actually. BTW, Tcl 7.4 has the same problem.

> > 2) I've tried to 'make test' in both tcl7.5 and tk4.1 source trees, 
> > both failed. Shouldn't we report this to the Tcl/Tk maintainers 
> > and/or try to fix it ? This works perfectly on other systems (tried 
> > Solaris).
> 
> What do you mean by failed?  If you mean some individual tests fail,
> then that is expected.  I believe all of the Tk failures are due to
> non-portable tests.  I have not had time to look into the Tcl
> fileevent failures yet, but I suspect they are either due to
> non-portable tests also or libc bugs.

Some individual test failed for Tcl 7.5 (one test), Tk 4.1 (3 or 4 
tests), TclX 7.5 (4 or 5tests). I'll try to check them out... when 
I've got time.

> > 3) I think I should have tclX be the same (regarding package 
> > management) and tcl and tk. ie, I will have tclX74 and tclX75, both 
> > incompatible with tclX. tclX74-dev and tcl75-dev being mutually 
> > exclusive too... What do you think about it ?
> 
> I agree, for now.  One change I'm considering is to give each major
> Tcl version it's own include directory (e.g. /usr/include/tcl7.4,
> /usr/include/tcl7.5).  This would make it easier to have multiple
> development packages installed simultaneously.  The limitation of only
> having one installed at a time is quickly becoming a problem because
> of the way Tcl/Tk-based packages are tied to a specific version of
> Tcl/Tk.  What do you think?

I think it's fine. Tcl and Tk will need a little package work, but 
TclX is already version clean as it's installed in 
/usr/lib/tclX/. But we'll have to implement 
/etc/alternatives stuff for the .a and the .so.
Do you see any other problem ?

> > 4) I plan having a separate tclX7[45]-doc package for the help 
> > system ( and /usr/bin/tclhelp). What's your 
> > opinion on that one ?
> 
> I've considered doing something like this with the section 3 manual
> pages for Tcl/Tk.  The reason I hadn't done it yet is that I didn't
> want to create yet another package unless I really needed to or
> someone else wanted it.

I think keeping the manual pages within the devel package is good.
However for TclX, /usr/lib/tclX/7.*/help contains a duplicate of 
all the man pages formatted differently to be used with tclhelp, 
hence the new 'doc' package. I must admit I never use this feature 
myself.
But generally, keeping the manpages with the development stuff 
should be a good thing.

Phil.

Bug#4051: access permissions for /usr/bin/fdmount

[Michael Meskes]

Daniel Quinlan writes:
> Use geteuid(2) and/or use a configuration file that says who has
> access.  Using permissions alone to dictate who has access to
> *running* the binary is bad, IMHO, and I think the Debian package
> guidelines agree (unless they've been changed).  Even worse, it's a
> `4750' binary in /bin -- so users are getting "permission denied"
> errors for something in their path.

Okay, I changed that. I will upload a new version once I'm back in the
office (Wednesday).

Michael

-- 
Michael Meskes   |_  __  
[EMAIL PROTECTED] |   / ___// / // / / __ \___  __
[EMAIL PROTECTED]  |   \__ \/ /_  / // /_/ /_/ / _ \/ ___/ ___/
[EMAIL PROTECTED]|  ___/ / __/ /__  __/\__, /  __/ /  (__  )
Use Debian Linux!| //_/  /_/  //\___/_/  //

util-linux 2.5-5 (m68k patches applied)

[Guy Maor]

Sorry for the long delay.  I'm uploading 2.5-5 now which has your m68k
patches, among other things.


Date: 20 Aug 96 16:57 UT
Format: 1.6
Distribution: unstable
Urgency: Low
Maintainer: Guy Maor <[EMAIL PROTECTED]>
Source: util-linux
Version: 2.5-5
Binary:  util-linux
Architecture:  i386 source
Description: 
 util-linux: Miscellaneous system utilities.
Changes: 
 Tue Aug 20 11:21:21 1996  Guy Maor  <[EMAIL PROTECTED]>
 .
Released version 2.5-5.
 .
* debian.rules: Cosmetic changes, fixed 4175.
 .
 Tue Jul 30 02:54:16 1996  Guy Maor  <[EMAIL PROTECTED]>
 .
* fdisk.c,cfdisk.c: Applied patch from Miquel van Smoorenburg
<[EMAIL PROTECTED]> to let fdisk and cfdisk support Linux
extended partitions.

Re: CC's on this mailing list

[Dan Stromberg]

Mr Stuart Lamble wrote:
> All very nice, but it dodges the major reason for people disliking duplicate
> copies of messages: they pay for their PPP link (or UUCP feed, or whatever).
> Identifying duplicates by their message IDs means that you have to download
> both messages, unless you can do the filtering at your ISP's end of the link.
> 
> I'm not overly concerned personally at the moment - I'm at university, and
> the government pays for my feed :-) - but it's generally not good etiquette
> full stop.


Bandwidth prices have dropped quite healthily in recent years, and they
are going to continue to do so.  Rambling on about being cc'd, when the
bandwidth prices are still dropping, and YOU HAVE alternatives, is silly
at best.


Those of you who've been going on and on about this, consuming far too
much human-time (on this already excessively voluminous list) :

1) Have you switched up to a 28.8kbps modem yet, or at least a 14.4kbps
modem?  Yes, modems cost money, but shelling out a little for a modem
now may save you heavily in bandwidth if you transfer much data - and
would save you a lot more than badgering people about cc'ing.

2) Are you transferring your mail gzip'd?  If not, why not?  Have you
bothered to look for an ISP that will help you do this?  This too would
save you a lot more than badgering people about cc'ing.

3) Have you bothered to look for an ISP that will do upstream filtering?
Have you even bothered to ask your current ISP if they'd be willing?  If
you want to do all your interaction with the internet over a low
bandwidth link, and you're concerned about bandwidth costs, then this
SHOULD be a deciding factor in your choice of ISP.  This also, would
save you a lot more than badgering people about cc'ing.

Bug#4202: dpkg chainsaw massacre

[Thomas Koenig]

Package: dpkg
Version: 1.2.11

In trying to make a Debian package, I managed to create a regular
file in debian-tmp/usr/lib (a wrong flag with install).

When I tried to test-install the package, there were a few warnings,
but dpkg happily overwrote /usr/lib with that particular text file.
I'll eagerly await what fsck has to say about this.

I'll have another go at developing for Debian when that particular
bug has been fixed.
-- 
Thomas Koenig, [EMAIL PROTECTED], [EMAIL PROTECTED]
The joy of engineering is to find a straight line on a double
logarithmic diagram.

Re: libpaper 1.0 on master

[Dan Stromberg]

Storing one thing in one place is an excellent goal.

Treating multiple things as tho they were one thing (EG "all printers
use the same paper) can be troublesome.

Ideal: keep the option of an /etc/papersize, but allow a user to
override /etc/papersize if desired, thru ~/papersize or environment
variables.

Richard Kaszeta wrote:
> 
> >Shouldn't the "paper size" be an attribute of a print queue, and not an
> >attribute of a machine?
> 
> Paper size effect more that just printers.  Previewers and tex tools
> come to mind, there may be others...
> 
> All I know is right now I've got to tweak quite a few things on a
> standard debian 1.1 system so that dvips, xdvi, genscript, and a few
> other programs work well and have the same idea of a default paper
> size.
> 
> --
> Richard W Kaszeta   Graduate Student/Sysadmin
> [EMAIL PROTECTED]University of MN, ME Dept
> http://www.menet.umn.edu/~kaszeta

Bug#4202: It's not that bad...

[Thomas Koenig]

Apparently, dpkg decided to rename /usr/lib to /usr/lib.dpkg-tmp
and only removed a few files from it.  Moving the directory
back again, I got a few errors such as perl being unable to find
libgdbm and libdb.

This appears to conform to warnings such as

dpkg - warning, overriding problem because --force enabled:
 trying to overwrite `/usr/lib', which is also in package libgdbm1

Oh well... I'll wait and see what other programs will have mysterious
problems now.  Seems like I hit ^C fast enough to avoid total lossage.

The problem still needs to be fixed, though.
-- 
Thomas Koenig, [EMAIL PROTECTED], [EMAIL PROTECTED]
The joy of engineering is to find a straight line on a double
logarithmic diagram.

Re: Question about latex package

[Richard Kaszeta]

>These problems with the unpacked (preinstalled configured) latex (and
>related) packages has been noticed earlier but was never dealed with.
>Anyone having a mail adress at hand for contacting the latex3 team?

The 'Latex3 Home Page',
http://homepage.cistron.nl/~jlbraams/ltx3/latex3.html,

says the following:

If you would like to contact the LaTeX3 Project Team personally (for
example for speaking at conferences, volunteering effort, offering
consultancy work, etc.) then please follow the instructions for
submitting a bug report.

The 'bug report page' is 

http://homepage.cistron.nl/~jlbraams/ltx3/bugs.html

Erick, do you want to send the email, or shall I?

-- 
Richard W Kaszeta   Graduate Student/Sysadmin
[EMAIL PROTECTED]   University of MN, ME Dept
http://www.menet.umn.edu/~kaszeta

Bug#4205: bind does not reinstall if /usr/sbin/bind was removed

[Yves Arrouye]

marin66# dpkg -i bind_4.9.3-P1-3.deb 
(Reading database ... 22241 files and directories currently installed.)
Preparing to replace bind (using bind_4.9.3-P1-3.deb) ...
start-stop-daemon: unable to stat executable `/usr/sbin/named': No such file or 
directory
dpkg: error processing bind_4.9.3-P1-3.deb (--install):
 subprocess pre-installation script returned error exit status 2
Errors were encountered while processing:
 bind_4.9.3-P1-3.deb

Yves.

-- 
Yves Arrouye Email : [EMAIL PROTECTED]
7, avenue Leon Bollee   Web : http://www.fdn.fr/~yarrouye/
75013 ParisWork : +33 53 61 09 55
France Home : +33 45 95 64 59

Bug#4203: sendmail does not install if /usr/sbin/sendmail does not exist?

[Yves Arrouye]

Package: sendmail
Version: 8.7.5-4

marin38# dpkg -i sendmail_8.7.5-4.deb 
(Reading database ... 4 files and directories currently installed.)
Preparing to replace sendmail (using sendmail_8.7.5-4.deb) ...
start-stop-daemon: unable to stat executable `/usr/sbin/sendmail': No such file 
or directory
dpkg: error processing sendmail_8.7.5-4.deb (--install):
 subprocess pre-installation script returned error exit status 2
Errors were encountered while processing:
 sendmail_8.7.5-4.deb

Apparently the install fails because the installation script is run with
-e set. If I touch /usr/sbin/sendmail, it installs fine.

Yves.


-- 
Yves Arrouye Email : [EMAIL PROTECTED]
7, avenue Leon Bollee   Web : http://www.fdn.fr/~yarrouye/
75013 ParisWork : +33 53 61 09 55
France Home : +33 45 95 64 59

Bug#4204: cron does not install if /usr/sbin/cron does not exist!?

[Yves Arrouye]

Package: cron
Version: 3.0pl1-33

Here is what I get:

marin13# dpkg -i cron_3.0pl1-33.deb 
(Reading database ... 0 files and directories currently installed.) 
Preparing to replace cron (using cron_3.0pl1-33.deb) ...
start-stop-daemon: unable to stat executable `/usr/sbin/cron': No such file or d
irectory
dpkg: warning - old pre-removal script returned error exit status 2
dpkg - trying script from the new package instead ...
start-stop-daemon: unable to stat executable `/usr/sbin/cron': No such file or d
irectory
dpkg: error processing cron_3.0pl1-33.deb (--install):
 subprocess new pre-removal script returned error exit status 2
start-stop-daemon: unable to stat executable `/usr/sbin/cron': No such file or d
irectory
dpkg: error while cleaning up:
 subprocess post-installation script returned error exit status 2
Errors were encountered while processing:
 cron_3.0pl1-33.deb

Apparently the install fails because the installation script is run with
-e set. If I touch /usr/sbin/cron, it installs fine.

Yves.

-- 
Yves Arrouye Email : [EMAIL PROTECTED]
7, avenue Leon Bollee   Web : http://www.fdn.fr/~yarrouye/
75013 ParisWork : +33 53 61 09 55
France Home : +33 45 95 64 59

Re: libpaper 1.0 on master

[Yves Arrouye]

Yves Arrouye Email : [EMAIL PROTECTED]
7, avenue Leon Bollee   Web : http://www.fdn.fr/~yarrouye/
75013 ParisWork : +33 53 61 09 55
France Home : +33 45 95 64 59

On Tue, 20 Aug 1996, Dan Stromberg wrote:

> Storing one thing in one place is an excellent goal.
> 
> Treating multiple things as tho they were one thing (EG "all printers
> use the same paper) can be troublesome.
> 
> Ideal: keep the option of an /etc/papersize, but allow a user to
> override /etc/papersize if desired, thru ~/papersize or environment
> variables.

That's what libpaper does: use whatever paper size is in the PAPER env
var, or if empty whatever name found in the file whose name is in the
PAPERSIZE env var, or if this var is empty too look in /etc/papersize,
defaulting to letter (sigh).

Yves.

Can someone release the latest i386 kernel packages?

[Brian Mays]

I've noticed that version 2.0.7 of the kernel packages, i.e.,
kernel-headers, kernel-image, and kernel-source, for the i386 have
been sitting in Incoming for about a month.  There are no .changes
files for these packages, which is probably the reason that they have
not been transferred out of the Incoming directory.

Last month I saw these packages in Incoming and compiled a new
pcmcia-cs package for this kernel version hoping that it would be
released along with them.  Well, the pcmcia-cs package has been
released for kernel version 2.0.7, but the kernel packages in
unstable/binary-i386/base are still version 2.0.6.

Can someone please transfer these packages to the unstable
distribution tree?  Thanks.

--
Brian

Bug#4139: libpaper /etc/papersize is auto-handled conffile

[Yves Arrouye]

> Package: libpaper
> Version: 1.0-1
> 
> The package contains /etc/papersize as a dpkg-handled conffile, but
> this file is also modified by many packages' maintainer scripts
> (including those of libpaper).
> 
> This is forbidden.  See the dpkg programmers' manual.

As I said before, this will be changed by libpaper 1.0-2. Which will maybe
have a papersize command instead of paper. 

Yves.

Bug#4137: libpaper contains compressed manpage, or policy should change

[Yves Arrouye]

> Package: libpaper
> Version: 1.0-1
> 
> The package contains:
> -r--r--r-- root/root   718 Aug 13 18:04 1996 usr/man/man1/paper.1.gz
> 
> 2. Either it should not be compressed (see the guidelines) or we
> should mandate compressed manpages.

I remember that a long time ago it was said that it was okay to gzip
manual pages because the manual reader did handle them nicely? If not,
I vote for having gzipped manual pages. The problem if it is not specified
clearly is that one cannot just gzip -9f /usr/man/man?/* because then
when packages are removed the original manual pages are not found and the 
gzipped ones not removed; and it would be foolish to make dpkg handle that
special case. If nobody objects, can we have gzipped (not compressed)
manual pages by default?

In the meantime, should I not compress the manual pages?

Yves.

Bug#4201: doc-debian `bug-reporting.txt' out of date

[Richard Kettlewell]

Package: doc-debian
Version: 1.0-3

In /usr/doc/debian/bug-reporting.txt.gz:

 HOW TO REPORT A BUG IN DEBIAN
   
   Send mail to [EMAIL PROTECTED], as described below.

However, according to:

http://www.cl.cam.ac.uk/users/iwj10/debian-bugs/Reporting.html

the address is now:

[EMAIL PROTECTED]

ttfn/rjk

Unanswered problem reports by maintainer and package

[owner]

The following problem reports have not yet been marked as `taken up' by a
message to [EMAIL PROTECTED] or or `forwarded' by a
message to [EMAIL PROTECTED]

The maintainer listed against each package is derived from the Maintainer
field of the package as found in the development tree; there is an override
file that can be amended to get the right results if you have taken over a
package and do not expect to issue a new version soon.

Variant versions of the Maintainer field for the same actual package
maintainer will be listed separately.

Maintainers with few outstanding bugs appear first, to avoid those with few
bugs being lost deep in the message.

 Package RefSubject

Michael Meskes <[EMAIL PROTECTED]> (1 bugs):
 lyx, ftp.d   4078  lyx should be in `contrib'

Manoj Srivastava <[EMAIL PROTECTED]> (1 bugs):
 make 4073  make pattern rules delete intermediate files

Martin Schulze <[EMAIL PROTECTED]> (1 bugs):
 sysklogd 4163  syslogd loops

Brian Mays <[EMAIL PROTECTED]> (1 bugs):
 cpio 4072  cpio package is missing rmt.8 manual

Karl Sackett <[EMAIL PROTECTED]> (1 bugs):
 exmh 3824  exmh fails to start

Martin Schulze <[EMAIL PROTECTED]> (1 bugs):
 zoo  3961  14 character file name limit in zoo

Nikhil Nair <[EMAIL PROTECTED]> (1 bugs):
 gnuchess 4123  "gnuchess" requires changes for multi-arch support

Karl Ferguson <[EMAIL PROTECTED]> (1 bugs):
 unarj3641  unarj description: ext start indented, summary starts w/ pk

[EMAIL PROTECTED] (Brian C. White) (1 bugs):
 gnats3053  gnats: typo in postinst omits install-info

David Frey <[EMAIL PROTECTED]> (1 bugs):
 rpncalc  4156  rpncalc has unexecutable unwriteable /usr/man, /usr/man/man

Jeroen van der Most <[EMAIL PROTECTED]> (1 bugs):
 dmalloc  3925  "dmalloc" requires changes for multi-arch support

Mike Coleman <[EMAIL PROTECTED]> (1 bugs):
 nn   4181  Searching for wrong active file

[EMAIL PROTECTED] (Bill Mitchell) (1 bugs):
 elv-ctags2503  elvis and emacs both provide ctags

Brian White <[EMAIL PROTECTED]> (1 bugs):
 ferret   4164  Ferret extended description has blank lines

Brian Sulcer <[EMAIL PROTECTED]> (1 bugs):
 mgt  4023  "mgt" requires changes for multi-arch support

Susan Kleinmann <[EMAIL PROTECTED]> (1 bugs):
 sp   4102  sp and LaTeX problems

[EMAIL PROTECTED] (Andy W.P. Guy) (2 bugs):
 dpkg-ftp 2870  dpkg-ftp-1.4.1 bug
 dpkg-ftp 2933  dpkg-ftp needs perl 5.002

[EMAIL PROTECTED] (Andrew D. Fernandes) (2 bugs):
 acs  3559  acs description: no ext
 acs  3851  "acs" requires changes to support multiple arches

Kenny Wickstrom <[EMAIL PROTECTED]> (2 bugs):
 tin  3787  tin uses /etc/news/descriptions instead of /etc/news/newsgr
 tin  3942  tin cannot find Newsgroup Descriptions

Siggy Brentrup <[EMAIL PROTECTED]> (2 bugs):
 electric-f   3582  electric-fence description: no ext
 electric-f   4045  "electric-fence" requires changes for multi-arch support

Anders Christrom <[EMAIL PROTECTED]> (2 bugs):
 lists.debi   3199  Bizarre message from [EMAIL PROTECTED]
 lists.debi   3978  problem (re)subscribing to debian-devel

Kenneth MacDonald <[EMAIL PROTECTED]> (2 bugs):
 ispell   2425  ispell thinks `formated' is correct
 ispell   3196  ispell symlinks broken

Anders Chrigstrom <[EMAIL PROTECTED]> (2 bugs):
 bison3955  yacc script uses $* instead of "$@"
 bison4052  access permissions for /usr/bin/{mkparser, mkparserclass}

Michael Alan Dorman <[EMAIL PROTECTED]> (2 bugs):
 lrzsz4075  Possible security problem with lrzsz
 mingetty 3362  Problems encountered while compiling "mingetty" for m68k ar

Ray Dassen <[EMAIL PROTECTED]> (2 bugs):
 www.debian   3431  some packages have no information on WWW-server
 www.debian   3700  Web pages lack 

Steve Greenland <[EMAIL PROTECTED]> (2 bugs):
 nvi  2825  restricted movement in nvi
 nvi  3967  hex codes instead of 8-bit characters

Christian Linhart <[EMAIL PROTECTED]> (2 bugs):
 xarchie   887  xarchie barfs when ftp closes unexpectedly
 xarchie  1275  xarchie clumsy with 2-button mouse

Rob Browning <[EMAIL PROTECTED]> (2 bugs):
 libwww-per   3611  libwww-perl description: no ext
 perl-tk  4068  pgs in perl-tk does not work

Steven B Dunham <[EMAIL PROTECTED]> (2 bugs):
 hdparm   2197  hdparm -c switch
 hdparm   3866  "hdparm" requires changes to support multiple arches

Maarten Boekhold <[EMAIL PROTECTED]> (2 bugs):
 slrn 4069  slrn gives error
 slrn 4103  slrn epends on unavailable slang-lib09931

[EMAIL PROTECTED] (D.J. Gregor) (2 bugs):
 cdtool   2450  `cdir' prints out huge chunks of /etc/passwd !
 unclutter4042  "unclutter" requires changes for multi-arch support

Raul Miller <[EMAIL PROTECTED]> (3 bugs):
 sam  4030  "sam" requires changes for multi-arch support
 ucbmpeg  3454  ucbmpeg control file problems
 ucbmpeg  3509  mpeg_play puts bogus statist

Re: TclX package again

[David Engel]

Note: I'm copying this to debian-devel to get feedback on my response
to Philippe's question #3.  If you do respond, please include a direct
response to me in addition to the list.  I was inadvertantly dropped
from debian-devel three weeks ago and no amount of trying on my or
Bruce's parts has been able to get me back on the list.

Philippe Troin writes:
> 1) When compiling (make -f debian.rules) Tcl (needed to build tclX, 
> what a shame that you need the tcl/tk source tree), I have errors 
> in tclPosixStr.c about a case having same value (EDEADLOCK and 
> EDEADLK are both defined and have the same value). Fixed by adding 
> an #if EDEADLOCK != EDEADLK.
> Did you recompile it lately ?

I'm aware of the problem, but haven't had time to fix it yet.

> 2) I've tried to 'make test' in both tcl7.5 and tk4.1 source trees, 
> both failed. Shouldn't we report this to the Tcl/Tk maintainers 
> and/or try to fix it ? This works perfectly on other systems (tried 
> Solaris).

What do you mean by failed?  If you mean some individual tests fail,
then that is expected.  I believe all of the Tk failures are due to
non-portable tests.  I have not had time to look into the Tcl
fileevent failures yet, but I suspect they are either due to
non-portable tests also or libc bugs.

> 3) I think I should have tclX be the same (regarding package 
> management) and tcl and tk. ie, I will have tclX74 and tclX75, both 
> incompatible with tclX. tclX74-dev and tcl75-dev being mutually 
> exclusive too... What do you think about it ?

I agree, for now.  One change I'm considering is to give each major
Tcl version it's own include directory (e.g. /usr/include/tcl7.4,
/usr/include/tcl7.5).  This would make it easier to have multiple
development packages installed simultaneously.  The limitation of only
having one installed at a time is quickly becoming a problem because
of the way Tcl/Tk-based packages are tied to a specific version of
Tcl/Tk.  What do you think?

> 4) I plan having a separate tclX7[45]-doc package for the help 
> system (/usr/lib/tclX/7.*/help and /usr/bin/tclhelp). What's your 
> opinion on that one ?

I've considered doing something like this with the section 3 manual
pages for Tcl/Tk.  The reason I hadn't done it yet is that I didn't
want to create yet another package unless I really needed to or
someone else wanted it.

> 5) I haven't had time yet to look after the other platform stuff. 
> Last time you told me to remove any hard-coded "i386" for the 
> debian support. I assume you're talking about the debian.* file,s 
> right ?

Yes.

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

dpkg-1.3.6, hello-1.3-10: new shared library scheme

[Ian Jackson]

I've now implemented the shared library scheme as described earlier.

I don't expect to make any further significant changes to the new
source package format and building scheme.  I shall finalise this in a
week unless there are significant complaints.  So: please download
these and look at them and try them out.

Please install dpkg-1.3.6 and read section 2.2 of the programmers'
manual to see what shared library package maintainers need to do.

Packages which just use shared libraries use dpkg-shlibdeps to
generate the dependencies.  See dpkg-source(1) and the hello package
for details.

There is a mechanism involving /etc/dpkg/shlibs.default to cope with
libraries which don't know about the new scheme.  At the moment I've
only put libc5 and ncurses3.0 in here; other libraries can be added
locally, but it would be better to mail me.

Other significant changes here are:
 * I've broken the argument unparsing to match braindamage in the
   latest versions of tar.  If you've had trouble with dpkg-source try
   this version.
 * dpkg-gencontrol has a default output file.

Ian.

-BEGIN PGP SIGNED MESSAGE-

Format: 1.5
Date: Tue, 20 Aug 1996 15:39:58 +0100
Source: dpkg
Binary: dpkg
Architecture: source i386
Version: 1.3.6
Distribution: experimental
Urgency: low (HIGH for new source format)
Maintainer: Ian Jackson <[EMAIL PROTECTED]>
Description: 
 dpkg   - Package maintenance system for Debian Linux
Changes: 
 dpkg (1.3.6) experimental; urgency=low (HIGH for new source format)
 .
   * dpkg-source now has broken argument unparsing for tar.  (Bug#4195.)
 .
   * dpkg-gencontrol writes to debian/tmp/DEBIAN/control by default.
   * dpkg-shlibdeps script added.
 .
   * Back to old sh update-rc.d, and removed manpage, because new Perl
 version and the manpage have different syntax and semantics.
   * update-rc.d prints usage message for missing terminal `.'.  (Bug#4122.)
 .
   * Use rm -rf instead of just rm -r in dpkg-deb --info &c.  (Bug#4200.)
 .
   * Added support for Installed-Size to dpkg-gencontrol, and documented.
   * Source packaging substitution variables and name syntax rationalised.
   * dpkg-source scripts' usage messages improved slightly.
   * dpkg-source works with non-empty second (orig dir) argument.
 .
   * Added rationale for copyright policy to manual.
   * More developers' PGP keys.
   * Control database handling cleanups (usu. Source field blanked).
Files: 
 385f880602b0d85f92849b1f89269ced 526 base required dpkg_1.3.6.dsc
 90752d02399d9049b130af87ab9dca6a 446149 base required dpkg_1.3.6.tar.gz
 ee97960479b05173ca1cd281dde57a6a 300202 base required dpkg_1.3.6_i386.deb
 2e41281d54977dbfe0769e0a8d2983eb 294667 byhand - 
dpkg_1.3.6_i386.nondebbin.tar.gz

-BEGIN PGP SIGNATURE-
Version: 2.6.2i

iQCVAwUBMhnQW8MWjroj9a3bAQGIkAP/XaTn/vzYh1XynmHXRZJaPhu4ZycLpVfx
azI1+R2sLRYkEmw3u+q8ssnOJfilJrPg9hczAkSPJY/SgLAqkvKUrfR+e4FfsXDu
9MGPtlDbBNwDSRvj67GpUGKKOriHxKa6lQAlQu4xQHOaGegVgM9bqAlhKo3IW4TI
rGAfQokUSvM=
=CKOO
-END PGP SIGNATURE-
-BEGIN PGP SIGNED MESSAGE-

Format: 1.5
Date: Tue, 20 Aug 1996 15:42:27 +0100
Source: hello
Binary: hello
Architecture: source i386
Version: 1.3-10
Distribution: experimental
Urgency: low
Maintainer: Ian Jackson <[EMAIL PROTECTED]>
Description: 
 hello  - The classic greeting, and a good example
Changes: 
 hello (1.3-10) experimental; urgency=low
 .
   * Use new shared library dependencies and dpkg-gencontrol scheme.
   * `source' and `diff' removed from .PHONY and now print message.
Files: 
 c823d000ae70b6b224972592e5d29217 587 devel optional hello_1.3-10.dsc
 b92b748ffb810c789d51852f8d367717 87701 devel optional hello_1.3.orig.tar.gz
 d97239a282d056e72abd9bbabf5574e9 3098 devel optional hello_1.3-10.diff.gz
 824fb083da0c54063a9deab7e7b8db26 13756 devel optional hello_1.3-10_i386.deb

-BEGIN PGP SIGNATURE-
Version: 2.6.2i

iQCVAwUBMhnQscMWjroj9a3bAQEn+gQA3ciX2C9vycG75uGfVCl12XkUbUSzufZU
WPJEmKNQnjGPQCzwbDoDCnSmCdVDImwDrkt/K37JkqPARQI8ePSJpoB+76X96PES
qhc3SeOChr5czfCV5T08TMw3X7x7WkW1f1xQw0tQmB9g3EkykQflzQlxF1bcEpnw
NWSZRL1wgQQ=
=kBO9
-END PGP SIGNATURE-

Anyone want to maintain "modconf"?

[llucius]

I hadn't realized this arch independence stuff would take so much time 
when I originally agreed to be the maintainer and I still don't see 
the end of the tunnel, so if anyone wants to let me know.

Thanks,

Leland

__ Y_ a_ m_ b_ o_ | The leanest, meanest, fightinest sweet tater on Earth!
   oo o  oo o  o  | 
o   o   o | [EMAIL PROTECTED]
 o ooo o  | 
-- -- -- -- -- -- | http://www.millcomm.com/~llucius   (maybe one day)

Bug#4218: Problems removing INN

[Rob Leslie]

Package: inn
Version: 1.4unoff4-1

deimos:~:[2]# dpkg --purge inn
(Reading database ... 20824 files and directories currently installed.)
Removing inn ...
Trying to stop INN..
Removing crontab for news..
Removing files in /var/log/news and /var/run/innd..
dpkg - warning: while removing inn, directory `/var/spool/news/.outgoing' not 
empty so not removed.
dpkg - warning: while removing inn, directory `/var/spool/news/over.view' not 
empty so not removed.
dpkg: error processing inn (--purge):
 cannot remove `/var/spool/news': Device or resource busy
** INN news server configuration
chown: /var/log/news/.: No such file or directory
I can't access your /etc/news/inn.conf (No such file or directory) - HELP
dpkg: error while cleaning up:
 subprocess post-installation script returned error exit status 2
Errors were encountered while processing:
 inn


I'm not so worried about the dpkg problems as I am the messages which follow.

Thanks.

-- 
Robert Leslie
[EMAIL PROTECTED]

Re: CC's on this mailing list

[Bruce Perens]

From: Dan Stromberg <[EMAIL PROTECTED]>
> 1) Have you switched up to a 28.8kbps modem yet, or at least a 14.4kbps
> modem?

We may be a bit spoiled here in the U.S.

Some people have to buy their net service from a government-mandated
monopoly, and pay by the packet. 28.8 modems are _illegal_ in some
places because the Post Office (regulator of _all_ communications) has
not approved them. You have to smuggle them in from other countries,
and when you use them, you are bootlegging.

About the funniest part is trying to find a pay phone. Many countries
only have them in post offices. When I visited Australia, there were
blue phones and gold phones, and only the gold ones could make long
distance calls.

Bruce

Re: Shadow vss PAM

[Michael Meskes]

Patrick Weemeeuw writes:
> I have the feeling that an awful lot of work is being duplicated here.

But then almost the complete work has already been done.

> All of the work being done to support shadow password files, will have
> to be done over again to support PAM.  Also, IMHO the PAM framework is
> superior, as it supports shadow password files among others (give or
> take maybe a few options particular to the shadow package actually
> used).

What exactly does it offer that shadow doesn't?

Michael

-- 
Michael Meskes   |_  __  
[EMAIL PROTECTED] |   / ___// / // / / __ \___  __
[EMAIL PROTECTED]  |   \__ \/ /_  / // /_/ /_/ / _ \/ ___/ ___/
[EMAIL PROTECTED]|  ___/ / __/ /__  __/\__, /  __/ /  (__  )
Use Debian Linux!| //_/  /_/  //\___/_/  //

fdutils_4.3-4

[Michael Meskes]

-BEGIN PGP SIGNED MESSAGE-

Date: 21 Aug 96 07:36 UT
Format: 1.6
Distribution: unstable
Urgency: Low
Maintainer: Michael Meskes <[EMAIL PROTECTED]>
Source: fdutils
Version: 4.3-4
Binary:  fdutils
Architecture:  i386 source
Description: 
 fdutils: Floppy utitlities
Changes: 
 fdutils (4.3-4) misc; urgency=LOW
 .
* Corrected fdmount mode to 4755 (Bug#4051)
* Usage of fdmount is still restricted to group floppy
* Applied upstream patche 2108
Files:
 cc6a27042a20211062cce1ae6c8c444c  95316  misc  -  fdutils_4.3-4.tar.gz
 8c46064c0d018bf4524e0caea4e2fdde  15419  misc  -  fdutils_4.3-4.diff.gz
 9fa2e53c62a0f2020651c1da63adbdda  99018  misc  optional  fdutils_4.3-4_i386.deb

-BEGIN PGP SIGNATURE-
Version: 2.6.2i

iQCVAwUBMhq8lSpaNcQEtuj1AQHHRAQA0ETTSdKVY0E9FQo+eRpDp8ZoLkQivEku
UCMN2b6NfML5h4soaWSHtESWY/fKrIWpeGFQ6Y8e4uwj0iuE4Zrr3qahHsLS291G
KtNYgxsr0QtuOTJG0FwHg9RFBgBRDr3uzIa/Z3MqmUHF+OEZRDlJCRIwYuYe9n0o
vTVC4cYSKjg=
=Iddy
-END PGP SIGNATURE-

-- 
Michael Meskes   |_  __  
[EMAIL PROTECTED] |   / ___// / // / / __ \___  __
[EMAIL PROTECTED]  |   \__ \/ /_  / // /_/ /_/ / _ \/ ___/ ___/
[EMAIL PROTECTED]|  ___/ / __/ /__  __/\__, /  __/ /  (__  )
Use Debian Linux!| //_/  /_/  //\___/_/  //

Re: Shadow vss PAM

[Patrick Weemeeuw]

   From: Michael Meskes <[EMAIL PROTECTED]>
   Date: Tue, 20 Aug 1996 18:25:36 +0200 (MET DST)
   [...]
   What exactly does it offer that shadow doesn't?

For general information, see http://www.redhat.com/linux-info/pam/
and for Linux-PAM: http://gluon.physics.ucla.edu/~morgan/pam/

But to answer your question in short: PAM (which stands for pluggable
authentication modules) is an API that encapsulates (hopefully) all
authentication methods.  As a consequence, an authentication client
using PAM does not need to be reengineered any more to be able to use
a new authentication method (e.g kerberos, s/key, id-cards...), but
the new authentication method must be coded once as a PAM module to be
available to all applications.

There are several kinds of modules, that can be transparently chained
together by PAM: e.g. for session logging, for granting/denying access
to a particular service based on the time of the day, tty, host; or to
log every single character the user types for the real paranoid
... you just name it (or implement it and plug it in :-).  Another
example: passwd can be configured via PAM to use some custom local
modules for extra password strength checking .

Currently PAM does support unix password files and shadow and some
other utility modules (and work is going on on s/key and kerberos),
which seems enough functionality to get started.

PAM is also a standard (DCE-RFC 86.0).

Patrick.
--
People who are doing things for fun do things the right way by
themselves -- Linus Torvalds

shadow package

[Michael Meskes]

I've just uploaded the first version of the new (almost final) shadow
packages to my ftp site. Please test them as much as possible. They are
under:

ftp://feivel.informatik.rwth-aachen.de/pub/debian.local/binary-i386/shadow-*

I devided shadow into three packages:
1) shadow-passwd which is thought to replace passwd
2) shadow-login which replaces the standard login
3) shadow-su which diverts the GNU su binary.

Comments welcome.

Michael
-- 
Michael Meskes   |_  __  
[EMAIL PROTECTED] |   / ___// / // / / __ \___  __
[EMAIL PROTECTED]  |   \__ \/ /_  / // /_/ /_/ / _ \/ ___/ ___/
[EMAIL PROTECTED]|  ___/ / __/ /__  __/\__, /  __/ /  (__  )
Use Debian Linux!| //_/  /_/  //\___/_/  //

Bug#4219: xonix can't write high score file

[Thomas Koenig]

Package: xonix
Version: 1.4-3

By default, xonix can't write to its highscore file.

As a remedy, I'd suggest

chgrp games /usr/games/xonix
chmod 2755 /usr/games/xonix
chgrp games /var/lib/games/xonix
chmod 775 /var/lib/games/xonix
-- 
Thomas Koenig, [EMAIL PROTECTED], [EMAIL PROTECTED]
The joy of engineering is to find a straight line on a double
logarithmic diagram.

Re: Shadow vss PAM

[Michael Meskes]

Patrick Weemeeuw writes:
> For general information, see http://www.redhat.com/linux-info/pam/
> and for Linux-PAM: http://gluon.physics.ucla.edu/~morgan/pam/


Got it. Thanks.

> But to answer your question in short: PAM (which stands for pluggable
> authentication modules) is an API that encapsulates (hopefully) all
> authentication methods.  As a consequence, an authentication client
> using PAM does not need to be reengineered any more to be able to use
> a new authentication method (e.g kerberos, s/key, id-cards...), but
> the new authentication method must be coded once as a PAM module to be
> available to all applications.
> ...

It seems it does not contain shadow completely, though.

Since the shadow transition is almost completed I wonder what we shoudl do
now.

Michael
-- 
Michael Meskes   |_  __  
[EMAIL PROTECTED] |   / ___// / // / / __ \___  __
[EMAIL PROTECTED]  |   \__ \/ /_  / // /_/ /_/ / _ \/ ___/ ___/
[EMAIL PROTECTED]|  ___/ / __/ /__  __/\__, /  __/ /  (__  )
Use Debian Linux!| //_/  /_/  //\___/_/  //

Incorrectly locates packages

[Michael Meskes]

I did a quick scan through the archive and found at least two (well that is
four) packages in an incorrect location. The way I understand it all
packages including a motif binary (statically or dynamically linked) belong
into contrib since there's no way for me (as normal user) to recompile them.
Thus gimp and ddd should be moved. 

Also, shouldn't the netscape and compress-package installer be moved to
contrib, too? I know they are free, but to be of any use you have to get the
some other software that is not free. So in fact they depend on it. Well at
least the netscape installer which has no own file to install.

Michael
-- 
Michael Meskes   |_  __  
[EMAIL PROTECTED] |   / ___// / // / / __ \___  __
[EMAIL PROTECTED]  |   \__ \/ /_  / // /_/ /_/ / _ \/ ___/ ___/
[EMAIL PROTECTED]|  ___/ / __/ /__  __/\__, /  __/ /  (__  )
Use Debian Linux!| //_/  /_/  //\___/_/  //

uploaded id-utils-3.2

[Erick Branderhorst]

-BEGIN PGP SIGNED MESSAGE-

Date: 21 Aug 96 11:30 UT
Format: 1.6
Distribution: unstable
Urgency: Low
Maintainer: Erick Branderhorst <[EMAIL PROTECTED]>
Source: id-utils
Version: 3.2-1
Binary:  id-utils
Architecture:  i386 source
Description: 
 id-utils: Fast, high-capacity, identifier database tool.
Changes: 
 Wed Aug 21 12:40:20 1996  Erick Branderhorst  <[EMAIL PROTECTED]>
 .
* mainstream 3.2
 .
Files:
 95ddb7da282697bd3a58f7a84b6889bf  388854  devel  -  id-utils-3.2-1.tar.gz
 8a24964297cbf331a0e745db46bb56f8  2154  devel  -  id-utils-3.2-1.diff.gz
 e984d8b47bafced617cf766f77c20f74  126870  devel  extra  id-utils_3.2-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: 2.6.2i

iQCVAwUBMhrzZeKGUa6t6e7lAQG/XQP9EVDTAlHgCIJriLrfjPu5o1JY83jVQOXt
+/Lz0oFkkznr1vKpEyrtJ8NmUpY63O2pP7i18Gl2eGCY0iRSsgXX4l+xMDmWiSQH
YLZYjk+KXw673mkdwAM3hFJPTjrycMeRcrADQpfTqwgmfWUrdEDZB/wrdesGYKhs
74IkZOchgVM=
=fJDF
-END PGP SIGNATURE-

Re: Shadow vss PAM

[Michael Meskes]

Patrick Weemeeuw writes:
> Thinking things over again, and considering that the shadow support
> for Debian is almost finished (as far as I know, only xdm and a few
> small utilities such as vipw have to be adapted for shadow support), I

The actual situation is that we have to make xdm and adduser shadow aware.
That's about it. Some minor changes to the shadow packages may have to be
done, too. BTW we now have shadow vipw/vigr thanks to the work of Miquel.

> would propose to go for shadow for 1.2.  In the mean time, I will try
> to make a few applications PAM-aware, to wet my feet and to gain some
> insight about how simple or complex things are.  After all, it's not a
> black or white thing, but we can PAMify application by application.

Sounds good to me.

Michael

-- 
Michael Meskes   |_  __  
[EMAIL PROTECTED] |   / ___// / // / / __ \___  __
[EMAIL PROTECTED]  |   \__ \/ /_  / // /_/ /_/ / _ \/ ___/ ___/
[EMAIL PROTECTED]|  ___/ / __/ /__  __/\__, /  __/ /  (__  )
Use Debian Linux!| //_/  /_/  //\___/_/  //

Re: Shadow vss PAM

[Patrick Weemeeuw]

   Date: Tue, 20 Aug 96 08:19 PDT
   From: [EMAIL PROTECTED] (Bruce Perens)
   Reply-To: Bruce Perens <[EMAIL PROTECTED]>

   From: Patrick Weemeeuw <[EMAIL PROTECTED]>
   > The big question is: is PAM ready for integration in the distribution?

   I agree that it sounds like a better way to do the job. I think the
   interested parties should decide together if they are able to deploy
   it reasonably _soon_. I have started work on the installation floppies
   for 1.2, we are about to change the source format and convert a lot of
   packages, we have architecture changes to merge in, etc., so you probably
   have a month but not much more.

   Thanks

   Bruce

Well, I do have some areas of concern, both pro and against
introducing PAM now.

Introducing PAM is certainly not a free lunch: it needs some changes
to rather many components of the distribution [including probably
changes to some unexpected ones such as e.g. init for session
logging--this is still in discussion on the mailing list].  This is
certainly easier to do with a more centralised control as in the
RedHat distribution, than in our distributed development model.  In
this light, a month is on the short side, and it might be easier to
wait and see how RedHat solves the hasles.  On the other hand, we do
not need complete PAM support in 1.2, but might well start with a few
PAMified applications.  However, I think that a commitment of Debian
to PAM in the long term, is important.

My second concern is that introducing the shadow support now might
make a later introduction of PAM more difficult.  Technically,
conversion from a unix password authentication scheme to PAM is
simpler than from unix + shadow to PAM (this might or might not be a
big issue, depending maybe on how compatible the PAM shadow module is
with the Debian shadow package).

Thinking things over again, and considering that the shadow support
for Debian is almost finished (as far as I know, only xdm and a few
small utilities such as vipw have to be adapted for shadow support), I
would propose to go for shadow for 1.2.  In the mean time, I will try
to make a few applications PAM-aware, to wet my feet and to gain some
insight about how simple or complex things are.  After all, it's not a
black or white thing, but we can PAMify application by application.

Patrick

Bug#4137: libpaper contains compressed manpage, or policy should change

[Lars Wirzenius]

Yves Arrouye:
> I remember that a long time ago it was said that it was okay to gzip
> manual pages because the manual reader did handle them nicely? 

Our man seems to handle them OK. Since there can be tens of megabytes of
manual pages (I have 18 MB), I think compressing them would be a good idea.

-- 
Please read  before mailing me.
Please don't Cc: me when replying to my message on a mailing list.




pgpffqo8cOxrz.pgp
Description: PGP signature

uploading gsfonts-4.01-2

[joost witteveen]

-BEGIN PGP SIGNED MESSAGE-

Date: 20 Aug 96 17:28 UT
Format: 1.6
Distribution: unstable
Urgency: Low
Maintainer: joost witteveen <[EMAIL PROTECTED]>
Source: gsfonts
Version: 4.01-2
Binary:  gsfonts
Architecture:  all source
Description: 
 gsfonts: Fonts for the ghostscript interpreter
Changes:
 - Really GNU-copyleft this time. (gs-4.01-1 still had a few fonts that
   were not copyable. Sorry).
 - This now contains the Fontmap file. It is currently also in
   the gs package.
Files:
 ac3d817e4778116d1c4d830bd3adc91b  2287817  unstable  -  gsfonts_4.01-2.tar.gz
 1234189b67e67b3d6faf03db541abb5a  1418  unstable  -  gsfonts_4.01-2.diff.gz
 50b1e3bcb9df34cb6917855ef51bc98e  2297376  unstable  Optional  
gsfonts_4.01-2_all.deb

-BEGIN PGP SIGNATURE-
Version: 2.6.2i

iQCVAwUBMhn2F5NVaG8BiEBRAQEj7QP+O1WD+NXHytVRiMa9H3tsuNC1eVVFwCPg
J9knqP21uSvHnDtX5UIaBf0DDHzfgV9l0jS7vxVEXIphxGpxqSKdaE8tv8XqStCR
Jdqnh/SBAX2WzJQGY4dF8cWsJlbMuoTAI+HwKAXwC48Hq3nGIcI2U/p6coIdShm0
9XMYpS1I9eI=
=WwvJ
-END PGP SIGNATURE-

Bug#4159: xcoral dies

[Christophe Le Bars]

**On 19 Aug, In article "Bug#4159: xcoral dies ",
**  RTMUE ([EMAIL PROTECTED]) writes:
RTMUE>Christophe Le Bars writes:
RTMUE> >Yes, I have never seen this error message with fvwm...
RTMUE> >I will reassign this bug...
RTMUE>Please don't do this.

Sorry, too late... But, I'll repair this...

RTMUE>The problem is with xcoral, not with 9wm.  To verify this, I
RTMUE>just tried running xcoral without any window manager at all.
RTMUE>It dies with the same problem when I try the New menu option 
RTMUE>off the file menu.

Yes, this problem is not with 9wm...
Indeed, I have also reproduce the problem without any window manager. 
But, there is no problem with fvwm and twm...

RTMUE>If this is not resolvable, perhaps xcoral should have a dependency
RTMUE>on fvwm?

No, because xcoral + twm (xbase) work together.
I think, we might forward this bug to the upstream maintainer...

-- 
Christophe Le Bars - Email : [EMAIL PROTECTED], [EMAIL PROTECTED]
01001DEBIAN0LINUX0110ESPERANTO00101011ML1010010GNU0111
10111010010100011 Utilisez Linux Debian! 10010101001110010