Re: New virtual package names.
On Wed, 21 Aug 1996, Ian Jackson wrote:
> 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.
The burden I am trying to shift onto your shoulders is for you to have
read the complete thread of this discussion. It is not clear that you have
done so. You declared the needlessness but gave no explanation of why this
was so.
The rest of us, as a group, have discussed this, at some length, and come
to the conclusion that the editor virtual package name was a viable
solution. As a late arrival to this discussion it is your responsibility
to have, at least, read the complete discussion, and speak to the points
raised and settled there. Blanket assertions without supporting arguments
are neither constructive, nor informative.
>
> > > * 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.
>
Well, if you read the foundation postings on this subject, the nut does
exist. I still think that we are using the right sized wrench.
Later,
Dwarf
--
aka Dale Scheetz Phone: 1 (904) 877-0257
Flexible Software Fax: NONE
Black Creek Critters e-mail: [EMAIL PROTECTED]
If you don't see what you want, just ask --
Bug#4236: ftp(1) barfs on QUOTE command
Package: netstd
Version: 2.06-1
muskogee:richard$ uname -a
Linux muskogee 2.0.13 #1 Tue Aug 20 18:45:22 BST 1996 i486
muskogee:richard$ ftp wigwam
Connected to wigwam.elmail.co.uk.
220 wigwam.elmail.co.uk CheckPoint FireWall-1 authenticated ftp server ready
Name (wigwam:richard): richard
331-aftpd: SKEY CHALLENGE: 92 richard
331 aftpd: you can use [EMAIL PROTECTED] string
Password:
200 aftpd: Enter SKEY string: you can use 'quote SKEY string' or Account
command ('ACCT')
ftp> quote
Not connected.
ftp> quit
This happens consistently. I don't know why the ftp client thinks
there's no connection - if deeper investigation is required I let me
know.
FWIW compare this with telnetting to the ftp port:
muskogee:richard$ telnet wigwam ftp
Trying 193.112.20.200...
Connected to wigwam.elmail.co.uk.
Escape character is '^]'.
220 wigwam.elmail.co.uk CheckPoint FireWall-1 authenticated ftp server ready
user richard
331-aftpd: SKEY CHALLENGE: 91 richard
331 aftpd: you can use [EMAIL PROTECTED] string
pass
200 aftpd: Enter SKEY string: you can use 'quote SKEY string' or Account
command ('ACCT')
200-aftpd: User richard authenticated by S/Key system.
200 aftpd: Host: (use 'quote ')
mojave
421-aftpd: Connected to mojave. Logging in...
421 aftpd: aborted
Connection closed by foreign host.
muskogee:richard$
(mojave was down when I did all this but it serves to illustrate the
point...)
With Sunos 4.1.3's ftp client:
[EMAIL PROTECTED]:richard$ uname -a
SunOS tlingit 4.1.3_U1 2 sun4m
[EMAIL PROTECTED]:richard$ ftp wigwam
Connected to wigwam.
220 wigwam.elmail.co.uk CheckPoint FireWall-1 authenticated ftp server ready
Name (wigwam:richard): richard
331-aftpd: SKEY CHALLENGE: 90 richard
331 aftpd: you can use [EMAIL PROTECTED] string
Password:
200 aftpd: Enter SKEY string: you can use 'quote SKEY string' or Account
command ('ACCT')
ftp> quote
200-aftpd: User richard authenticated by S/Key system.
200 aftpd: Host: (use 'quote ')
ftp> quote muskogee
421-aftpd: User [EMAIL PROTECTED] is not allowed for service ftp on muskogee.
421 aftpd: aborted
ftp>
(again, this serves to illustrate the point, even if it didn't
actually work fully.)
--
Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED]
http://www.elmail.co.uk/staff/richard/
Bug#4234: errors in /usr/man/man8/make-kpkg.8
Package: kernel-package Version: 2.03 The man page for make-kpkg has a few typos, some of which refer to file names and might therefore cause confusion. A diff file is attached. Susan Kleinmann *** make-kpkg.8 Thu Aug 22 10:40:19 1996 --- make-kpkg.8.rev Thu Aug 22 10:56:23 1996 *** *** 28,34 file using PGP. This option will override the builtin default and the site wide customizations stored in the file ! .B /etc/kernal-package.conf. This option is only relevant to the .B dist target, since that is the only target that uses --- 28,34 file using PGP. This option will override the builtin default and the site wide customizations stored in the file ! .B /etc/kernel-package.conf. This option is only relevant to the .B dist target, since that is the only target that uses *** *** 128,138 If there is no .I .config file in the kernel source directory, a default configuration is provided ! similair to the one used to create the .B Debian boot\-floppies. The package produced updates the .I /boot/psdatabase ! file at install time, it also update symbolic links in the root directory to point to the new kernel image in .I /boot. It also offers to run the --- 128,138 If there is no .I .config file in the kernel source directory, a default configuration is provided ! similar to the one used to create the .B Debian boot\-floppies. The package produced updates the .I /boot/psdatabase ! file at install time, it also updates symbolic links in the root directory to point to the new kernel image in .I /boot. It also offers to run the *** *** 186,202 file run by .B make\-kpkg also looks for site\-wide defaults in the file ! .I /etc/kernel-packge.conf. The default configuration allows there to be a site wide override for the full name and email address of the person responsible for maintaining the kernel packages on the site, but the ! .I /etc/kernel-packge.conf file is actually a Makefile snippet, and any legal make directives may be included in there. .B Note: Caution is urged with this file, since you can totally change the way that the ! make is run by suitable editing this file. .SH "SEE ALSO" .BR dchanges (1), .BR make (1), --- 186,202 file run by .B make\-kpkg also looks for site\-wide defaults in the file ! .I /etc/kernel-package.conf. The default configuration allows there to be a site wide override for the full name and email address of the person responsible for maintaining the kernel packages on the site, but the ! .I /etc/kernel-package.conf file is actually a Makefile snippet, and any legal make directives may be included in there. .B Note: Caution is urged with this file, since you can totally change the way that the ! make is run by suitably editing this file. .SH "SEE ALSO" .BR dchanges (1), .BR make (1),
Bug#4233: startx does not initialize X cookies
Package: xbase Version: 3.1.2-9 The startx script does not initialize the X Magic Cookies when X is started up. This can be a significant security hole. I would suggest adding a line like xauth add :0 . `dd if=/dev/urandom count=1 bs=16 | md5sum` to startx (ok, so md5sum is merely the fastest way to get a correctly formatted string - possibly od can be persuaded with the right options, or somebody can write a Perl script). -- Thomas Koenig, [EMAIL PROTECTED], [EMAIL PROTECTED] The joy of engineering is to find a straight line on a double logarithmic diagram.
Bug#4232: bison dumps core
Package: bison
Version: A2.6-12
The following input file (which contains errors, I know :-) causes
bison to dump core.
I have no idea wether this is a libc or a bison error. Gdb tells me
the following:
$ gdb /usr/bin/bison core
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.15.1 (i486-linux), Copyright 1995 Free Software Foundation, Inc...
(no debugging symbols found)...
Core was generated by `bison crash.y'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.5.2.18...(no debugging symbols found)...done.
Reading symbols from /lib/ld-linux.so.1...(no debugging symbols found)...done.
#0 0x4003c567 in malloc ()
Here's the input file (called crash.y):
%{
#include
#define YYDEBUG 1
time_t currtime;
struct tm currtm;
struct tm exectm;
%}
%union {
struct tm tmstruct;
time_t timet;
int intval;
}
%token INT
%token NOW
%token TIMEZONE_NAME
%token AM PM
%token NOON MIDNIGHT TEATIME
%token SUN MON TUE WED THU FRI SAT
%token TODAY TOMORROW
%token NEXT
%token MINUTE HOUR DAY WEEK MONTH YEAR
%token JAN FEB MAR APR MAY JUN JUL AUG SEP OCT NOV DEC
%token WORD
%type inc_period
%start timespec
%%
timespec: time
| time date
| time increment
| time date increment
| time decrement
| time date decrement
| nowspec
;
nowspec : now
| now increment
| now decrement
;
now:: NOW
;
time: hr24clock_hr_min
| hr24clock_hr_min timezone_name
| hr24clock_hour time_sep minute
| hr24clock_hour time_sep minute timezone_name
| hr24clock_hour am_pm
| hr24clock_hour am_pm timezone_name
| hr24clock_hour time_sep minute am_pm
| hr24clock_hour time_sep minute am_pm timezone_name
| NOON
| MIDNIGHT
| TEATIME
;
date: month_name day_number
| month_name day_number ',' year_number
| day_of_week
| TODAY
| TOMORROW
;
increment : '+' inc_number inc_period
{
switch($3) {
case MINUTE:
exectm.tm_min
break;
default:
yyerror("Internal parser error");
YYERROR;
}
}
| NEXT inc_period
;
decrement : '-' inc_number inc_period
;
inc_period : MINUTE { $$ = MINUTE ; }
| HOUR { $$ = HOUR ; }
| DAY{ $$ = DAY ; }
| WEEK { $$ = WEEK ; }
| MONTH { $$ = MONTH ; }
| YEAR { $$ = YEAR ; }
;
hr24clock_hr_min: INT
;
timezone_name : TIMEZONE_NAME
;
hr24clock_hour : INT
;
minute : INT
;
am_pm : AM
| PM
;
month_name : JAN
| FEB
| MAR
| APR
| MAY
| JUN
| JUL
| AUG
| SEP
| OCT
| NOV
| DEC
;
day_number : INT
;
year_number : INT
;
day_of_week : SUN
| MON
| TUE
| WED
| THU
| FRI
| SAT
;
inc_number : INT
;
time_sep: ':'
| '\''
| '.'
| 'h'
| ','
;
%%
#include "mydate.h"
time_t parsetime(int, char **);
int
main(int argc, char **argv)
{
#ifdef YYDEBUG
yydebug = 1;
#endif
currtime = time(NULL);
currtm = *localtime(&currtime);
yyparse();
}
int yyerror(char *s)
{
fprintf(stderr,"%s. Last token seen: %s\n",s, last_token);
return 0;
}
Re: HELP! (pppd and slirp)
On Thu, 22 Aug 1996 02:01:47 -0400 I wrote: < re pppd and slirp I must have been really tired when I sent this -- I don't know why I wrote debian-devel in the To: list. Well, nobody responded but I figured it out anyway. It seems as though problem was likely to come partly from the kernel not having a proper System.map (and killing syslog), and partly from expecting the kernel daemon to load slhc properly. Once set up modules to load slhc and pppd in the order specified in the README, and fixed the map, I was able to get debugging info and have ppp work. Thanks, Jim
Bug#4227: Tin TIN_NOVROOTDIR wrong value for tin
> Package: tin > Version: 1.3beta.950824-12 > > The default value of TIN_NOVROOTDIR is /var/lib/news. The Debian INN uses > /var/lib/news/over.view to store the overview database. > > The result of this problem is two overview databases one in /var/lib/news and > one in > /var/lib/news/over.view. Plus there is a slow response since tin has to > generate those > indexes that are already there. > > I fixed it by setting Version: 1.3beta.950824-12 > TIN_NOVROOTDIR in /etc/profile You mean /var/spool/news and /var/spool/news/over.view -- 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)
Re: Shadow vss PAM
Date: Wed, 21 Aug 96 11:59 PDT From: [EMAIL PROTECTED] (Bruce Perens) Cc: debian-devel@lists.debian.org (Debian Development) Patrick Weemeeuw writes: > I would propose to go for shadow for 1.2. > In the mean time, I will try to make a few applications PAM-aware, > to wet my feet and to gain some insight about how simple or complex > things are. After all, it's not a black or white thing, but we can > PAMify application by application. Good decision. If I understand you correctly, we can set PAM to authenticate via shadow password only and deploy it in a piece-wise fashion. Then, once we have it deployed fully, we can start to introduce additional methods of validation. Thanks Bruce Even better yet: as soon as any application has been adapted to PAM it can use all available PAM modules immediately (as configured by the system administrator per application), independently of the status of other authentication clients. I also hope that the support for shadow passwords is compatible with the current shadow package: that would avoid most transition problems. Patrick.
Bug#4222: dig in the wrong package?
> Package: bind > Version: 4.9.3-P1-3 > > `dig' really belongs in the `dnsutils' package, not the `bind' > package; just because one is not running a local name server does not > imply that one doens't want to use `dig' to look things up. > May I suggest that the "nslookup" in the dnsutils package is replaced by the real one. The nslookup in dnsutils is now a shell script wrapper around "host" and I HATE IT HATE IT HATE IT I guess I've made my point haven't I :) 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#4231: acct(2) man page refers to nonexistent acct(5) man page
Richard> Package: manpages Richard> Version: 1.11-4 ... Richard> No manual entry for acct in section 5 I wrote a realy minimial acct(5) for the acct package which basically refers back to acct(2), see below. As acct.h is in the kernel source, and hence in libc5-dev, this acct.5 (or an improved version) chould move to manpages. .TH ACCT 5 "1995 October 31" "Debian/GNU Linux" .SH NAME acct \- execution accounting file .SH SYNOPSIS .B #include .SH DESCRIPTION The kernel maintains an accounting information structure for all processes. If a process terminates, and accounting is enabled, the kernel calls the .BR acct (2) function to prepare, and then append, a record for this process to the accounting file. The accounting structure .B "struct acct" is described in the file .IR /usr/src/linux/include/acct.h . .SH SEE ALSO .BR acct (2), .BR sa (1). -- Dirk Eddelb"uttel http://qed.econ.queensu.ca/~edd
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.
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
build: config.status
make
config.status:
./configure --prefix=/usr $(arch)
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)
HELP! (pppd and slirp)
If anyone out there has pppd working with slirp, I would surely appreciate getting a copy of their chat and options file (remember to edit our the password!). I've been trying on and off for weeks now, spending 15 minutes trying to figure out why pppd dials, seems to connect, and then hangs up (no debugging info shows up in messages, daemon, or debug...). I've decided to give up and ask for help. Anyone? Jim
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? Erick
Re: Consensus is for compressed manpages
From: Ian Jackson <[EMAIL PROTECTED]> > Further to this discussion, I'm going to write into the policy manual > that manpages should be installed compressed using gzip -9. Good. I said it was OK to start doing it a while back, but I never said _everyone_ should do it, and no doubt I should have said that some time ago. Thanks Bruce
Bug#4231: acct(2) man page refers to nonexistent acct(5) man page
Package: manpages Version: 1.11-4 According to `man 2 acct': SEE ALSO acct(5) But: [EMAIL PROTECTED]:richard$ man 5 acct No manual entry for acct in section 5 [EMAIL PROTECTED]:richard$ -- Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
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.
Bug#4228: syslogd loops
Package: sysklogd Version: 1.3-10 Aug 21 13:59:47 beagle syslogd 1.3-0#10: restart. Aug 21 13:59:47 beagle kernel: klogd 1.3-0, log source = /proc/kmsg started. Aug 21 13:59:47 beagle syslogd 1.3-0#10: restart. Aug 21 13:59:47 beagle syslogd: select: Bad file number Aug 21 14:00:17 beagle last message repeated 103329 times Aug 21 14:01:17 beagle last message repeated 244779 times Aug 21 14:02:17 beagle last message repeated 245329 times and so on... Thanks Bruce
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#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#4137: libpaper contains compressed manpage, or policy should change
Yves> I remember that a long time ago it was said that it was okay to gzip Yves> manual pages because the manual reader did handle them nicely? Lars> Our man seems to handle them OK. Since there can be tens of Lars> megabytes of manual pages (I have 18 MB), I think compressing them Lars> would be a good idea. We already compress them. I seem to have 108 compressed man pages, coming from 14 of the 210 packages I have installed. Could this be added to the guidelines as either a policy, or at least an option? [EMAIL PROTECTED]:~> find /usr/man -name \*.gz | wc -l 108 [EMAIL PROTECTED]:~> grep -l -e "/usr/man.*gz" /var/lib/dpkg/info/*list | wc -l 14 [EMAIL PROTECTED]:~> ls -1 /var/lib/dpkg/info/*list | wc -l 210 -- Dirk Eddelb"uttel http://qed.econ.queensu.ca/~edd
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.
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.
Bruce - fiat required to end discussion on lyx/copyright ?
Bruce, if you feel it is appropriate, I'd like you to use your magic fiat power to end the discussion about lyx, contrib, and so forth, by endorsing the appropriate part of the new policy manual. I've attached a copy below. According to that part lyx, all the Motif packages and the compress installer need to go in contrib because of their dependency (at build- or run-time) on non-free software. Alternatively, if noone objects to this message proposing a sensible different _policy_ rather than that we should make an exception I'll take it that what I've written there is agreed by the project. Ian. 2. Package copyright Please study the copyright of your submission *carefully* and understand it before proceeding. If you have doubts or questions, please ask. The aims of the policy detailed below are: * That any user be able to rebuild any package in the official Debian distribution from the original source plus our patches. * That we make available in our packaging formats as much software as we can. * That it be easy for people to make CDROMs of our distribution without violating copyrights. 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. Packages whose copyright permission notices (or patent problems) do not allow distribution and copying for profit, without restriction on the amount charged, or where distribution is restricted according to the medium used, or where the distributor must ask any kind of special permission of the authors, or with other onerous conditions, may only be placed in the semi-supported non-free section of the Debian FTP archives. This is important so that CDROM manufacturers can distribute Debian without having to check the copyright of each package individually, simply by leaving out the contents of the non-free area; CDROM distributors are encouraged, though, to check the copyrights on programs in non-free individually and include as many as they can. Packages whose copyright permission notices (or patent problems) allow only distribution of compiled binaries (and thus of which only binaries are available), or where the source code which may be distributed is not the complete source code required to compile the program (ie, the program cannot be compiled using only packages in the main Debian distribution), or which depend for their use on non-free or contrib packages, or allow free use only for a trial period (shareware), or are demonstration programs lacking vital functionality (crippleware), or are only installer-packages which require the user to supply a separate file to be installed, or which fail to meet some other policy requirements, may only be placed in the semi-supported contrib section of the Debian FTP archives (unless they need to be in non-free - see above). Programs whose authors encourage the user to make donations are fine for the main distribution, provided that the authors do not claim that not donating is immoral, unethical, illegal or something similar; otherwise they must go in contrib (or non-free, if even distribution is restricted by such statements). Packages whose copyright permission notices (or patent problems) do not allow redistribution even of only binaries, and where no special permission has been obtained, cannot placed on the Debian FTP site and its mirrors at all. Note that under international copyright law[1] *no* distribution or modification of a work is allowed without an explicit notice saying so. Therefore a program without a copyright notice *is* copyrighted and you may not do anything to it without risking being sued! Likewise if a program has a copyright notice but no statement saying what is permitted then nothing is permitted. [1] This applies in the United States, too. Many authors are unaware of the problems that restrictive copyrights (or lack of copyright notices) can cause for the users of their supposedly-free software. It is often worthwhile contacting such authors diplomatically to ask them to modify their terms generally, or specially for Debian. However, this is a politically difficult thing to do and you should ask for advice on debian-devel first. When in doubt, send mail to . Be prepared to provide us with the copyright statement. Software covered by the GPL, public domain software and BSD-like copyrights are safe; be wary of the phrases `commercial use prohibited' and `distribution re
Re: libpaper 1.0 on master
joost witteveen wrote: > > > > > >Shouldn't the "paper size" be an attribute of a print queue, and not an > > >attribute of a machine? > > Well, it could be argued that Yvess libppaper could look at > the current $PRINTER setting, and select the correct papersize > depending on the /etc/papersize.printer file or something. But > at the moment not very many programmes use libpaper or /etc/papersize, > so it's better to have them at least get to recognise a global > /etc/papersize than nothing. Yup, sometimes something is better than nothing. Then again, sometimes "something part way" makes it harder to get to "all the way" too. If you make it queue-specific, it might be best to add it into /etc/printcap (as opposed to /etc/papersize.queuename). There is precedent for this (with at least one printer I've set up), and it's discussed in at least one popular book about system administration (by Evi Nemeth, under the name "printcap extensions"). BTW, this book lies thru it's teeth about Solaris 2.x, Parsing /etc/printcap is a simple matter - 20 lines of /bin/sh, or pgetent in the lpd source. An external library, such as libpaper.*, is precisely the right place to put such a thing. AS long as it has a good'n'general interface, the long-term nice-scenario get here eventually. > > Paper size effect more that just printers. Previewers and tex tools > > come to mind, there may be others... > > > > All I know is right now I've got to tweak quite a few things on a > > standard debian 1.1 system so that dvips, xdvi, genscript, and a few > > other programs work well and have the same idea of a default paper > > size. > > Well, after you've done the tweaking, maybe it's worth the little > extra efford of mailing the patches to the maintainer/bug-system > and wait to see them included in the next release? > If you don't want to do that, could you send your patches to me, > so that try to handle it?
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.
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: 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: 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: 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: 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.
copyright files in /usr/doc//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//changelog.Debian.gz, or changelog.gz for a package whose upstream and Debian maintainers are the same. 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.
`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.
Bug#4227: Tin TIN_NOVROOTDIR wrong value for tin
Package: tin Version: 1.3beta.950824-12 The default value of TIN_NOVROOTDIR is /var/lib/news. The Debian INN uses /var/lib/news/over.view to store the overview database. The result of this problem is two overview databases one in /var/lib/news and one in /var/lib/news/over.view. Plus there is a slow response since tin has to generate those indexes that are already there. I fixed it by setting Version: 1.3beta.950824-12 TIN_NOVROOTDIR in /etc/profile
Re: Shadow vss PAM
Patrick Weemeeuw writes: > I would propose to go for shadow for 1.2. > In the mean time, I will try to make a few applications PAM-aware, > to wet my feet and to gain some insight about how simple or complex > things are. After all, it's not a black or white thing, but we can > PAMify application by application. Good decision. If I understand you correctly, we can set PAM to authenticate via shadow password only and deploy it in a piece-wise fashion. Then, once we have it deployed fully, we can start to introduce additional methods of validation. Thanks Bruce
Bug#4220: ghostview and /etc/papersize
Package: ghostview Version: 1.5-8 When I installed this version of ghostview, it issued the message cat: /etc/papersize: no such file or directory but didn't return a non-zero exit status to dpkg, which therefore assumed that the installation had succeeded. This is two bugs. Firstly it should behave sensibly in the absence of /etc/papersize (or depend on a package which is known to provide it, though I think this is not as good an option). Secondly the postinst script ignores any errors that occur; it should include `set -e' so that errors are never ignored. -- Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#4226: Mosaic fails to substitute %XX in mailto: URLs
Package: mosaic Version: 2.7b5-2 See the page 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. mailto:ijackson%40chiark.chu.cam.ac.uk";> test page testing 1 2 3 mailto:ijackson%40chiark.chu.cam.ac.uk";>spong
Bug#4225: lynx fails to substitute %XX in mailto: URLs
Package: lynx Version: 2.4-FM-960316-1 See the page 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 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. mailto:ijackson%40chiark.chu.cam.ac.uk";> test page testing 1 2 3 mailto:ijackson%40chiark.chu.cam.ac.uk";>spong
Bug#4224: Mosaic produces poor rendering of nested markup
Package: mosaic
Version: 2.7b5-2
See the page
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:
* doesn't work correctly inside - it overrides the
italics produced by .
* inside a fails to go back to the ordinary proportional
font from the fixed one produced by .
* and headings like fails to work properly with
and elements inside them - the and go back to
ordinary sized not-bold text.
* The typographic markups and work correctly, as does
inside .
Ian.
mailto:[EMAIL PROTECTED]">
test page
testing 1 2 3
mailto:[EMAIL PROTECTED]">spong
testing spong
The var strong-var var.
Should be: times italic, times italic bold
The code var-code code.
Should be: courier, times italic
The code em-code code.
Should be: courier, courier italic
The strong code-strong strong.
Should be: times bold, courier bold
The strong var-strong strong.
Should be: times bold, times italic bold
The tt i-tt tt.
Should be: courier, courier italic
The i tt-i i.
Should be: times italic, courier italic
The code and var in the heading
Should be: large times bold, large courier bold, large times italic bold.
begin 664 mosaic-2.7b5-2-nested-markup.xwd.gz
M'XL(`+I%&S("`^V=#W`;57['5Q$7T<'U!FB+71QO0AAG>E..).XE-C$1+0P<
M,T?"E,FDG<`EP<&>ZQ$KB4%.*MOKG)D89ES[.,^5:&[EMAIL PROTECTED]&RO
M78<8$\6^7J=PJ;#71CF[W,5>"8%7ROYY?6__R+)CY'CWP3'A[=C2:B5]]=G?
MV_?;][[2>TM1U',41;[EMAIL PROTECTED]"_F](7^)A:L^#^4>KJQ6&\?T7&^VGX
M_VWTY/;['_OK-7^WYA%/];X?EJ_9])TM3WYWS>YGGJI^9LW!?95//9$AX]*T
[EMAIL PROTECTED]:XJ)V8%X!Y8<'7>_GF\?5]']TF69#0'P?>MS
M'VJ":[D'1];?>CP'JLH=+0\=S]FP#VZ<&,[77I9E48\.^!E-R8]N3X0G*XJ+
MX=IW*G84E1>7PL]*=<`MI7X4C]^&A[279=7SGQB!?,?:2E'H7PQ?FJQ&NUI4
MOWU_(E&LZ4T>KG;[.^#&2T-#_L`2>H[2C2B`[F*G=CL4OC35"C?O'P^'IU8>
MA-()?WCR\)'B8_#I\(G\6P>SZ\D)9S'BJQ:K[&K
M]94T?#1PZ6A'Z3"#],Y.=6PO.@@TO>'"0\7H(`J4U([02^A-Y>YGY^KOO`-V
MQ%K5G?H"B43`FMY(1G[)U$NZ+>L!63LUR11C:E'IC^C+C-BX8PFQF(./FJN0P^5H(W<,-2=UF6!)=>;<7!]^R;VUF=
M3W7BX/OLU%T&H;RPC@>`_$=Z*M"?::"NH?YX3SWM%HU\,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*G<2M,5<
M*^[L>BP\ED78WZ!0
M".LD6![<[EMAIL PROTECTED]:H6/9[E,/J&SN\^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%JB03X65&GY>`[7C,R"S2_'-K*Z1N<:S*$M"/N#J8;7\UUWHE&!G#H%!
M/5C,6V%H()]T#?%3F<8^,[EMAIL PROTECTED]:?I:I=`,2ZLE:?U4400I6XZ;L\5-JU!V.
M!O3V]/D-G3_FSFA03W\DO4TYI3Z*7J)IR@(7YMAXU.Q\:%FZ2Z,>FD^YS&,\4-ZU]+:N>8%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_DC>KOTB_34
M91WGL!<@H/X';`_U?\%+N&7QO;K78ZP/`#G5D$AG3):34&@YP(F9M/`DK:C:
MJ3IM.&CKDO[1[+]1'N/UC5"OHQH]P_'+T.,R]5#Y"@!HYUXGU'LEK:?JV?]J
M/6F.204+]0#[+S?>+]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<'][9D>DT+_H?Q^:[EMAIL PROTECTED]@
MB/W'W3VS0="IEZ_F-O711GFD!(Z_%^J)*8%'3:K.1$2`N]D%.WM`F>7%8:@7
M4GI!W2O*5#`">J4Z$&&/2G6S/A`0P.F@@&H;A;[EMAIL PROTECTED]>!?7"CI%
MI-?8!6)(SRUT*6IRJ\PR=;V2<+J`[776-40.^I+*K(3B=[H2\NU%>NS5>F,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'^JX:[?#+M=,'[EMAIL PROTECTED])<[EMAIL PROTECTED]@LBA
M=FEF,RUP>OEJQ\O"9J'X!?67,RL'JJWS$H>[EMAIL PROTECTED]([EMAIL PROTECTED](VR8
MB@";Z21\J?X:X!#_VT)0Z:5`83']*;`$Z9QL''`17I'5/W24TX^-Q`
M_XF5&@>#&/CDW()5:_.2=!Q&L!4#GUKV\(EX0SF#]!@,?&K)>[^)-R.]A$KC
MX"NY\8BN-P6:L/#))5#/'0:FL+!
M]Y:\[KCJ2(SCJ1V%>V=X;UM!]]0Z9P99?HJTX\PL`4R-X\U\T@)(Y_J"U:-XHS?UF#5!9SQ
M:P]61?'&KTK`&;[EMAIL PROTECTED],']<([EMAIL PROTECTED]"!_AN_[X
M$ICY$CCY#+\8&Y_A%V-K'QA^<7]^+,HX[/.9?K&_8?)@3CF&]I_A%_]3\X,;
MF\LQ\!E^<9-]/8-/]XL'D%XE#C[=+YZ`>BT,#C[=+WX#Z;$8^`R_V/_1UT\H%-I1W_
M;K-\^2+AE]M39WX2?C@@?^*_]]NSR><%;HW(U
MU#M1^'[EMAIL PROTECTED]:[EMAIL PROTECTED]'W>K?^Y6G>=M\-2\_)FWL"%\`H-0O_R[`VN-K
M64?WGD\>SR>S=Z?JZ`*P('[EMAIL PROTECTED]@O?3([EMAIL
PROTECTED];&4GV<-/;1!4/[EMAIL PROTECTED]:
M!+=L/9VO_I7B+?3K+_'H>^6OPTT3EN)7^/WV+D^;5[EX
MJY>O.G"&#=U1%9F^`#<57;!4OL/3D2XAY%(BH96LYT(0A&KVCDRGND#(.VJ)
M;U;38Z$>Z_;DEID&P7-/.NFFYB=QU%\!
M<_WE2?XC?(2/\!$^PD?XOB+_8-[/[EMAIL PROTECTED],.;2/L'&7J\':_#]`\&
M6W/=\8)21GZ\['$V'AUHM<7GI4/>:5[BNH'4WA[B9D9#-;;XO(#S7F:DVGN!
M^.&'I]W":,AECP_J38,KB9[8%O'#((!ZK#V^&K2_5T0?$!-=6UBXOUZ;_L%@
MZY^YE>0&-EER]&T0C[[;0O(+X2-\.I_I1VCZJ+>O@@1KG<_T(_3'$M+C)=8Z
MG^E'Z(N6FGG)1OQ,/T(MJ'CTT&NQ.UL+RX[?<]!&_`P_0KZXY:FJ\]*;1=.]
M'T4J;)2OZ4=(0<]>[EMAIL PROTECTED]<6ZG-J*-1LPU5\5<_U52/XC?(2/
M\!$^PD?X%FT?X/,C,OR#$1QV1(:_(6"P(\S^;Z8?8KAV1X1]<9F*;>9MV1*:_,0W$V5_9M2-,/LV/$+V<33O"X#/\B.2E
[EMAIL PROTECTED]@N07PG?]\%7
MHP^M;>EP6X[?/#\B]6;5^Z,O!3=?Y"R7
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. -- Coming again: Best quotes of the net. Today: | Nils Rennebarth Kristian Köhntopp <[EMAIL PROTECTED]| Schillerstr. 61 >>I'd also be interested in the comparison [of Linux] | 37083 Göttingen >>with a cisco router. I assume a factor of about ten.| ++49-551-71626 >What? faster or slower? | http://www.nus. Cheaper! | de/~nils
Re: CC's on this mailing list
You (Bruce Perens) wrote: > About the funniest part is trying to find a pay phone. Many countries > only have them in post offices. When I visited Australia, there were > blue phones and gold phones, and only the gold ones could make long > distance calls. But when you have the right phone, and you know the trick with the Follow button you can dial for free (even internationally!). An old backpackers trick :). These are the orange ones you find in pubs and government buildings. 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#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("`^SE-+\Z0L<(D3>Z/3H+1-+$;)PM#
M;X`6R,TPZ1WEAQ,<+!C`BB.P'&3Y.9<.#H.QR)EIHHF(.D/+3>&H88*C<(JR
M"[EMAIL PROTECTED]&`Y"D%=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[Z>HU=VS<\L3?K7GDOMVU:_YQ=_4S1D/M!N.:
M>PW//;GFI[OU3SXV`2UB,F93D09_OR>08X_+>XOU"N^@"UJ$_:FDI)I9PFIV
M/7]D;JL2QZD7U]$W7A7T3O22=.=3+\G-UW/0-_$D0*GD&,L5];ADUK/>D)>D
M7M+61;]F*QG<>VF`+.U=$1\\M_MVHG(5=9=VW[[\)9+88CS*5INM*A_OLB68
M9Z/>*IV^QNNQTT[^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*?3M>MKPC3Z
M'*5Y]M%,ZWH<_^N?P]N!?,FLU]C;0S-(O!451]HWT"4G(PB#UC.>X)WIO
MR`--+"^K6GPVFRY.DATVKZU,IR=_)-YCT^GT8;J3DKY*8WAVSZ&O>4FE7CA*
MWG5M.%YA-R:HMS92L6_/"LP\8T.;CU:BY.KM\>@<7F3O>G2M_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?;[EMAIL PROTECTED]:PLX6P*0/3M(7VCJ684J-
M5I'\:@E4W(^]!TGLTC!/BGLR351.S>_3[A"ME'G^9'[EMAIL PROTECTED]>P)Q:
[EMAIL PROTECTED](K]D"MO>!/8AV[5GS)5[5*/B<]`"*$5A""QOB_FP9[F(%8.55
M1/S/G7,?``JRX>"=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'5"Q`\]CGNX1)DQZ(NKWQ]_A">U0,Z5M58>^/)YAO'
MXV]33]NM06I2OCY_-LA8Q
MV5LYBL>KU+D\,DPEXPU-E'D=E\?Q;RZ3[<<\!<&)GCS*%7KF]&0>:1&G\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\1&EK
M+M",;,(3OR21_^`;*"Q)G"S-1
M5Z["+#YSFFP'DGILO"I)Y$]`/#!7?0$CS06:B?U/;M*Q#F0^$[6D6A5JHG-T
M31'NUWAF68O3],_CB"F1L>[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-880&A.4?>36O&692=S"#A-.-=
M661Y9191$3Z8.:`LKKQ+Q])+79AS%/C)42?U%L$)[3']AY340A/-!CNZ7C_]
MM2;CG25>12_&%S!4KGG2#!Z,\3.7EQU[/<3;WTOS1SV`T?4>O':>7QT6I_5^
M\I??88[UQ_N9Y\`7RG=YPN1+PP&GA+LDK"U]7,'1+JR,(<$4'7CC("B6MC;"
M&;R;7OH.:[EMAIL PROTECTED])X8`B<',)N"4OPC>^PY,9*/0XZI>!_6LA'
M"K2(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.'Z"7[5_B!:[EMAIL PROTECTED]&[-$W-*)L3..3BD(+;-ZVUKDS+@>X_[D\J,D
M?R%OOR1+S.N21&WI9V/P:)?D'[EMAIL PROTECTED]/"@S+P9G+*]V4G>/;A=$^Z+73>+$
M%?#,'C>IKW$EM?KL':A9AN;1='O+3_DI/_TAIYR>;/?DV.N?>$DV%Y/'DWN/
M([U+44GU`!`+LQJ9O0.I=7@:5+.1UBN)F!N?R>L_JV(2R>D%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=?[6>C;8N_?=)]2RU2T,1B2
MM&T#B9D]J?6BX)+--2N'FNHQ'#X*W;H:V66M)REP.+CQ-R[7;X6PR?64826L
MQ:C7)SAXDWGZ(WO"2[Q^(4"]#J>,QK!%%.`!4X>LB":2`L3'#;S%%7Q)KU0ZD%3!^9%/4DA'N`M)X)-$H#P)(^?
M37E.O0O/[EMAIL PROTECTED]/1[EMAIL
PROTECTED]"8+?M?EIYXP>APZ5
MO1R#6[I+M.!UG(@=2B36=B?.6W=L[B[!,;FLU+N!U)<[EMAIL PROTECTED]
MQ]BI&5I(IOWFZDQ";CU-)[EMAIL PROTECTED]:>$C?LX1SG+^_EO;R7]_)>WOLC
M>]RR)63^*'O*(;)8;W4QF=G-?5PN/+#:0&8IZ^'<>"VANL'RI/6P_XG!4'11
M^^/'8W0^<5]XUQTC&PJWA#WWC>7`"]T?KM3%=3I=Q'>_NBAO]PB=O9Y0)1K.DB\N.Y$Q*?&%N49$W0^UAAFGC?B:XPORHNK=&Y_^*W&S7&]
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_-HP($LN`;'L;'+Z92A:N"N]907^^"
M->&-7Y&$#P."H^R82YCBO>MV7L`6I]GI!*)%#`RYW=+0:-`=A'A<>+Q*Q,$K
MJ50A."0T&:07W1:YUB"2A$!`X,UN]Y6IWK;W+F!8Y]SR'@!J2<-5Z"Z^2CP/
MQ-#+O!^D4KW!F_OJ#-(22+Q=@"0$0!_Q#LA3O&?\X!B";DEZ
M3G0CXEU,Y0^SU(O!([EMAIL PROTECTED],:I!VA"P$'S!Z]<[SEYB_PV\43+!9%YKZ:\='D!
M2R7EE6JIYR8>30B(TWIRTY:[EMAIL PROTECTED]/[EMAIL PROTECTED];G%H5'0+`H8/!(>'X5/[EMAIL PROTECTED]"#&DT,"J$2O'W__LJSWA*N
M>UE;22B($S]LC<[EMAIL PROTECTED]>NJ_I^R[22AKO)E;=E;WD-PQO:;
M[>O*,/MF8O\W=5E>O.%X`"=X8)JUY^ME+PM%T`SWXF`>S15?ICM?7_3/$).^*+,I!14P-W$#J4J7)249R9`DA-[T%RRT#>KL3
M]61RP+&0F0QQR0?D0"%.][EMAIL PROTECTED]'?H)K)TG'B;=M&?I%T
MM_7(^=/:'UDSGN7(:\;3/'[LT;9_.C31$V11ZC.+T"0.U7]:&VX1GO(AP)U0
M3,/"-[5HJ]S7![?*M6/BAZ8WRUR\OA[W0CI+V]]T.UT\MK]:[EMAIL PROTECTED]
MA5J59+/>;)"D,W`8`?Z"XAP[`\?0(\K0$'R$I(M?*6,[EMAIL PROTECTED],O.$
[EMAIL PROTECTED])VAGEE,6KFEI6:0\58FLM[-ZB/F75EOR01//D4]K3(TT6N6Q:[EMAIL
PROTECTED]
uploading pixmap_pl2-1
-BEGIN PGP SIGNED MESSAGE- Date: 21 Aug 96 17:23 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: joost witteveen <[EMAIL PROTECTED]> Source: pixmap Version: 2.6pl2-1 Binary: pixmap Architecture: i386 source Description: pixmap: A pixmap editor. Changes: * upgraded upstream source. Although the debian-patches for pixmap_2.6pl1-5 are identical (for all intends and purposes) to the upstream patch2, changeing the version number makes it clear to outsiders that this debian package realy is the most recent release, which is good. * removed a debugging message. Files: 0d5b8eb84f5c1acaf0a43f32fba26398 126343 x11 - pixmap_2.6pl2-1.tar.gz 26856b5f5fb8b31f80148bf5b16e4c23 20567 x11 - pixmap_2.6pl2-1.diff.gz bad544b541b68a7e35f054d8e99c6d12 101898 x11 Optional pixmap_2.6pl2-1_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMhtGxZNVaG8BiEBRAQEYHAP9GcFR3i6ogueyQDuXIWIt9v70qtGlyCAf tmMSGdsX2QHaGhC/CV8QI59l1UK1eHv6mrM7DaxL4aqREE+wXVY8FUF2l7ZBuWFJ 5phKroQmzEqd3SCuVx3EY/wDskvt86oA2mx8YWhTcM/MkgCeSLOYauVFEBCujIPd fdOdNRkr07M= =q+Ij -END PGP SIGNATURE-
Bug#4222: dig in the wrong package?
Package: bind Version: 4.9.3-P1-3 `dig' really belongs in the `dnsutils' package, not the `bind' package; just because one is not running a local name server does not imply that one doens't want to use `dig' to look things up. -- Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#4218: Problems removing INN
You (Rob Leslie) wrote: > Package: inn > Version: 1.4unoff4-1 > > deimos:~:[2]# dpkg --purge inn > (Reading database ... 20824 files and directories currently installed.) > Removing inn ... > Trying to stop INN.. > Removing crontab for news.. > Removing files in /var/log/news and /var/run/innd.. > dpkg - warning: while removing inn, directory `/var/spool/news/.outgoing' not > empty so not removed. > dpkg - warning: while removing inn, directory `/var/spool/news/over.view' not > empty so not removed. > dpkg: error processing inn (--purge): > cannot remove `/var/spool/news': Device or resource busy Ehm yes. /var/spool/news shouldn't be in the INN package; your /var/spool/news is probably on a seperate partition so rmdir /var/spool/news will always fail.. This is a bug in the INN package. I'm still working on it, though rather slowly (vrry slowly, sorry). > ** INN news server configuration Yep, dpkg tries do undo the purge so it probably starts the postinst script again with a special argument which the INN postinst happiliy ignores. > chown: /var/log/news/.: No such file or directory > I can't access your /etc/news/inn.conf (No such file or directory) - HELP Yes, too late.. armageddon :) > dpkg: error while cleaning up: > subprocess post-installation script returned error exit status 2 > Errors were encountered while processing: > inn No worries, but it _is_ kind of hard to get entirely rid of all traces of INN on your system.. dpkg will keep thinking some parts are still installed. 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)
Re: CC's on this mailing list
From: Miquel van Smoorenburg <[EMAIL PROTECTED]> > But when you have the right phone, and you know the trick with the > Follow button you can dial for free (even internationally!). If you get caught they are less likely to let you visit their country again :-) . I got a speeding ticket from the darn traffic camera while I was there, too. They didn't mail it to me until I was back in the States. I had little choice but to pay it, as I figured they'd stop me at Immigration next time I visited if I didn't pay up. Bruce
uploaded screen-3.7.1-7
-BEGIN PGP SIGNED MESSAGE- Date: 21 Aug 96 17:00 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: joost witteveen <[EMAIL PROTECTED]> Source: screen Version: 3.7.1-7 Binary: screen Architecture: i386 source Description: screen: A screen manager with VT100/ANSI terminal emulation. Changes: added "|shadow-login" to dependency list, to allow installation of shadow password. Files: b12aefd11ba2a657f6005d5769e344a7 389093 misc - screen_3.7.1-7.tar.gz 4930ef6edf74f19bd8e4a8af0716c2a8 13268 misc - screen_3.7.1-7.diff.gz 24262ce37c0ca7badb8a25de4e2abded 191988 misc optional screen_3.7.1-7_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMhtBHJNVaG8BiEBRAQF0rQQAq51MDMl7nrnywk0K44a5IxatcZdoucXs erAnHWI94Bfn2SGm20mMOSveslFB01KyuvusqBBz/GemDCnTrK0FFrg/iK0ugeqL K9hbLBvvNOcr0L7lr8U/xOy6giTspHpMBRbEkn44cNYXpAkWNfYvxSBjaIVB2Vqb nliCg9q3B4U= =2aq4 -END PGP SIGNATURE-
