Bug#3895: file conflicts
Package: mgetty, netpbm Version: 0.98-2, 1994.03.01p1-1 See below. I think these should be left in netpbm - after all, what are you going to do with the pbm file without it ? I seem to remember that the versions included with mgetty fix some problem with those in netpbm. Would be worth checking... Carlos Fonseca
dpkg-changelog-mode (dpkg-changelog.el)
My upload of dpkg 1.3.0 didn't include the file below. It is an Emacs mode for editing the changelogs that dpkg-parsechangelog understands. Try it (on your own packages or on the changelog from hello 1.3-7) and let me know what you think. When I know where to put the autoload definitions I'll release a dpkg version with this file. I don't propose to use the auto-mode-alist: the file is named simply `changelog' because it is in the `debian' subdirectory of the source tree, and binding that filename to dpkg-changelog-mode would IMO be too obnoxious. Instead people can perhaps use a local variables clause to set the mode. There are facilities in dpkg 1.3.0 for defining a parser for a different changelog format. I put this in because people seemed so hung up on the Emacs format, which I think is dreadful. However, if someone defines a standard way of representing the required information in an Emacs-style changelog and writes the parser for it I'll distribute it. Of course I'd be far happier if there were a (possibly rough) consensus that we should stick to my format so that I can write that into the policy manual, but for the moment I'll just mandate that you have to use a format that the latest dpkg supports (so that people don't need to find your home-grown parser to build your package). Ian. ;; dpkg-changelog.el --- change log maintenance for dpkg-style changelogs ;; Keywords: maint ;; Copyright (C) 1996 Ian Jackson ;; This file is part of dpkg. ;; ;; It is free software; you can redistribute it and/or modify ;; it under the terms of the GNU General Public License as published by ;; the Free Software Foundation; either version 2, or (at your option) ;; any later version. ;; ;; dpkg is distributed in the hope that it will be useful, ;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;; GNU General Public License for more details. ;; ;; You should have received a copy of the GNU General Public License ;; along with your Debian installation, in /usr/doc/copyright/GPL. ;; If not, write to the Free Software Foundation, 675 Mass Ave, ;; Cambridge, MA 02139, USA. (require 'add-log) (defvar dpkg-changelog-urgencies '((?l.LOW) (?m.MEDIUM) (?h.HIGH)) alist of keystrokes vs. urgency values dpkg-changelog-urgency ^c^u.) (defvar dpkg-changelog-distributions '((?s.stable) (?u.unstable) (?c.contrib) (?n.non-free) (?e.experimental)) alist of keystrokes vs. distribution values for dpkg-changelog-distribution ^c^d.) (defvar dpkg-changelog-mode-map nil Keymap for dpkg changelog major mode.) (if dpkg-changelog-mode-map nil (setq dpkg-changelog-mode-map (make-sparse-keymap)) (define-key dpkg-changelog-mode-map \C-c\C-a 'dpkg-changelog-add-entry) (define-key dpkg-changelog-mode-map \C-c\C-f 'dpkg-changelog-finalise-last-version) (define-key dpkg-changelog-mode-map \C-c\C-c 'dpkg-changelog-finalise-and-save) (define-key dpkg-changelog-mode-map \C-c\C-v 'dpkg-changelog-add-version) (define-key dpkg-changelog-mode-map \C-c\C-d 'dpkg-changelog-distribution) (define-key dpkg-changelog-mode-map \C-c\C-u 'dpkg-changelog-urgency) (define-key dpkg-changelog-mode-map \C-c\C-e 'dpkg-changelog-unfinalise-last-version)) (defun dpkg-changelog-add-entry () Add a new change entry to a dpkg-style changelog. (interactive) (if (eq (dpkg-changelog-finalised-p) t) (error most recent version has been finalised - use ^c^e or ^c^v)) (goto-char (point-min)) (re-search-forward \n --) (backward-char 5) (if (prog1 (looking-at \n) (forward-char 1)) nil (insert \n)) (insert * ) (save-excursion (insert \n))) (defun dpkg-changelog-headervalue (arg re alist) (let (a b v k (lineend (save-excursion (end-of-line) (point (save-excursion (goto-char (point-min)) (re-search-forward re lineend) (setq a (match-beginning 1) b (match-end 1)) (goto-char a) (if arg nil (message (mapconcat (function (lambda (x) (format %c:%s (car x) (cdr x alist )) (while (not v) (setq k (read-char)) (setq v (assoc k alist (delete-region a b) (if arg nil (insert (cdr v (if arg (goto-char a (defun dpkg-changelog-urgency (arg) Without argument, prompt for a key for a new urgency value (using dpkg-changelog-urgencies). With argument, delete the current urgency and position the cursor to type a new one. (interactive P) (dpkg-changelog-headervalue arg \\;[^\n]* urgency=\\(\\sw+\\) dpkg-changelog-urgencies)) (defun dpkg-changelog-distribution (arg) Without argument, prompt for a key for a new distribution value (using dpkg-changelog-distributions). With argument, delete the current distribution and position the cursor to type a new one. (interactive P) (dpkg-changelog-headervalue arg ) \\(.*\\)\\; dpkg-changelog-distributions))
Bug#4061: Debian
Hello, This is not really a bug, just an oversight. There is no Timezone information for St. John's Newfoundland. It used to appear as 'Newfoundland' in the list of timezones. There is one for St_Johns which is in New Brunswick (GMT-4); but none for St_John's which is in Newfoundland (GMT-3.5). In fact, the entire Canada subdirectory off of /usr/lib/zoneinfo is no longer there. Bruce P.S. - sorry if this is the wrong location for notifying you folks.
Bug#4006: Fileutils has /usr/libexec directory
Package: fileutils Version: 3.13-2 The fileutils package has an empty /usr/libexec directory in the .deb file. I don't think the FSSTND supports libexec yet, so the directory should be removed. This dir is standard by make install in gnu packages and didn't see any harm so will not do an update just for removing this dir if you don't mind. If someone can come up with serious problems having this empty dir in the package I'll remove it. Erick
Bug#4011: simple c++ program segfaults
On 4 Aug 1996, Rob Browning wrote: Is this actually a bug? I don't think you are supposed to call a destructor directly in this situation. I would assume that the crash comes when the destructor is called a second time when the program exits main. It is legal to explicitly call a destructor but rarely needed. It certainly makes no sense in this case, as the destructor will be called twice. The question, it seems, is what was the programmer trying to do? Guy
Bug#4013: groff version is old
Package: groff Version: 1.09-11 GNU troff 1.10 has been out since November 1995. 1.09 is relatively ancient. Version 1.10 fixes some very significant bugs, adds a LaserJet output device, and more. Im sorry, I have totally failed to notice this release. I will build a new package ASAP. I will be atlease a week though. Also, the description incorrectly reads GNU RunOFF. It's GNU troff. Runoff is an early precursor to troff. I will fix this. alvar
Re: Uploading compress-package 1.1 on master
In message [EMAIL PROTECTED], Yves Arrouye writes: On Aug 4, 6:55pm, David Frey wrote: } Subject: Re: Uploading compress-package 1.1 on master } In message [EMAIL PROTECTED], } [EMAIL PROTECTED] writes: } Description: } compress-package: fileset to build a Debian compress package } compress belongs into non-free, not into devel! } Reason: Copyright-problems (Unisys-Patent) No. This package *is* free: it only allows one to build a compress binary package, which then will be distributable under Unisys conditions. OK. But isn't the netscape-package in non-free/contrib as well? BTW, I read in this list that the Unisys patent does not apply outside of the USA. Is this true? In this case, maybe someone in Europe can make a binary compress package available? I don't know. [Sidenote (just thinking aloud): Has for example Sun licensed it's compress(1)?] David
Could we use gunzip -c instead of zcat?
Hello, I'd like to suggest that scripts, debian.rules etc... use gunzip -c instead of zcat when the intent is to get the contents of a gzipped file on stdout. This is because if binaries from a BSD compress package (not necessarily built with compress-package) will make a true zcat available on the system, which of course cannot handle gzipped files. IMO, zcat means `cat a compressed (.Z) file', because that's what it does for years. The fact that /bin/zcat on Debian systems also handle gzipped files is a convenience for the user, but in no case guarantee scripts that the first available zcat in $PATH will be able to do so (and again zcat is not the best name for such a command due to historic heritage). Is this something unreasonable to ask? Yves.
Re: Emacs per-package startup files
Erick Branderhorst writes: If the files there really depend on each other, then it may be nice to require that each .el file contains (provide 'site-start-xxx) (as the *last* line so nothing is provided in case of error), and other files will just use (require 'site-start-xxx) as needed. Nice of course but now it happens that package A require stuff from B to be loaded, but this code for A is always executed before the stuff from B is executed and so A fails unless, the load process is run again and checks are made whether something needs to be loaded or if it has been loaded in an earlier run. That's wrong. If A requires stuff from B we'll have something like: ; package a (require 'site-start-b) ; do things here... (provide 'site-start-a) and ; package b ; do things here... (provide 'site-start-b) Now whatever the order packages are loaded, it works. If we load a, we get - a starts interpreting - a requires b - b starts interpreting - b ends providing site-start-b, so a's require is fullfilled - a continues interpreting - a ends providing site-start-a and if b was already loaded b is not loaded again. The only problem would be with circular dependencies, but then nothing can help you in such cases... Yves. P.S.: Erick, I read the list. No need to send emails twice.
trouble with perl ... continued
James D. Freels writes: I took the advice of a couple of individuals: (1) installed wg15_locale_1-1 (2) already had perl_5.003-2 installed This did not fix the problem below. I have verified that the /usr/share/locale and /usr/share/nls directories are present. warning: setlocale(LC_CTYPE, ) failed. warning: LC_ALL = (null), LC_CTYPE = (null), LANG = de, warning: falling back to the C locale. The wg15-locale package does not have abbreviated locale names like the ones Sun uses. Christophe nearly promised he'll add them buth then you can simply make the necessarily link(s) in /usr/share/locale (de - de_DE, fr - fr_FR etc.). Yves.
Bug#4058: etc/papersize doesn't allow spaces
Oh, BTW, this has nothing to do with libpaper (I don't know why you think it does, gs doesn't depend on libpaper, and has been reading /etc/papersize before the existance of libpaper.) I do wonder if libpaper does a better job, Yes it does ;-) That's its big advantage: centralize such bugs in one place so that we're sure all packages get fixed at once (who said I wanted to share features too? ;-)) and I do wonder if gs really should read A4 . Some people were really glad I added a wrapper to allow gs to read /etc/papersize. Some are angry it didn't read A4 . Well, you never please them all! Can you try my gsfrontend.c in libpaper 0.3? It would be nice if you used it for these reasons: - people will benefit from new paper sizes immediately; - I think if something else than me provides a working package using libpaper, other package maintainers will start adopting it; - I won't have to overwrite your gs with my wrapper each time you make a new package ;-). If you use my wrapper (please, please...), I suggest installing the real gs as 'ghostscript' (a meaningfull name, no?) and the wrapper as 'gs' of course. Apparently people were confused by your gs-papersize being the gs that does not handle papersize despite its name. Yves. P.S.: I run this wrapper for some weeks now without problems.
Bug#4058: etc/papersize doesn't allow spaces
Erick Branderhorst writes: Package: libpaper, gs Version: 0.2-1, 3.53-4 Oef what do I hate these errors. The char indicates the EOL char. # cat /etc/papersize A4 # gs -h Warning: unknown papersize in /etc/papersize Aladdin Ghostscript 3.53 (1996-1-10) [deleted] # cat /etc/papersize A4 # gs -h Aladdin Ghostscript 3.53 (1996-1-10) [deleted] What is the gs you use? Is it the shell script included with libpaper 0.2 or is it the gs from the gs package, which in turn calls gs-papersize (or whatever if the name changed)? I think it may be the later but don't have libpaper 0.2 handy (Joost, sorry if it's my fault...). Please tell me if the gs you use depends on libpaper. In any case, with the gs frontend included with libpaper 0.3 (in /usr/doc/examples/libpaper/gsfrontend.c), I have no problems: marin21# cat /etc/papersize | sed 's/\(.*\)/\1/' A4 marin22# gs -sDEVICE=bjc600 Aladdin Ghostscript 4.01 (1996-7-10) Copyright (C) 1996 Aladdin Enterprises, Menlo Park, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. GScurrentpagedevice /PageSize get == [595.0 842.0] GSquit marin23# If you want to use this frontend with the gs in 3.53, you must either compile it as in gcc -O2 -DGS=gs-papersize -o gs gsfrontend.c or have the GS environment variable set to gs-papersize because the default is ghostscript. So I'd like to close this bug report for libpaper (either it's not its fault or the latest version has no problem). Because the bug report number is shared between gs and libpaper, is it okay to close it for me? Yves.
Bug#4057: compress package install additional zcat
Michael Meskes writes: Package: compress-package Version: 1.2-1 Compiling and installing the compress source found on ftp.inria.fr I get a file /usr/bin/zcat. However, gzip already install zcat in /bin. I cannot see how it's useful to have both. :-) Hmmm. This is somewhat more complex than it looks like. I cannot just remove /usr/bin/zcat because it is intimately linked with compress. If you say 'man compress' for example you'll get the synopsis for zcat too and if the corresponding zcat would not be provided then I think users can be confused. In addition I have no control about what programs will be built by make-cpkg. A gzip program could even be generated (now that I think of it, this is something I could check for!). What I want to say is that it is really difficult to filter things in the generated package because of documentation, related files etc. My opinion is that gzip should *not* provide /bin/zcat but rather /bin/gzcat (and the same for other z* tools). The /bin/zcat program is just *not* zcat, it also handles gzip files which the original zcat program cannot do. I think that we should have /bin/gzcat (or even /usr/bin/gzcat because gzip only should be enough in /bin) and have /usr/bin/zcat be a symbolic link to gzcat installed by the gzip package (and not an alternative as I suggested before). And most importantly people should refrain from using zcat in scripts when the intent is to gunzip something... If gzcat was provided and /usr/bin/zcat a symbolic link to it, the zcat link would correctly be diverted by any compress-package generated package and nobody would have two semantically different zcat commands installed by installing these packages. Yves.
Re: IP-aliasing
CS == Craig Sanders [EMAIL PROTECTED] wrote: CS I'd like to see a bourne-like shell with perl-like regexp stuff CS (mainly sed grep) built in - i'd switch to that in a flash. People may say it's called ksh93. IMHO, it may seem somewhat interesting, but I really don't like it. Look likes tcl... :-) Please no flame war! Emilio. -- Emilio C. Lopes mailto:[EMAIL PROTECTED] Instituto de Fisica da Universidade de Sao Paulo Caixa Postal 66318, 05389-970 Sao Paulo - SP, BRAZIL Phone: (+55) (11) 818-6724 (Voice) / 818-6715 (Fax)
Re: uploaded babel 3.6-4 to master
MM == Michael Meskes [EMAIL PROTECTED] wrote:
What is wrong with
\usepackage[latin1]{inputenc}
MM Note that as my fault. I've been using latin1.sty for so long I
MM didn't even realize that this was a possibility. Sorry for that.
MM But I still think we should keep latin1.sty for guess who are used
MM to it (like me, although I will probably change my files).
Yes, but maybe in a latex-misc package. It surely does not belong to
babel.
Ciao, Emilio.
--
Emilio C. Lopes mailto:[EMAIL PROTECTED]
Instituto de Fisica da Universidade de Sao Paulo
Caixa Postal 66318, 05389-970 Sao Paulo - SP, BRAZIL
Phone: (+55) (11) 818-6724 (Voice) / 818-6715 (Fax)
Re: Emacs per-package startup files
IJ == Ian Jackson [EMAIL PROTECTED] wrote: IJ /etc/emacs/site-start.d ? There would be something else inside /etc/emacs or just site-start.d? If not, it seems we need a better name. /etc/site-start.d? /etc/emacs.d? /etc/emacs-start.d? /etc/emacs-lisp.d? Yes, I know would nice to have something that looks like site-start.el. Ciao, Emilio. -- Emilio C. Lopes mailto:[EMAIL PROTECTED] Instituto de Fisica da Universidade de Sao Paulo Caixa Postal 66318, 05389-970 Sao Paulo - SP, BRAZIL Phone: (+55) (11) 818-6724 (Voice) / 818-6715 (Fax)
Bug#4062: running ps as root does not report controlling ttys correctly
Package: procps Version: 1.01a-1 Running ps as root always shows ? for the controlling tty of every process, although it works for normal users. The problem occurs under kernel 1.2.13 (haven't tried 2.0.x), both with procps-0.99-3 and with the new package procps-1.01a-1. The solution was in the ps(1) man page: to remove /etc/psdevtab (which had permissions !) and subsequently run ps as root to recreate it. Perhaps this file should be recreated when the package is installed? Carlos Fonseca
Re: Documentation formats
LW == Lars Wirzenius [EMAIL PROTECTED] wrote: LW Ian Jackson (after my deletions): * GNU Texinfo ... HTML. * The Linux FAQ ... HTML ... * The Linux HOWTOs ... HTML ... * My new dpkg manuals ... HTML ... * The Perl documentation ... HTML LW I think I see a trend here. While HTML is not the perfect format (e.g., LW it lacks the navigation hints in Info), it is still the only LW common There is a great advantage of info over html: you can search an entire document with it. I think this is fundamental. LW denominator, and I guess most people will have a web browser LW installed anyway. People who have standalone machines might not want to install a www browser. Lynx is ugly (JMHO). Can't really use it. Nevertheless, I must be able to read docs in text mode. IMHO info is a great format. After reading some discussion on gnu.misc.disc I'm pretty convinced that it's currently the best format for online docs (and don't forget texinfo files can also generate printed manuals) and that we should try it a bit more. The real problem are the info browsers. The last version I checked of the standalone info program simply sucks. Maybe someone with a good knowledge of termlib should take a look at it. Maybe add some mouse support via gpm? What about xinfo? Is this any good? Yes, I know there is tkinfo, but it needs tcl/tk... Ciao, Emilio. -- Emilio C. Lopes mailto:[EMAIL PROTECTED] Instituto de Fisica da Universidade de Sao Paulo Caixa Postal 66318, 05389-970 Sao Paulo - SP, BRAZIL Phone: (+55) (11) 818-6724 (Voice) / 818-6715 (Fax)
Draft manuals
I have finished draft versions of the programmers' and policy manuals. The PostScript conversion isn't working yet, but they are available for your perusal in HTML or plain text (with or without overstrikes). HTML via the Web: http://chiark.chu.cam.ac.uk/~ian/programmer.html/ http://chiark.chu.cam.ac.uk/~ian/policy.html/ Note the trailing / on each URL. ASCII text versions, SGML source and the DTD via anon-ftp: chiark.chu.cam.ac.uk:/users/ian/dpkg-doc/ Your comments would be appreciated; feel free to send patches to the .sgml files if you think it appropriate (but don't send lots of unrelated patches together). PACKAGE MAINTAINERS TAKE NO ACTION. This is NOT an official announcement of the change to the standards. If you want to see what's coming and argue about it (again) please do so though :-). The DTD was once linuxdoc but is no longer. I've ripped out everything that my converters don't support, and added new tags to do the things that I needed. I've called it dpkgdoc. The converters are based on sp (the SGML parser package containing nsgmls) and sgmlspm (the Perl modules for parsing sgmls output) with another Perl glue script for cross-referencing. Ian.
Re: Emacs per-package startup files
EB == Erick Branderhorst [EMAIL PROTECTED] wrote: EB How will these files be read. In alphabetical or fileposition order? EB Some scripts written in these might work only properly if some other EB script is executed first. I can't come up with some proper example EB but I can imagine that this might be very true. This will force us EB to scan the files several times and execute what is in there only if EB some specific other scripts are executed earlier. Maybe they could be eval'ed following some number scheme, a la init. Ciao, Emilio.
Bug#4063: magicfilter has wrong path
Package: magicfilter Version: 1.2-5 There is one serious problem which prevented magicfilter from working here, and some small glitches. 1. The executable is installed as /usr/sbin/magicfilter, but the (rather well done) /usr/sbin/magicfilterconfig extracts a filter, in my case /usr/sbin/dj500-filter which starts with # !/usr/bin/magicfilter (not bin, not sbin) so that my initial print attempt failed with Aug 6 19:24:18 miles lpd[13640]: cannot execv /usr/sbin/dj500-filter as dj500-filter tries to start a program that's not there. A solution would be to do a s|usr/sbin|usr/bin| from magicfilterconfig. 2. There is another problem with extracting the filter from the set of filters in /usr/doc/examples/magicfilter/filters/filters.tar.gz as the extracted file is not registered with dpkg --- upon removal of the package a useless file will remain on the machine. 3. The generated /etc/printcap had a :pl#72:, you could check /etc/papersize and then put :pl#66: for letter paper users. 4. The package suggests pbmplus, and we don't seem to have such a package. I think that netpbm replaced pbmplus. -- Dirk Eddelbuttel http://qed.econ.queensu.ca/~edd
Unanswered problem reports by maintainer and package
The following problem reports have not yet been marked as `taken up' by a
message to [EMAIL PROTECTED] or or `forwarded' by a
message to [EMAIL PROTECTED]
The maintainer listed against each package is derived from the Maintainer
field of the package as found in the development tree; there is an override
file that can be amended to get the right results if you have taken over a
package and do not expect to issue a new version soon.
Variant versions of the Maintainer field for the same actual package
maintainer will be listed separately.
Maintainers with few outstanding bugs appear first, to avoid those with few
bugs being lost deep in the message.
Package RefSubject
Michael Meskes [EMAIL PROTECTED] (1 bugs):
fdutils 4051 access permissions for /usr/bin/fdmount
Karl Sackett [EMAIL PROTECTED] (1 bugs):
exmh 3824 exmh fails to start
Michael Alan Dorman [EMAIL PROTECTED] (1 bugs):
mingetty 3362 Problems encountered while compiling mingetty for m68k ar
Rob Browning [EMAIL PROTECTED] (1 bugs):
libwww-per 3611 libwww-perl description: no ext
Karl Ferguson [EMAIL PROTECTED] (1 bugs):
unarj3641 unarj description: ext start indented, summary starts w/ pk
[EMAIL PROTECTED] (Brian C. White) (1 bugs):
gnats3053 gnats: typo in postinst omits install-info
Jeroen van der Most [EMAIL PROTECTED] (1 bugs):
dmalloc 3925 dmalloc requires changes for multi-arch support
[EMAIL PROTECTED] (Bill Mitchell) (1 bugs):
elv-ctags2503 elvis and emacs both provide ctags
Brian Sulcer [EMAIL PROTECTED] (1 bugs):
mgt 4023 mgt requires changes for multi-arch support
[EMAIL PROTECTED] (Andrew D. Fernandes) (2 bugs):
acs 3559 acs description: no ext
acs 3851 acs requires changes to support multiple arches
Kenny Wickstrom [EMAIL PROTECTED] (2 bugs):
tin 3787 tin uses /etc/news/descriptions instead of /etc/news/newsgr
tin 3942 tin cannot find Newsgroup Descriptions
Yves Arrouye [EMAIL PROTECTED] (2 bugs):
compress-p 4057 compress package install additional zcat
libpaper,4058 /etc/papersize doesn't allow spaces
Siggy Brentrup [EMAIL PROTECTED] (2 bugs):
electric-f 3582 electric-fence description: no ext
electric-f 4045 electric-fence requires changes for multi-arch support
Anders Christrom [EMAIL PROTECTED] (2 bugs):
lists.debi 3199 Bizarre message from [EMAIL PROTECTED]
lists.debi 3978 problem (re)subscribing to debian-devel
Kenneth MacDonald [EMAIL PROTECTED] (2 bugs):
ispell 2425 ispell thinks `formated' is correct
ispell 3196 ispell symlinks broken
Anders Chrigstrom [EMAIL PROTECTED] (2 bugs):
bison3955 yacc script uses $* instead of $@
bison4052 access permissions for /usr/bin/{mkparser, mkparserclass}
Martin Schulze [EMAIL PROTECTED] (2 bugs):
zoo 3676 zoo description: summary starts w/ pkg name
zoo 3961 14 character file name limit in zoo
Ray Dassen [EMAIL PROTECTED] (2 bugs):
www.debian 3431 some packages have no information on WWW-server
www.debian 3700 Web pages lack LINK REV=MADE ...
Christian Linhart [EMAIL PROTECTED] (2 bugs):
xarchie 887 xarchie barfs when ftp closes unexpectedly
xarchie 1275 xarchie clumsy with 2-button mouse
Steven B Dunham [EMAIL PROTECTED] (2 bugs):
hdparm 2197 hdparm -c switch
hdparm 3866 hdparm requires changes to support multiple arches
Chuck Stickelman [EMAIL PROTECTED] (2 bugs):
symlinks 3364 Problems encountered while compiling symlinks for m68k ar
symlinks 3614 symlinks description: ext extra spaces
David Frey [EMAIL PROTECTED] (2 bugs):
dump 3949 dump requires changes for multi-arch support
dump 4050 access permissions for dump
Giuseppe Vacanti [EMAIL PROTECTED] (2 bugs):
diald3457 diald control file problems
diald3573 diald description: ext start blank line
Raul Miller [EMAIL PROTECTED] (3 bugs):
sam 4030 sam requires changes for multi-arch support
ucbmpeg 3454 ucbmpeg control file problems
ucbmpeg 3509 mpeg_play puts bogus statistics on stdout
Doug Geiger [EMAIL PROTECTED] (3 bugs):
abuse3963 abuse
apsfilter3224 apsfilter doesn't configure on a read-only filesystem
apsfilter3812 Apsfilter should depend on file
[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
Richard Kettlewell [EMAIL PROTECTED] (3 bugs):
majordomo1881 Majordomo UID wrong?
repair 1532 no revision number with repair
vm 4031 vm requires changes for multi-arch support
joost witteveen [EMAIL PROTECTED] (3 bugs):
gsfonts 1112 a2gs output unusable by gs but usable by ghostview
gsfonts 3596 gsfonts description: no ext
gsfonts 3673 gsfonts
netscape 3.0-beta6-1 released
-BEGIN PGP SIGNED MESSAGE- Date: 07 Aug 96 00:45 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: Brian White [EMAIL PROTECTED] Source: netscape Version: 3.0-beta6-1 Binary: netscape Architecture: i386 source Description: netscape: Popular World-Wide-Web browser software (installer) - Netscape (pronounced Mozilla) is a graphical World-Wide-Web browser - with many features. It supports advanced features of HTML and new - technologies such as Java from Sun Microsystems. - . - Netscape Communications Corporation does not allow redistribution of - their software. Therefore, this package requires the user to fetch - the netscape archive seperately and place it in the directory pointed - to by the TMPDIR environment variable (or /tmp if TMPDIR not defined) - before attempting to install this package. You can get the linux - packages via anonymous ftp from ftp[1-9].netscape.com. - . - Do NOT try to install any version of Netscape other than 3.0-beta6 with - this package! - . - Netscape Communications Corporation does not support the Linux release - in the slightest, even for paying customers. It has been made available - purely as a courtesy, so please do not send them questions about Linux. - . - This installer package has been placed in the public domain! Changes: no changes info provided Files: 61f2cffc426f5cfaa376f150f899421b 3869 net- netscape_3.0-beta6-1.tar.gz 5b7a0dde47679d1f42856f35b7c3717b 3480 net extra netscape_3.0-beta6-1_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMgfnS7wRa6IPcXgFAQEq+gP/ayvs/bBx1qctXsiAXkt+tVR8Dfw+lzJM OayTvyOSAQnWh9SdstzXR1Qff/wEqH0DKDiOx0cgMy2VNL0TRjC6Yug5uYhHI/A3 JkDmDO3UUfLphdCNRowhVRhWTUA3EX3SVffgEca3HHHEzoiFg5HV6FwY/Y9mKlp5 p1rvGkUR4E0= =JeBb -END PGP SIGNATURE-
Bug#4011: simple c++ program segfaults
Guy Maor wrote:
It is legal to explicitly call a destructor but rarely needed. It
certainly makes no sense in this case, as the destructor will be called
twice.
The question, it seems, is what was the programmer trying to do?
Well I haven't got a clue on that one as I didn't write the code. But
I guess the more important question is that the crash did not seem to
be related to the destructor. That is, it crashes even without the call
to the destructor.
--
Debian GNU/Linux 1.1 is out! { http://www.debian.org/ }
A. B = True B. A = False
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
PGP Key: [EMAIL PROTECTED] or any other key sites
Re: fileutils can now replace perforate...
Hello, I have a question on that topic. I think sparse files are simply generated by lseek'ing over a block of zeros, which will automatically converted to sparse files by filesystems which support it (actually they could even create them if the notice blocks filled with 0's but dont do it). The question is, which filesystem generates sparse files and has problems with it? Generally, wht is the problem with sparse files? They seem to be completely transparent to me (except for cluttering the disk, perhaps). Greetings Bernd
Bug#3951: kernel-image-2.0.7-0 postinst looks for /bin/perl
Package: kernel-image Version: 2.0.7-0 The postinst and prerm scripts of kernel-image have as their first line: #! /bin/perl My vanilla installation of Debian 1.1 seems to have perl only in /usr/bin/perl. The problem is exhibited with: $ dpkg --install kernel-image-2.0.7-0.deb ... dpkg (subprocess): unable to execute post installation script: no \ such file or directory ... returned error status 2 ... $ The unpacking succeeds but the configuration fails. If I edit the kernel-image-2.0.7-0.postinst script in /var/lib/dpkg/info to add the /usr to the path of perl and do configure it all works nicely: $ dpkg --configure kernel-image-2.0.7 -- Dr [EMAIL PROTECTED] ,--_|\ Tel: (+61 6) 216 7042 Senior Research Scientist, Data Mining / \ Fax: (+61 6) 216 7112 CSIRO Div of Info Tech, Aust Nat Univ \_.--_*/ GPO Box 664 Canberra URL:http://www.dit.csiro.au/~gjw v ACT 2601 Australia
Bug#4019: Decompression failure on Install Boot Disk
Hi Chris -- I don't know if you have gotten Linux booted yet. If you haven't, please let me know. I'll be happy to make a boot disk for you and mail it to you by real, old-fashioned physical US Mail. Just let me know what kernel you need to have on it, or if you need a special one. Cheers, Susan Kleinmann [EMAIL PROTECTED] Package: Boot1440.bin Version: Debian 1.1 I have been unable to boot from the boot1440.bin image. I have tried the following: - downloaded the image from a variety of sources. - used several different floppies - erased (using dd if=/dev/zero ...) the floppies before writing the image to them. - formatted the floppies using a variety of tools When I attempt to boot, I get the following: invalid compressed format (err=2) Then it tells me that the system is halted. I've tried entering boot options (such as 'linux ether=10,0x320,eth0'). When I do this, I get a slightly different error message: incomplete literal tree Where do I go from here? Chris Hertel -)- [EMAIL PROTECTED] . -- Christopher R. Hertel -)- University of Minnesota [EMAIL PROTECTED] Networking and Telecommunications Services
Bug#4006: Fileutils has /usr/libexec directory
Hello, This dir is standard by make install in gnu packages and didn't see any harm so will not do an update just for removing this dir if you don't mind. If someone can come up with serious problems having this empty dir in the package I'll remove it. The new FHS will include /usr/libexec and a few other changes which wil require a lot of new packages to be released. Personally I like the new draft very much. Greetings Bernd
Bug#4006: Fileutils has /usr/libexec directory
[EMAIL PROTECTED] writes: Package: fileutils Version: 3.13-2 The fileutils package has an empty /usr/libexec directory in the .deb file. I don't think the FSSTND supports libexec yet, so the directory should be removed. This dir is standard by make install in gnu packages and didn't see any harm so will not do an update just for removing this dir if you don't mind. If someone can come up with serious problems having this empty dir in the package I'll remove it. Well, since Linux does not use libexec, it can confuse users and other developers. It should be removed in the next maintenance revision or before the next public release of Debian, which ever comes first. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Bug#4017: boot disk doesn't recognize NCR scsi
Hi Richard -- I've made a couple of NCR-aware kernels for friends. If you'd like one of them, you might try: ftp://sgk.phast.umass.edu/pub/boot1440.bin.gz If you have some special requirement and can't make your own, let me know and I'll make one for you. Cheers, Susan Kleinmann [EMAIL PROTECTED] Package: bootdisk Version: 1.1.1 Attempted to install Debian 1.1.1 from PHT cd rom. Bootdisk doesn't see my SCSI system, based on NCR 53c8xx PCI Rev 2.0 1993 This device worked find under Debian .93R6/ Linux 1.2.13
Bug#4011: simple c++ program segfaults
Is this actually a bug? I don't think you are supposed to call a destructor directly in this situation. I would assume that the crash comes when the destructor is called a second time when the program exits main. It is legal to explicitly call a destructor but rarely needed. It certainly makes no sense in this case, as the destructor will be called twice. It is legal, but highly discouraged! If the dtor is not implemented with this in mind (as most are not), then that could very easily be the cause of the seg fault. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
xpdf needs an entry in mailcap
The xpdf postinst needs to add itself to the mailcap file so it can be spawned by web browsers. I'd suggest the following in the postinst: if [ -x /usr/sbin/install-mime ] then install-mime --install --package=xpdf --content=application/pdf \ --view=/usr/bin/X11/xpdf %s --test='test $DISPLAY != ' \ --comment=A generic PDF viewer for X-Windows fi And the following in the prerm: if [ -x /usr/sbin/install-mime ] then install-mime --remove --package=xpdf fi Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: Could we use gunzip -c instead of zcat?
I'd like to suggest that scripts, debian.rules etc... use gunzip -c instead of zcat when the intent is to get the contents of a gzipped file on stdout. This is because if binaries from a BSD compress package (not necessarily built with compress-package) will make a true zcat available on the system, which of course cannot handle gzipped files. Calling gzip -dc would be an even better solution. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: xpdf needs an entry in mailcap
[ I goofed on the first message. Use this one instead. :-] The xpdf postinst needs to add itself to the mailcap file so it can be spawned by web browsers. I suggest the following in the postinst: if [ -x /usr/sbin/install-mime ] then install-mime --install --package=xpdf --content=application/pdf \ --description='Adobe Acrobat File' --nametemplate=%s.pdf \ --view=/usr/bin/X11/xpdf %s --test='test $DISPLAY != ' fi And the following in the prerm: if [ -x /usr/sbin/install-mime ] then install-mime --remove --package=xpdf fi The 'if' statements can be removed if you want to add a dependancy on mime-support (=2.0). Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Bug#4065: FEATURE(local_procmail) needs manual override to /usr/bin
Package: sendmail Version: 8.7.5-4 This line in sendmail.mc: FEATURE(local_procmail) doesn't work, because it's looking in /usr/local/bin. This works: FEATURE(local_procmail, `/usr/bin/procmail') (assuming the procmail package is installed), but it shouldn't be necessary to do this as procmail is a standard Debian package. /usr/lib/sendmail.cf/features/local_procmail.m4 should have its embedded path changed. -- Shields, CrossLink.
Bug#4057: compress package install additional zcat
Hmmm. This is somewhat more complex than it looks like. I cannot just remove /usr/bin/zcat because it is intimately linked with compress. I disagree. The job of a package maintainer includes the process of doing things like this to a package. I have to do the same thing for the tar package, for example, where we've agreed that the tar package will not provide the 'rmt' executable, even though the GNU tar upstream sources makes it easy to include and annoying to remove. The complexity of handling alternatives just isn't worth it for silly stuff like this. If you say 'man compress' for example you'll get the synopsis for zcat too and if the corresponding zcat would not be provided then I think users can be confused. By definition, a Debian system will have 'zcat' from the gzip package, since gzip is an essential base package. I don't see a problem here. In addition I have no control about what programs will be built by make-cpkg. Why not? I haven't looked at your compress package, but I can't see what the problem would be, offhand. My opinion is that gzip should *not* provide /bin/zcat but rather /bin/gzcat (and the same for other z* tools). I disagree. Prefixing stuff with the 'g' isn't particularly useful. In this case, the 'zcat' provided by gzip is a *superset* of the functionality provided by the 'zcat' in the compress package, and I can see no rational explaination for preferring the version that comes with compress over the version that comes with gzip. people should refrain from using zcat in scripts when the intent is to gunzip something... Why? If gzcat was provided and /usr/bin/zcat a symbolic link to it, the zcat link would correctly be diverted by any compress-package generated package and nobody would have two semantically different zcat commands installed by installing these packages. Why don't you just make your compress package *not* provide the 'zcat' command, since any Debian system by definition has the gzip package installed (since it's an essential base package), and the 'zcat' provided with gzip is a superset that will always do the expected thing with a compressed file? I continue to be willing to convinced that I'm wrong about all this, but so far, all you've done is to say that gzip's zcat does more than the one that compress provides, which I already knew... and then whine about how it's hard to make your package do what it should given what's already provided by gzip. Bdale
Bug#4066: strangeness with X3 server
Package: xserver-s3 Version: 3.1.2-5 I think this may be related to the mouse cursor problem I reported earlier. I noticed this problem shortly after sending that bug report, but didn't fully investigate it until now. (The other bug report contains information not reproduced here.) I have an Diamond Stealth64 Video 3200 (S3-968 based) PCI video card with 2 MB VRAM running on a really crappy 1024x768 SVGA monitor that won't run legibly above 640x480. I was trying to determine if using the virtual window (server-based) feature of X was causing the mouse cursor problem, so I shut it off by using a virtual window the same size of the screen (640x480). I did not run a window manager for the purposes of isolating the bug. If I position any window such that it extends beyond the left edge of the screen (obscuring a strip of window), then approximately 8 pixels of the window (the part of the window you shouldn't be able to see because they're off the screen) appear in a strip on the right side of the screen. Pretty bizarre. To illustrate this graphically, let this little thingy represent a window where each letter is about 8 pixels wide. ABCDEFGH ABCDEFGH ABCDEFGH Not drawn to scale, you get. ++ |BCDEFGHA| |BCDEFGHA| |BCDEFGHA| || || || || || ++ If you position the mouse over A, it still thinks it is over the main window. In other words, the mouse knows where it is supposed to be! This is what the window should look like (since I put the upper RHS of the window at 0, 0). ++ |ABCDEFGH| |ABCDEFGH| |ABCDEFGH| || || || || || ++ Also, the gray background pattern is interrupted near the right edge in a analogous fashion to this pattern. (I'd go blind if I tried to reproduce the actual wicker pattern.) X X X X X X X XX X X X X X X X X X X X X X X X X X X X X XX X X X X X X X X X X X X X X X X X X X X XX X X X X X X X X X X X X X X X X X X X X XX X X X X X X X X X X X X X |--| 8 pixels (as best as I can tell)
Bug#4058: etc/papersize doesn't allow spaces
Oh, BTW, this has nothing to do with libpaper (I don't know why you think it does, gs doesn't depend on libpaper, and has been reading /etc/papersize before the existance of libpaper.) I do wonder if libpaper does a better job, Yes it does ;-) That's its big advantage: centralize such bugs in one place so that we're sure all packages get fixed at once (who said I wanted to share features too? ;-)) and I do wonder if gs really should read A4 . Some people were really glad I added a wrapper to allow gs to read /etc/papersize. Some are angry it didn't read A4 . Well, you never please them all! Can you try my gsfrontend.c in libpaper 0.3? It would be nice if you used it for these reasons: - people will benefit from new paper sizes immediately; That's not true, the gs wrapper I have reads _all_ papersizes gs understands. (it gets them at compile time from ps_init.ps or something) - I think if something else than me provides a working package using libpaper, other package maintainers will start adopting it; - I won't have to overwrite your gs with my wrapper each time you make a new package ;-). If you use my wrapper (please, please...), I suggest installing the real gs as 'ghostscript' (a meaningfull name, no?) and the wrapper as 'gs' of course. Apparently people were confused by your gs-papersize being the gs that does not handle papersize despite its name. So, that's not the case any more (the real gs is gs.real, the wrapper is gs). What is causing me not to upgrade gs at the moment is this SVGA stuff: someone (svga maintainer) wanted a patch in that would make a setuid root gs safe, but I'm still having problems with this. -- joost witteveen [EMAIL PROTECTED] [EMAIL PROTECTED] -- Use Debian/GNU Linux!
Bug#4063: magicfilter has wrong path
2. There is another problem with extracting the filter from the set of filters in /usr/doc/examples/magicfilter/filters/filters.tar.gz as the extracted file is not registered with dpkg --- upon removal of the package a useless file will remain on the machine. a if [ $1 = purge ] ; then in postrm should remove these filters IMHO. I suggested this unpacking of filter because these filters take up quit some space and they are never used. 4. The package suggests pbmplus, and we don't seem to have such a package. I think that netpbm replaced pbmplus. I'm sure on this. Erick
Bug#4067: Umsdos 0.8.4 needs upgrade.
Package: Umsdos Version: 0.8.4 Debian linux 1.1 (kernel 2.0.6, libc 5.2.18) umssync fail to produce the --linux-.--- files. By upgrading to version 0.9 of the umsdos programs the problem is solved.
Re: dpkg-changelog-mode (dpkg-changelog.el)
Ian Jackson writes: My upload of dpkg 1.3.0 didn't include the file below. It is an Emacs mode for editing the changelogs that dpkg-parsechangelog understands. Do we have an official look the changelog has to have? If so how should it look? I won't be able to test your emacs style since I don't use emacs. Michael -- Michael Meskes |_ __ [EMAIL PROTECTED] | / ___// / // / / __ \___ __ [EMAIL PROTECTED] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [EMAIL PROTECTED]| ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian Linux!| //_/ /_/ //\___/_/ //
Bug#4064: sendmail should recommend deliver, not depend
You (Michael Shields) wrote: Package: sendmail Version: 8.7.5-4 sendmail depends on deliver. However, in at least two common configurations -- null client, and delivery by procmail -- it will run perfectly without deliver. sendmail should only recommend it. And as a result you can install sendmail without deliver and your mail installation won't work at all.. Sendmail should come with mail.local instead of deliver IMHO. Mike. -- Miquel van| Cistron Internet Services --Alphen aan den Rijn. Smoorenburg, | mailto:[EMAIL PROTECTED] http://www.cistron.nl/ [EMAIL PROTECTED] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)
Bug#4057: compress package install additional zcat
Yves Arrouye writes: Hmmm. This is somewhat more complex than it looks like. I cannot just remove /usr/bin/zcat because it is intimately linked with compress. If you say 'man compress' for example you'll get the synopsis for zcat too and if the corresponding zcat would not be provided then I think users can be confused. I've found nothing in your zcat that GNU zcat can't do. My opinion is that gzip should *not* provide /bin/zcat but rather /bin/gzcat (and the same for other z* tools). The /bin/zcat program is just *not* zcat, it also handles gzip files which the original zcat program cannot do. I think that we should have /bin/gzcat (or But that means it can do more than the original one. So why not using this name? Michael -- Michael Meskes |_ __ [EMAIL PROTECTED] | / ___// / // / / __ \___ __ [EMAIL PROTECTED] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [EMAIL PROTECTED]| ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian Linux!| //_/ /_/ //\___/_/ //
Bug#4057: compress package install additional zcat
Yves Arrouye writes: Michael Meskes writes: Package: compress-package Version: 1.2-1 Compiling and installing the compress source found on ftp.inria.fr I get a file /usr/bin/zcat. However, gzip already install zcat in /bin. I cannot see how it's useful to have both. :-) My opinion is that gzip should *not* provide /bin/zcat but rather /bin/gzcat (and the same for other z* tools). The /bin/zcat program is just *not* zcat, it also handles gzip files which the original zcat program cannot do. I think that we should have /bin/gzcat (or even /usr/bin/gzcat because gzip only should be enough in /bin) and have /usr/bin/zcat be a symbolic link to gzcat installed by the gzip package (and not an alternative as I suggested before). And most importantly people should refrain from using zcat in scripts when the intent is to gunzip something... If gzcat was provided and /usr/bin/zcat a symbolic link to it, the zcat link would correctly be diverted by any compress-package generated package and nobody would have two semantically different zcat commands installed by installing these packages. IMHO: There should be one zcat and it should always be gzip. This won't break anything as gzip understands .Z files... Making zcat point to compress even sometimes will definitely break things; IME much of the Linux world has been assuming it's gzip for a number of years. That seems unlikely to change. compress is obsolete software; there's never any need to use it to uncompress things. Indeed, my experience (err, on Sunos rather than Linux, so this may not be relevant) is that gzip is much more reliable even at uncompressing .Z files. I can't see the need to compress things using compress either, as gzip produces smaller output, runs on pretty much everything and is free. -- Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#4068: pgs in perl-tk does not work
Package: perl-tk
Version: b11.02-3
Typing pgs at the prompt produces these messages:
Use of uninitialized value at /usr/lib/perl5/Tk/DSC.pm line 15.
Can't use an undefined value as a HASH reference at /usr/bin/pgs line 16.
I've got perl 5.003-2 and tk41 4.1-1 for that matter.
--
Debian GNU/Linux 1.1 is out! { http://www.debian.org/ }
A. B = True B. A = False
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
PGP Key: [EMAIL PROTECTED] or any other key sites
Bug#4069: slrn gives error
Hello developers, Package: slrn Version: 0.8.7.1-3 When I invoke slrn it prints: slrn: can't resolve symbol 'SLang_define_key1' and exits. transcript: $slrn slrn: can't resolve symbol 'SLang_define_key1' $ I am using debian 1.1 kernel version 2.0.0 #8 and libc.so.5.2.18 . succes
