signify 1.00-1 released
-BEGIN PGP SIGNED MESSAGE- Date: 27 Aug 96 22:26 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: Brian White <[EMAIL PROTECTED]> Source: signify Version: 1.00-1 Binary: signify Architecture: all source Description: signify: Autamatic semi-random signature generator - Signify is a neat little program that allows a random signature to be - generated from a set of rules. Each section can be one of an unlimited - number of possibilities, each with its own weighting so those really cool - quotes can appear more often than others. Sections can also be placed next - to each other vertically to create columns. Each section can be formatted - independently as left/right/center and top/bottom/vcenter. Changes: - First release of a new product! Files: 4bdd2f64ff7d892a5e66685944e89324 8728 mail - signify_1.00-1.tar.gz 000c7bad00dd13cee55e03b88fe064d0 8094 mail optional signify_1.00-1_all.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMiN2X7wRa6IPcXgFAQFZ9gP+JekIzKSxb05VkJiKGwzS7FuL52pcRMol lXM46918s0Hvr/XhLwhNYORVuq295jsIkthMmZlE1RSueiT9XB0t3AH78As6q11U qixQbrniPqgTFObbx6UqE6UddiVv13yX4HoNIM7g9Fjz/jFRB6VDa6NsIREGhSg3 9oP7a6zLSCo= =h4Rg -END PGP SIGNATURE-
Re: Do we ever retire packages?
Ian> Unless enscript provides programs a2gs and a2ps which emulate their Ian> command line interfaces then it is not a complete replacement. That is a valid point, so I rest my case. -- Dirk Eddelb"uttel http://qed.econ.queensu.ca/~edd
Re: 'nother glitch with new source format...
Michael Alan Dorman writes ("'nother glitch with new source format..."):
> I've almost finished converting a whole package---the only thing I
> lack is a completed .changes file.
>
> When running dpkg-buildpackage on my testbed, I get the following:
> ...
> dpkg-genchanges: error: package ncftp has section in control file but
> - in files list
> ...
> The problem, I guess, is obvious enough, but I feel unsure of why this
> is a problem (I thought we were being encouraged to leave section and
> priority and all that to the archive maintainer).
See the new policy manual,
, and
read the section on `Section and Priority'.
The problem is due to a bug in dpkg-genchanges which should have
called this a warning rather than an error, and due to your failure to
suggest a section and priority.
> Once this can be resolved, I guess my only remaining complaint would
> be that the build process is (until I have time to really sit down
> with the tools and explore them and exactly what they do) just a touch
> on the opaque side.
>
> Which, I suppose just proves that Ian can't satisfy everyone all at
> once.
Have you found the right docs ? Try the programmers' manual.
Ian.
Re: Do we ever retire packages?
Dirk Eddelbuettel writes ("Re: Do we ever retire packages?"):
...
> I would like to have a2gs and a2ps removed. They both have the same
> Description: text, and scope, "ASCII to PostScript filter".
>
> For me, a2gs is broken. I filed bug 1112 against it [1], and this bug is
> still open after 13 months. There are also bugs 3456 and 3848 against it.
> a2ps does a similar thing, but is in non-free. It has bugs 1874 and 3911
> against it.
>
> Both programs are _completely surpassed_ by enscript (which used to be called
> genscript), a _GPL'ed_ program that does more than a2ps and a2gs.
>
> I propose, as I did before, that these programs get removed. Unless someone
> complains, I will, as suggested, file two bugs against ftp.debian.org to have
> them removed.
I disagree. If they really are that broken and noone wants to
maintain them, put them in contrib.
Unless enscript provides programs a2gs and a2ps which emulate their
command line interfaces then it is not a complete replacement.
Ian.
Re: [linux-alert] LSF Update#13: Vulnerability of mount/umount utilities from util-linux 2.5
(Note wide crossposting - please trim followups.) Alexander O. Yuriev writes: ... > Until the official fix-kits are available for those > systems, it is advised that system administrators > obtain the source code of fixed mount program used > in Debian/GNU Linux 1.1, compile it and replace the > vulnerable binaries. ... Debian is now phasing in a new source packaging format, which has some advantages for internal uses, notably automatic building. The procedure for unpacking the source without using our own tools will change - I'm afraid it's a little more complicated, though fairly obvious. I've placed a description of what to do in /debian/doc/source-unpack.txt in the Debian FTP archive, and made links called README.source-unpack in /debian/unstable/source, /debian/contrib and /debian/non-free. A copy of the file is below. Ian. HOW TO UNPACK A DEBIAN SOURCE PACKAGE There are two kinds of Debian source packages: old ones and new ones. A. Old ones look like this: hello-1.3-4.tar.gz hello-1.3-4.diff.gz You unpack them by untarring the .tar.gz. There is NO need to apply the diff. B. New ones look like this: hello_1.3-11.dsc hello_1.3-11.diff.gz hello_1.3-11.orig.tar.gz - note the `.orig' part Here you MUST use dpkg-source or apply the diff manually - see below. If you have `dpkg-source' you should put the files in the same directory and type `dpkg-source -x .dsc'. If you do not you can extract the Debian source as follows: 1. untar P_V.orig.tar.gz. 2. rename the resulting P-V.orig directory to P-V. 3. mkdir P-V/debian. 4. apply the diff with patch -p0. (where P is the package name and V the version.) C. There are some packages where the Debian source is the upstream source. In this case there will be no .diff.gz and you can just use the .tar.gz. If a .dsc is provided you can use `dpkg-source -x'. -- Ian Jackson <[EMAIL PROTECTED]> Sat, 31 Aug 1996
Re: dpkg-buildpackage and -source questions
Dale Scheetz writes ("Re: dpkg-buildpackage and -source questions"):
> On Fri, 30 Aug 1996, Ian Jackson wrote:
> > If you get this message [deleted]
> > you should upgrade your cpio. [...]
>
> This resolved the problem for me. At least at this point I can unpack
> hello ok. Shouldn't dpkg have a depends added for this? I have not
> understood your reluctance to add depends for patch and diff as well. If
> they really aren't dependencies, souldn't they be recommended or
> suggested? If not there should, at least be some mention of their
> usefulness in the description somewhere.
I've added Suggests for patch and cpio, and given a version for cpio,
and mentioned patch and cpio in the Description.
diff is in the base and marked essential.
Ian.
Bug#4329: Emacs has hardcoded path for jka-compr, breaks at upgrade
Mark W. Eichin writes ("Re: Bug#4329: Emacs has hardcoded path for jka-compr,
breaks at upgrade"):
> Did you upgrade from 19.29-3 to 19.31-2 as indicated in your message,
> or to 19.34-2, which is current?
19.34-2 hasn't reached my local mirror yet. Isn't it still in
Incoming ?
> (I ask, because I just got the bug
> report today, and it appears to be about a day old -- but if you
> actually reported it before 8/27, then there is a bug tracking problem
> that needs attention.)
Years only have 12 months, ITYSBT. Perhaps you meant the 27th of
August, aka 27.8.1996 aka 1996-8-27 ? [1]
If you look at the headers of the messages you'll see that I reported
it at 02:23 BST (= 01:23 GMT) on the 29th.
> I can see about making the emacs postinst smarter, but it's clear that
> the line you quoted from site-start was what was wrong in the first
> place. I don't know, however, what package included it (which is a
> part of the reason for the change in the way startup code is handled...)
Right ...
Ian.
[1] Yes, I know it was probably deliberate, but American middle-endian
date-formats are stupid and confusing and I want them stamped out.
Bug tracking system's outgoing mail
I have reconfigured the sub-MTA in my home directory on master which is used by the bug tracking system. (I have Smail installed in my filespace because qmail's sendmail command line emulation is broken and using Smail as a gateway to the system's real MTA was easier than trying to parse RFC822 recipient fields myself.) The bug system's mailer will now deliver mail itself whenever it can; previously it used `localhost' as a smarthost, so that master's qmail installation would do the actual delivery. This will, I hope: (a) provide logs for outgoing mail at least. qmail does not log anything at all, making it impossible to trace missing mail. (b) provide faster delivery. qmail doesn't deliver things immediately - it always waits for a queue run. (c) provide more reliable delivery. I have had a couple of unexplained `unknown mail domain' type bounces. (d) allow me to inspect the outbound mail queue without becoming root. Users should not notice any difference. If you encounter any problems (eg, malformed messages from the bug system) please let me know. Ian.
Re: Bug#4051: access permissions for /usr/bin/fdmount
Michael Meskes writes ("Re: Bug#4051: access permissions for /usr/bin/fdmount"):
> Ian Jackson writes:
...
> > Err, I strongly suggest that you compile the group check out of the
> > executable. This is only likely to lead to confusion.
>
> I think I understand what you mean. But is it really that bad?
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.
Ian.
Re: New virtual package names.
Dale Scheetz writes ("Re: New virtual package names. "):
...
> Well, I'm pretty sure that Bill didn't just wake up one morning and say
> "Wow! That essential field sure is neat! Let's put it in ae! My assumption
> was that this was an attempt to keep ae in the system.
I think that Bill was under the mistaken impression that every base
package should be marked essential.
...
> No, I am concerned about programs that might use $EDITOR as the means to
> providing an editor. [...]
As has been pointed out, the dependency scheme doesn't help at all
here.
Ian.
Bug#4354: movemail doesn't work
Michael Shields 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. That's odd. [EMAIL PROTECTED]:richard$ ls -l /usr/lib/emacs/19.31/i386-debian-linux/movemail -rwsr-sr-x 1 root mail14516 Jun 3 05:05 /usr/lib/emacs/19.31/i386-debian-linux/movemail* [EMAIL PROTECTED]:richard$ (I understood that the whole point of movemail was to separate out the bit of a mailer that needed to be setgid mail into a separate executable.) -- Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Re: varargs, terminfo, and a note for the policy manual
Bruce Perens writes on debian-user and to lots of people: ... > OK, I hear you - here's a note for the policy manual, Ian, if it isn't > already in there. > > Varargs and libtermcap are provided to support end-users installing > legacy software, and the few packages (like Netscape) that are not > available to us in binary form. Debian packages should be ported to > stdarg and ncurses when they are built, please. I have added the attached text. Let me know if you want something changed. Ian. Obsolete constructs and libraries: varargs and libtermcap Debian packages should be ported to
Manuals other than as HTML in the dpkg*.deb file
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 ? Ian.
Re: FAQ: Work-Needing and Prospective Packages
Sven Rudolph writes ("FAQ: Work-Needing and Prospective Packages"):
...
> 1. General Questions
>
> 1.1.What is Debian GNU/Linux
>
> [etc]
Sven, did you receive my message below ?
Ian.
--- start of forwarded message (RFC 934 encapsulation) ---
Newsgroups: chiark.mail.debian.devel
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
To: debian-devel@lists.debian.org
Subject: Re: FAQ: Work-Needing and Prospective Packages
Sven Rudolph writes ("FAQ: Work-Needing and Prospective Packages"):
> Unfortunately there are some newly orphaned packages. Please look at
> sections 2. and 3.
Sven, how about making this list a little more concise. It's hard to
see at a glance what's going on in amongst all the tables of contents
and descriptions and so forth.
A summary, near the top, with one line per package, would be very
good. The only information needed there is the package name and the
summary description (from the package, or made up). People can mail
debian-devel if they want to take over something.
Ian.
--- end ---
Re: /usr/local (again)
Richard Kaszeta writes ("/usr/local (again)"):
...
> Since packages generally don't install anything other than empty dirs
> in /usr/local, can't this be handled in a way that makes it easier for
> those of us trying to maintain many debian machines?
Section 3.2.9 of the policy manual may be informative.
I haven't implemented the required feature for dpkg yet.
Ian.
3.2.9 /usr/local - for the use of the system administrator
As mandated by the FSSTND no package should place any files in
/usr/local, either by putting them in the filesystem archive to be
unpacked by dpkg or by manipulating them in their maintainer scripts.
Every package that searches a number of directories or files for
something (for example, looking for shared libraries in /lib or
/usr/lib) should search an appropriate directory in /usr/local too.
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.
In the future it will be possible to tell dpkg not to unpack files
matching certain patterns, so that system administrators who do not
wish these directories in /usr/local do not need to have them.
Re: Bug#4204: cron does not install if /usr/sbin/cron does not exist!?
Steve Greenland writes ("Re: Bug#4204: cron does not install if /usr/sbin/cron
does not exist!?"):
> Yves Arrouye wrote:
...
> > 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
...
>
> Interesting. It's failing because it's an upgrade (otherwise prerm
> wouldn't be called), but /usr/sbin/cron isn't there. I'm able to
> duplicate it by simply rm'ing cron, and then trying to do pretty
> much anything with dpkg -- install doesn't work, and neither does
> remove. I've tried --force-reinstreq ('cause one of the messages
> >from dpkg is "Package is in a very bad inconsistent state - you
> should reinstall it before attempting a removal.") but that doesn't
> help. I'm not sure how to get out of this other than going down
> into the bowels of /var/dpkg and messing with the prerm script:
> I don't see a --ignore-script-errors option for dpkg.
I could add one, of course, but it's probably a bad idea.
...
> They're supposed to have -e set. I'm not inclined to modify the
> script to check for /usr/sbin/cron, because the if the prerm script
> is called, then the cron package is installed, and the cron program
> is supposed to be there. If it isn't, then the file has been removed
> by manipulations outside the domain of the dpkg/dselect.
Indeed.
> If all the package scripts are supposed to deal with things happening
> outside the control of dpkg/dselect then I have about 300 bug
> reports to file :-).
Quite.
> I'm not closing this bug yet, because I would like to know if there
> is a way around this problem (other than 'touch /usr/bin/cron', which
> may well be the best answer).
I think that `touch /usr/bin/cron' is the best answer.
Ian.
Bug#4356: menu-bar-mode flag argument is inconsistent with universe
Package: emacs Version: 19.31-2 I used to have in my startup files (menu-bar-mode nil) which used to turn off menu bars. In 19.31 this has changed so that `nil' doesn't have the desired effect. Instead, you have to supply a negative number ! This is totally inconsistent with almost every other emacs-lisp function. menu-bar-mode should accept `nil' to turn menu bars off and `t' to turn them on. I don't have an opinion about whether positive and negative numbers ought to be supported. Ian.
Re: Bug#4261: Ghostview and virtual package postscript_viewer
Brian C. White writes ("Re: Bug#4261: Ghostview and virtual package
postscript_viewer"):
...
> Yes, [something] _is_ what should be done. "install-mime" handles
> multiple entries for the same mime-type. Thus, if both "ghostview"
> and "gv" get installed, the user is given the choice of which is to
> have priority in the mailcap file. Trust me, this will work. It
> was designed to handle just this case.
>
> Please see the "install-mime" man page for more information.
Would someone please write a paragraph for the policy manual on the
use of install-mime ? It's OK to refer to the manpage.
Thank you.
Ian.
Re: 96 New Debian i386 Packages
Michael Meskes writes ("Re: 96 New Debian i386 Packages"):
> Ian Jackson writes:
> > Can we please have a statement on what we should do ?
> >
> > I think we should post the release announcements to debian-changes as
> > well has having the summary postings.
> >
> > If people want just the summaries we should provide a separate list.
>
> I second all of that.
I propose to add the text below to the policy manual.
Ian.
Upload handling - announcements
When a package is uploaded an announcement should be posted to
If a package is released with
Bug#4355: lesstif-dev has incoorect location for include files
Package: lesstif-dev Version: 0.50-1 The header files are placed under /usr/include/X11/Xm. However, thex shoudl go in /usr/include/Xm since they include others with: #include Michael -- Michael Meskes |_ __ [EMAIL PROTECTED] | / ___// / // / / __ \___ __ [EMAIL PROTECTED] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [EMAIL PROTECTED]| ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian Linux!| //_/ /_/ //\___/_/ //
Bug#4354: movemail doesn't work
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. -- Shields, CrossLink.
Bug#4353: fcntl.2 references nonexistent manpage
Package: manpages Version: 1.11-4 SEE ALSO open(2), dup2(2), F_DUPFD(2), F_GETFD(2), F_GETFL(2), F_GETLK(2), socket(2). but: [EMAIL PROTECTED]:richard$ man F_GETLK No manual entry for F_GETLK -- Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#4352: stat(2) man page doesn't mention all error returns.
Package: manpages Version: 1.11-4 ERRORS EBADF filedes is bad. ENOENT File does not exist. EACCESS, EFAULT, ENOMEM and ENAMETOOLONG are also possible. -- Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#4350: Self-contradictory help message for dpkg-buildpackage
Package: dpkg Version: 1.3.12 sfere:/home/ftp/pub/debian/binary/base$ dpkg-buildpackage -h [...] Usage: dpkg-buildpackage [options] Options: -r [...] -si (default) src includes orig for rev. 0 or 1} genchanges -sa uploaded src includes orig (default) } Clearly one or the other of these is the default, but not both! (S)
