dpkg 1.3.4: cosmetic bugfix and manual update
-BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Sun, 11 Aug 1996 13:25:44 +0100 Source: dpkg Binary: dpkg Architecture: source i386 Version: 1.3.4 Distribution: experimental Urgency: low Maintainer: Ian Jackson [EMAIL PROTECTED] Description: dpkg - Package maintenance system for Debian Linux Changes: dpkg (1.3.4) experimental; urgency=low . * Removed debugging output from dpkg-source -x. Oops. * Removed section on source package permissions from policy manual - dpkg-source now sorts these out. Files: afe8d675892c18d203a27a8bc864d9bf 526 base required dpkg_1.3.4.dsc 5202cb7f1013fea980c52aac23915fe4 457383 base required dpkg_1.3.4.tar.gz 745d1b46cc96f9c429f2d89784d8767c 295270 base required dpkg_1.3.4_i386.deb 1621703f3fd1fe1e76eb67af1a8bccf7 289934 byhand - dpkg_1.3.4_i386.nondebbin.tar.gz -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMg3S18MWjroj9a3bAQE1FQP+Ja3rnBWkEFvD+qEoa7N6j70aFUSaRs/g ZTNjkbq1P8g5RRoC41DtU47DrBzGw7SyVq/EUZ/8plIIpyyz167l1So8WdlvL8dc l6nD5+gAUNlV8BuTm7/lHhDycxPQzCAw0Io59zRpbCxL6USV0SQE5LdMyWFLkflk lKbsSLvvmeI= =cGcj -END PGP SIGNATURE-
debiandoc-sgml 1.0.2: bugfixes, manuals
-BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Sun, 11 Aug 1996 17:42:46 +0100 Source: debiandoc-sgml Binary: debiandoc-sgml Architecture: source all Version: 1.0.2 Distribution: experimental Urgency: medium Maintainer: Ian Jackson [EMAIL PROTECTED] Description: debiandoc-sgml - Documentation formatting for Debian manuals Changes: debiandoc-sgml (1.0.2) experimental; urgency=medium . * PostScript converter really works now, honest. * Markup authors' manual provided (in /usr/doc, HTML format). * Manpages for converters included. . * Source package archival corrected. * PostScript converter displays error messages from Lout. * saspconvert prints correct name in error messages. Files: 1f17fe6f83e633323e8eaae2d9b1c4c4 555 text optional debiandoc-sgml_1.0.2.dsc 334e98fef4916316a41cb63dc6ef6a77 30749 text optional debiandoc-sgml_1.0.2.tar.gz d184988042e7c77f63520e59c036af27 22120 text optional debiandoc-sgml_1.0.2_all.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMg4NqMMWjroj9a3bAQEmLwP/Z6yHJfbtV6lb0R4Sp15LNM0rAZIxXDb2 AsrtViwp6jpJ8ors/Di9GpDjgPLqRfe773+ouZemg4HwclfCwHbaJ6a2toWeTAne Pk4xFFkRleN7gPq0bXzCg41DbiFtRXKxuH7GjbTv0wkY+jFT2zysom2daXfuD/Sx wxeW1yHCznc= =KD9h -END PGP SIGNATURE-
debiandoc-sgml 1.0.3: actually formats documents
Grr, I screwed up the SGML entity catalogue handling so the last version wouldn't work at all unless you happened to be in a directory with a few particular files. -BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Mon, 12 Aug 1996 02:30:24 +0100 Source: debiandoc-sgml Binary: debiandoc-sgml Architecture: source all Version: 1.0.3 Distribution: experimental Urgency: low Maintainer: Ian Jackson [EMAIL PROTECTED] Description: debiandoc-sgml - Documentation formatting for Debian manuals Changes: debiandoc-sgml (1.0.3) experimental; urgency=low . * Converters work again. Oops. * Lout (and hence PostScript) more space at end of compact list. * Minor markup manual improvements. Files: e51b564a6ea92ec2295491a501f50076 555 text optional debiandoc-sgml_1.0.3.dsc 05d299378bbbf29cdf0c406c36407df4 30842 text optional debiandoc-sgml_1.0.3.tar.gz da10dbdb218d5474048863c172459bc1 22106 text optional debiandoc-sgml_1.0.3_all.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMg6LWcMWjroj9a3bAQFnbQP+LbZa5OZZ4fAjSMP4piayK/v/gg6rQCBN XXmzHHr3AuFldlaXlIu/n+HCXX5tOvBOutZkyk3ahQXXDep+zIekocfk8H4mup9Q +bcZgOv4Fj/MBMfTxRNQvIaPoEs4ItFoGAM1nqYvfHyQMgyMy6G+mjPxfXkdqn96 88Cu0yhsJb4= =Z5wr -END PGP SIGNATURE-
Re: Conversion procedure for new source packages DRAFT
I wrote: This is my first draft of a quick document saying how to convert an old to a new source package. DO NOT DO ANYTHING YET except read this and suggest amendments. I've thought of something to add to this list: * Check that the description is well-formatted and meaningful and helpful to people wanting to know whether to install a package. Should I put all of this in an appendix to the policy manual ? Ian.
Re: Emacs per-package startup files
Brian C. White writes (Re: Emacs per-package startup files): ... [someone:] So, do these files go in /var/lib/emacs, /etc/emacs, or /usr/lib/emacs/site-lisp, and why? I can set it up and send changes to the emacs package maintainers this weekend if that gets worked out... I'd vote for /usr/lib/emacs/site-lisp. Why? Because /var/lib/emacs is for files that can't be on a read-only filesystem and /etc/emacs is for user config files and the like. /usr/lib/emacs/site-lisp is for something entirely different. It's for the main lisp files (modes or whatever) that a package installs. /var/lib is obviously wrong, as the files aren't changed in normal operation. The files need to be conffiles so that the sysadmin can modify their behaviour, remove them, c, and have their changes respected. So it needs to be in /etc. Ian.
Re: des encryption..
Yves Arrouye writes (Re: des encryption.. ):
Ian Jackson writes:
Also I propose to mandate in the policy manual that packages which use
/opt should provide appropriate links or files in
/opt/{bin,lib,man,include,info,doc} and that packages which search
paths must look in /opt too. Comments ? (And see the recent
FSSTND/FHS work on /opt - it's deliberately very vague.)
Should we put /opt/bin before or after /usr/bin by default? (I'd suggest
before).
After, because it will be larger, and because it makes it harder for
an /opt package to accidentally cause problems ?
The sysadmin can always use /usr/local to change which one is run if
they want some different arrangement locally.
Ian.
Bug#4107: emacs leaves stale lockfiles and publishes pathnames
Package: emacs Version: 19.29-3 My /var/lib/emacs/lock directory contains many old lock files. I'm quite happy to believe that the occasional leftover lock is unavoidable, but steps should be taken to clean them up. Furthermore, all the pathnames for the lockfiles are world-readable. This is not what one would expect, and confidential information is not infrequently present in filenames. The best solution might be to put the filename or other information about the file through a cryptographically strong one-way function (eg SHA-1 or MD5) and only include the filename in the file itself (which should be readable only by owner). I don't think all the files should be world-writeable, either. Ian.
Shared library dependencies revisited
Please read the proposal below and comment on it. If noone says
anything I'll probably implement and mandate something very like it in
the next week or two, in time for the new source package format (we
only want to change this once). Now is the time to have your say.
I've been thinking about shared library dependencies some more and
have come to the conclusion that the current scheme is not good
enough. As the new source format spec stands every package which
depends on a shared library must have hardcoded into the
debian/control which shared libraries are involved - the names and
version numbers of the packages must be entered manually into the
Depends or Recommends fields.
This will mean, amongst other things, that when we move to libc6 we
won't just be able to recompile the packages - we'll have to edit the
control files too. This is already causing the alpha people problems
because their libcs are different.
I propose the following arrangement (if you don't understand things
you should read dpkg-source(1) and the relevant parts of the new
programmers' manual):
Every package which contains compiled binaries invokes, in its
debian/rules, a program which automatically determines what the
dependencies are. Eg,
dpkg-shlibdeps -fPre-Depends main/dpkg dselect/dselect
This produces on stdout something like
shlib-Pre-Depends=libc5 (= 5.2.18-2), ncurses3.0 (= 1.9.9e-1)
(The -fpre-depends option can be -fDepends, -fRecommends or even
-fSuggests to specify a particular level of dependency, and
-f... options can be mixed with binary arguments).
The debian/rules puts the output in debian/substvars. Then when it
runs dpkg-gencontrol the main source control file can say:
Source: dpkg
...
Package: dpkg
Pre-Depends: ${shlib-Pre-Depends}
...
The dpkg-shlibdeps program works as follows: it runs ldd on the binary
in question, finding out which libraries are being loaded. It uses
dpkg --search to find which packages they are in. It then looks in a
file provided by that package to find out what the dependency name
ought to be (for example, libX11.so.6 is in xlib but the dependency
name should be elf-x11r6lib) and what version is required to make
ld.so not complain. The file has lines looking like
libname.so.soname dependency
eg
libX11.so.6 elf-x11r6lib
libc.so.5 libc5 (= 5.2.18-2)
I'm not sure where to put the package-provided file. Three
possibilities come to mind:
* /etc/dpkg/shlibs/package
* /usr/lib/dpkg/shlibs/package
* /var/lib/dpkg/info/package.shlibs (came from DEBIAN/shlibs)
/etc has the feature that it can be a conffile, though it's not clear
to me whether this is necessary. The second and third options seem
much of a muchness to me, but I'm inclined towards the /var/lib/dpkg
location as this will effectively hide the real location from anyone
but dpkg (the package maintainer puts the file in DEBIAN/shlibs and
dpkg-shlibdeps is the only thing that needs to find it).
There ought to be a conffile /etc/dpkg/shlibs.default which contains
overriding entries (and can be used to avoid problems when the shared
library in question didn't come from a Debian package, for example
when bootstrapping).
Ian.
Re: Documentation formats
Bruce Perens writes (Re: Documentation formats): From: Ian Jackson [EMAIL PROTECTED] The thing is that I think we need to be able to distribute other [documentation] end-products [than HTML]. HTML is bad for printing, for example, and not ideal if you have a slow machine. Choice is a good thing. Do you have a proposal? I'm not trying to exclude other formats, but I'm trying to arrive at a common denominator, even if it has its detriments. Yes, fine. I think we're in agreement. I'll post my proposal in another message. I'm not sure I agree with the slow machine part. That seems to be browser-specific. Well, even lynx is much slower than less, and has a worse user interface in some people's eyes. Ian.
Re: Documentation formats
Bruce Perens writes (Re: Documentation formats): ... The unification of Debian documentation will be carried out via HTML. You should not consider the merits of a particular HTML viewer, or even the weight of the best of our existing HTTP servers. These things will change with time, and without effort on our part. Instead, you should concentrate in providing automatic means to present man files, info files, and other various forms of documentation to the user. This can be done at run-time via CGI scripts, or when the documentation packages are installed. Use existing software where possible. Try to consider disk space, but having a full documentation system takes priority over that. A keyword search facility and a unifying set of indices are a high priority. Texinfo-generated info files are very common for obvious reasons. Do we start distributing Texinfo-generated HTML instead ? (Is texi2html any good ?) Or do we do some kind of display-time conversion from info to HTML ? Or leave the question for the moment ? Ian.
Re: Documentation formats
Bruce Perens writes (Re: Documentation formats): From: Ian Jackson [EMAIL PROTECTED] The thing is that I think we need to be able to distribute other [documentation] end-products [than HTML]. ... Do you have a proposal? ... My initial proposal is as follows: If it's available we distribute HTML documentation with the package itself (if the documentation is usually distributed with the package) or in the main documentation package package-doc (if it wants to be distributed separately, for example because it's large). Other formats are distributed in separate packages package-doc* where * is some string. We can either put them all together, keeping the number of packages small, or have one package per format, making it possible to install formats selectively. If we do former the * should probably be `xf' (extra formats) or `fmts' (formats) or some such; if we do the latter it should represent the format (`dvi', `ps', `text', whatever). We can do a mixture of the two, specifying that one or two specific formats should be supplied in their own packages, or allow the package maintainer to decide, or set size-based guidelines, or whatever. Opinions and arguments, anyone ? Ian.
Re: des encryption..
(Moved to debian-devel:)
[EMAIL PROTECTED] writes (Re: des encryption..):
[Ian Jackson:]
Can we please put /opt - /usr/opt and the empty /opt tree in the base
package, before things get any worse ?
Also I propose to mandate in the policy manual that packages which use
/opt should provide appropriate links or files in
/opt/{bin,lib,man,include,info,doc} and that packages which search
paths must look in /opt too. Comments ? (And see the recent
FSSTND/FHS work on /opt - it's deliberately very vague.)
And where goes the copyright file ? /opt/doc/package/copyright ? This will
be messy. /usr/doc/package/copyright seems to be inappropriate as well.
/opt/package/copyright, in line with the non-integrated nature of
many of these packages ?
Any opinions, anyone ?
Ian.
dpkg 1.3.5: source packaging bugfixes, esp. changelog mode
-BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Wed, 14 Aug 1996 14:46:47 +0100 Source: dpkg Binary: dpkg Architecture: source i386 Version: 1.3.5 Distribution: experimental Urgency: low (high for debian-changelog-mode) Maintainer: Ian Jackson [EMAIL PROTECTED] Description: dpkg - Package maintenance system for Debian Linux Changes: dpkg (1.3.5) experimental; urgency=low (high for debian-changelog-mode) . * 822-date script included. (Bug#4136.) * debian-changelog-add-version works on empty file. * debian-changelog-mode mode-help works properly. . * dpkg-source tells patch not to make numbered backups. (Bug#4135.) . * More developers' PGP keys. * Paragraph on uucp -a and -g options removed from policy manual. Files: 874197b9a4e419ed96495771f02f1515 526 base required dpkg_1.3.5.dsc 1d22445d0c340f8745e41d7db8cffc78 489432 base required dpkg_1.3.5.tar.gz fe8e6ebd2d1c391b43ce7b7db2c8a6aa 296204 base required dpkg_1.3.5_i386.deb 9ab4ac1deb119daa963d199de0eec029 290999 byhand - dpkg_1.3.5_i386.nondebbin.tar.gz -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMhHaKsMWjroj9a3bAQEq7wP+NF7gCUorNzQuwk2vGKGPQbAROYDmundM w19vDRk1iquSCo37/uZH/Gx1C0GhT/NUPJ6djPCLZIXdCjDNqJRIxL/Vlwm80xFL 8x5jMHkr0PExtPxxLGMdda/h2M5aTxqjEegS8zYuHeNx7TuMEDqi6UEJTP22Bkcl V91HbChCSl4= =JSuC -END PGP SIGNATURE-
Bug#4156: rpncalc has unexecutable unwriteable /usr/man, /usr/man/man1
Package: rpncalc Version: 1.1-1 Directories must be 755 root.root. Ian. chiark:~/junk dpkg --contents /csunix-export1/debian/unstable/binary-i386/math/rpncalc_1.1-1.deb drwxr-xr-x root/root 0 Jul 23 23:00 1996 ./ drwxr-xr-x root/root 0 Jul 23 23:00 1996 usr/ drwxr-xr-x root/root 0 Jul 23 23:00 1996 usr/bin/ -rwxr-xr-x root/root 15792 Jul 23 23:00 1996 usr/bin/rpncalc drw-r--r-- root/root 0 Jul 23 23:00 1996 usr/man/ drw-r--r-- root/root 0 Jul 23 23:00 1996 usr/man/man1/ -rw-r--r-- root/root 2485 Jul 23 23:00 1996 usr/man/man1/rpncalc.1 drwxr-xr-x root/root 0 Jul 23 23:00 1996 usr/doc/ drwxr-xr-x root/root 0 Jul 23 23:00 1996 usr/doc/copyright/ -rw-r--r-- root/root 1695 Jul 23 23:00 1996 usr/doc/copyright/rpncalc chiark:~/junk
Bug#4049: access permissions for sysklogd
Martin Schulze writes (Bug#4049: access permissions for sysklogd): Good morning Daniel! }/sbin/klogd and /sbin/syslogd should be 755. Why? I don't see any reason they should be executable by everyone. I have copied those permissions from my predecessor and I agree to them. Please see the policy manual. All binaries should be executable by everyone unless they're set-id, and even then they should be readable. Ian.
Bug#4175: util-linux has file /usr/doc/copyright/debian.copyright
Package: util-linux Version: 2.5-4 dpkg - warning, overriding problem because --force enabled: trying to overwrite `/usr/doc/copyright/debian.copyright', which is also in package util-linux
Bug#4188: ldd never gives non-zero exit status
Package: ldso Version: 1.7.14-4 -chiark:~ ldd /bin/ls libc.so.5 = /lib/libc.so.5.2.18 -chiark:~ echo $? 0 -chiark:~ ldd /bin/true ldd: /bin/true is not a.out or ELF -chiark:~ echo $? 0 -chiark:~ ldd /dev/null ldd: can't read header from /dev/null -chiark:~ echo $? 0 -chiark:~ ldd /spong ldd: can't open /spong (No such file or directory) -chiark:~ echo $? 0 -chiark:~ ldd usage: ldd [-vVdr] prog ... -chiark:~ echo $? 0 -chiark:~
Re: New source format and related issues...
Michael Alan Dorman writes (New source format and related issues...): ... I've looked at the docs, I've examined hello and dpkg, and I'll be damned if I can find any information that would allow me to actually reproduce the files that were uploaded to master, and assuming that dpkg was in fact build with the utilties it includes, this is annoying. Both dpkg and hello were built with those utilities. My first problem stems from the simple fact that the new process of building a package isn't terribly well documented in the programmers manual---it devotes a whole sentence to saying Look at dpkg-source(1). Since I missed that sentence, I was baffled for a while. I'll see what I can do about this. This was compounded by the fact that, since the 'source' target is still listed in the .PHONY target, when you do 'debian/rules source', you get Nothing to do for target source, rather than Don't know how to make source, or even better, Source is an obsolete target, please use dpkg-source. This will be fixed in the next hello package. Anyways, I finally figured out that I had to invoke dpkg-source. So I tried dpkg-source, and here's what I get: dpkg-source: building hello in hello_1.3.orig.tar.gz tar: Cowardly refusing to create an empty archive Try `tar --help' for more information. dpkg-source: failure: tar gave error exit status 2 Since I had both appropriate hello-1.3 and hello-1.3.orig directories, I figured maybe I was doing something wrong in invoking dpkg-source, so I looked around a little more and found dpkg-buildpackage. After figuring out that it needs to be run from within the debian source directory, I ran it, and lo and behold, it has the same problem with dpkg-source that I do. Well, all I can say is that it doesn't do this for me. Can you send me, privately, (a) what command line you're invoking dpkg-source with (b) the output of `find -ls' in the directory where you're invoking it ? So, I've got the tools, but I can't get them to work, and furthermore, most of them aren't even mentioned in the draft programmers manual that goes to great lengths to document the files and requirements and so forth, without ever really discussing the the tools, or how to use them. The tools are documented in the manpage. Have you read the manpage ? I'll try to put some less reference-oriented documentation in the programmers' manual. ... Also, on the subject of our available examples: I think the debian/rules file in the hello source package makes at least 1 poor decisions in how certain things should be implemented---and given that prospective maintainers are often pointed in its direction, I think we should take care of these before immortalizing them. If you send me good patches to hello I'll integrate and release them. I'm not going to defer the release of the new source format because the examples aren't ideal. ... It would also be nice if we could produce some simple tools that would help take care of some of the small administrative headaches automatically---say, a tool that would look through the debian directory and install all appropriate files into the DEBIAN directory, running them through any appropriate filters. `cp' ? Another useful tool would go through the temporary directory structure and assign permissions and ownerships. Certains parts of the tree (*/bin, */man, you get the idea) would have defaults associated with them (0755, for */bin, 0644, for */man, root.root owning everything, etc). The package maintainer would then need only supply the program with a list of the exceptions (along with correct perms and ownership), and the rules file then could just execute _that_ command with su -c, since nothing else would need that access (well, the clean command might). Feel free to write this command. I don't have time, I'm afraid. Now I know that there are always situations in which this just wouldn't work, and that's fine---there's nothing that stops a rules file from overriding parts of this when necessary. The important thing is that tools like this would make the creation of 90%+ package that much more automated, and most likely that much more free of the little bugs that clutter up the bug system. Yes. Ian.
Perl `pod' documentation should be in /usr/doc or not installed
Package: perl Version: 5.003-2 This package contains some documents in a Perl-specific documentation format called `pod'. These files are installed in /usr/lib/perl5, eg /usr/lib/perl5/POSIX.pod oor /usr/lib/perl5/pod/perlop.pod. They should be somewhere in /usr/doc, or (since they're distributed in manpage form in /usr/man too) not installed in the package. Ian.
dpkg-1.3.6, hello-1.3-10: new shared library scheme
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-
Bug#4223: Mosaic looks bad on mono display
Package: mosaic
Version: 2.7b5-2
When I run Mosaic on a mono X terminal the 3d button borders and so
forth are not highlighted or coloured correctly, making them difficult
to see and use.
Below are two xwd files, one created by Debian's Mosaic 2.7b5-2 and
one by an OSF/1 installation of Mosaic 2.7b4 on a local system here.
Both were displaying on a monochrome X terminal with no X resources
loaded into the server and no Mosaic-related environment variables
except WWW_HOME.
I'd like Debian's Mosaic to produce a display like the OSF/1 2.7b4.
I enclose a copy of the /usr/lib/X11/app-defaults/Mosaic file from the
OSF/1 installation.
Thanks,
Ian.
begin 664 debian-mosaic-2.7b5-2.xwd.gz
M'XL(`'(^S(`^S?W`;57X`#DN=H+E-+\Z0L(D3Z/3H+1-+$;)PM#
M;X`6R,TPZ1WEAQ,+!C`BB.P'3Y.9.#H.QR)EIHHF(.D/+3H88*C(JR
M[EMAIL PROTECTED]`YD%=K1T:)/9*%O9*WGWO];VG'[$=_XAMW1V]T[86CVM/GYO
M][WOOK[7HU\TN-1E-$?I:0GP+RTDQ^3FNN36LFO)+/-3_57#\5I+^_9,+W
MZ?N5],,'[W[HKC4_7_.`P;C[ZHU=VS\L3?K7GDOMVU:_YQ=_4S1D/M!N.:
MPW//;GFI[OU3SXV`2UB,F93D09_OR08X_+XOUN^@UJ$_:FDI)I9PFIV
M/7]D;JL2QZD7U]$W7A7T3O22=.=3+\G-UW/0-_$D0*GD,L5];ADUK/D)D
M7M+61;]F*QGVF`+.U=$1\\M_MVHG(5=9=VW[[\)9+88CS*5INM*A_OLB68
M9Z/*IV^QNC2\_7C.SI]ME)WAP5),5NH]OC5[IVMMJLGFU5G'@'NQTT[^L
MVZ#OI47=T[1OO=_O8Y[^P5[55D$2-[2WVY)S,WV5NJI/@_U?.VZ#9$825Y?
[EMAIL PROTECTED]/M:M.GHN-$=5\7M\S+L?,_6KHM$J*?3MMKPC3Z
M'*5Y]M%,ZWH_^N?P]N!?,FLU]C;0S-(O!451]HWT4LG(PB#UC.X)WIO
MR`--+^K6GPVFRY.DATVKZU,IR=_)-YCT^GT8;J3DKY*8WAVSZO4FE7CA*
MWG5M.%YA-R:HMS92L6_/LP\8T.;CU:BY.KM\@7F3OG2M_4ZJL/%M=[(
MA'@PD?`G%^;%9_TZL(]KIGM'$TB8VE0YN/B5NLJ'D.K+CY_T,\+=3D=BK(
ML8?ST[Q;62*WGA_^WKQ8+KR.!_:EFRCPY,+;U/E!.H?U#9.#LBOI4)!ZI.
M:\%AYLG0N5G-Q!+VH6G-LDK%TU%;[EMAIL PROTECTED]:PLX6P*0/3M(7VCJ684J-
M5I'\:@E4W(^]!TGLTC!/RBGLR351.S_3[AME'G^9'[EMAIL PROTECTED]P)Q:
[EMAIL PROTECTED](K]DMO!/8AV[5GS)5[5*/B]`*$5AQOB_FP9[F(%8.55
M1/S/G7,?``JRX=?YMC`]J5#7Z7YNUL3Q07-S/O!)WAI\\L%NTYT$V
MVA\[1\%.B-N9AW#7-;S9/+W;YW?SNK]EOPTI^H+C_FWQ_%_CZ]E5LM3?%(
M_DY^,;MWG%3E_E1]YG'5Q`\]CGNX1)DQZ(NKWQ]_AU0,Z5M58^/)YAO'
MXV]33]NM06I2OCY_WGO(LQE:]1.``'B7N*^SGB(3C)(T?BI!:APMF]7Q,O
M6^/?021_[ZT!Y%ZW/DY+X+SY!R#S[]NM`M`M01-LFCW]F@!\J-LA8Q
MV5LYBLKU+D\,DPEXPU-E'D=E\?Q;RZ3[\!)GCS*%7KF]0:1G\3`/
M?`[!SE'`]C^--)WLKO1#(,F6/[8?DT\;2:=+1ZF[0/A-NQRC5HD(DC?VCY
MA/P5DTHYQ_Y-[EMAIL PROTECTED]/2/O`Q,/,\^.L1]K;AJ1$=MT-`Y41%L7C0=X_QE
MVGX1MU#.F+,NXMX-!Y(-^293B%.+2RD39AX8+1JE,47DC^\9%`M9S\1EK
M+M,;,(NA$/GEU+HR2-IY=YQ.(?U^#!CE2@(A[9+3OR21_^`;*Q)GS-1
M5Z[+#YSFFP'DGILOI)Y$]`/#!7?0$CS06:B?U/;M*Q#F0^$[6D6A5JHG-T
M31'NUWAF68O3],_CBF1L[A6;WY3_3XT9]#3YMC#WS_/^!''LWTMNYX8EX
MMR1S(@UDO+VYJ8`WI[WFZ!.O!?45`?[EMAIL PROTECTED])]Y-`^D.4*SG'@?6UD7E,2W
MW'B6[EMAIL PROTECTED]/XX/1[EQH-880A.4?36O6CTY,C;92=S#A-.-=
M661Y9191$3Z8.:`LKKQ+Q])+79AS%/C)42?U%L$)[3']AY340A/-!CNZ7C_]
MM2;CG2512_%S!4KGG2#!Z,\3.7EQU[/3;WTOS1SV`T?4O':7QT6I_5^
M\I??88[UQ_N9Y\`7RG=YPN1+PPGA+LDKU]7,'1+JR,($4'7CC(B6MC;
M;R;7OH.:[EMAIL PROTECTED])X8`B',)N4OPC^PY,9*/0XZI!_6LA'
MK2(THSE9/(PFAZ?QR1H7(ZXR)?Z,88F,%4X2#XA).*MW\Y!,6YN#AO3
MVX]X9[#(=_Q+YV7F:?O#_QNH%H:[EMAIL PROTECTED];VZ.4R\I=1#:_5$\2
[EMAIL PROTECTED]'Q!E(X:.63U67GH=JAE/RI\DBFZS/-$SU_-BW(`AD(`((1Q6IM\?MX^E
MRDL.'Z7[5_B!:[EMAIL PROTECTED][-$W-*)L3..3BD(+;-ZVUKDS+@X_[D\J,D
M?R%OOR1+S.N21WI9V/P:)?D'[EMAIL PROTECTED]/@S+P9G+*]V4G/;A=$^Z+73+$
M%?#,'CIKW$EM?KL':A9AN;1='O+3_DI/_TAIYR;/?DV.N?$DV%Y/'DWN/
M([U+44GU`!`+LQJ9O0.I=7@:5+.1UBN)F!N?RL_JV(2RD%K:W,$P7:'TYY
M6U/K.##V9ZZF`5P1$;'X(59F\6A45[`Y%=X%G.U(F:_/'\`6LB2Y9O*B7=1[
MK#)XZZ7=L5.K\0H,8T\B:(HE6JK:2(I:UUKWH=?[6C;8N_?=)]2RU2T,1B2
MMT#B9D]J?6BX)+--2N'FNHQ'#X*W;H:V66M)REP.+CQ-R[7;X6PR?64826L
MQ:C7)SAXDWGZ(WO2[Q^(4]#J,QK!%%.`!4XLB:2`L3'#;S%%7QDMV6
M#BFWK!P!IPVN6;Q),'9U;,F]XK0FW,YLV1;VBEJ0`\;E=O,4:O%.R'H;
MW\/5S,,N[=;I1Y*JGVX_X9A`O`Y)KU0ZD%3!^9%/4DA'N`M)X)-$H#P)(^?
M37E.O0O/[EMAIL PROTECTED]/1M+O`+6^39(*PDR?EM4CEIFL%#8LK[G0*?
M,[EMAIL PROTECTED]/V!_4,[EMAIL PROTECTED],)QZ.U_*N8ZUM]X%]SOQ[EMAIL
PROTECTED]8+?M?EIYXPAPZ5
MO1R#6[I+M.!UG(@=2B36=B?.6W=L[B[!,;FLU+N!U)[EMAIL PROTECTED]
MQ]BI5I(IOWFZDQ;CU-)[EMAIL PROTECTED]:$C?LX1SG+^_EO;R7]_)WOLC
M]RR)63^*'O*(;)8;W4QF=G-?5PN/+#:08IZ^'VANL'RI/6P_XG!4'11
M^^/'8W0^5]XUQTCPJWA#WWC7`]T?KM3%=3I=Q'_NBAO]PB=O9Y0)1O
MI)[EMAIL PROTECTED]K.DB\N.Y$Q*?%N49$W0^UAAFGC?B:XPORHNK=Y_^*WS7]
M3H[X'AY9E=#.I\/W9LH;#MN3N0]7)'+;?(I3;*#DV#/G.%ZU?-_B7][[
MT_5R?3XL[^6]O)?W)GI=XC'_X[9-#4:6!Z%5#$/+9:V6DR$:=3$02I:^*C
MK#+%2SR4R_1T_.GLH-S8/8?%C;[EMAIL PROTECTED].JF`_
MGSWS=:V\087G^53^4#9_9$*\Q!*D_-'ED8SJXGX^OP1[]27_-E96.GU.UH
M;^5[\?QN-]'X0D$.78C'P\\I4:NC2MC.WZ6-MWNB/I+H*DFN#/*O_,I[
M:(KWAGE+`#_E-)M66D2+,_`3ETW\^-GHP($LN`;'L;'+Z92A:NN]907^^
M--7Y$#P.H^R82YCBOMV7L`6I]GI!*)%#`RYW=+0:-`=A'A+Q*Q,$K
MJ50A.0T:07W1:YUB2A$!`X,UN]Y6IWK;W+F!8Y]SR'@!J2-5ZZ^2CP/
MQ-#+O!^D4KW!F_OJ#-(22+Q=@0$0!_Q#LA3O?/,E?O=/)`P\X!B;DEZ
M3G0CXEU,Y0^SU(O!([EMAIL PROTECTED],:I!VAP$'S!Z][SEYB_PV\43+!9%YKZ:\='D!
M2R7EE6JIYR830B(TWIRTY:[EMAIL PROTECTED]/[EMAIL PROTECTED];G%H5'0+`H8/!('X5!
MTM]X*HP].P]8_6N3GFX5B0)KL#O/[EMAIL PROTECTED]#DT,J$2O'W__LJSWA*N
MUE;22B($S]LC[EMAIL PROTECTED]NJ_I^R[22AKO)E;=E;WD-PQO:;
Bug#4225: lynx fails to substitute %XX in mailto: URLs
Package: lynx Version: 2.4-FM-960316-1 See the page URL:http://chiark.chu.cam.ac.uk/~ijackson/bad-mailto.html (a copy of the page is included below). If you load this page in lynx and select the `spong' you will enter a dialogue offering to send mail to `ijackson%40chiark.chu.cam.ac.uk', and if you accept this it does actually send mail to the address with the %40 untranslated. The same problem happens if you try to use the LINK REV=MADE ... to send a comment to the document author (ie, press the `c' key). According to RFC1738 URL's may be encoded in this way, and in fact it advises that they must be so encoded if they contain certain characters. For example, the quote character must be quoted if it appears in a local-part of an email address to stop it from being interpreted as the end of the URL's delimiter in the surrounding hypertext. Ian. htmlhead link rev=made href=mailto:ijackson%40chiark.chu.cam.ac.uk; titletest page/title /headbody h1testing 1 2 3/h1 A href=mailto:ijackson%40chiark.chu.cam.ac.uk;spong/A /body/html
Bug#4224: Mosaic produces poor rendering of nested markup
Package: mosaic Version: 2.7b5-2 See the page URL:http://chiark.chu.cam.ac.uk/~ijackson/nested-markup.html (a copy of the page and an xwd of the output produced by 2.7b5 on my mono display is included below). As you can see: * strong doesn't work correctly inside var - it overrides the italics produced by var. * var inside a code fails to go back to the ordinary proportional font from the fixed one produced by code. * strong and headings like h1 fails to work properly with code and var elements inside them - the code and var go back to ordinary sized not-bold text. * The typographic markups i and tt work correctly, as does em inside code. Ian. htmlhead link rev=made href=mailto:[EMAIL PROTECTED] titletest page/title /headbody h1testing 1 2 3/h1 A href=mailto:[EMAIL PROTECTED]spong/A h1testing spong/h1 The varvar strongstrong-var/strong var/var.br Should be: times italic, times italic bold p The codecode varvar-code/var code/code.br Should be: courier, times italic p The codecode emem-code/em code/code.br Should be: courier, courier italic p The strongstrong codecode-strong/code strong/strong.br Should be: times bold, courier bold p The strongstrong varvar-strong/var strong/strong.br Should be: times bold, times italic bold p The ii-tt/i tt/tt.br Should be: courier, courier italic p The ii -i/tt i/i.br Should be: times italic, courier italic h1The codecode/code and varvar/var in the heading/h1 Should be: large times bold, large courier bold, large times italic bold. /body/html begin 664 mosaic-2.7b5-2-nested-markup.xwd.gz M'XL(`+I%S(`^V=#W`;57['5Q$7T'U!FB+71QO0AAGE..).XE-C$1+0P M,T?E,FDG`EPZQ$KB4%.*MOKG)D89ES[.,^5:[EMAIL PROTECTED]RO M788$\6^7J=PJ;#71CF[W,58%7ROYY?6__R+)CY'CWP3'A[=C2:B5]]=G? MV_?;][[2TM1U',41;[EMAIL PROTECTED]_F](7^)A:L^#^4KJQ6\?T7^VGX M_VWTY/;['_OK-7^WYA%/];X?EJ_9])TM3WYWSYGGJI^9LW!?95//9$AX]*T [EMAIL PROTECTED]:XJ)V8%X!Y8'7_GF\?5]']TF69#0'P?YAIPIU^4F%I:J`R,(+Z1,'H0 M=:O5F7H!N*8BO8\+#T`1E+:;4`U=KU5HT)ZBM%[\FO0#B_@'T-O\MS M'VJ:[D'1];?CP'JLH=+0\=S]FP#VZ,[77I9E48\.^!E-R8]N3X0G*XJ+ MX=IW*G84E17PL]*=`MI7X4C]^A[279=7SGQB!?,?:2E'H7PQ?FJQNUI4 MOWU_(ELZ4TKG;[.^#2T-#_L`2H[2C2B`[F*G=CL4OC35C?O'P^'IU8 MA-()?WCR\)'B8_#I\(G\6PSZ\D)9S'BV]B-3W_4'AJ[EMAIL PROTECTED] M8BYT.VU.))?0^9=%.7K;JML0(-0[V/')T6T!J;\8;BR'ND-WRH_6'TM MJQ:K[FCV^\-P_^64/^IO#D_#QEI\X?#DY6HD`+%9.5V?52DQ7[X$K M]94T?#1PZ6A'Z3#],Y.=6PO.@@TO'0\7H(`J4U([02^A-YYGY^KOO`-V MQ%K5G?HB43`FMY(1G[)U$NZ+L!63LUR11C:E'IC^C+C-BX8PFQF(./[X6 MRY?:/L!4!(:]F]/7M.2K98Q/FJN0P^5H(W,-2=UF6!)=;7!]^R;VUF= M3W7BX/OLU%TH;RPC@`_$=Z*M?::NH?YX3SWM%HUHO$-]D`V0DXF99@ MED!$4*\;WG`Y6*4U$!E2V#B70?0'6IKP(*:[EMAIL PROTECTED]))[EMAIL PROTECTED]@_S%T4XI.I M%2S4`X(7YKMD*BYZP`G0C:*.K(*U$E`=O7L`5)L+^C=ZY3`,=#MCB^7HKR M(;[?W2Q(%OCKY9!*,RKC7V$5^,5G\.6P`Q5KT/16U07K,*#@[`!`?+X%_ M.!58LGXTZ'[EMAIL PROTECTED]POB^T^*YAH6OQ^=9.TU]4M410RP% M)8'6J/5DQP82KI5A;G0(WLC@H!QJ)M\/3[V4E\,Y'/HQTN=)#L8[MD] MTI#MU4N$=-\3I/OP(]RLIW%![*+OUX5D!L):/^\N@[EMAIL PROTECTED];(#4%J/A9D MY5/#0)1IO;[527V%#+=GIP3UWBZG?.Z`[EMAIL PROTECTED].7U$-=0S*G2M,5 MCG%LMP\/[EMAIL PROTECTED]:;^07J7O^QP?UNB$?Q_*PGYGF$P/HS?Y MV+'L\?N14V`[EMAIL PROTECTED]'M4/D^__.L*^[LBP\ED78WZ!0 M.LD6![[EMAIL PROTECTED]:H6/9[E,/JSN\^Y=2D^06[EMAIL PROTECTED];JI7O M,P*F7QW2[`;LD3\@'!O39)-:IUJ6#\H6#]8:0BXNPLIWXS,=E,;,OA.PX-R MB?*%I`O1E%FLT%IYLA'@74NQ,`B:6#3H?3%V7`B*0W4L[EMAIL PROTECTED] M2XSNV87J+]N=2_D^;P6([\0#X81EF\0R$ORS:QF97=?'ZK,+_(KBN=6GZ! M?.`S%JB03X65GY`[7C,RS2_'-K*Z1N:S*$M/N#J8;7\UUWHE!G#H%! M/5C,6V%H()]T#?%3F8^,[EMAIL PROTECTED]:?I:I=`,2ZLE:?U4400I6XZ;L\5-JU!V. M!O3V]/D-G3_FSFA03W\DO4TYI3Z*7J)IR@(7YSR*IER+:/](JHUX`5=#\/Y MUVA?(ZL(8_LJJMAXU.Q\:%FZ2Z,FD^YS,\4-ZU]+:N8%ZCT?P,+7I+5/ MH5XNC87LM,'GH-=CX?N%_$U4$[F)2Q\KS;I;4^*.8^%[[4XXNNC*#./0'T M%K!Z!68GL/]ZH3M4X#.1Q-8^#C`:XUQ!\#$=\,$:5,)R:^D_DCKOTB_34 M91WGL!@H/X';`_U?\%+N7QO;K78ZP/`#G5D$AG3):34@YP(F9M/`DK:C: MJ3IM.CKDO[1[+]1'N/UC5OHQH]P_'+T.,R]5#Y@!HYUXGU'LEK:?JV?]J M/6F.204+]0#[+S?+I:]REZ:6`5+#260E?6[NUD*'?Z0%O[*H*GI%(C) M;F56E,!$+%F_6G`-OJ%KBTK[EMAIL PROTECTED]@X`^.W[VZ01(V_)*WM;PI M'XW:*B2O\[PHO_@+!M]H%X)-^H/5V9AZ'][9DDT+_H?Q^:[EMAIL PROTECTED]@ MB/W'W3VS0=IEZ_F-O711GFD!(Z_%^J)*8%'3:K.1$2`N]D%.WM`F7%8:@7 M4GI!W2O*5#`J4Z$/2G6S/A`0P.F@@H;A;[EMAIL PROTECTED]!?7CI% MI-?8!6)(SRUT*6IRJ\PR=;V2+J`[776-40.^I+*K(3B=[H2\NU%NS5F,B M%S3T?%U`T/B$=R!Z2.FD%X0!`HB'A\D$\RRS=VG_XM4J:*.EZ(:0WDM:; M%'[EMAIL PROTECTED]:\(]013KV=2XWLUQR-J^PNKE5JME2_4\XFB)$6$L2FN1PH+W9R MONHN:;'UWX@:GKW3L]((:@70N7Q#HA4^:2//A`%R-](1CN'^J!S;D0[W! MJ$L41'FKP.=SO=+;-1]YN*;F+BGX:[?#+M=,'[EMAIL PROTECTED])[EMAIL PROTECTED]@LBA M=FEF,RUPOEJQ\O9J'X!?67,RL'JJWS$H[EMAIL PROTECTED]([EMAIL PROTECTED](VR8 MB@;Z21\J?X:X/1MCQI8^D$9,'9BL:X.#'KN3*_DL6PB`X'[EMAIL PROTECTED] MO'RN1KQ\KGZ\?/0`7K[;)O#R,5\?$P[EMAIL PROTECTED]'ROAY6,5O'RX\PN% M.;_LW(67#V.'PL(WS!#_VT)0Z:5`83']*;`$Z9QL''`17I'5/W24TX^-Q` M_XF5@#/CDW()5:_.2=!QL!4#GUKV\(EX0SF#]!@,?K)[^)-R.]A$KC MXNY\8BN-P6:L/#))5#/'0C8``+GYH7;SX(H_?R%_1*E\LG0;UJJ%:FL+! M]Y/GWBC:\[KCJ2(SCJ1V%V=X;UM!]]0Z9P99?HJTX\PL`4R-X\U\T@)O MYL;+1\YOA(_P$3[1_@(7U:^6XX,36#D4R]NVG\(Y_JU:-XHS?UF#5!9SQ
Bug#4226: Mosaic fails to substitute %XX in mailto: URLs
Package: mosaic Version: 2.7b5-2 See the page URL:http://chiark.chu.cam.ac.uk/~ijackson/bad-mailto.html (a copy of the page is included below). If you load this page in Mosaic and click on the `spong' URL you will see a dialogue box offering to send mail to `ijackson%40chiark.chu.cam.ac.uk', and if you accept this it does actually send mail to the address with the %40 untranslated. According to RFC1738 URL's may be encoded in this way, and in fact it advises that they must be so encoded if they contain certain characters. For example, the quote character must be quoted if it appears in a local-part of an email address to stop it from being interpreted as the end of the URL's delimiter in the surrounding hypertext. Ian. htmlhead link rev=made href=mailto:ijackson%40chiark.chu.cam.ac.uk; titletest page/title /headbody h1testing 1 2 3/h1 A href=mailto:ijackson%40chiark.chu.cam.ac.uk;spong/A /body/html
`binary' target and per-architecture rebuilding
In order to solve some tricky problems to do with architecture-independent files being produced and uploaded as a result of per-architecture porting builds, I'm splitting the `binary' target into two: binary-arch will build the architecture dependent binary packages and files. For a straightforward architecture-dependent package this is usually all the work. binary-indep will build architecture-independent binary packages and files. For a completely architecture-independent package this is all the work. binary will remain, and simply do one and then the other. Ian.
Consensus is for compressed manpages
Further to this discussion, I'm going to write into the policy manual that manpages should be installed compressed using gzip -9. Ian.
copyright files in /usr/doc/package/copyright
Since we need closure on this I'm mandating this change in the new policy manual and source package format. I'll also mandate that the debian/changelog file be included, in /usr/doc/package/changelog.Debian.gz, or changelog.gz for a package whose upstream and Debian maintainers are the same. Ian.
Re: Documentation formats
Mark Eichin writes (Re: Documentation formats): [Ian asked:] (Is texi2html any good?) http://www.cygnus.com/ (and I'm sure other places) has texi2html'ed versions of gnu compiler-related tools, if you want a quick look at them. Thanks. They do look reasonable. Ian.
Re: CC's on this mailing list
Dale Scheetz writes (Re: CC's on this mailing list): ... However, there are several people who post to the lists, but don't read them, who ask to be responded to directly. Maybe we should just require that these people suffer reading the lists like the rest of us? Yes. It is rude to post to a mailing list or newsgroup that you don't read (except certain closed lists that operate more like aliases, eg [EMAIL PROTECTED] which forwards to debian-private or [EMAIL PROTECTED]). Ian.
Re: Documentation formats
Mark Eichin writes (Re: Documentation formats): if we standardize the names for the alternate formats, can we also have, for each format foo, a virtual foo-viewer package, and include it in the dependencies? (That will, as a side effect, make it easier to determine which formats are supported in a given package...) It looks like we don't have a consensus or indeed a technical basis for a decision on documentation formats, so we'll keep the current ad-hoc arrangements for the moment. When we go for a more formalised scheme this sounds like a good idea. Ian.
Re: New virtual package names.
Dale Scheetz writes (Re: New virtual package names. ): On Fri, 9 Aug 1996, Ian Jackson wrote: ... Noone is going to deinstall all the editors on their system and not notice what they've done wrong and how to fix it - this is not the kind of `mistake' our dependency scheme should try to address. It was my understanding that this was EXACTLY what dependancies were designed for; Protecting the installer from removing functionality that other packages need. Surely this is only useful if this is a mistake the user will be likely to make, and then not know how to undo ? The only possible consequences of creating an `editor' virtual package and having things depend on it are: * Needless updates to packages to add dependencies and Provides This is not a technical argument. It is an economic one, and should not be listed as a primary point. (all change takes work) Your assertion that it is needless is not yet backed up by technical arguments. In addition, the modification of other editor packages to encorporate this new VPN are not on any critical path, so they can happen as need arrises. I can't prove that it's needless. You're shifting the burden of proof. It's up to you to show that it's needed. * Some person installs their own favourite editor in /usr/local and wants to remove all ours but can't. This is true for any package that has others that depend on it. If I want to put a qmail of my own into /usr/local, I will still need to keep some Debian mail-delivery-agent installed to satisfy other packages dependance on an MDA. A way to tell dpkg about non-package provides would fix this problem in general, but I don't necessarily think that it is needed, or even desirable. The difference is that an editor is such a fundamental and striaghtforward thing that it will be obvious to the user what they're doing without the dependency scheme having to tell them. You're using a sledgehammer to crack a probably-nonexistent nut. Ian.
Re: New package standards - LAST CALL
Michael Alan Dorman writes (Re: New package standards - LAST CALL ): In message [EMAIL PROTECTED], Ian Jackson writes: Therefore I propose that unless someone raises a serious problem or issue within the next week or two the new packaging guidelines as described in the draft dpkg programmers' manual, the draft Debian policy manual and as implemented by dpkg 1.3.x, will become official. I hate to even ask this, since if we want to make this change for the next release, but can we have just a bit more time? I have been singularly busy of late, and have only recently gotten to the point of being able to read the new docs you put up, and while everything seems sensible on paper, I worry that it we don't have people actually try it out, there's going to be some unexpected problems. I've tried very hard to leave hooks all over the place, especially in the parts where the new scheme is more automatic than the old. It won't be a disaster if we don't get everything converted. * Automation of the generation of .changes files from information in a parseable changelog and elsewhere. I have installed the changelog macros, and find they work well. Thanks. Finally, though you say the documents are just cut-n-paste from other stuff, they seem to do a better job of documenting some of the conventions that we've adopted over the last several months, WRT shared libraryies and the rest. Good. And if you're creating them from your linuxdoc-sgml hack, I'm quite interested that you make it available for others use. It seems much cleaner than the original. Or maybe that's just a function of a better conversion tool. :-). The better conversion tool helps. But having a DTD that only describes things that are actually implemented helps too. Ian.
Re: $(ARCH)-debian-linux-gnu
Erick Branderhorst writes ($(ARCH)-debian-linux-gnu): Should we use $(ARCH)-debian-linux-gnu as parameter for ./configure and $(ARCH)-debian-linux? If so can it specified in the guidelines. If not what should we use? $(ARCH)-debian-linux, but $(ARCH) should usually be 486, shouldn't it ? I don't know what the $(ARCH) parameter changes with GNU software, when you vary it between 386, 486, 586, c. When this is settled please remind me to mention this in the policy manual. Ian.
Re: Non-existent .deb's
Daniel Lynes writes (Non-existent .deb's): Just a thought, but I was wondering if perhaps the dselect program could be modified to allow for it to not allow you to be able to select .deb archives that are non-existent? I've noticed that for the .deb archives that I haven't downloaded, the only way I know that they're not there, is that their names don't show up during execution of the installation script. Perhaps you could have a warning in the dselect windowed interface that gives you an error if you try to install a non-existent package? If you delete the `Packages' files, or fail to download them, dselect will offer to scan the .deb files that are actually on your disk. Also, in the matter of gs(?), the dselect program does not state that X11-R6 is required to be installed; it states that svgalib can also be used. However, in the list of dependencies (brought up by the 'i'nfo command, it states that X11-R6 _IS_ required.) When installing it, it fails, giving the reason that the Xlib library is not installed. So, can you use it without Xlib, and instead use svgalib? i.e. Do I need to do a dpkg-deb, and force it to install, ignoring dependencies? No, that won't work. You can use dpkg --force-depends --install to see it if you don't believe me. Install xlib. Ian.
Bruce - fiat required to end discussion on lyx/copyright ?
prohibited' and `distribution restricted'. Every package submission *must* be accompanied by verbatim copy of its copyright (with the exceptions of public domain packages and those covered by the UCB BSD licence or the GNU GPL or LGPL; in these cases simply indicate which is appropriate). This information must be included in a file installed by the binary package - see subsection 3.2.6, ``/usr/doc/package/copyright''. -- Ian Jackson, at home. [EMAIL PROTECTED] + 44 1223 3 31579 General: [EMAIL PROTECTED]Permanent: [EMAIL PROTECTED] Churchill College, Cambridge, CB3 0DS. http://www.cl.cam.ac.uk/users/iwj10/
Re: New source format and related issues...
I wrote: Michael Alan Dorman writes (New source format and related issues...): ... dpkg-source: building hello in hello_1.3.orig.tar.gz tar: Cowardly refusing to create an empty archive Try `tar --help' for more information. dpkg-source: failure: tar gave error exit status 2 ... Well, all I can say is that it doesn't do this for me. Can you tell me whether 1.3.6 fixes it ? This looks like it might be the argument parsing bug in tar that Bruce reported. 1.3.6 has a workaround. Ian.
Re: Bug#4129: dselect 1.3.0 infelicity
Bruce Perens writes (Bug#4129: dselect 1.3.0 infelicity): If I position the selection bar on All Brokenly Installed Packages and press the - key, _all_ packages are de-selected, not just the brokenly installed ones. This is counter-intuitive. `counter-intuitive' ?! You're a master of understatement. It's bloody awful. My apologies. I've fixed this in my working source tree for 1.3.7. I'm going to release a 1.2.14 with it. Ian.
Bug#4229: /etc/init.d/skeleton is missing `set -e'
Package: sysvinit Version: 2.64-1 The file /etc/init.d/skeleton should use `set -e' as this is good practice and it is an example script. Ian.
Bug#4230: /etc/init.d/network is an auto-handled conffile
Package: sysvinit Version: 2.64-1 The file /etc/init.d/network is a dpkg-handled conffile, despite containing important site-specific configuration information which is set up by the base disks. Files manipulated by installation scripts should not be dpkg-handled conffiles. Ian.
Bug#3838: GCC should depend on CPP, not conflict with it
David Engel writes (Re: Bug#3838: GCC should depend on CPP, not conflict with it): Ian Jackson writes: David Engel writes (Re: Bug#3838: GCC should depend on CPP, not conflict with it): ... Because they're designed to work together. That's why the FSF includes cpp with gcc instead of packaging it separately. This doesn't much sense to me, at least not without more detail. Why do gcc and cpp need to know each other's particular versions ? cpp, cc1, cc1plus, etc., together comprise what we loosely call gcc. They work together as a closely matched set, and consequently, need to stay exactly in sync in much the same way that dpkg and dselect need to stay exactly in sync. I'm sorry to say that I still don't understand. You haven't, as far as I can see, actually explained what complicated dependencies cpp and cc1 and the compiler driver gcc have on each other - you've just restated the claim that they have such complicated dependencies. For example, if I were asked whether one version of dpkg could work with a different version of dselect I'd say: mostly yes, but sometimes I change the format of some files in /var/lib/dpkg or occasionally I introduce a new option to dpkg for dselect to use and then you would need to upgrade together. Can you give me an answer like that for cpp/gcc/cc1/cc1plus c ? As far as I can tell the hardest thing would be getting the right version numbers into the predefined macros __GCC__ or whatever they are, and this doesn't seem hard to solve. After all, the input and output formats of cpp are defined by the fact that it has to be a C preprocessor accepting and producing valid C. There seems not much scope in the output from cpp for making it tied to a particular cc1 version. In any case, even if this is true it would probably be better to have the two packages depend on exact versions of each other. There are lots of other things that are designed to work together where a bit of version slippage doesn't matter. This isn't one of those cases. I making gcc and cpp conflict with and replace each other in version 2.7.2.1. This should make it easier for users to switch between them. Until I hear a better suggestion that doesn't involve duplicating files, or keeping two packages exactly in sync, I'm going to leave it this way. Please do _not_ make either of these packages Replace the other. This is not what Replaces is for, and in the future dselect will take enough notice of Replaces that this will cause confusion in it and probably in the user. I'm going to reopen this bug for at least this last reason. Ian.
Bug#4051: access permissions for /usr/bin/fdmount
Damn, it looks like my comment Before anyone changes anything, please read the appropriate part of the new policy manual. went unheeded. I see that the change that Daniel Quinlan requested has been made. It's a shame that I didn't get around to writing this more detailed response to the situation sooner. Daniel Quinlan writes (Re: Bug#4051: access permissions for /usr/bin/fdmount): ... Michael Meskes [EMAIL PROTECTED] writes: I agree that the installation is not correct, but I doubt mode 4755 is a solution. I for one don't like the idea that everyone is able to access my floppy drive. Since the Debian standard installation for floppy devices is mode 660 with owner root and group floppy I propose to use the same owner/group combination for fdmount. Any comments before I create a new version? There is nothing wrong with having an executable mode 4754 setuid root, owned by some particular group. This is the right way to solve this problem. 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). The guidelines were ambiguous on this subject. The new policy manual is not. The relevant section, which I wrote before this came up BTW, says that the access control should be done in the way that it was (I presume) being done here before. Compiling names of groups or even worse group ids into binaries is a bad idea. Even worse, it's a `4750' binary in /bin -- so users are getting permission denied errors for something in their path. There is nothing wrong with users getting a `permission denied' message when they try to do something they are not permitted to, surely ? I'm going to reopen this bug report. Sorry, Michael Meskes (but you should have heeded my warning). Sigh, Ian.
Re: New package standards - LAST CALL
Otmar Lendl writes in private email which I'm sure he won't mind me posting: ... What I would appreciate is, that all the Developer Ressources (Guidelines, Hints, Virtual Names, FSSTD co.) have a central WWW page where I can easily look up the currently valid standards. Could you please arrange something like that ? It makes life a LOT easier for part-time packagers. I think this would be a good idea. We already have a central FTP area, so it may be just a matter of writing the HTML page and making the dpkg SGML documentation available. What do I need to do to make the dpkg SGML documentation available ? I can cause releases of the dpkg package to upload formatted versions of the manual, but how should I package these for shipment ? The HTML versions in particular come in many files ... Ian.
Re: installing elisp .el files
Mark Eichin writes (Re: installing elisp .el files): ... Byte-compilation depends much more on *speed* than size. The changelog mode doesn't do enough (I assume) to merit the speed improvement... gnus, for example, really really needs to be byte compiled. mailcrypt, w3, vm, probably all do as well. They also happen to be big, but that's not the main issue, though there's some correlation. Generally, if a package includes an elisp helper file, it probably doesn't need to be byte-compiled. If the package is *written* primarily in emacs, it's probably complex enough that speed is an issue and should be byte compiled. In between it's a convenience issue. Right. I'd like to put that last paragraph in the policy manual, if I may (lightly edited, probably). Is that OK ? It would also be good if something like the GNU people's byte-compilation helper elisp-comp which Erick Branderhorst sent me could be included in some appropriate package, so that packages can just use it at build-time. Let me know if and when this happens so that I can mention it in the policy manual too. Text fragments appreciated, or I might get it wrong. Ian.
manual updates (0.2.1.0)
I propose to post here the changelog entries for the package builders' manuals as and when I release new versions of them. So, here goes: debian-manuals (0.2.1.0) unstable; * Policy says when and how to include original source in upload. * Need -sa on dpkg-genchanges/dpkg-buildpackage when converting. * Use minor patchlevel for meaning changes which don't affect packages. * More verbosity about netiquette. * Reorganised participation and upload policy: merged with mailing lists. -- Ian Jackson [EMAIL PROTECTED] Fri, 23 Aug 1996 12:48:09 +0100 debian-manuals (0.2.0.1) experimental; * Said that system administrators' manual does not exist. -- Ian Jackson [EMAIL PROTECTED] Fri, 23 Aug 1996 04:05:36 +0100
New source package uploads to `unstable' allowed
You may now upload packages in the new source format to `unstable'. Packages in `stable' will continue to be in the old format. Note that the caveats in my release announcement on debian-changes for 1.3.8 apply: * The new source tools have not been very well tested and will have bugs, some probably serious. * The source format is not entirely fixed yet. You may need to make significant changes. You _will_ need to keep up with minor documentation changes and _will_ need to make at least one further release when the format is finalised as the Standards-Version value will be changed. However, building releases is a lot easier now :-) and you don't have to re-upload the original source tarfile part of the source more than once per upstream version. I shall probably declare the new format official on Sunday. Ian.
Bug#4195: dpkg-source and new tar package don't mix
Bruce Perens writes (Bug#4195: dpkg-source and new tar package don't mix): Package: dpkg Version: 1.3.5 The latest iteration of the tar package unfortunately is not able to understand the -- flag. I suggest you not use that flag in dpkg-source for now. Thanks for pointing out what was wrong. I have worked around this in 1.3.6 by removing the `--' argument. However, this will cause dpkg-source to break if the next argument ever starts with a `-' so I do not propose to leave this workaround in permanently. I shall leave this bug report open against dpkg so that I do not forget to change it. Ian.
Re: Bug#4202: dpkg chainsaw massacre
Thomas Koenig writes (Bug#4202: dpkg chainsaw massacre): ... 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. My apologies. I have fixed this in dpkg 1.3.9, which I'll release shortly. It will now only replace a directory hierarchy with a file if the directory hierarchy is from a previous instance of the same package, and isn't anywhere else. You can force it to go ahead anyway with --force-overwrite-dir, but you don't want to :-) (and it's not enabled by default, unlike ordinary --force-overwrite). Ian.
Re: Debian Policy and Dpkg programmer's manuals
Bruce Perens asks me in private email: The policy and dpkg programers documents are very good. Can you get Ray to put these up on our web site ASAP? I'd like to, but I think the web site is all confused. I could be wrong. Does Matt Bailey still exist ? We've been waiting for him for several months now wrt the move of the WWW tree ... Anyway, the SGML source to the manual is in the dpkg source package, and can be converted to whatever format anyone likes using debiandoc-sgml. We just need to decide where to put it and in what format. Ian.
Re: Documentation formats
Lars Wirzenius writes (Re: Documentation formats ): ... I'm not certain that distributing HTML with the packages and other formats separately is a good idea. I think it might be a better idea to continue as now and use on-line conversions from man and Info to HTML. Pre-converted HTML should be distributed as separate packages. So you'd rather I put the SGML source for the manuals in the dpkg binary package, rather than the HTML pre-converted form ? Conversion of things into HTML is particularly awkward because you end up with lots of intermediate files. And, my debiandoc-sgml converters are not exactly fast. Converting the dpkg manuals to plain text takes about 5 minutes on my Cx5x86/120 (clock-tripled 40MHz). This is about 50% of the time it takes to build a whole new release of dpkg (the HTML converter is much faster). Ian.
Re: Draft manuals (qmail)
Raul Miller writes (Re: Draft manuals (qmail)): ... Perhaps it's reasonable to specify that every mail aware program supports the MAIL environmental variable. As qmail's default behavior is to deliver mail to ~user/Mailbox in standard unix mailbox format, this should suffice. But does it use the same locking strategy as our other mailers ? Additional recommendations or specifications which open the door to maildir compatability (e.g. that movemail be used to retrieve locally stored mail -- allowing, at worst, the administrator to set policy by replacing movemail) might also be reasonable. This can't be done sensibly for mailers like mailx, Elm and Pine which manipulate and leave messages in the inbox, and incurs extra delay with (eg) mh. Ian.
Re: Bug#4164: Ferret extended description has blank lines
Dale Scheetz writes (Re: Bug#4164: Ferret extended description has blank lines ): ... Objections to reporting something as a bug are not founded on this concept. No one feels personaly put down by a bug report. Those of us who object to trivial bug reports are more concerned about the distribution's public perception. The new user is apt to see a security bug and a blanks in description bug as having equal weight. Large numbers of outstanding bugs also leave new users feeling uncertain. The bug tracking system is for _our_ _internal_ use. I couldn't care less if the some idiotic users think that two hundred `missing description' bug reports are vitally important. We must not allow bugs to go unreported because they'd end up on the bug list and so be publicly visible. That's absurd. ... No, the trivial way to reach maintainers is to start with debian-user. No, because debian-user is a high-traffic mailing list. The best way to report a trivial problem in package foo is to mail To: [EMAIL PROTECTED] Subject: ... Package: foo Case in point: Recently a user reported smtp problems with pine. This problem turned out to be a configuration issue, unrelated to any functional problems with the pine software. By reporting the bug on debian-user first, a non-bug bug report was avoided. This is a different matter. Encouraging people to discuss things that might or might not be bugs is fine. Discouraging people from reporting things that definitely are bugs is not fine. Ian.
Re: exmh and Xauthority
Maarten Boekhold writes (exmh and Xauthority): ... # Generate a random key; Mui and Pearce offer a number of alternatives # for this. randomkey=`perl -e 'srand; printf int(rand(10))'` Do NOT do this. It results in a weak cookie, meaning that someone could fairly easily guess your cookie and take over your session and account. There are ways of getting a good cookie. This isn't one. Ian.
Re: Shadow problems
Rob Browning writes (Re: Shadow problems): Miquel van Smoorenburg [EMAIL PROTECTED] writes: You can ofcourse make the new directory setgid (chmod g+s). All files created in that directory will have their gid set to that of the directory.. But I can see that using newgrp might be more convenient Right. The gid bit trick works fine unless you're running some set of commands that may create a bunch of directories. Then I don't think the sgid bit will propagate. It does. Ian.
Re: Packaging questions (newbie)
Milan Zamazal writes (Packaging questions (newbie)): I'd like to contribute some packages, but I'd like to ask some questions first: 1. One of these packages is the replacement of `libX11.so'. Do I have to make whole alternative version of appropriate standard X package or is there some way to make small one-file-replacement package? Yes. It's in the manual. 3. What and where are (are there?) up-to-date `Debian Packaging Guidelines'? Install dpkg 1.3.8 and run your favourite web browser on the local file /usr/doc/dpkg/programmer.html/index.html and .../policy.html/index.html. Thanks, Ian.
Bug#2475: at' uses middle-endian 2-digit-year date format
Thomas Koenig writes (Bug#2475: at' uses middle-endian 2-digit-year date format): Date outputs from 'at' are mandated as date +%a %b %e %T %Y (i.e. Wed Aug 14 20:05:13 1996) by the Posix.2a draft I have, which is the date used in the upcoming release 3.0 of at(1). Yep, that's pretty broken. If anybody has later, better news, please let me know. Of course if we really do not like it we can use ISO standard date format (say) and only produce the POSIX-mandated format if POSIXLY_CORRECT is set or some flag is used. Ian.
Re: libpaper 1.0 on master
Yves Arrouye writes (Re: libpaper 1.0 on master): ... 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). Would it be possible to rename this variable PAPERCONF, to correspond to the new name of the program ? It seems to me that having an environment variable PAPER is asking for trouble. Ian campaign against namespace pollution Jackson.
Re: Incorrectly locates packages
Michael Meskes writes (Incorrectly locates packages): ... 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. Yes. Ian.
Bug#660: GDB gets address wrong of struct member in memory breakpoint
Buddha M. D. Buck writes (Bug#660: GDB gets address wrong of struct member in memory breakpoint): I'm looking at the backlog of forgotten bugs, and have verified that this one still exists. The original report was for gdb 4.12, but Ian Jackson verified that the problem exists under 4.14, and I just verified that it exists for 4.15.1-1. Should this be forwarded to the upstream maintainers of gdb? We haven't touched this bug since October. Yes. Ian.
Bug#818: echo builtin doesn't check for write errors
Buddha M. D. Buck writes (Bug#818: echo builtin doesn't check for write errors): As of 1.14.6-4, this bug is still there... maybe $ type echo echo is a shell builtin $ echo foo /dev/full $ echo $? 0 $ cat /dev/zero /dev/full cat: write error: No space left on device $ echo $? 1 $ /bin/echo foo /dev/full $ echo $? 0 $ file /bin/echo /bin/echo: ELF 32-bit LSB executable, Intel 80386, version 1, stripped $ The built-in version of echo is faithfull reproducing what the binary version does. If they are both in error, should another bug be filed for shellutils? The manpage for echo makes no mention whatsoever of return values. There are already bug reports against shellutils and tcsh too. All programs should check for write errors. The fact that the documentation neglects to say that it does doesn't mean it is OK for it not to bother. Ian.
Bug#4218: Problems removing INN
Rob Leslie writes (Bug#4218: Problems removing INN): ... dpkg: error processing inn (--purge): cannot remove `/var/spool/news': Device or resource busy Would it be better if I made dpkg treat this as a warning ? It happens one of the directories in a package is a mount point. Ian.
Bug#4221: knews silently overwrites configuration file
Nils Rennebarth writes (Bug#4221: knews silently overwrites configuration file): Knews should handle an upgrade more intelligently and not simply overwrite the (possibly customized) /usr/X11R6/lib/X11/app-defaults/Knews configuration file. I know this is difficult to do right. A lot of Knews functionality depends on a working Knews.ad and what is necessary there changes from release to release. Maybe it should look if there already exists one and give the user an option to install a new one / back up the old one ... like dpkg does. Listing it as a conffile is not satisfactory though because it is created from user-input at installtime. Furthermore, configuration should definitely not be in /usr. It belongs in /etc. Ian.
Re: Bruce - fiat required to end discussion on lyx/copyright ?
[EMAIL PROTECTED] writes (Re: Bruce - fiat required to end discussion on lyx/copyright ?): All packages in the Debian distribution proper must be freely useable, modifiable and redistributable in both source and binary form. It must be possible for anyone to distribute and use modified source code and their own own compiled binaries, at least when they do so as part of a Debian distribution. This can't be done with nearly all (la)tex related style files. When one wants to change a (la)tex style an other named copy can be used but the original may not be touched. Do we really want to ditch (la)tex? I've added the following footnote: footnoteIt is OK for there to be a requirement that modified versions carry a warning, or that they be released with a different name or version number, or something similar, because we can comply with this requirement if necessary./footnote Ian.
Re: Bruce - fiat required to end discussion on lyx/copyright ?
[EMAIL PROTECTED] writes (Re: Bruce - fiat required to end discussion on lyx/copyright ?): All packages in the Debian distribution proper must be freely useable, modifiable and redistributable in both source and binary form. It must be possible for anyone to distribute and use modified source code and their own own compiled binaries, at least when they do so as part of a Debian distribution. This can't be done with nearly all (la)tex related style files. When one wants to change a (la)tex style an other named copy can be used but the original may not be touched. Do we really want to ditch (la)tex? Being required to change names is fine, as we can do that if necessary. Ian.
Re: Bruce - fiat required to end discussion on lyx/copyright ?
Michael Meskes writes (Re: Bruce - fiat required to end discussion on lyx/copyright ?): ... Ahem, this isn't exact enough IMO. With a standard Debian system I am able to rebuild LyX. You can't rebuild LyX entirely from source using only packages in the main Debian distribution. [...] All packages in the Debian distribution proper must be freely useable, modifiable and redistributable in both source and binary form. It must be possible for anyone to distribute and use modified source code and their own own compiled binaries, at least when they do so as part of a ^^^ Fixed the typo. 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: ... Compiling names of groups or even worse group ids into binaries is a bad idea. Why? Because it's not easy to change? It's hard to change and obscure. Policy is best implemented where it can be seen. I talked to Alain (upstream maintainer) about my changes and he's going to included them into 4.4. I don't see the problem right now, since you're able to put everyone in group floppy who shall be able to use fdmount. On the other hand this group coding (which is ifdef'ed btw so it's not much work to create a new version) adds security. How many systems have wrong permissions on some files? In particular a file with s.bit should be as secure as possible IMHO. Obviously if you've done it right having the binary check itself whether rgid or getgroups includes `floppy' and having it only executable by group floppy have the same security effect. However, there are other differences: having the permissions on the binary do the enforcement means that a programming error of any kind in the binary is at most an exposure to group floppy (which may well be only the sysadmin anyway). It also makes it much more obvious to people how to get access. ... No problem Ian. But then I'm not so sure if it's a bug now. We should either change fdmount to match the policy and the other similar programs (dip, for example), or we should change the policy and the other programs to match fdmount. I think that using the file permissions is technically superior, so I think we should stick with it. Ian.
Re: Bruce - fiat required to end discussion on lyx/copyright ?
Dale Scheetz writes (Re: Bruce - fiat required to end discussion on lyx/copyright ?): [...] xforms is improperly located in contrib instead of non-free where it belongs (because source is not distributed). [...] Sourceless packages are fine to distribute in contrib, so long as the binaries may be redistributed for profit c. Please see the policy manual, chapter 2. Ian.
Re: dpkg 1.3.8: dpkg-buildpackage -sa works and is recommended
Peter Tobias asks me in private email: ... BTW: I didn't have much time the last weeks (and I won't have much time the next weeks) so I wasn't able to check if this new source format will also work for packages like netstd (packages which contain lots of sub packages each with its own original source. Do you see any problems with it? I'm afraid I totally fail to understand the netbase and netstd source packages. The new source packaging scheme will require you to put all of these sub-packages together, and turn the whole thing into a normal package. Ian.
Bug#4235: cpp, gcc, dpkg
[EMAIL PROTECTED] writes (Bug#4235: cpp, gcc, dpkg ): ^ was this intentional ? ... Somehow installation with dpkg-ftp and the new cpp uninstalled my gcc package and look how dpkg selects on a dselect update. This shouldn't happen. Somehow gcc is too easily uninstalled because the conflict with the cpp package. Another reason to remove the cpp thing from gcc and let it come in its own package and let gcc depend on it. The problem with gcc and cpp is being discussed atm. # dselect update dpkg (subprocess): failed to exec C compiler `gcc': No such file or directory dpkg: subprocess gcc --print-libgcc-file-name returned error exit status 2 This is due to dpkg-ftp calling `dpkg --print-architecture' rather than `dpkg --print-installation-architecture'. I'm reassigning this bug report. Ian.
Re: Bug#4263: dpkg-source requires patch
Susan G. Kleinmann writes (Bug#4263: dpkg-source requires patch): ... # dpkg-source -x sgmlspm_1.03ii-2.dsc dpkg-source: extracting sgmlspm in sgmlspm-1.03ii dpkg-source: failure: exec patch: No such file or directory dpkg-source: failure: patch gave error exit status 2 ... patch is only required by dpkg-source, and not to install packages. I've added it to Suggests and mentioned it in the Description. This will be in 1.3.10. Ian.
Re: $(ARCH)-debian-linux-gnu
Miquel van Smoorenburg writes (Re: $(ARCH)-debian-linux-gnu): ... The GNU configure scripts usually match on i[3456]86-*-*) for architecture support, so that's not a problem. I usually do something like: a = $(shell dpkg --print-architecture) ifeq (i386,$(a)) arch = i486-debian-linux else arch = $(a)-debian-linux ... Should I provide a command to do this automatically ? dpkg --print-gnu-build-architecture perhaps. Ian.
Re: Bug#4238: mirror requires perl
Dirk Eddelbuettel writes (Bug#4238: mirror requires perl): ... On the other hand, we seem to have (had ?) a policy of relying on (at least a rudimentary) perl in the base system --- but I cannot find anything on that in the programmers and policy manuals of dpkg-1.3.8. So should timezone.pl move into base? Comments? Ian, Bruce? I propose the following policy, which is roughly what we have at the moment: A basic version of Perl is shipped with the base system. This should be a separate package, say `perlbase'. If you only need this you don't need a dependency. If you need extra modules, c, you must declare a dependency on `perl'. Ian.
Re: Bruce - fiat required to end discussion on lyx/copyright ?
Dale Scheetz writes (Re: Bruce - fiat required to end discussion on lyx/copyright ?): ... Pine is in non-free because it's copyright places restrictions on the distribution of source. Xforms has more severe restrictions on the distribution of source than pine does. It is my understanding that this source distribution restriction is what makes Xforms' proper location to be non-free. Please read chapter 2 of the new policy manual. Ian.
Bug#4257: request-route would be better as conffile
Kevin M. Bealer writes (Bug#4257: request-route would be better as conffile): ... The modules packages contains a file /sbin/request-route. This is run by the kernel to create routes as needed. The script's comments suggest is it very configurable, and I usually configure it heavily .. however it is written over whenever I install a new version of the package it is in (dpkg -S shows it as modules). I propose this file be a conffile, and that the user be prompted to replace it or not. If the script is made to be a conffile it should be in /etc. Ian.
Re: Bug#4051: access permissions for /usr/bin/fdmount
Michael Meskes writes (Re: Bug#4051: access permissions for /usr/bin/fdmount): ... I have no problem with it being mode 4750 again. It should be 4754 - there's no point in stopping people reading it. (I've been saying 4754 all along, and this is what is in the policy manual.) ... No problem with me. But just in case I let the group check in (since it's in the upstream source anyway). Err, I strongly suggest that you compile the group check out of the executable. This is only likely to lead to confusion. Ian.
Re: New virtual package names.
Dale Scheetz writes (Re: New virtual package names. ): ... Part of my concerns stem from the past history of ae. I have only recently taken over the maintainance of this package. When I got it, the essential field had been declaired a bug, but the discussion of that bug seemed to indicate that removal of the essential flag was not a sufficient solution. In addition, I am concerned by the fact that this field was only added to the package a couple of revisions ago, and now needs to be removed. The fact that the field was added was a mistake, and it was noticed and reported as a bug (several times, in fact). It is not surprising that once a mistake is made people ask for it to be unmade again. I didn't see anything in that discussion to think that the removal of the essential flag wasn't a full solution. I saw several people with the `hammer and nail' problem: `we have dependencies so we must use them here'. I don't see any difference, in principle, between an editor and a mail-delivery-agent. They are both programs that deliver specific functionality. The only differnce I can see is that an editor may not be viewed as being as critical to system operations as the other, and Ian has pointed out that users are likely to be more aware of their needs for an editor than they are for other dependant programs. I am pretty sure that we have users who are not this aware, but that is not the basis for my feelings here. If we have users who are not aware of this then they will not be satisfied by `vi' or `ed' either - and these programs will have to satisfy the dependency. We can't solve this problem with the dependency mechanism. Ae is in the base package because it was deemed necessary to have an editor in the system, and ae was small enough to fit. It is this necessity that is driving the editor virtual package dependance as the proposed solution. If it is not necessary for the system to contain an editor, then why is one in the base system? The base system is provided as a tool for installing the rest of the packages, and is supposed to be a sensible default. Both the essential flag and the dependency mechanism actually _prevent_ the user from doing something, and we should only do this if we really mean it. ... If it is necessary for an editor to be on the system, it seems desirable to provide protections from the inadvertant removal of all editors. If there is a better way to insure the existance of an editor on the system, I would be happy to hear it. What terrible thing do you think will happen if the user removes all their editors ? They'll sit there wanting to edit a file and think Damn, I can't figure out why I can't edit this file. I just sit here blankly and wonder how I used to edit files. ? In addition, it is not clear to me that being unnecessary is the same as undesirable. I can be convinced (no, really!) of either position at this point. I just need a little more 'splaining. For it to be right for us to do this there has to be a good reason in favour of it. It is not sufficient for it merely to be neutral. In any case, it isn't neutral: it is a lot of work, and while the work is done silly things will happen like users being forced to install particular editors to satisfy the dependency scheme. Ian.
Re: $(ARCH)-debian-linux-gnu
Juergen Menden writes to me in private email: ... well, unfortunately some packages (like ldso) need i386-linux and wouldn't like to match i486-linux. better might be ld.so is not a GNU package, is it ? It probably uses our own canonical architecture strings, which include i386 for intel, and which is generated by dpkg --print-architecture. I'm only putting the --print-gnu-build-architecture flag in because the many GNU packages all need the same mapping from our to their architecture. dpkg --print-architecture --intel-arch=i486 (with --intel-arch=i386 being the default) This is a hack, which I will not implement. Ian.
Re: $(ARCH)-debian-linux-gnu
Miquel van Smoorenburg writes (Re: $(ARCH)-debian-linux-gnu): You (Ian Jackson) wrote: Should I provide a command to do this automatically ? dpkg --print-gnu-build-architecture perhaps. Sure, why not. It would result in more consistency, and that's a Good Thing (TM) This will be in 1.3.11. Can anyone think of a reasonable thing to say in the policy manual about when and how to use it ? Ian.
Bug#4218: Problems removing INN
Miquel van Smoorenburg writes (Re: Bug#4218: Problems removing INN): You (Ian Jackson) wrote: ... Would it be better if I made dpkg treat [EBUSY] as a warning ? (It happens one of the directories in a package is a mount point). Yes, I think so. Every directory can be a potential mountpoint. This will be in 1.3.11. Ian.
Re: Bruce - fiat required to end discussion on lyx/copyright ?
Susan G. Kleinmann writes (Re: Bruce - fiat required to end discussion on lyx/copyright ? ): ... This is my synopsis of the relevant parts of Chapter 2: Packages go into contrib if their copyrights or patents require that they: a. allow distribution of no source code b. allow distribution of only some source code, but not all the source code needed to compile the program (even given the existence of other sources in the Debian distribution). c. depend on a non-free or contrib package in order to be used d. allow use only for a trial period e. lack vital functionality f. are installer packages g. fail to meet some other policy requirement Packages go into non-free if their copyrights or patents require that they: h. disallow distribution for profit i. disallow distribution on certain media j. disallow distribution except if special permission is obtained k. have any other onerous conditions. My reactions: Condition (a) is redundant, given condition (b). Yes, if you think about them like that. I haven't expressed it quite that way. It is not clear either what is meant by condition (k), nor how condition (k) differs from condition (g). Without such a distinction, non-free and contrib overlap. (k) is there as a catch-all, in case someone comes up with another example of a bad thing in a copyright. non-free and contrib do overlap - they are intended to. The way I have phrased it makes it clear that if a package meets the bad criteria for needing to be in non-free, and those for contrib, it must go in non-free. The word onerous in condition (k) would seem inconsistent with the Debian objective to be a base upon which value-added GNU/Linux distributions can be built. I don't understand this at all. Ian.
Bug#4298: arrow keys in dselect don't work after search
Joey Hess writes (Bug#4298: arrow keys in dselect don't work after search): ... I'm running dselect in an xterm. I go to the [S]elect part of it, and the up and down addor keys scroll through the list of packages. But when I type /mosaic\n, to search for mosaic, the arrow keys stop working. ctrl-p and ctrl-n still work, as do pageup and pagedown and all the other keys, except for the up and down arrows. This is a four-month-old bug in ncurses, which has previously been reported as #2962 and #3974. I'm reassigning it to ncurses3.0 and merging it with those others. Ian.
Unanswered problem reports by maintainer and package
/etc/news/descriptions instead of /etc/news/newsgr
tin 3942 tin cannot find Newsgroup Descriptions
tin 4227 Tin TIN_NOVROOTDIR wrong value for tin
[EMAIL PROTECTED] (Jonathan K. Rabone) (3 bugs):
trn 825 trn warning messages corrupt thread selector display
trn 1845 dead.letter and dead.article are world readable
trn 2298 trn bug with shell escaping
Anders Chrigstrom [EMAIL PROTECTED] (3 bugs):
bison3955 yacc script uses $* instead of $@
bison4052 access permissions for /usr/bin/{mkparser, mkparserclass}
bison4232 bison dumps core
Michael Alan Dorman [EMAIL PROTECTED] (3 bugs):
lrzsz4075 Possible security problem with lrzsz
mingetty 3362 Problems encountered while compiling mingetty for m68k ar
ncftp4272 ncftp dumps core when xterm window is too wide
[EMAIL PROTECTED] (Michael R. Nonweiler) (3 bugs):
ipx 2913 ipx bootup scripts are broken
ipx 3592 ipx description: no ext
ncpfs3630 ncpfs description: summary starts w/ pkg name
Rob Browning [EMAIL PROTECTED] (3 bugs):
gimp-smoti 4303 config of gimp-smotif
libwww-per 3611 libwww-perl description: no ext
perl-tk 4068 pgs in perl-tk does not work
Simon Shapiro [EMAIL PROTECTED] (3 bugs):
rc 3206 rc terminates on CTRL-C
rc 3533 Problems encountered while building rc on m68k arch
rc 3607 rc description: no ext
Ian Jackson [EMAIL PROTECTED] (3 bugs):
bugs.debia 2296 debian-bugs WWW doesn't say how to find out Debian version
bugs.debia 2966 bugs2ftp is broken
bugs.debia 2998 bugs2ftp still flaky
Craig Sanders [EMAIL PROTECTED] (3 bugs):
squid3834 squid core dumps regularly
tkdesk 3640 tkdesk description: ext start indented
tkdesk, tk 3842 tkdesksh grows really large
Alvar Bray [EMAIL PROTECTED] (3 bugs):
groff2233 groff-1.09-4
groff2970 soelim [in groff] is confused by .so in macros definitions
groff4013 groff version is old
[EMAIL PROTECTED] (Andy W.P. Guy) (4 bugs):
dpkg-ftp 2870 dpkg-ftp-1.4.1 bug
dpkg-ftp 2933 dpkg-ftp needs perl 5.002
dpkg-ftp 4235 cpp, gcc, dpkg
dpkg-ftp 4241 Connect with nothing to do
Bernd Eckenfels [EMAIL PROTECTED] (4 bugs):
lilo 3247 Lilo unpack removes boot.b
lilo 3761 LILO installation problem
lilo 3772 lilo should not depend on MBR
net-acct 4309 no manpage in net-acct
Doug Geiger [EMAIL PROTECTED] (4 bugs):
abuse3963 abuse
abuse4096 abuse is still a.out
apsfilter3224 apsfilter doesn't configure on a read-only filesystem
apsfilter3812 Apsfilter should depend on file
Christophe Le Bars [EMAIL PROTECTED] (4 bugs):
xcoral 3654 xcoral description: summary starts w/ pkg name
xcoral 4115 xcoral requires changes for multi-arch support
xcoral 4159 xcoral dies
xtel 4037 xtel requires changes for multi-arch support
Yves Arrouye [EMAIL PROTECTED] (4 bugs):
libpaper 4125 libpaper should ask for papersize
libpaper 4138 libpaper /usr/bin/paper is likely to have name clashes
libpaper 4139 libpaper /etc/papersize is auto-handled conffile
libpaper 4251 libpaper calls ldconfig in prerm/postrm script
Richard Kettlewell [EMAIL PROTECTED] (4 bugs):
itimer 4274 itimer requires changes for multi-arch support
majordomo1881 Majordomo UID wrong?
repair 1532 no revision number with repair
vm 4031 vm requires changes for multi-arch support
Christian Hudon [EMAIL PROTECTED] (4 bugs):
termcap-co836 Possible bugs in termcap system
termcap-co 1045 tgetflag(hc) segfaults (fwd)
termcap-co 1803 /etc/termcap linux definition incomplete
termcap-co 3721 Problems while compiling termcap-compat on m68k arch
[EMAIL PROTECTED] (Susan G. Kleinmann) (4 bugs):
elv-vi 4034 elvis requires changes for multi-arch support
elviscmn 3562 elviscmn description: no ext
elvisctags 4016 ref not in elvisctags
elvisnox 2592 Elvis Compilation Peoblem
Marcel Riedi [EMAIL PROTECTED] (4 bugs):
rsynth 2206 Description
rsynth 3684 rsynth description: summary starts w/ pkg name, no ext
rsynth 3932 rsynth requires changes for multi-arch support
rsynth 4141 say is an a.out binary
Giuseppe Vacanti [EMAIL PROTECTED] (4 bugs):
diald3457 diald control file problems
diald3573 diald description: ext start blank line
diald4128 ppp/diald interaction
diald4290 Cannot install diald
Martin Schulze [EMAIL PROTECTED] (4 bugs):
manpages 2861 glob(3) references glob(7); the latter doesn't exist
manpages 3165 fcntl(2) references nonexistent man pages
manpages 4231 acct(2) man page refers to nonexistent acct(5) man page
manpages-d 4193 German Manpages
Dale Scheetz [EMAIL PROTECTED] (5 bugs):
gmp 4312 gmp should
Bug#4326: smail can lose bounce messages
Package: smail Version: 3.1.29.1-14 Under certain obscure circumstances Smail can lose mail: When it needs to send a bounce message it reinvokes itself with the `-bS' flag, meaning to read SMTP commands from standard input but not to produce responses. It then feeds an SMTP `session' to the subprocess. Now, smail never produces error responses to syntactically valid input (unlike, for example, some sendmails which will fail a RCPT TO on a user that they think is local to them but is unknown). However, the subprocess may fail for some other reason. Perhaps the copy of Smail it wishes to reinvoke cannot be found, or has some configuration error serious enough to cause it to fail to write the message anywhere. In this case the parent smail will write the message into its child anyway and fail to notice the non-zero exit status. I have reproduced the problem with a test setup under controlled conditions, and can provide strace logs c. I'm not sure what happens if the disk is full. Ian.
Bug#4329: Emacs has hardcoded path for jka-compr, breaks at upgrade
Package: emacs Version: 19.31-2 I just upgraded from 19.29-3, and it left me with the following /etc/site-start.el: (load /usr/lib/emacs/19.29/lisp/jka-compr.elc) (if (file-exists-p /usr/lib/emacs/site-lisp/w3-init.el) (load w3-init)) (autoload 'lout-mode lout-mode Mode for editing Lout source t) (setq auto-mode-alist (append '((\\.lout$ . lout-mode)) auto-mode-alist)) (require 'vm-init) This caused Emacs to fail to start because of the changed version number in the pathname for jka-compr. IMO this entry should not have used an absolute pathname, rather, it should rely on the load-path. If it did need an absolute pathname the Emacs postinst should have fixed it up. Ian.
Re: dpkg-buildpackage and -source questions
Karl Sackett writes (dpkg-buildpackage and -source questions):
Regarding the -r option for dpkg-buildpackage, are there any
examples of what's called for here? Is the gain-root-command
something each developer provides for himself, or is there a command
or shell somewhere that performs this function?
How to get root is a piece of local policy, so you provide it
yourself. It's possible that `su' or `sudo' or `really' or `super'
may be available to you and DTRT.
Invoked as root, dpkg-buildpackage works fine. But when I try to unpack the
new package this is what happens:
mycroft$ dpkg-source -x exmh_1.6.9-1.dsc
dpkg-source: error: tarfile `./exmh_1.6.9.orig.tar.gz' contains object with
newline in its name
(exmh-1.6.9.orig/?exmh-1.6.9.orig/exmh.README?exmh-1.6.9.or
ig/COPYRIGHT?exmh-1.6.9.orig/e...(rest of output deleted)
This happens with the packages I build and with the hello package I downloaded
from master.
Needless to say this doesn't happen to me. I think your cpio or your
perl is broken.
Please send me by private email the output of the following commands
(feeding it to sh and sending me all the output concatenated is fine):
md5sum exmh_1.6.9.orig.tar.gz
zcat exmh_1.6.9.orig.tar.gz | md5sum
cpio --version
perl -v
type cpio perl
which cpio perl
dpkg -s cpio perl
echo -e 'ab\0cd\0' | perl -e '$/=\0;while(){print$_\n;}' | cat -vET
zcat exmh_1.6.9.orig.tar.gz | cpio -0t | uuencode cpio-0t
gzip -9v `type -p cpio` | uuencode cpio.gz
(If you want to MIME-attach it make sure that the file is in
`Content-Transfer-Encoding: 7bit'.)
Thanks,
Ian.
Bug#4335: cat -vET is lossy - there should be a non-lossy version
Package: textutils Version: 1.17-2 -chiark:~ echo -e 'hi^IthereM-z\011hi' | cat -vET hi^IthereM-z^Ihi$ -chiark:~ As you can see, it's not possible to distinguish a single escaped control character ^something or M-something from the corresponding sequence of printable characters. There should be an option to do a reversible transformation. I don't particularly care what the transformation is, provided that it's not insane. Ian.
Re: dpkg-buildpackage and -source questions
If you get this message: dpkg-source: error: tarfile `./exmh_1.6.9.orig.tar.gz' contains object with newline in its name (exmh-1.6.9.orig/?exmh-1.6.9.orig/exmh.README?exmh-1.6.9.orig/COPYRIGHT?exmh-1.6.9.orig/e...(rest of output deleted) You should upgrade your cpio. Unfortunately the (Debian-specific) change that I'm relying on wasn't documented in any changelog file, so I don't know which versions are OK, but I do know that 2.4.2-2 works. If someone has a version of cpio between 2.3-2 (which I know doesn't work) and 2.4.2-2 I'd be grateful if they'd do one of the following two tests: * Try to unpack a source package with it using dpkg-source or * Type `cpio -Hustar -0t anything.tar | cat -vet' and see whether the output from cpio is null-terminated or newline-terminated. I'll be making some changes to dpkg-source and the dpkg control file. Thanks, Ian.
Unanswered problem reports by date
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]
OVER 17 MONTHS OLD - ATTENTION IS REQUIRED:
Ref PackageKeywords/Subject Package maintainer
660 gdbGDB gets address of structure David Engel [EMAIL PROTECTED]
725 xbase twm places windows incorrectly Stephen Early [EMAIL
PROTECTED]
740 xbase xclock leaves `droppings' in i Stephen Early [EMAIL
PROTECTED]
773 xbase xmh falls over if mh is not in Stephen Early [EMAIL
PROTECTED]
775 xbase twm reports errors on incorrec Stephen Early [EMAIL
PROTECTED]
OVER 16 MONTHS OLD - ATTENTION IS REQUIRED:
Ref PackageKeywords/Subject Package maintainer
818 bash bash builtin `echo' doesn't ch Guy Maor [EMAIL PROTECTED]
820 tcsh tcsh builtin `echo' doesn't ch Andrew Howell [EMAIL
PROTECTED]
821 shellutils /bin/echo doesn't check write [EMAIL PROTECTED] (Da
825 trntrn warning messages corrupt t [EMAIL PROTECTED] (Jonathan
836 termcap-co Possible bugs in termcap syste Christian Hudon [EMAIL
PROTECTED]
OVER 15 MONTHS OLD - ATTENTION IS REQUIRED:
Ref PackageKeywords/Subject Package maintainer
887 xarchiexarchie barfs when ftp closes Christian Linhart [EMAIL
PROTECTED]
889 info Info 3.1-6 Erick Branderhorst branderhors
902 lprlpr can't print a PostScript f Sven Rudolph [EMAIL PROTECTED]
911 libc4 libc causes rsh to fail on com (unknown -- `libc')
957 dpkg dpkg should automatically log Ian Jackson [EMAIL PROTECTED]
OVER 14 MONTHS OLD - ATTENTION IS REQUIRED:
Ref PackageKeywords/Subject Package maintainer
988 bsdutils `script' is insecure, and gene Austin Donnelly [EMAIL
PROTECTED]
998 boot-flopp Can't Configure DOS Partitions Bruce Perens [EMAIL
PROTECTED]
1009 bash bash problem with quoting/comp Guy Maor [EMAIL PROTECTED]
1016 procps top has 3's in vt100 Helmut Geyer [EMAIL PROTECTED]
1032 boot-flopp Linux Counter Project Info Not Bruce Perens [EMAIL
PROTECTED]
1037 dpkg dselect user interface (was Re Ian Jackson [EMAIL PROTECTED]
1045 termcap-co tgetflag(hc) segfaults (fwd) Christian Hudon [EMAIL
PROTECTED]
1061 lpr/etc/printcap vs. /usr/man/man Sven Rudolph [EMAIL PROTECTED]
OVER 13 MONTHS OLD - ATTENTION IS REQUIRED:
Ref PackageKeywords/Subject Package maintainer
1099 perl perl bug Darren Stalder [EMAIL
PROTECTED]
1108 binutils No manpage ar(5) David Engel [EMAIL PROTECTED]
1112 gsfontsa2gs output unusable by gs but joost witteveen [EMAIL
PROTECTED]
1118 fortunefortune is setuid games ?! [EMAIL PROTECTED] (David H.
Silbe
1130 libc4 Stdlib.h problems when using g (unknown -- `libc')
1164 shellutils who --help uses /etc/{w,u}tmp [EMAIL PROTECTED] (Da
1170 perl perl fails to make headers fir Darren Stalder [EMAIL
PROTECTED]
1176 procps /usr/bin/top segfault with unk Helmut Geyer [EMAIL PROTECTED]
1201 perl perl doesn't know about includ Darren Stalder [EMAIL
PROTECTED]
OVER 12 MONTHS OLD - ATTENTION IS REQUIRED:
Ref PackageKeywords/Subject Package maintainer
1211 libc4 libc __nis_getgrnam() segfault (unknown -- `libc')
1239 findutils /etc/cron.daily/find: updatedb Kevin Dalley [EMAIL
PROTECTED]
1240 procps ps(1) man page incomplete Helmut Geyer [EMAIL PROTECTED]
1246 procps ps man page does not agree wit Helmut Geyer [EMAIL PROTECTED]
1247 perl perl ... globbing only works Darren Stalder [EMAIL
PROTECTED]
1265 uucp Misc. uucp bugs[EMAIL PROTECTED] (David H.
Silbe
1275 xarchiexarchie clumsy with 2-button m Christian Linhart [EMAIL
PROTECTED]
1278 libc4 dpkg seg faults with NIS (unknown -- `libc')
1279 libc4 Strangeness involving bsd/sig (unknown -- `libc')
1281 bin86 bin86 (unknown -- `bin')
1292 xserver-sv X locks up Stephen Early [EMAIL
PROTECTED]
1303 binutils `man 1 nm` slightly incomplete David Engel [EMAIL PROTECTED]
1314 ncurses3.0 ncurses fails in silly way on (unknown -- `ncurses')
OVER 11 MONTHS OLD - ATTENTION IS REQUIRED:
Ref PackageKeywords/Subject Package maintainer
1336 procps CFLAGS shouldn't be used when Helmut Geyer [EMAIL PROTECTED]
1366 acmacm networking problemsIan Murdock [EMAIL PROTECTED]
1372 boot-flopp rootdisk: no dvorak keytable Bruce Perens [EMAIL
PROTECTED]
1378 libc4 weird ELF/a.out difference (unknown -- `libc')
1381 workbone workbone postinst fails[EMAIL PROTECTED] (D.J. G
1399 dpkg dselect error handling not con Ian Jackson [EMAIL PROTECTED]
1406 dbackupbackup postrm can fail
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. sectUpload handling - announcements p 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 If a package is released with tt/Distribution: experimental/ the announcement should be posted to tt/debian-devel/ instead.
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.
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#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.
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.
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: 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.
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.
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.
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.
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.
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 whatever.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
