A message

[Jason Gunthorpe]

sorry about this, 

A test email. #1.


Jason


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian listserver on 2%

[Jason Gunthorpe]

On Wed, 6 May 1998, Martin Schulze wrote:

> thanks to everyone who has asked if we have problems with the 
> listserver.  Indeed we had a problem with it.  Delivery was
> sized down to 2%.  I have to admit that I don't know why.  I've
> resized it back to 100% and from the log I see delivery runs
> again.

Okay, here is what happened.

#1 A run away elvis proccess took up all the cpu power and that reduced
the delivery capacity

#2 The list configuration got messed up and all email went 'someplace' -
I'll leave that to a listmaster to determine exactly where that somepalce
is.

I have fixed both and my test email seems to have gone well, I'll keep an
eye on this one too.

Jason
Debian-admin



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Tiny libraries

[Nicolás Lichtmaier]

> I have a package that uses two very small libraries, shhmsg and shhopt.
> I packaged the libs separately from the program that uses them, but it
> has been suggested that I just incorporate them in the package that
> uses them (snake4).
> 
> The libs are generally useful and they are distributed separately
> from the author, so I still think it's a good idea to have them
> as packages.
> 
> Any opinions?

 If that program is the only packaged program that uses those libraries,
make just one package. You can always split it when needed.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Time to say goodbye...

[Karl M. Hegbloom]

> "Nils" == Nils Rennebarth <[EMAIL PROTECTED]> writes:

Nils> [1 ] On Tue, May 05, 1998 at
Nils> 11:23:38AM +0100, Luis Francisco Gonzalez wrote:
>> Craig Sanders wrote:
>> > On Mon, 4 May 1998, Michael Meskes wrote:
>> > > Jim Pick writes:
>> > > > I must admit, I've been entirely negligent in following
>> > > > the policy discussions - due to lack of time, I've
>> > > > skipped them entirely.
>> > > Me too.
>> > me too.
>> There goes another me too.
Nils> The same holds for me

 I cannot keep up either.  I've too much study to do.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

`MIT-scsh': May it go in the main distribution?

[Karl M. Hegbloom]

 I just recieved the following email...  below it is the COPYING file
 that ships with `scsh'.  May it go into the main distribution, or
 should I see if I can negotiate a different licence?

 Is this licence DFSG compliant, and if not, what parts of it are in
 conflict?  Help me learn this, please.

 (cons.org is the home of CMU Common Lisp)
8<->8
From: Martin Cracauer 
Subject: scsh and CDROM
To: "Karl M. Hegbloom" <[EMAIL PROTECTED]>
Date: Wed, 6 May 1998 16:45:55 +0200

Karl,

don't know if you received an answer regarding putting scsh on CDROM. 

I maintain the FreeBSD port of scsh and Olin let me know that it is OK
to distribute scsh (sources and package binaries) with a Freeware
CDROM. He didn't want 0.4.x to be on CD, but that was a matter of
quality on his side.

Hope this helps
Martin
--

Martin Cracauer  http://www.cons.org/cracauer
  [EMAIL PROTECTED] (batched, preferred for large mails)
  Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
  Paper: (private) Waldstrasse 200, 22846 Norderstedt, Germany

8<>8

Copyright (c) 1993, 1994 by Richard Kelsey and Jonathan Rees.
Copyright (c) 1994, 1995 by Olin Shivers and Brian D. Carlstrom.

   Use of this program for non-commercial purposes is permitted provided
that such use is acknowledged both in the software itself and in
accompanying documentation.

   Use of this program for commercial purposes is also permitted, but
only if, in addition to the acknowledgement required for
non-commercial users, written notification of such use is provided by
the commercial user to the authors prior to the fabrication and
distribution of the resulting software.

 This software is provided ``as is'' without express or implied warranty.



Distributing Autoconf Output


[excerpt from autoconf documentation]

   The configuration scripts that Autoconf produces are covered by the
GNU General Public License.  This is because they consist almost
entirely of parts of Autoconf itself, rearranged somewhat, and Autoconf
is distributed under the terms of the GPL.  As applied to Autoconf, the
GPL just means that you need to distribute `configure.in' along with
`configure'.

   Programs that use Autoconf scripts to configure themselves do not
automatically come under the GPL.  Distributing an Autoconf
configuration script as part of a program is considered to be *mere
aggregation* of that work with the Autoconf script.  Such programs are
not derivative works based on Autoconf; only their configuration scripts
are.  We still encourage software authors to distribute their work under
terms like those of the GPL, but doing so is not required to use
Autoconf.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#21969: debian-policy: needs clarification about Standards-Version

[Dale Scheetz]

On 6 May 1998, Manoj Srivastava wrote:

> Hi,
> >>"Dale" == Dale Scheetz <[EMAIL PROTECTED]> writes:
> 
> Dale> On 6 May 1998, Manoj Srivastava wrote:
> 
> Dale> During our past discusion on these issues I made direct requests
> Dale> for clarifying statements about priorities of policies. I
> Dale> specifically asked to be kept on the cc list for any discusion
> Dale> of the issues.
> 
>   I think at the moment most of the policy document, unless
>  other wise indicated, is a MUST directive. 

I KNOW that is what you believe. It is the point of view that I most
reject from any you profess to hold.

> 
> 
> Dale> Debian's policy has always been one that rejects non functional
> Dale> binary packages.
> 
>   If policy, if followed, creates broken packages, we have a
>  problem. 

Only because you insist on your "broken" view of policy.

> 
> Dale> Even you have been willing to admit that Policy
> Dale> is broader than "The Policy Statement".
> 
>   I never said that. The policy document set, (currently a
>  a set that is referenced in or pointed to by the core 3 policy
>  documents) is all that I see as policy. 
> 
So, we ignore the DFSG, pay no attention to the "Debian Manifesto", and
completely ignore anything in any of the faqs, HOWTOs, or other related
documents. Policy makes no mention of ANSI, or POSIX and may not even make
reference to the File System Standards (this one may actually be
referenced, but I haven't looked at the Policy Statement in a while and
can't be sure). Do we throw all this in the trash? NO! Of course not! Be
reasonable...

> Dale> Do you deny that it is our policy to deliver functional binary
> Dale> packages?
>   
>   I fail to see this in policy, but that is because I think most
>  people would take it as given; I understand it is a critical goal. In
>  fact, this has to be added to the policy, if people do not find it as
>  an acceptable unspoken rule.

You can't have it both ways. If it is taken "as given", then how do people
"not fine it as an acceptable unspoken rule"?

Does anyone in this group think that delivering broken executables is
either implied or stated anywhere in Debian Policy?

I suggest that your counter example is "the empty set" and quite useless.

I can think of no one (not even you ;-) who would consider delivering
broken binaries to be even mildly suggested anywhere in "The Policy of the
Debian Development Team" (which, of course, includes "The Policy
Statement").

> 
> Dale> Do you suggest that the "strip binaries" rule should
> Dale> superceed this prime directive?
> 
>   No. The strip binaries rule, if it contravenes this primary
>  directive, is quite obviously broken. You can't say "following blah
>  would break stuss, so I shall ignore it for now. However, I do not
>  see blah as wrong [even though following blah would break my
>  package]". I just don't understand this line of reasoning.
> 
Your "understanding" is based of false assumptions.

Any reasonable person would read any portion of policy similar to the
"stripped binary" rule in the same way that I do. If you wish to make it
more explicit and state clearly that stripping binaries is only desirable
if it results in functioning code, you should feel free to work within the
policy group and change the document to be clearer.

I'm only going to say this once more:

If you think it's broken, YOU fix it.

In any case, I have no interest in hearing about how broken you think it
is. I understand your broken attitude, but seem completely unable to mend
it. As you seem unswayable by "reasonable" arguments, I will cease trying.

Later,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: List of bugs that *must* be fixed before releasing Hamm

[Dale Scheetz]

On Wed, 6 May 1998, Brian White wrote:

> > > Several people have asked for this, but maintainers already get separate
> > > reports about their packages and reports by package are available on
> > > the web site, so I don't really understand the usefulness of presenting
> > > it that way here.  Is there something I'm missing?
> > 
> > If your own bugs are scattered around in a list of several dozen, it is
> > really easy to miss one. Grouping them together makes this less of a
> > problem.
> 
> I guess this is the part I don't really understand.  As a maintainer with
> open bugs, you're already getting mail from "nag" about them directly so
> why would you depend on this general mail intended for everybody else.

Don't even get me started on the nags ;-) In any case they have nothing to
do with this message.

If this message is not intended to inform maintainers which of their bugs
are considered critical to the release then you can stop sending it along
with those nags.

> 
> However, as Jason pointer out, there is no reason at all for it to be sorted
> numerically (other than perhaps a touch of athetics) so I've changed it to
> sort by package name.  The new sorted list should come out Friday.
> 
This is just fine with me, as I do (sometimes) know which packages are
mine.

Thanks,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: `MIT-scsh': May it go in the main distribution?

[Bill Leach]

I would suggest that this one is very close but still misses...

On Wed, May 06, 1998 at 06:41:14PM -0700, Karl M. Hegbloom wrote:
[snip]
>Use of this program for non-commercial purposes is permitted provided
> that such use is acknowledged both in the software itself and in
> accompanying documentation.
> 
>Use of this program for commercial purposes is also permitted, but
> only if, in addition to the acknowledgement required for
> non-commercial users, written notification of such use is provided by
> the commercial user to the authors prior to the fabrication and
> distribution of the resulting software.
> 
>  This software is provided ``as is'' without express or implied warranty.
[snip]

The 'sore spot' I believe is the requirement to provide written notification
prior to commercial use (though it in fact does not seem to actually 
be requiring specific permission for commercial use.


-- 
best,
-bill
[EMAIL PROTECTED]
   [EMAIL PROTECTED]  [EMAIL PROTECTED]
from a 1996 Micro$loth ad campaign:
"The less you know about computers the more you want Micro$oft!"
 See!  They do get some things right!


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

`/etc/passd' locking glibc/shadow, PAM?

[Karl M. Hegbloom]

 From what I can tell, the method for locking the passwd and shadow
 files is not the same in glibc and the shadow utils.  Can anyone shed
 some light on this?

 Is anyone working on porting PAM from Red Hat to Debian?  Is that
 planned?


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#21969: debian-policy: needs clarification about Standards-Version

[Manoj Srivastava]

Hi,

This is getting nowhere. Well, when the constitution is
 ratified, maybe one can see how much support there is for more
 strongly ratifying the policy documents. As it stands, I have no
 motivation to work on the ``good practices'' document unless I have
 any indication it is going to be useful.

>>"Dale" == Dale Scheetz <[EMAIL PROTECTED]> writes:


>>  I never said that. The policy document set, (currently a a set
>> that is referenced in or pointed to by the core 3 policy documents)
>> is all that I see as policy.

Dale> So, we ignore the DFSG, pay no attention to the "Debian
Dale> Manifesto", and completely ignore anything in any of the faqs,
Dale> HOWTOs, or other related documents. Policy makes no mention of
Dale> ANSI, or POSIX and may not even make reference to the File
Dale> System Standards (this one may actually be referenced, but I
Dale> haven't looked at the Policy Statement in a while and can't be
Dale> sure). Do we throw all this in the trash? NO! Of course not! Be
Dale> reasonable..

You are the one being unreasonable. I said there are certain
 sets of documents that constitute the Debian policy
 documents. That does not mean those are the only ones which
 are followed.

"official" brand for cdroms

[Andreas Jellinghaus]

maybe the term "offical" for cdroms be used, if someone sells a set of
cdroms, constisting of the official cdroms and an extra cd with things
like debian-non-US, debian-non-free (those parts that are allowed to be burned
and sold), and other stuff like 2.0 + 2.1 kernel source, netscape, mozilla,
kde ... ?

does anyone know how dselect can handle installing packages from several cd's ?

andreas


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Uploaded perl 5.003.07-11 (source i386) to master

[Martin Schulze]

On Thu, May 07, 1998 at 07:41:02AM +0200, Alexander Koch wrote:
> On Thu, 7 May 1998 01:48:56 -, Christian Hudon wrote:
> > Source: perl
> > Binary: perl-suid perl-debug perl
> > Version: 5.003.07-11
> > Distribution: stable

You misquoted a part:

> > Urgency: high
 
Changes: fixes security problem.

> I mean.. well, no.

Well yes. :-)

> This is not a real upload, isn't it? Since 5.003.whatever is a bit ...
> out-dated for years?

It is a real upload.  It's a security fix for our stable release.
Uploads into stable may only fix security problems and should not
introduce new upstream releases.

Regards,

Joey

-- 
  / Martin Schulze  *  [EMAIL PROTECTED]  *  26129 Oldenburg /
 / http://home.pages.de/~joey/
/There are lies, statistics and benchmarks. /


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: `/etc/passd' locking glibc/shadow, PAM?

[Jules Bean]

--On Wed, May 6, 1998 8:07 pm -0700 "Karl M. Hegbloom"
<[EMAIL PROTECTED]> wrote: 

>  From what I can tell, the method for locking the passwd and shadow
>  files is not the same in glibc and the shadow utils.  Can anyone shed
>  some light on this?
> 
>  Is anyone working on porting PAM from Red Hat to Debian?  Is that
>  planned?

PAM is in frozen, but it's not actually used by any of the core system
(passwd, xdm, etc.).  I assume that is planned for slink.

Jules

/+---+-\
|  Jelibean aka  | [EMAIL PROTECTED] |  6 Evelyn Rd|
|  Jules aka |   |  Richmond, Surrey   |
|  Julian Bean   | [EMAIL PROTECTED]|  TW9 2TF *UK*   |
++---+-+
|  War doesn't demonstrate who's right... just who's left. |
|  When privacy is outlawed... only the outlaws have privacy.  |
\--/



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

/tmp permissions !

[Nuno Emanuel F. Carvalho]

Hi,

  I'm using Debian 1.3.1 and till that i'm using only as root's user
cause
I was having problems on installing my PCBIT ISDN card, but know it's ok
! :)

 When the problem was resolved I'd log in as other user but I couldn't
make "man" 
command as well start up X ! 

 My problem was the /tmp permissions ! I didn't had write permissions on
my /tmp
directory! So I made:

   $ chmod 777 tmp

 ... and it worked ! ;)


 My question is: Is a good policy users to have write permissions !?!? 
 Should they have it !?
 

 Best regards,
Nuno Carvalho


---
 Nuno Emanuel Carvalho  
 University of Coimbra 
 Dep. of Informatics Engineering  
 PORTUGAL  
  URL: http://student.dei.uc.pt/~nemanuel 
  e-mail: [EMAIL PROTECTED] 
---


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /tmp permissions !

[Martin Schulze]

On Thu, May 07, 1998 at 11:08:45AM +, Nuno Emanuel F. Carvalho wrote:
> Hi,
> 
>   I'm using Debian 1.3.1 and till that i'm using only as root's user
> cause
> I was having problems on installing my PCBIT ISDN card, but know it's ok
> ! :)
> 
>  When the problem was resolved I'd log in as other user but I couldn't
> make "man" 
> command as well start up X ! 
> 
>  My problem was the /tmp permissions ! I didn't had write permissions on
> my /tmp
> directory! So I made:
> 
>$ chmod 777 tmp

>From a clean install you should have
drwxrwxrwt  11 root root 8192 May  7 13:13 tmp/
chown root.root /tmp
chmod 777 /tmp
chmod +t /tmp

+t means that the user who has created the files is the only one (except
for root) to delete them.

Regards,

Joey

-- 
  / Martin Schulze  *  [EMAIL PROTECTED]  *  26129 Oldenburg /
 / http://home.pages.de/~joey/
/There are lies, statistics and benchmarks. /


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /tmp permissions !

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Thu, 7 May 1998, Nuno Emanuel F. Carvalho wrote:

>$ chmod 777 tmp

Please do

chmod 1777 /tmp

instead.

If you are worried about security, the sticky bit is supposed to be
explained in every good general FAQ about Unix.

Thanks.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNVGd0CqK7IlOjMLFAQHDlwP+O1P92RlFH56/uhy2xKdU9Dk8VCp0oi2H
TUTgAeni3BC8F8jajF3n6+7raJ/yk/wfuHXCwLDhGKXvfd6KWl72uBOf8fsy1Cqg
oA7+XijpPqD9rzIRLMCOct4JTrvb3tA4eXoqkpbftHX/1uflJckSkN3yRL92G6oq
fBHoJTpj7qQ=
=+mqV
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Configuration of teTeX broken (send once more due to list problems)

[Andreas Tille]

Sorry, I've got no messages from the list since yesterday.  Is the
list alive?  So I send my message from yesterday once more and hope that
now all is right.


Hello,

I have installed tetex-base_0.9-5 and the other related teTeX packages
dpkg --status tetex-base says:

Package: tetex-base
Status: install ok installed
Priority: standard
Section: tex
Installed-Size: 15898
Maintainer: Christoph Martin <[EMAIL PROTECTED]>
Version: 0.9-5
Replaces: texinfo, texidoc, bibtex, texpsfnt, mfbasfnt, xdvik, dvipsk, mfnfss, 
latex, babel, texlib, mflib, textfm, kpathsea, latex2e-doc, ltxgraph, 
tetex-extra, tetex-doc
Depends: tetex-bin (>= 0.9-1)
Pre-Depends: dpkg-perl
Recommends: tetex-nonfree
Conffiles:
 /etc/texmf/XDvi b3c84872095f944d4fdaa6b810c1f72b
 /etc/texmf/dvips/config.ams 32978f814ef9354d55042c38995976a6
 /etc/texmf/dvips/config.amz bef5a8a0ebcd9ea3b3ca5ca4628e4285
 /etc/texmf/dvips/config.cm 62d1394ef3c3eb95c242ea1ac70f9363
 /etc/texmf/dvips/config.cmz 9de754839ee6eb014c9e4f0a5868da24
 /etc/texmf/dvips/config.ps 2ec77d6175cc5a33cb981d0c7cecc447
 /etc/texmf/dvips/config.dfaxhigh 4b3d24e544b98cb95a86b66b239e1ac1
 /etc/texmf/dvips/config.dfaxlo 0dfd4985380fbe28bdfc0e5ae70f84e2
 /etc/texmf/dvips/config.www 951905793fcd94d8fe183448430e79a2
 /etc/texmf/modes.mf 8985161376dc78ed599e0eb5c7265b31
 /etc/texmf/language.dat 5574f39628eae6b68ac46415303c4da0
Description: basic teTeX library files
 teTeX (version 0.9) is a TeX distribution for UNIX compatible
 systems.
 .
 Together with tetex-bin you have a minimal installation
 .
 Includes: texlib, latex, mflib, mfbasfnt, bibtex, textfm

---

I think there are several problems:

1) As the Conffiles part shows there is no
  /etc/texmf/texmf.cnfand
  /etc/texmf/maketex.site
   as it was the case in former teTeX packages of the 0.4 release.
   
   I consider it to be in contrast with the usual way of Debian to store
   configuration files into /etc or subdirectories.
   
   The files now reside in
  /usr/lib/tetex/web2c/texmf.cnf  and
  /usr/lib/tetex/web2c/mktex.cnf
   (use `kpsewhich texmf.cnf mktex.cnf` to verify this fact!)
   Actually when using `texconfig` these files were changed which
   is bad when mounted /usr readonly.
   In my opinion this should be changed before hamm goes to stable.
   (Sorry, I don't know if it is considered as bug.  If so I should
   write an official bug-report, but may be the teTeX maintainer
   reads this thread.)
   
2) It's very strange that setting the seach variables in the way it worked
   under teTeX 0.4 won't work under 0.9.
   I set up in /usr/lib/texmf/web2c/texmf.cnf the following
   
% The main tree, which must be mentioned in $TEXMF, below:
TEXMFMAIN = /usr/lib/texmf

% A place for local additions to a "standard" texmf tree.  For example:
TEXMFLOCAL = /usr/local/lib/texmf

% Now, list all the texmf trees. If you have multiple trees,
% use shell brace notation, like this:
TEXMF = {!!$TEXMFLOCAL:!!$TEXMFMAIN}

VARTEXFONTS  = /var/spool/texmf

TEXMFDBS = $TEXMFLOCAL:$TEXMFMAIN:$VARTEXFONTS
SYSTEXMF = $TEXMFLOCAL:$TEXMFMAIN

   But files in /usr/local/lib/texmf were not found!!!
   `kpsewhich  fails!!
   That's boring and took me several hours editing the config file.

   Now I'm using the workaround:
   
ln -s /usr/local/lib/texmf /usr/lib/texmf/local
ln -s /usr/lib/texmf/local/tex /usr/lib/texmf/tex/local
   ...
   to get it work.  But this is *not* the sense of the configuration
   file, thought.

   Despite the ugly not working configuration file the additional
   drawback of this workaround is that you can not say which tree
   is searched first.  If there are two style files with the same
   name in /usr/lib/texmf/tex and /usr/local/lib/texmf/tex TeX uses
   *any* of them and not the one in $TEXMFLOCAL which should be used
   according to the config file.
   
3) When using the workaround under 2) make sure that you do
   
 ln -s /usr/lib/texmf/local/mf /usr/lib/texmf/fonts/source/local
 
   AND NOT
   
 ln -s /usr/lib/texmf/local/mf /usr/lib/texmf/metafont/local
 
   In the latter case, which I've done first, any local font (*.tfm,
   *pk) file will be stored in "." which is really boring!
   
4) The workaround does work only if you do `texhash` after linking
   the local tree into the appropriate directory.  If I understood
   kpathseach right at first the TeX looks into the ls-R databases.
   If that fails TeX searches the filesystem "manually" in the
   appropriate directories.  So the files in the local tree should
   be found whether texhash has rebuild the databases or not.
   
   This is importand for users which want to install private
   styles but hav't write permissions to the ls-R database.
   
5) Am I the first who has this trouble
   This is a real question, because I wonder why I'm busy for hours
   making my teTeX working.  This was the first time since years
   using sev

kernel make install

[Kenneth . Scharf]

I downloaded the kernel-source_2.0.33-7.deb package and installed it on my
1.3.1r6 system.  (I needed the fat32 patch).  I now understand why I had
trouble patching kernel sources from .deb packages, because they have
already been patched, so patch tried to REMOVE the patch instead of
INSTALLING them.  The system previously had the 2.0.29 kernel installed
from the rescue disk at the time of the install.

Here's what I noticed  /etc/lilo.config contained the line
image=/vmlinuz./vmlinuz was symlink /vmlinuz->/boot/vmlinuz-2.0.29

After compiling the new kernel ( make menuconfig ; make dep ; make clean ;
make zImage ; make modules ; make install)
the link at /boot/vmlinuz was /boot/vmlinuz->vmlinuz-2.0.33.
Lilo had run but the OLD kernel still booted until I made the link
/vmlinuz-> /boot/vmlinuz.  Then the new kernel would boot, and all was
correct each time I might
re-compile the kernel and make install to run lilo.

IE:  The symbolic link created at /vmlinuz when the system was installed
was not consistant with what the make install option expected.

Has this been fixed for hamm?  ( Or have I missed something here?)

Anyway thanks for the updated kernel.  Is there a text file somewheres that
lists all the patches that have been applied in a given .deb kernel package
for the given revision of that kernel (IE: whats different between the .deb
package and the .orig source files)?



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: kernel make install

[Eric Leblanc]

On Thu, May 07, 1998 at 08:10:16AM -0400, [EMAIL PROTECTED] wrote:
> Has this been fixed for hamm?  ( Or have I missed something here?)

I use the kernel-package .deb to make custom kernels. It is available 
for bo and hamm. It makes a .deb that you can install with dpkg -i.

I quot.

"This package provides the capability to create a debian kernel-image
package by just running make-kpkg kernel_image in a kernel source directory
tree.  It can also build the kernel source package as a debian file, the
kernel headers package. In general, this package is very useful if you need
to create a custom kernel, if, for example, the default kernel does not
support some of your hardware, or you wish a leaner, meaner kernel."


> 
> Anyway thanks for the updated kernel.  Is there a text file somewheres that
> lists all the patches that have been applied in a given .deb kernel package
> for the given revision of that kernel (IE: whats different between the .deb
> package and the .orig source files)?

The Readme.Debian in the /usr/doc/kernel-source-2.0.33 will have that info.
Also, you might want to take a look at the .diff.gz that is in the source
directory on ftp.debian.org for the actual patches.

> 
> 
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
I tried cp /proc/kcore /dev/audio on my home Linux system and distinctly
heard John Lennon saying "I buried Paul".  -- Jonathan Guthrie at asr


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: on forming a new Linux Distribution

[Brederlow]

[EMAIL PROTECTED] writes:

> No problem here.  As I said I *DID* find the answers and got my debian
> installation to talk to my
> ethernet card after making use of available documentation.  But it was not
> Debian specfic documentation that
> was most helpfull, but rather general linux networking and slackware
> specific documentation that gave me my answers.

I found the Suse handbook a valueable source of information. Debian
needs a good Handbook (maybe tex, dvi, ps, html)

> >Yep, lots of apps need to be ported - are you volunteering?
> 
> Ok put your money where your mouth is eh?  I'm not yet at the point where I
> could make the kind of
> contribution that I'd like to.  First I need to get my own system in order
> (I'll end up starting from scratch with
> debin 2.0 when it is ready for prime time).  Then I need to learn how to
> program GUI under X (which standard? Motif etc?), I currently know MFC
> under windows professionally.

I would suggest GTK, it has interfaces to many languages and it looks
and works good (see gimp).
You shouldn't make the same error as many other projects and start
writing your own toolkit. It will never be as good as taking something 
like gtk and enhancing on that.

May the Source be with you.
Mrvn


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Configuration of teTeX broken (send once more due to list problems)

[Nils Rennebarth]

I tried to upgrade tetex-0.4 to tetex-0.9 but that failed altogether,
because the postinst failed. I corrected the install scripts and sent a 
patch to the maintainer but did not get any feedback.

Nils

--
*-*
| Quotes from the net:  L> Linus Torvalds, W> Winfried Truemper   |
| L>this is the special easter release of linux, more mundanely called 1.3.84 |
| W>Umh, oh. What do you mean by "special easter release"?. Will it quit  |
* W>working today and rise on easter? *


pgpulx3CayqJ2.pgp
Description: PGP signature

FW: Yet another Linux distribution! :-)

[Patrick Ouellette]

I have tossed around the idea of a ham specific configuration that
would fit on a zip disk.  Not the fastest way to run the system,
but you could set up a swap and var/temp area on a small local
hard drive, use a ramdisk and have an easy way to upgrade the node.

I haven't thought about what software should be in it.  I can see
2 configurations, a node/bbs and an end user.

I use the term configuration because that is exactly what it would
be in my case.  In my mind if the system uses the Debian packages
and upgrade/configuration tools then it is a Debian distribution
configured for the task.


Pat
-Original Message-


> I also will plug again for an Amateur Radio specific distribution. (IE:
> AX2.5, RTTY, SSTV, log, contest, CAD S/W etc).  And yes when I come up to
> speed on my own debian system (I'm going to install GTK / GHOME / GIMP and
> see about porting my MFC knowledge to X) I'll try to write some of this
> stuff.




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#21969: debian-policy: needs clarification about Standards-Version

[Dale Scheetz]

On 7 May 1998, Manoj Srivastava wrote:

>   Fine. But the moment any package ``ignores'' policy and
>  insists policy is not broken, so should not be fixed, I shall file
>  bugs against the package.

Which I will happily reasign to Policy.

> 
>   As the technical committee would look at the policy, either
>  the package shall follow policy, or policy shall be mended. I have no
>  intention of giving up on this.
> 
Good!
You have my complete support to "fix" any problems you see in the Policy
Statement.

Luck,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: on forming a new Linux Distribution

[Brederlow]

"Rev. Joseph Carter" <[EMAIL PROTECTED]> writes:

> [1  ]
> On Fri, May 01, 1998 at 04:19:42PM +1000, John Boggon wrote:
> 
> > Can someone tell me why a new distribution has to be started up just
> > because the current one isn't newbie friendly or easy to install ?

> There isn't really.

Apart from flames one will get from Debian developers for using their
work, especially when selling the distribution. And you get quite a
lot.

> > Why not concentrate on an installation system or front end for dpkg / APT
> > along with a system management GUI package that can help an inexperienced
> > sysadmin or user maintain his/her system ? This work could be done
> > independently of Debian and be designed to sit over the top of it.
> > Wouldn't this achieve Bruce's aims ? Why re-invent the wheel ?
> 
> Not quite that, but similar is what a few of us have been talking about and
> I have had in mind for some time now..  Debian's a good dist.  Why duplicate
> the effort?  And, we could not duplicate the shortcuts that the developers
> have already if we are working on newbie stuff.  Then it would end up like
> redhat, either you can have it really simple or not at all.
> 
> Debian has a lot of shortcuts for people who know their way around the
> system.  Those are just as important as the the configuration scripts for
> the most absolute novice in the world.  Moreso really because most will
> eventually grow out of the novice scripts and tools and into the standard
> shortcuts found in Debian now.

One of the big Problems with Debian for a newbie are all those
questions asked, he never heard about. Also questions are asked every
few minutes during the installation, which is a bad thing [tm].
One can change the first by preconfiguring most stuff and thus blowing 
up the base.tgz, the second can not easily be changed. One would need
a new mechanism that asked all questions beforehand or afterwards, or
dpkg should continue installing other packages when waiting for user
interactions on another.

Debian is a very good starting point, but Debian changes slowly. There 
are too many people makeing and talking about decisions, so quick
Reactions are hardly possible.
That also has a good site, things arent changeing without being well
thought and many Problems are thought out before being
programmed. Also things are just programmed by someone, and if its
helpfull for most people, the Debian community really use it and
enhance it.

May the Source be with you.
Mrvn


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian Source distributions (was Re: Intent to package pine-src)

[Brederlow]

Here are my thoughts:

"Jules Bean" <[EMAIL PROTECTED]> writes:

> --On Thu, Apr 30, 1998 1:57 pm -0400 "Dale Scheetz" <[EMAIL PROTECTED]>
> wrote: 
> > Keep source in Source Format and use the .deb files for what they were
> > intended, the distribution of "binary" components.
> 
> I have little doubt you're right.  I know none of the background.

It would be a great idea to have source dependencies. I compile all
sources on my debian mirror and most fail because of missing
files. One then has to search the package and install that before
compiling again. Maybe deb isn't the right thing for source, but some
format to store source dependencies should be there.

As a start, a script that reads in the dependencies of the binary
package and compares that to the installed packages and dev packages
would be helpfull. When compiling something like fvwm, the script
should complain if xpm-dev isn't installed and promt the user (You
will need xpm-dev, shall I install it?).

[snip]

May the Source be with you.
Mrvn


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Uploaded perl 5.003.07-11 (source i386) to master

[Andy Dougherty]

On Thu, 7 May 1998, Martin Schulze wrote:

> On Thu, May 07, 1998 at 07:41:02AM +0200, Alexander Koch wrote:
> > On Thu, 7 May 1998 01:48:56 -, Christian Hudon wrote:
> > > Source: perl
> > > Binary: perl-suid perl-debug perl
> > > Version: 5.003.07-11
> > > Distribution: stable
> > > Urgency: high
>  
> Changes: fixes security problem.

> > This is not a real upload, isn't it? Since 5.003.whatever is a bit ...
> > out-dated for years?
> 
> It is a real upload.  It's a security fix for our stable release.
> Uploads into stable may only fix security problems and should not
> introduce new upstream releases.

But 5.003_07 is still quite vulnerable to a once widely-circulated buffer
overflow attack.  Only upgrading to 5.004_04 will fix that problem.[*] Now
whether users *want* to upgrade their stable systems to 5.004_04 is
another question, and it probably has different answers depending on
whether or not the users run suid scripts vulnerable to the buffer
overflow or whether they want the absolute stability of sticking with
5.003_07. 

Andy Dougherty  [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042

[*] Well, I guess I could probably plug that one hole without touching
much else, if there's really enough need.  The resulting perl would still
have a few quite obscure buffer overflow possibilities, but nothing for
which I'm aware of any widely circulated automated attacks.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Seeking other archs to build packages on

[Brederlow]

Shaleh <[EMAIL PROTECTED]> writes:

> I am the E/Imlib/Fnlib maintainer.  I would like to help or make
> packages for the other architectures that are able to run them.  If you
> have a machine and can give me access please let me know.
> 
> BTW is there a list of machines like this somewhere?  Might be nice.

Do you have accounts on the Debian m68k and the ppc system?
Apart from that, you could also crosscompile.

May the Source be with you.
Mrvn


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian Source distributions (was Re: Intent to package pine-src)

[Falk Hueffner]

Brederlow <[EMAIL PROTECTED]> writes:

> It would be a great idea to have source dependencies. I compile all
> sources on my debian mirror and most fail because of missing
> files. One then has to search the package and install that before
> compiling again.

A very simple way to improve in this area would be if it was allowed
in the policy to add a "Depends:" line to the .dsc file with the same
format as for .debs. Very easy. Developers probably would start to use 
it, since it makes compiling really much easier for other people. Some 
time in the future this field would probably be made obligatory and
tools for source extraction could be extended to check them.

Any opionions?



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Configuration of teTeX broken (send once more due to list problems)

[Andreas Tille]

On Thu, 7 May 1998, Nils Rennebarth wrote:

> I tried to upgrade tetex-0.4 to tetex-0.9 but that failed altogether,
> because the postinst failed. I corrected the install scripts and sent a 
> patch to the maintainer but did not get any feedback.
Try 
 dpkg --purge --force-depends tetex-base tetex-bin tetex-ext
first to uninstall your old tetex-0.4.  Then install tetex-0.9.
This (and only this) worked for me.  But be sane and keep your old
tetex-0.4 packages to downgrade if you can't cope with the trouble
I mentioned!

Regards

Andreas.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Seeking other archs to build packages on

[James Troup]

Brederlow <[EMAIL PROTECTED]> writes:

> Apart from that, you could also crosscompile.

Uh, no.  Please do not upload untested cross-compiled code.  Untested
stuff is the most likely to break and cross compilation is often
dodgy.  There are maintainers for the non-i386 architectures who will
compile all packages, which can be compiled, sooner or later.  If you
want to help us, a) ensure your package builds from a fresh source
tree, and b) fix the bugs we file about packages which won't build
from source[2].  People who don't own and can't access non-i386
machines producing non-i386 debs are in general, going to cause
trouble[1], not help.  Even on the slowest architectures, it's the
broken packages holding us back, not the number of compilable
packages.

[1] There are of course, some exceptions to this, e.g. non-free
pre-compiled binaries.

[2] There was until recently still #3xxx era bugs filed by previous
m68k maintainers about source packages being unbuildable from source.
I think Dirk may have fixed the last with his upload of autopgp, I
can't check right now though (nameserver problems).

-- 
James 


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

bo updates

[Michael Stone]

I seem to remember that the packages in bo used to be updated for major
bugs (like security problems.) It seems like now such packages are only
in bo-updates, not in bo itself, which means that they don't show up in
the Packages list. An example is the bind fix that was put in
bo-updates a couple of weeks ago. Is there some way of automatically
getting such updates using dselect that I'm not aware of? I always
thought that the ability to pull up dselect and see all the updates was
one of debian's major strengths.

-- 
Michael Stone, Sysadmin, ITRI PGP: key 1024/76556F95 from mit keyserver,
[EMAIL PROTECTED]finger, or email with "Subject: get pgp key" 


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian Source distributions (was Re: Intent to package pine-src)

[Dale Scheetz]

On 7 May 1998, Falk Hueffner wrote:

> Brederlow <[EMAIL PROTECTED]> writes:
> 
> > It would be a great idea to have source dependencies. I compile all
> > sources on my debian mirror and most fail because of missing
> > files. One then has to search the package and install that before
> > compiling again.
> 
> A very simple way to improve in this area would be if it was allowed
> in the policy to add a "Depends:" line to the .dsc file with the same
> format as for .debs. Very easy. Developers probably would start to use 
> it, since it makes compiling really much easier for other people. Some 
> time in the future this field would probably be made obligatory and
> tools for source extraction could be extended to check them.
> 
>   Any opionions?

Whithout meaning to sound too negative, I want to caution against such
patch and fill design. Ian J. worked very hard (and was very successful in
my opinion) to design the current source package format to manage the
various problems of absorbing and using upstream sources. We should be
careful to craft any "improvements" to that format in a consistant and
smooth fashion.

That said, I am strongly in favor of a source dependency scheme. It just
needs to be workable.

WRT your suggestion above, I don't think that developers can/should edit
the .dsc file (its check sum is computed by dpkg and provided in the
changes file for dinstall to verify the components).

The correct place for this information is in the control file. This file
has, at least, two paragraphs. One source paragraph, and, at least, one
package paragraph (one for each binary package built from this source).

Currently package depends are placed in the Package paragraph. The logical
place for source depends field is in the Source paragraph. Then
dpkg-buildpackage (and friends) could construct the proper .dsc file
containing the details of the source dependencies.

I see only one problem with source dependencies: How do you tell the
difference between a dependency on a source package and the depencency on
a binary package. I know that most problems are with the need for some
binary program to allow the build to proceed, but sometimes these needs
are for a source file to be present (and in the desired location).

In addition it would be nice if we could come to terms with upstream
source in multiple tarballs (libc6 comes like that as do many others).

There are a number of ways in which the source package format could be
improved, and I agree that source depends are pretty high on that list. I
only wish to caution against trying easy hacks with the distribution
without much more thought and consideration. We should all feel free to
try such ideas out on our own machines just to see how they might work,
but we need much more discusion before actually moving in a particular
direction.

Luck,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Uploaded perl 5.003.07-11 (source i386) to master

[Alexander Koch]

On Thu, May 07, 1998 at 11:27:46AM +0200, Martin Schulze wrote:
> > > Version: 5.003.07-11
> > > Distribution: stable
> > > Urgency: high
[..]
> It is a real upload.  It's a security fix for our stable release.
> Uploads into stable may only fix security problems and should not
> introduce new upstream releases.

Acute dainbramage... stable as in "oh, that's bo" - right?

Sorry.

Alexander

-- 
SGH Internet Division Alexander Koch, Administration
Waldstr. 36, 30163 Hannover   eMail: [EMAIL PROTECTED]
Telefon: +49 511 391088, Fax +49 511 391307, http://www.sgh-net.de/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian Source distributions (was Re: Intent to package pine-src)

[Jules Bean]

--On Thu, May 7, 1998 10:38 am -0400 "Dale Scheetz" <[EMAIL PROTECTED]>
wrote: 

> WRT [Falk's] suggestion above, I don't think that developers can/should
edit
> the .dsc file (its check sum is computed by dpkg and provided in the
> changes file for dinstall to verify the components).
> 
> The correct place for this information is in the control file. This file
> has, at least, two paragraphs. One source paragraph, and, at least, one
> package paragraph (one for each binary package built from this source).
> 
> Currently package depends are placed in the Package paragraph. The logical
> place for source depends field is in the Source paragraph. Then
> dpkg-buildpackage (and friends) could construct the proper .dsc file
> containing the details of the source dependencies.
> 

Agreed.

> I see only one problem with source dependencies: How do you tell the
> difference between a dependency on a source package and the depencency on
> a binary package. I know that most problems are with the need for some
> binary program to allow the build to proceed, but sometimes these needs
> are for a source file to be present (and in the desired location).

Really? This is presumably the exception, rather than the general rule.  In
general, you are only going to be worrying about .h files (which are
provided by the -dev.deb family of packages) and libraries (which are
provided by the lib*.deb packages).

But in any case, the answer is, I would have thought to have have two
different lines.  A 'Depends: ' line and a 'Depends-Source:' line.  (FWIW, I
think Depends-Source is better than Source-Depends, since the latter reads
like 'the source depends on').

> In addition it would be nice if we could come to terms with upstream
> source in multiple tarballs (libc6 comes like that as do many others).

Presumably one complication here is the required unpacking order (do both
tarballs expand into the same dir, or do I have to expand one, then cd to a
different directory and expand the other).

And, finally, as I have said before, it would be nice to see automated
source-downloading available from a front end.  (Preferably the same
front-end as the automated binary downloading - dselect or apt - but in a
different section).

Jules

/+---+-\
|  Jelibean aka  | [EMAIL PROTECTED] |  6 Evelyn Rd|
|  Jules aka |   |  Richmond, Surrey   |
|  Julian Bean   | [EMAIL PROTECTED]|  TW9 2TF *UK*   |
++---+-+
|  War doesn't demonstrate who's right... just who's left. |
|  When privacy is outlawed... only the outlaws have privacy.  |
\--/



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#21969: debian-policy: needs clarification about Standards-Version

[Oliver Elphick]

Dale Scheetz wrote:
  >On 7 May 1998, Manoj Srivastava wrote:
  >
  >>Fine. But the moment any package ``ignores'' policy and
  >>  insists policy is not broken, so should not be fixed, I shall file
  >>  bugs against the package.
  >
  >Which I will happily reasign to Policy.

Hang on, Dale. Just think about this.

A package ignores policy - the only good reason is that policy is
inappropriate to this particular package.

In that case, the policy is inadequate - file a bug against policy,
requesting a better definition.


But if the package maintainer says that policy is _not_ broken, the
fault must be with the package.


You are saying that you would reassign a bug to policy, while at the
same time denying that policy is broken?  That does not make sense.

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight  http://www.lfix.co.uk/oliver
   PGP key from public servers; key ID 32B8FAA1
 
 "If it is possible, as much as it depends on you, live 
  peaceably with all men."Romans 12:18 



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: List of bugs that *must* be fixed before releasing Hamm

[Brian White]

> > > > Several people have asked for this, but maintainers already get separate
> > > > reports about their packages and reports by package are available on
> > > > the web site, so I don't really understand the usefulness of presenting
> > > > it that way here.  Is there something I'm missing?
> > >
> > > If your own bugs are scattered around in a list of several dozen, it is
> > > really easy to miss one. Grouping them together makes this less of a
> > > problem.
> >
> > I guess this is the part I don't really understand.  As a maintainer with
> > open bugs, you're already getting mail from "nag" about them directly so
> > why would you depend on this general mail intended for everybody else.
> 
> Don't even get me started on the nags ;-) In any case they have nothing to
> do with this message.

They have everything to do with this message.  Both come from the same
place.  In fact, the summary report is generated as a by-product of
generating nags.


> If this message is not intended to inform maintainers which of their bugs
> are considered critical to the release then you can stop sending it along
> with those nags.

The message is intended to inform _others_ of the problems that exists
in order to encourage them to help solve those problems.  When people
whine about "When is Hamm going to be released?" I can just point them
to this weekly message and ask them what they've done to help.

  Brian
 ( [EMAIL PROTECTED] )

---
 Generated by Signify v1.04.  For this and more, visit http://www.verisim.com/



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#21969: debian-policy: needs clarification about Standards-Version

[Dale Scheetz]

On Thu, 7 May 1998, Oliver Elphick wrote:

> Dale Scheetz wrote:
>   >On 7 May 1998, Manoj Srivastava wrote:
>   >
>   >>  Fine. But the moment any package ``ignores'' policy and
>   >>  insists policy is not broken, so should not be fixed, I shall file
>   >>  bugs against the package.
>   >
>   >Which I will happily reasign to Policy.
> 
> Hang on, Dale. Just think about this.
> 
> A package ignores policy - the only good reason is that policy is
> inappropriate to this particular package.
> 
> In that case, the policy is inadequate - file a bug against policy,
> requesting a better definition.
> 
> 
> But if the package maintainer says that policy is _not_ broken, the
> fault must be with the package.

Not true.

If the package maintainer says that policy is not broken and the bug
report says that the package violates policy, I would suggest that the
policy needs ammending to clarify the issue and would reassign the bug
accordingly.
> 
> 
> You are saying that you would reassign a bug to policy, while at the
> same time denying that policy is broken?  That does not make sense.
> 
Sure!

Hasn't it been clear from the discusion between Manoj and myself that we
each take different interpretations from the same document. I say the
document is adequate for me to make the decision that it is proper for
particular binaries to be delivered unstripped. This is clear to me from
the Policy that I understand. From Manoj's point of view this is very
unclear and should be fixed. 

I have no problems clarifying the document for others, even when I think I
understand it correctly.

If I believe that I am following the "full" Policy (while appearing to
violate a specific clause) I have no problem with Policy being made more
specific, for those who don't see things the way I do.

BTW, I believe that this is why Ian wants a "Technical Committee". These
kinds of debates cry out for a third party arbitration technique.

Luck,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: on forming a new Linux Distribution

[Ardo van Rangelrooij]

Brederlow <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] writes:
> 
> > No problem here.  As I said I *DID* find the answers and got my debian
> > installation to talk to my
> > ethernet card after making use of available documentation.  But it was not
> > Debian specfic documentation that
> > was most helpfull, but rather general linux networking and slackware
> > specific documentation that gave me my answers.
> 
> I found the Suse handbook a valueable source of information. Debian
> needs a good Handbook (maybe tex, dvi, ps, html)

Within the Debian Documentation Project we're working on a Debian
Tutorial (as well as some other documents and manuals).  Maybe you
want to join us? 

Thanks,

Ardo
-- 
Ardo van Rangelrooij
home email: [EMAIL PROTECTED], [EMAIL PROTECTED]
home page:  http://www.tip.nl/users/ardo.van.rangelrooij
PGP fp: 3B 1F 21 72 00 5C 3A 73  7F 72 DF D9 90 78 47 F9


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Marking bugs as fixed (was Re: Bug#18018: These bugs can be closed.)

[jdassen]

On Thu, May 07, 1998 at 08:16:56AM -0700, Joel Klecker wrote:
> At 16:29 +0200 1998-05-07, Martin Schulze wrote:
> >On Wed, May 06, 1998 at 07:43:45PM -0700, Joel Klecker wrote:
> >Nope!  Non-Maintainer releases doesn't justfify closing of bugreports.
> >They only justify 'severity normal'.
> I was noting it for the maintainer's benefit.

My preferred way of doing that is to use the BTS's "retitle" command, e.g.
retitle 1234 Fixed in NMU: foo: foo --bar fails
(and, if necessary severity 1234 normal).

Ray
-- 
Cyberspace, a final frontier. These are the voyages of my messages, 
on a lightspeed mission to explore strange new systems and to boldly go
where no data has gone before. 


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: List of bugs that *must* be fixed before releasing Hamm

[Dale Scheetz]

On Thu, 7 May 1998, Brian White wrote:

> The message is intended to inform _others_ of the problems that exists
> in order to encourage them to help solve those problems.  When people
> whine about "When is Hamm going to be released?" I can just point them
> to this weekly message and ask them what they've done to help.
> 
So this is strictly for your benfit? ;-)

I don't know if you have looked at the list of bugs against libc6 lately,
but I find this list of "critical release bugs" to be of great help in
organizing my time to the best effect. Putting the list in package order
can only aid me in that effort.

Thank you for "fixing" the order of the list!

I'm sure that those you wish to entice to help via this list will also
find it much easier to determine where help is needed, as well as
possible.

Thanks,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: List of bugs that *must* be fixed before releasing Hamm

[Brian White]

> > The message is intended to inform _others_ of the problems that exists
> > in order to encourage them to help solve those problems.  When people
> > whine about "When is Hamm going to be released?" I can just point them
> > to this weekly message and ask them what they've done to help.
>
> So this is strictly for your benfit? ;-)

Well, I like to think that others also benefit from releasing Debian. :-)


> I'm sure that those you wish to entice to help via this list will also
> find it much easier to determine where help is needed, as well as
> possible.

True.

  Brian
 ( [EMAIL PROTECTED] )

---
 the difference between theory and practice is less in theory than in practice



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Seeking other archs to build packages on

[Shaleh]

I was gratiously given an account by another developer on an alpha.  I
do not believe that imlib/fnlib/E works on m68k -- correct me anyone if
I am wrong.  I would be more than willing to try and get a ppc version
going.  I never received a bug from an alpha maintainer -- I stumbled
across it in the bug list.

-- 
---
How can you see, when your mind is not open?
How can you think, when your eyes are closed?
- Jason Bonham Band, "Ordinary Black and White"
---


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Seeking other archs to build packages on

[James Troup]

Shaleh <[EMAIL PROTECTED]> writes:

> I do not believe that imlib/fnlib/E works on m68k -- correct me
> anyone if I am wrong.

Unless it broke recently, you are; certainly I've seen imlib based
stuff work on m68k IIRC.  m68k is usually the least problematic port
(sparc & powerpc are using dodgy glibc betas, alpha has a less stable
compiler (& libc?) and is 64bit), and I doubt imlib & friends suddenly
became big endian unfriendly.  Of course if E was even packaged, I
could make sure...

> I never received a bug from an alpha maintainer -- I stumbled across
> it in the bug list.

You've certainly received 2 from me WRT to *imlib.

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#22206: Some package uses psmisc without a dependency

[Santiago Vila]

Package: general
Version: 1998-05-07

Today I have just tried the new APT on a libc5 machine to upgrade to hamm.
[ Looks promising! ].

Well, from the hundreds of messages I was able to see a "killall: command
not found" or something alike. I am quite surprised to see that psmisc is
just optional (is this priority ok?).

Anyway, since psmisc is not essential (and this is what really matters),
it would be interesting to know which package uses killall (if any) and
where, to add the appropriate Dependency.

Thanks.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#22206: Some package uses psmisc without a dependency

[James Troup]

Santiago Vila <[EMAIL PROTECTED]> writes:

> Anyway, since psmisc is not essential (and this is what really
> matters), it would be interesting to know which package uses killall
> (if any) and where, to add the appropriate Dependency.

Maintainer scripts (and most everything else) should not use killall,
killall is Evil[1].  Packages using killall should be fixed not to use
it rather than depend on psmisc.

[1]  
http://www.nl.debian.org/Lists-Archives/debian-devel-9801/msg01205.html>

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian Source distributions (was Re: Intent to package pine-src)

[Manoj Srivastava]

Hi,
>>"Dale" == Dale Scheetz <[EMAIL PROTECTED]> writes:

Dale> On 7 May 1998, Falk Hueffner wrote:

Dale> Whithout meaning to sound too negative, I want to caution
Dale> against such patch and fill design. Ian J. worked very hard (and
Dale> was very successful in my opinion) to design the current source
Dale> package format to manage the various problems of absorbing and
Dale> using upstream sources. We should be careful to craft any
Dale> "improvements" to that format in a consistant and smooth
Dale> fashion.

One of the co-maintainers of dpkg (Klee) has made an
 experimental dpkg [not available widely, or outside the CVS
 tree]). It has support for multiple upstream tar balls, multiple
 patches to be applied in sequence using a custon unpack script (in
 case one needs to move things around between pathces or whatever); it
 has unpack-depends, and a separate build-depends. (It has other stuff
 too, it is just that these points stuck in my memory).

Dale> That said, I am strongly in favor of a source dependency
Dale> scheme. It just needs to be workable.

I think this shall be workable. In fact, I think it is
 working, at least for the author (I do not have access ot it
 either). I would advocate patience. It is not as if we could change
 the souce format in the middle of a freeze anyway.

manoj

-- 
 To exist is to change, to change is to mature, to mature is to go on
 creating oneself endlessly.  -- Henri Bergson
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]