dpkg manuals in other formats and on web site
Since noone has answered my question I've done what seemed the right thing: The next dpkg upload will be accompanied by the manuals in gzipped PostScript (formatted for A4) and HTML in gzipped tarfiles, as separate files in the upload. Ian.
changes to dpkg manuals in 2.1.0.0 (dpkg 1.3.14) since 2.0.0.0
debian-manuals (2.1.0.0) unstable; * Upstream changelog must be installed too (was just recommended). * Modification to use dpkg-shlibdeps added to conversion instructions. * Packages which are buggy and orphaned but which are preserved for compatibility go in contrib. * Programmers' manual source package section refers to conversion instructions in policy manual. * Make it clear that recommending a non-free or contrib package puts a package in contrib. -- Ian Jackson [EMAIL PROTECTED] Sun, 1 Sep 1996 17:47:18 +0100 debian-manuals (2.0.1.0) unstable; * varargs.h and libtermcap are obsolete - use stdarg.h and ncurses. * Shared library link/library ordering corrected (aargh). * When to byte-compile Elisp files. * Missing final newlines not represented by dpkg-source. * Must post upload announcements to debian-changes. * Moved some sections into new `configuring and building' chapter. * Typo fixes. -- Ian Jackson [EMAIL PROTECTED] Sat, 31 Aug 1996 20:07:22 +0100
debiandoc-sgml 1.0.5: bugfixes (req'd to compile dpkg 1.3.14)
-BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Sun, 1 Sep 1996 23:59:20 +0100 Source: debiandoc-sgml Binary: debiandoc-sgml Architecture: source all Version: 1.0.5 Distribution: unstable Urgency: low (HIGH for building dpkg) Maintainer: Ian Jackson [EMAIL PROTECTED] Description: debiandoc-sgml - Documentation formatting for Debian manuals Changes: debiandoc-sgml (1.0.5) unstable; urgency=low (HIGH for building dpkg) . * debiandoc2ps -O (output to stdout) works. * Lout converter uses `paperconf' (thanks to Yves Arrouye). . * Manpages installed compressed. * dpkg-gencontrol invocation moved to near end of debian/rules. * Some typos in markup manual corrected. * Spurious `t' file removed from source package. * Updated to Standards-Version 2.1.0.0. Files: 63492024bd04abe5bd0a12ce6a07a1e9 559 text optional debiandoc-sgml_1.0.5.dsc 6127aeedbb950d2fdaf6ffe59c69bd6e 34047 text optional debiandoc-sgml_1.0.5.tar.gz bf6a689902005cbada5f0f37a2f367d9 25002 text optional debiandoc-sgml_1.0.5_all.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMioVjsMWjroj9a3bAQE1rwQA5/ZtzBrp6DnuL48Wgqe8HXro1uunTc8O o2gO0JeIUFX3pNbD6LkS3wVsOC9swfo6nON6liyv+I977lQjKYAwejLKCUegm+hm iIAj//i2T7gNmsJp1yEs8QmHQ4Ei0bp+UWGmcvRIhlg5VVxVQTqKKt5m+mRvHfBF XnKqu/m8EbA= =HxUL -END PGP SIGNATURE-
hello 1.3-12: minor packaging changes
-BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Sun, 1 Sep 1996 16:02:23 +0100 Source: hello Binary: hello Architecture: source i386 Version: 1.3-12 Distribution: unstable Urgency: low Maintainer: Ian Jackson [EMAIL PROTECTED] Description: hello - The classic greeting, and a good example Changes: hello (1.3-12) unstable; urgency=low . * Added Debian and upstream changelogs to binary package. * Updated to Standards-Version 2.1.0.0. Files: 47595e5623b90d936805f43b404d7e41 596 devel optional hello_1.3-12.dsc feaaf374a97be998622918c2b7b78b01 3359 devel optional hello_1.3-12.diff.gz 47a4a5ff14524256b452911b7fefc71c 17490 devel optional hello_1.3-12_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMioZFMMWjroj9a3bAQEGpQP/ZcAFER+Wde08NnzEgePxHU9nL0++hvZv EXaJAwjmRA9q4LgVVOyGzEuP9T+AF4Bs8M/Zcm7zUAz+xDMXwdmGJKi8ehqI/cYB zwdzcG8MC+G3jS/UYxUk6u2in87WevnPQxhI6S//LF7juzVLf/lKIOP2DFf2uv9+ 8RZKQMbl3xk= =waHg -END PGP SIGNATURE-
It's time for dpkg-dev
Ian, Would you consider splitting dpkg into runtime and developers packages? It's getting big, and the space on the base system is limited. Thanks Bruce
dpkg 1.3.14: source packaging minor changes; manual updates
-BEGIN PGP SIGNED MESSAGE-
Format: 1.5
Date: Sun, 1 Sep 1996 20:43:40 +0100
Source: dpkg
Binary: dpkg
Architecture: source i386
Version: 1.3.14
Distribution: unstable
Urgency: low
Maintainer: Ian Jackson [EMAIL PROTECTED]
Description:
dpkg - Package maintenance system for Debian Linux
Changes:
dpkg (1.3.14) unstable; urgency=low
.
* dpkg-buildpackage new -tc (clean source tree) option.
.
* Formatted documentation removed by `make clean' and so not in source.
* Manuals and own Standards-Version: updated to 2.1.0.0.
* Distribute {policy,programmer}.{html.tar,ps}.gz with each upload.
Files:
61bf1106e51ff3f61a946b2981ffed24 532 base required dpkg_1.3.14.dsc
f7d587f09d8de2d0b63730ea38b2e379 475066 base required dpkg_1.3.14.tar.gz
83059911314f210fe0e6a09b66860d09 353042 base required dpkg_1.3.14_i386.deb
e962fec5d3666c865370d52028cab843 348367 byhand -
dpkg_1.3.14_i386.nondebbin.tar.gz
ae3a653c2c548edeb8461c3dc8da78a4 66341 byhand - policy.ps.gz
5fb35198a41f41f2de5a629e964689b3 23610 byhand - policy.html.tar.gz
28a6bca1607677838ee17a253c2551cb 121444 byhand - programmer.ps.gz
79023db8ae75add7444a28a57cf62f73 41254 byhand - programmer.html.tar.gz
-BEGIN PGP SIGNATURE-
Version: 2.6.2i
iQCVAwUBMioX48MWjroj9a3bAQHgRwP6AjBhK9CSYTQysE5zX0kBxkr9syDpy2BF
rpSNkkCjRU2Vj1W4+vOCOrny4JWJJJ8ZrVcHuBTYYy8fRPGUiVcH1HWwZ5tvWG7v
KWQducfpR6dtqJT0Bc9fKK+dhwb4vR143TmQ0ytdIu3LJYxRrhUc5S6LsGxAqBmj
SDCTXBs0a9c=
=Zaih
-END PGP SIGNATURE-
Re: It's time for dpkg-dev
Bruce Perens writes (It's time for dpkg-dev): Would you consider splitting dpkg into runtime and developers packages? It's getting big, and the space on the base system is limited. I've done a quick check of which files would go in which package, and the results are (see below): dpkg: 476K dpkg-dev: 378K I'm inclined to make the change. Ian. dpkg: /etc/dpkg/shlibs.default /usr/doc/copyright/dpkg /usr/doc/dpkg/copyright /usr/doc/dpkg/WISHLIST /usr/doc/dpkg/changelog.dpkg.gz /usr/bin/dpkg /usr/bin/dpkg-split /usr/bin/md5sum /usr/bin/dpkg-name /usr/bin/dselect /usr/bin/dpkg-deb /usr/sbin/update-rc.d /usr/sbin/start-stop-daemon /usr/sbin/update-alternatives /usr/sbin/install-info /usr/sbin/dpkg-divert /usr/sbin/cleanup-info /usr/man/man1/md5sum.1.gz /usr/man/man1/dpkg-deb.1.gz /usr/man/man1/dpkg-name.1.gz /usr/man/man8/start-stop-daemon.8.gz /usr/man/man8/update-alternatives.8.gz /usr/man/man8/install-info.8.gz /usr/man/man8/dpkg.8.gz /usr/man/man8/update-rc.d.8.gz /usr/lib/dpkg/methods/disk/names /usr/lib/dpkg/methods/disk/setup /usr/lib/dpkg/methods/disk/update /usr/lib/dpkg/methods/disk/install /usr/lib/dpkg/methods/disk/desc.harddisk /usr/lib/dpkg/methods/disk/desc.mounted /usr/lib/dpkg/methods/disk/desc.cdrom /usr/lib/dpkg/methods/disk/desc.nfs /usr/lib/dpkg/methods/floppy/names /usr/lib/dpkg/methods/floppy/setup /usr/lib/dpkg/methods/floppy/update /usr/lib/dpkg/methods/floppy/install /usr/lib/dpkg/methods/floppy/desc.floppy /usr/lib/dpkg/mksplit dpkg-dev: /usr/doc/dpkg/programmer.html/index.html /usr/doc/dpkg/programmer.html/ch-scope.html /usr/doc/dpkg/programmer.html/ch-binarypkg.html /usr/doc/dpkg/programmer.html/ch-sourcepkg.html /usr/doc/dpkg/programmer.html/ch-controlfields.html /usr/doc/dpkg/programmer.html/ch-versions.html /usr/doc/dpkg/programmer.html/ch-maintainerscripts.html /usr/doc/dpkg/programmer.html/ch-descriptions.html /usr/doc/dpkg/programmer.html/ch-relationships.html /usr/doc/dpkg/programmer.html/ch-conffiles.html /usr/doc/dpkg/programmer.html/ch-alternatives.html /usr/doc/dpkg/programmer.html/ch-diversions.html /usr/doc/dpkg/programmer.html/ch-sharedlibs.html /usr/doc/dpkg/programmer.html/ch-sysvinit.html /usr/doc/dpkg/programmer.html/ch-methif.html /usr/doc/dpkg/programmer.html/footnotes.html /usr/doc/dpkg/policy.html/index.html /usr/doc/dpkg/policy.html/ch-scope.html /usr/doc/dpkg/policy.html/ch-pkgcopyright.html /usr/doc/dpkg/policy.html/ch-binarypkg.html /usr/doc/dpkg/policy.html/ch4.html /usr/doc/dpkg/policy.html/ch-sourcepkg.html /usr/doc/dpkg/policy.html/ch-developer.html /usr/doc/dpkg/policy.html/ch-conversion.html /usr/doc/dpkg/policy.html/footnotes.html /usr/doc/dpkg/developer-keys.pgp /usr/doc/dpkg/changelog.manuals.gz /usr/bin/dpkg-source /usr/bin/dpkg-genchanges /usr/bin/dpkg-gencontrol /usr/bin/dpkg-shlibdeps /usr/bin/dpkg-buildpackage /usr/bin/dpkg-parsechangelog /usr/bin/dpkg-distaddfile /usr/bin/822-date /usr/sbin/dpkg-scanpackages /usr/man/man1/dpkg-source.1.gz /usr/man/man1/822-date.1.gz /usr/man/man1/dpkg-buildpackage.1.gz /usr/man/man1/dpkg-gencontrol.1.gz /usr/man/man1/dpkg-genchanges.1.gz /usr/man/man1/dpkg-distaddfile.1.gz /usr/man/man1/dpkg-parsechangelog.1.gz /usr/man/man1/dpkg-shlibdeps.1.gz /usr/man/man5/deb-control.5.gz /usr/man/man5/deb.5.gz /usr/man/man5/deb-old.5.gz /usr/man/man8/dpkg-scanpackages.8.gz /usr/lib/dpkg/parsechangelog/debian /usr/lib/dpkg/controllib.pl /usr/lib/emacs/site-lisp/debian-changelog-mode.el
Re: Bug#4365: no section and priority in debian/tmp/DEBIAN/control
Andreas Jellinghaus writes (Bug#4365: no section and priority in debian/tmp/DEBIAN/control): Package: dpkg Version: 1.3.12 dpkg-gencontrol creates no priority and section entries in debian/tmp/DEBIAN/control, but theese fields are in debian/files. is this ok or is this a bug ? This is not a bug but a failure to read the documentation - see below. I'm closing the report. Ian. From the Debian policy manual: 3.1.5 Including Priority and Section in the .deb control file If a user installs a package which is not part of the standard distribution, or without downloading and updating from a new Packages file, the information about the priority and section of a package will be absent, and the dselect package listing will have the package listed under `unclassified'. In order to improve this it is permissible to use the -is, -isp or -ip option to dpkg-gencontrol, so that the Section and/or Priority is copied into the actual control information in the .deb file. However, if you do this you should make sure you keep the information up to date so that users are not shown conflicting information. From dpkg-gencontrol's usage message: ... -isinclude section field -ipinclude priority field -isp|-ips include both section and priority ... From dpkg-gencontrol(1): DPKG-GENCONTROL OPTIONS ... -is, -ip, -isp Include the Section and Priority fields for this package from the main source control file in the binary package control file being generated. Usu- ally this information is not included here, but only in the .changes file. -isp includes both fields, -is only the Section and -ip only the Pri- ority.
Re: Manuals other than as HTML in the dpkg*.deb file
On Sat, 31 Aug 1996, Ian Jackson wrote: I've asked this question before, but noone seemed to want to answer me, so I'm asking again: It would be good for the dpkg manuals to be on the Debian web pages. How do I organise this ? I can (for example) ship a .tar.gz of the HTML files with each dpkg upload. I'd like to distribute PostScript versions too, since there seems to be demand. Should I just upload the .ps.gz files with dpkg uploads ? The web pages are in a bit of flux right now; see recent mail on debian-private. I've been keeping the latest docs in debian/doc/package-developer on the ftp site at least. I just dashed off a quick script to do that. Guy
Re: Need to copy perl-tk into other ftp dirs on ftp.debian.org
On 30 Aug 1996, Rob Browning wrote: I just had someone with a problem with perl-tk and Debian 1.1.5. Apparently we have perl 5.003 and perl-tk b11.02-2 together in some of the directories. perl-tk b11.02-2 is not compatible with perl 5.003, so we need to move a copy of perl-tk b11.02-3 into these dirs. Who do I ask about making this happen? Me; it's done; Debian 1.1.8 has it. Guy
Bug#4354: movemail doesn't work
Mark W. Eichin writes (Re: Bug#4354: movemail doesn't work): [Ian:] Why does movemail need to be setuid root ?! Well, the package as I inherited had the following in debian.rules: ... # movemail is installed setuid so that POP can work. (This is # safe.) ... I suspect this has to do with using movemail locally on a machine which is also a pop server, but I haven't verified that. (The emacs build blessmail process will only make it setgid mail.) Anyone else remember? This sounds doubtful to me .. ... Still haven't heard from the original reporter what, if anything, explains why his movemail wasn't installed properly... He wasn't the guy on linux-security who unsetuidded everything and said none of his users had complained ... ? :-) Ian.
Bug#4356: menu-bar-mode flag argument is inconsistent with universe
Mark W. Eichin writes (Re: Bug#4356: menu-bar-mode flag argument is inconsistent with universe): That's because (interactive p) converts to a number. Not sure why that's relevant, since menu-bar-mode uses (interactive P): p -- Prefix arg converted to number. Does not do I/O. P -- Prefix arg in raw form. Does not do I/O. which, as I suggested earlier, passes nil for no argument. Forgive my ignorance, but could it not use `p' rather than `P' ? Ian.
Bug#4367: corrupted kernel message re NFS mount
Package: mount, kernel Version: 2.5j-1.1, 2.0.0 (upstream) I did a df while I had NFS partitions mounted which were inaccessible due to network lossage: Sep 2 01:06:15 chiark kernel: NFS server nfs-uxsuale/%/%N.cat not responding, timed out. Sep 2 01:06:15 chiark kernel: nfs_statfs: statfs error = 5 The server was called nfs-uxsup.csx.cam.ac.uk. This error message is bizarre and corrupted. Ian.
Bug#4368: [SECURITY]
Followup indicates that this will be fixed in NetKit-B 0.08, so we
should update to that ASAP.
--- start of forwarded message (RFC 934 encapsulation) ---
Return-Path: [EMAIL PROTECTED]
Received: from brimstone.netspace.org ([128.148.157.143]) by
nessie.crosslink.net (8.7.5/8.7.3) with ESMTP id RAA13920 for [EMAIL
PROTECTED]; Wed, 21 Aug 1996 17:58:36 -0400
Received: from netspace.org ([128.148.157.6]) by brimstone.netspace.org with
ESMTP id 24582-5637; Wed, 21 Aug 1996 17:56:56 -0500
Received: from netspace.org (netspace [128.148.157.6]) by netspace.org
(8.7/8.6.12) with SMTP id RAA21187; Wed, 21 Aug 1996 17:57:22 -0400
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8b) with
spool id 284875 for [EMAIL PROTECTED]; Wed, 21 Aug 1996 17:55:32
-0400
Received: from netspace.org (netspace [128.148.157.6]) by netspace.org
(8.7/8.6.12) with SMTP id RAA19877 for [EMAIL PROTECTED]; Wed,
21 Aug 1996 17:42:38 -0400
Approved-By: [EMAIL PROTECTED]
Received: from phoenix.iss.net (phoenix.iss.net [204.241.60.5]) by netspace.org
(8.7/8.6.12) with SMTP id QAA14809 for [EMAIL PROTECTED]; Wed,
21 Aug 1996 16:45:46 -0400
Received: (from [EMAIL PROTECTED]) by phoenix.iss.net (8.6.13/8.6.12) id
QAA01683; Wed, 21 Aug 1996 16:39:01 -0400
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved-By: David J. Meltzer [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
Reply-To: Bugtraq List [EMAIL PROTECTED]
X-To: [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
In-Reply-To: [EMAIL PROTECTED]
From: David J. Meltzer [EMAIL PROTECTED]
Sender: Bugtraq List [EMAIL PROTECTED]
To: Multiple recipients of list BUGTRAQ [EMAIL PROTECTED]
Subject: rwhod buffer overflow
Date: Wed, 21 Aug 1996 16:38:57 -0400
There is a remote buffer overflow in the path variable in rwhod.c in the
line: (void) sprintf(path, whod.%s, wd.wd_hostname);
Although wd_hostname is defined to be only 32 characters, it is read as
part of the wd structure from a remote host through a UDP packet and can
be as large as the remainder of the structure starting at that point.
Through examining the source this appears to be a problem in current
OpenBSD, NetBSD, FreeBSD, and Linux distributions. Through penetration
testing I have also found this problem present on AIX; I have not examined
other platforms running rwhod and so do not know about their potential
vulnerability.
I have succesfully exploited this remotely to produce undesirable effects
(segfaults and overwriting argv[0] on different OSes), I have not spent
sufficient time on this to determine exactly how/if to compromise root
directly with this overflow, but it is definitely something that should be
corrected.
I would suggest prior to the sprintf line you add something to the effect:
if(strlen(wd.wd_hostname) = sizeof(wd.wd_hostname)) {
syslog(LOG_WARNING, possible hostname overflow attack apparently from %x,
from.sin_addr);
continue;
}
Program: /usr/sbin/rwhod
Affected Operating Systems: OpenBSD, NetBSD, FreeBSD, Linux, AIX, others.
rwhod must be running on the system
Requirements: Ability to send UDP packet to target host
Security Compromise: Possible denial of service, Possible annoyance,
Possibly root compromise?
Author: Dave M. ([EMAIL PROTECTED])
Synopsis: rwhod reads a structure from a udp packet and
does not check the hostname member of the
structure for being the expected size.
- +-
David J. Meltzer | Email: [EMAIL PROTECTED]
Systems Engineer | Web: www.iss.net
Internet Security Systems, Inc. | Fax: (404)252-2427
- +-
David J. Meltzer | Email: [EMAIL PROTECTED]
Systems Engineer | Web: www.iss.net
Internet Security Systems, Inc. | Fax: (404)252-2427
--- end ---
--
Shields, CrossLink.
Re: Manuals other than as HTML in the dpkg*.deb file
I think we have an offer for the main web site from someone who I think has a T3, and we have a few offers for regional web sites. I'll firm them up this week. Bruce
Bug#4354: movemail doesn't work
Michael Shields [EMAIL PROTECTED] writes: Package: emacs Version: 19.31-2 movemail complains about not being able to write a temp file in /var/spool/mail. One fix might be to make it setgid mail, iff the code is written to be sufficiently paranoid. As shipped, it *was* installed setuid root + setgid mail... could you check your installation and verify, and perhaps be more specific about movemail's complaint? Ack -- I'm embarassed. VM found another movemail in my path, a broken one, and used that instead. But this seem to have exposed a real bug: why *is* the real movemail suid root? -- Shields, CrossLink.
Re: Bug#4329: Emacs has hardcoded path for jka-compr, breaks at upgrade
This is really off-topic, but it's one of my pet peeves. Sorry. Rob Browning: 5) Debian should use either the big or little endian format and always use four digits for the year. That way we won't have trouble when the millenium hits, and you can always tell by looking if it's big or little endian. I've had some experience with how people from all over the world write dates. I used to fix dates by hand for the LSM database (it's automatic now, and people who send them must check them). The only official LSM date format is ddMMMyy, where dd is two digits for day of month, MMM is first the letters of the English name of the month, and yy is the last two digits of the year (which lets us reach the 2090's). All other date formats seem to invite a large number of errors. For reasons unknown, people _will_ write dates in the form -dd-mm. Don't ask me why, but they do. Up to several percent of them. Having the month spelled out as text is the only way to make dates unambiguous. (I don't care if date formats are stupid or not, just whether they work.) -- Please read http://www.iki.fi/liw/mail-to-lasu.html before mailing me. Please don't Cc: me when replying to my message on a mailing list. pgpqaBoOISyBi.pgp Description: PGP signature
Bug#4371: clean target does not rm debian/substvars
Package: hello Version: 1.3-12 Section 3.2.4 of the programmer's manual says: The file (debian/substvars) may be a static part of the source archive, or generated and modified dynamically by debian/rules targets. In the latter case it must be removed by the clean target. hello's clean target doesn't remove it. Guy
Re: Bug#4329: Emacs has hardcoded path for jka-compr, breaks at upgrade
Rob Browning: Why in the world wouldn't you want to require 4 digits for the date? Because of all the usual bad reasons, and one good one: it doesn't matter. The LSM dates are always past tense, and making the new requirement is trivial, all of thirty seconds of coding. Converting all old dates (once they've been checked) is also trivial. Ambiguity is the problem with LSM, not Y2K. For reasons unknown, people _will_ write dates in the form -dd-mm. Don't ask me why, but they do. Up to several percent of them. It's because they will sort properly with a standard alphabetical sort, like that used by ls, or perl's default sort, etc. yyy-mm-dd will sort properly, but -dd-mm will not. As long as you disallow middle endian, the four digit year makes little or big endian unambiguous. Only if you assume people don't make errors. If I tell you that I wrote something 1996-10-09, you must either assume I _really_ meant 1996-09-10, or that I am a liar. With 10SEP96 (or 10SEP1996) there is no problem. That's the problem, isn't it? People do make mistakes, and the date format might as well guard against it, if the checking can't be done at the input stage. -- Please read http://www.iki.fi/liw/mail-to-lasu.html before mailing me. Please don't Cc: me when replying to my message on a mailing list. pgptZW6lw5cuY.pgp Description: PGP signature
Re: /usr/local (again)
Hello Ian, you wrote: In order that the system administrator may know where to place additional files a package should create an empty directory in the appropriate place in /usr/local by supplying it in the filesystem archive for unpacking by dpkg. The /usr/local directory itself and all the subdirectories created by the package should have permissions 2775 (group-writeable and set-group-id) and be owned by root.staff. I diskussed that with Richard in private email earlier and what i proposed was: 1. Provide a link /usr/lib/package/local pointing to /etc/local/package. (One might as well use /etc/alternatives ...) 2. At installation time ask the installer where the local directory is located and make create a link /etc/local/package to the location given by the installing person. Thus there is a well-defined path at compile time which is configurable at run-time. The reaseon for the redirection through /etc is the support of read-only media (CD-ROM or NFS-shares). Comments? Dominik Kubla =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Visit the FAN SITE of the WORLD LEAGUE OF AMERICAN FOOTBALL: A HREF=http://www.uni-mainz.de/~kubla/WLAF/Welcome.htmlHTTP/A or A HREF=file:/afs/zdv.uni-mainz.de/homes/UFO/kubla/public_html/WLAF/Welcome.ht mlAFS file/A access.
Bug#4375: Hello forgets to increment loop counter when reading mailbox
Package: hello
Version: 1.3-12
1) Line 196-201 contain the following loop:
d = dirs;
do
{
sprintf (mailname, %s/%s, *d, user);
mailfd = open (mailname, O_RDONLY);
} while (mailfd == -1 (errno == ENOENT || errno == ENOTDIR));
The loop variable, d, is not incremented. Hello will not exit if
a) $MAIL is not set, and b) /usr/spool/mail is not the user's mailbox.
2) `hello' looks under /usr/spool rather than /var/spool.
(Not serious, but IMHO, should be corrected.)
3) `hello' lacks a manpage.
Peter Benie
Re: What parts of TeX are architecture independent?
On Mon, 19 Aug 1996, llucius wrote: I finally bit the bullet and started work on the TeX packages to make them build on multiple architectures. Sorry for the long delay. Well, since I don't much at all about TeX, I'm not sure what's platform specific. I'm especially concerned about endianness. As far as I can gather, the only files that aren't independent are tfm files. Is that correct? No. *Everything* is platform independent except the executable binaries (of course) and .base and .fmt files, but the latter are generated at installation time anyway. Much care had been taken by D.E.Knuth to make .dvi .tfm and .pk files platform and especially endianness independent. All other files of the TeX system are simple ASCII textfiles. Nils -- Coming again: Best quotes of the net. Today: | Nils Rennebarth Kristian Köhntopp [EMAIL PROTECTED]| Schillerstr. 61 I'd also be interested in the comparison [of Linux] | 37083 Göttingen with a cisco router. I assume a factor of about ten.| ++49-551-71626 What? faster or slower? | http://www.nus. Cheaper! | de/~nils
Bug#4376: vm doesn't use /etc/emacs/site-start.d
Package: vm Version: 5.95beta-2 vm's postinst follows /usr/lib/emacs/site-lisp/site-start.el and modifies the file it ultimately points to in order to arrange for its initialization code to be run at startup. It should, instead, place the vm-init.el file in the directory /etc/emacs/site-start.d. When this is done it should depend on emacs being = 19.34-2 (unless someone knows earlier versions of the emacs package which have this directory.) Do not forget that upgrading to a later version of vm shouldn't cause it to install itself twice. (I'll find some time to sort all my packages out soon, honest.. l-) -- Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#4377: modules on boot-disk seem to be broken
Package: bootdisk Version: boot1440.bin (1996_7_14) The following happened twice on two different systems (a 486 and a P6) while attempting to make a fresh installation of Debian 1.1.7: When installing the kernel, I selected the module for nfs filesystem support. I was then asked to insert again the boot-disk, got a couple of error messages which went by too quickly to read (something 'unresolved'), and when attempting to include the module for nfs, it said: 'module symbols (2.0.6) do not match your linux (2.0.6)'. It seems to me that the modules on the boot-disk are broken. (I was able to work around this problem by installing a kernel with full network support, which I needed for proceeding with the installation, by hand.) Further suggestion: It would be helpful for everybody to have a log-file of the installation process being generated automatically. -- Univ.-Doz. Dr. Anton Rebhan Inst. f. Theoret. Physik, Techn. Univ. Wien Wiedner Hauptstr. 8-10/136 A-1040 Vienna, Austria Tel: +43-1-58801-5695 Fax: +43-1-5867760
Bug#4378: incomplete Packages files and incomplete distributions
Package: ftp.debian.org Version: 1.1.7 Repeatedly, I faced problems with a new installation and with upgrades coming from an out-of-date Packages file and/or of an incomplete set of packages. I have ignored missing packages when they were just recommended but not available. Currently, however, there is the package gs_4.01 in /non-free, which *depends* on gsfonts (=4.01), libpaper (=1.0-1), both of which are not availabe, however, in the stable tree. An older version of gs, which is in /buzz and which would do with the existing gsfonts package, cannot be installed, because dselect picks only the newest version. Perhaps it would be possible to automatically generate up-to-date Packages files and to automatically check whether all the packages others depend on are really there. Univ.-Doz. Dr. Anton Rebhan Inst. f. Theoret. Physik, Techn. Univ. Wien Wiedner Hauptstr. 8-10/136 A-1040 Vienna, Austria Tel: +43-1-58801-5695 Fax: +43-1-5867760
Bug#4379: dselect insists on wrong installation order
Package: dselect Version: 1.2.12 (a.out) and 1.2.11elf In upgrading from 0.93R6 to 1.1 I had the following problem running dselect: The installation of perl failed because libgdbm was not installed, although the latter was selected. Instead of proceeding with the installation, which would obviously have solved the problem in a second run, it terminated. Only after stepping out and installing libgdbm by dpkg -iB by hand could I resume the installation by dselect. Fortunately, there was no similar problem with the other packages. The very same problem but with different packages (sorry, I forgot which), happened recently by making a fresh installation on a new computer. This time, the version of dselect was 1.2.11elf. Again, I solved the problem by dpkg -iB on the missing package which was selected but not processed because the installation stopped prematurely. (Rerunning it stopped always at the same point) I guess that a quick fix would be to let the installation proceed and to ask for a further run at the end. -- Univ.-Doz. Dr. Anton Rebhan Inst. f. Theoret. Physik, Techn. Univ. Wien Wiedner Hauptstr. 8-10/136 A-1040 Vienna, Austria Tel: +43-1-58801-5695 Fax: +43-1-5867760
Re: dpkg manuals in other formats and on web site
On Mon, 2 Sep 1996, Ian Jackson wrote: Since noone has answered my question I've done what seemed the right thing: The next dpkg upload will be accompanied by the manuals in gzipped PostScript (formatted for A4) and HTML in gzipped tarfiles, as separate files in the upload. I didn't see anything wrong with this the first time you posted it. (Apparently no one else did either) I have assumed that the seperate packaging was for those who only want the documents and don't wish to unpack dpkg to get it. It should also allow linking it with the web site, without the rest of dpkg. Thank you, Ian, for your wonderful effort in producing this fine manual. I'm sure we will be reading it any time we are uncertain (or challenged) about proper package building. I know that I will. Thanks again, Dwarf -- aka Dale Scheetz Phone: 1 (904) 877-0257 Flexible Software Fax: NONE Black Creek Critters e-mail: [EMAIL PROTECTED] If you don't see what you want, just ask --
Bug#4380: crippled anon ftp
Package: wu-ftpd Version: 2.4-23 Package: netstd Version: 2.06-1 The man pages ftpd(8) and wu-ftpd(8) are both present on my system [Debian 1.1 kernel 2.0.0. #8] and they slightly differ from each other. However, both say, that for anonymous ftp you need to have ls(1) in ~ftp/bin with mode 111. That's not enough. I had to download fileutils source and recompile ls to be statically linked [using LDFLAGS=-static ./configure]. Without this step the anon ftp does not return directory listing, neither it reports any error message. It's a trap for beginners (like me). Suggested steps: 1. remove one of the man pages above and make it a link to the other, and 2. include a note about the neccessity of further investigation regarding ls linking, or 2. include the statically linked ls in wu-ftpd package. Anyway, what's the doubled *ftpd good for? The in.ftpd [or ftpd(8)] seems to me the same as wu-ftpd(8). And the same maintainer... -- Robert Komanec mailto:[EMAIL PROTECTED] UMEL FEI VUTcheck out if http://www.umel.fee.vutbr.cz is alive
Re: devel directory reorg?
run-time programs and files needed to run applications devel programs and files needed to develop applications That's a very reasonable suggestion. It makes a clear division in devel, and moves about half of the packages out. Guy
Bug#4378: incomplete Packages files and incomplete distributions
On Mon, 2 Sep 1996, Anton Rebhan wrote: Repeatedly, I faced problems with a new installation and with upgrades coming from an out-of-date Packages file and/or of an incomplete set of packages. I have ignored missing packages when they were just recommended but not available. Currently, however, there is the package gs_4.01 in /non-free, which *depends* on gsfonts (=4.01), libpaper (=1.0-1), both of which are not availabe, however, in the stable tree. I'm sure you know that both of those packages are available in the unstable tree. I don't know of a longterm solution short of duplicating the contrib and non-free trees into stable and unstable versions. Our ftp hierarchy is already too complicated. An older version of gs, which is in /buzz and which would do with the existing gsfonts package, cannot be installed, because dselect picks only the newest version. It seems overloading the gs name is causing problems. Joost, the maintainer of both gs's, offered several times to rename them to gnu-gs and alladin-gs and let them conflict. Perhaps this needs to be done. Ian? Perhaps it would be possible to automatically generate up-to-date Packages files That is already done, once a day. and to automatically check whether all the packages others depend on are really there. An automatic dependency check would be useful. Guy
Bug#4360: bug in route man page
Hi, the example is missing -net before 224.0.0.0. fixed in net-tools-1.33-alpha (upstream version, not yet released). Greetings Bernd
Re: Bug#4378: incomplete Packages files and incomplete distributions
In article [EMAIL PROTECTED] you wrote: : I don't know of a longterm solution short of : duplicating the contrib and non-free trees into stable and unstable : versions. During the time when I was master of master, I was working on a proposal for restructuring the hierarchy... and this is the same conclusion that I came to. Right now, the contrib and non-free trees are, by definition, unstable since they aren't frozen at release time. I don't think this is very nice for folks who are trying to run latest stable bits all the time. As an aside... Another way of looking at it that I spent some time on one weekend is that what you really want on the FTP server is something like a versioned filesystem effect, where you could have an object pool of packages with potentially multiple revisions per package present. Each release, and indeed the unstable tree, would just be symlink trees pointing to the appropriate revisions in the object pool. If you picked a reasonably sized amount of disk for the object pool, you could then treat it sort of like a cache, ensuring at all times that any object which is the target of a currently-maintained symlink stays around, and all other versions of objects get tossed out using an LRU strategy as new objects are uploaded. It's a very neat idea, and solves a handful of problems, but it presents a problem for mirror sites or users who want to get just the objects associated with a given revision. It's not clear to me how you'd train an ftpd to know when it should return a tree of symlinks, and when it should return a tree populated with the objects that the tree of symlinks on the server point to. Oh well, next time I'm resting I'll think about it some more... : Our ftp hierarchy is already too complicated. Flexibility often drags complexity along. I thought it would be easy to make 'contrib' and 'non-free' be directories at the same level as 'base', 'devel', and so forth... but met some reluctance about making it harder for CD-ROM folk to do the right things by having these trees exist inside a release tree. : An older version of gs, which is in /buzz and which would do with : the existing gsfonts package, cannot be installed, because dselect : picks only the newest version. : : It seems overloading the gs name is causing problems. Joost, the : maintainer of both gs's, offered several times to rename them to gnu-gs : and alladin-gs and let them conflict. Perhaps this needs to be done. : Ian? It'd be nice, in my mind, if they were 'gs-gnu' and 'gs-alladin' so they sort together, etc... : and to automatically check whether all the packages : others depend on are really there. : : An automatic dependency check would be useful. Yep. Seems like a report to the owners of packages in question indicating issues with the dependency tree for files installed in the stable/unstable hierarchies would be generally useful. I don't have time right now, or I'd offer to write it. A release criteria should certainly be that all of the dependencies specified by packages in the stable tree can be resolved by packages in the stable tree. Our recent discussions about dependencies crossing the boundaries between normal/contrib/non-free trees indicate that some checking up on what's really being done is probably a good idea... Bdale
Shared libraries and symbols
Can we strip shared libraries? I don't know whether that's possible but I just found out that 'nm /lib/libc.so.5.4.4' (yes, I know this is not the Debian version) on my system gives: /lib/libc.so.5.4.4: no symbols However, almost all other shared libraries come with symbols, some even with debugging sysmbols (at least strip -g is able to reduce the library size). If these symbols are not needed I'd like to ask all libraries to be stripped since it saves an awful lot of disk space. If for some reasons the symbols are needed could anyone tell me why my libc works? Michael -- Michael Meskes |_ __ [EMAIL PROTECTED] | / ___// / // / / __ \___ __ [EMAIL PROTECTED] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [EMAIL PROTECTED]| ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian GNU/Linux!| //_/ /_/ //\___/_/ //
Re: Bug#4051: access permissions for /usr/bin/fdmount
Ian Jackson writes: Well, how hard is it to compile out ? It's not the most awful thing that could happen to a program to have this unnecessary check, but I do think it will add confusion. It's not that difficult. I'll take care of it when I release a new version. Michael -- Michael Meskes |_ __ [EMAIL PROTECTED] | / ___// / // / / __ \___ __ [EMAIL PROTECTED] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [EMAIL PROTECTED]| ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian GNU/Linux!| //_/ /_/ //\___/_/ //
Re: 96 New Debian i386 Packages
Ian Jackson writes: When a package is uploaded an announcement should be posted to tt/debian-changes/. The announcement should give the (source) package name and version number, and a very short summary of the changes, in the prgn/Subject/ field, and should contain the PGP-signed tt/.changes/ file. Some additional explanatory text may be added before the start of the tt/.changes/ file. p Okay IMO. If a package is released with tt/Distribution: experimental/ the announcement should be posted to tt/debian-devel/ instead. 'Distribution: experimental' means unstable, doesn't it? Or do you really mean the experimental subtree under project? Michael -- Michael Meskes |_ __ [EMAIL PROTECTED] | / ___// / // / / __ \___ __ [EMAIL PROTECTED] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [EMAIL PROTECTED]| ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian GNU/Linux!| //_/ /_/ //\___/_/ //
My packages
Here's a rundown on my packages. Remember I habe to give away most of it since I might not have the time for it in my new job. Here are the one I found new maintainers for. Is there a list where we have to enter the packages? Also some of these are listed as 'maintainer wants to give away'. I take it this should be changed. lshell - Heiko Schlitterman[EMAIL PROTECTED] joe - Dale Scheetz [EMAIL PROTECTED] shadow - Guy Maor [EMAIL PROTECTED] sudo- Bdale Garbee [EMAIL PROTECTED] symlinks- Bernd Eckenfels [EMAIL PROTECTED] xcolors - Syrus Nemat-Nasser[EMAIL PROTECTED] xsysinfo- Syrus Nemat-Nasser[EMAIL PROTECTED] mtools - Mark Eichin [EMAIL PROTECTED] The packages I still have are: adjtimex1.2-4 fdutils 4.3-5 gccbeta 2.7.2.l.3 hkgerman2-5 html2latex 0.9c-1 lyx 0.10.1 metamail2.7-8 modules 2.0.0-8 perforate 1.0-3 quota 1.55-3 xautolock pl10-2 xforms 0.81-1 Anyone's interested? Michael -- Michael Meskes |_ __ [EMAIL PROTECTED] | / ___// / // / / __ \___ __ [EMAIL PROTECTED] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [EMAIL PROTECTED]| ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian GNU/Linux!| //_/ /_/ //\___/_/ //
Re: Shared libraries and symbols
Hi Michael, [...] /lib/libc.so.5.4.4: no symbols This is most certainly a bug! [...] since it saves an awful lot of disk space. If for some reasons the symbols are needed could anyone tell me why my libc works? Try debug a dynamically linked binary using gdb and you will see lots of messages about loading symbols from the shared libraries ... I would prefer to keep the symbols in the libraries. CU, Dominik =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Visit the FAN SITE of the WORLD LEAGUE OF AMERICAN FOOTBALL: A HREF=http://www.uni-mainz.de/~kubla/WLAF/Welcome.htmlHTTP/A or A HREF=file:/afs/zdv.uni-mainz.de/homes/UFO/kubla/public_html/WLAF/Welcome.ht mlAFS file/A access.
Bug#4381: tkps installs itself into /usr/local/bin
Package: tkps Version: 1.2-0 The binary is installed into /usr/local/bin. However, no package should do that. Since tkps doesn't run without X it should be installed into /usr/X11R6/bin. Michael -- Michael Meskes |_ __ [EMAIL PROTECTED] | / ___// / // / / __ \___ __ [EMAIL PROTECTED] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [EMAIL PROTECTED]| ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian GNU/Linux!| //_/ /_/ //\___/_/ //
Bug#4305: metmail uses non-existent flag in postinst
Mark Eichin writes: The problem is that the interface is *far* from intuitve. It needs at least a sentence or two up top explaining what it's asking about (it wasn't clear to me until after I'd seen a third viewer show up...) Valid point. But then the bug should be filed against mime-support that contains install-mime, not metamail that only uses it. Michael -- Michael Meskes |_ __ [EMAIL PROTECTED] | / ___// / // / / __ \___ __ [EMAIL PROTECTED] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [EMAIL PROTECTED]| ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian GNU/Linux!| //_/ /_/ //\___/_/ //
Bug#4376: vm doesn't use /etc/emacs/site-start.d
RK == Richard Kettlewell [EMAIL PROTECTED] wrote: RK Package: vm RK Version: 5.95beta-2 RK ... VM maintainer, when fixing this bug, it would also be a good idea to upgrade to 5.96beta. Kind regards, Emilio. -- Emilio C. Lopes mailto:[EMAIL PROTECTED] Instituto de Fisica da Universidade de Sao Paulo Caixa Postal 66318, 05389-970 Sao Paulo - SP, BRAZIL Phone: (+55) (11) 818-6724 (Voice) / 818-6715 (Fax)
