Re: Status of Debian Policy

[Erik B. Andersen]

I cannot agree more.  We should definatly add these fields to the
.deb package format!  This will involve a bit of work, but will be
VERY worth it.  No more licensing surprises, for instance.

 -Erik

--
Erik B. Andersen   Web:http://www.inconnect.com/~andersen/ 
   email:  [EMAIL PROTECTED]
--This message was written using 73% post-consumer electrons--

> 
> > 
> > TOPIC 8: packages have to specify their source urls
> > ---
> >   STATUS: DISCUSSION
> >   
> 
> 
> In addition to what you propose below, I think that "dpkg -I" should be
> concerned with some of that info. Specifically, three important fields are
> missing:
> 
> Author: name and email of main upstream author (copyright holder)
> License: code describing license type
> Original-Site: site/URL at which the package is originally stored
> 
> 
> The "Author" field I think is important for giving due credit to whom
> rightfully deserves it. Some novice Debian users might think that the
> maintainer mentioned in "dpkg -I" is the author or the upstream maintainer.
> That is convenient for having users contact the Debian maintainer instead
> of bypassing them for the upstream author. However, I am convinced it is not
> fair for the "real authors" to create this confusion. Once the package is
> installed, users can check who the real author is, but they should be able
> to know it from the beginning.
> 
> The License field shoud be a code taken from a list like the following:
> 
> GPL LGPL BSD Artistic: we know what they are
> PD: public domain
> 
> Freeware: free use and redistribution, according to Debian policy (this will
>   be used only for packages which do not follow any of the types given
>   above)
> 
> Non-Free: does not comply with Debian definition of free software
> 
> We could even go further and specify the type of non-free license.
> Common types are:
> 
> packages containing sources
> ---
> 
> Non-Commercial: free use and redistribution for non-commercial purposes
> Academic: free use and redistribution for academic/research purposes
> Non-Commercial-Academic: combination of previous types
> Source-Shareware: redistribution allowed, but payment for use expected
> Tidyware: free use, redistribution only in original form or if approved
>   by author
> 
> packages without sources
> 
> Crippleware: crippled functionality, fully functional version must be 
> purchased
> Demoware: time-bombed fully functional program
> Shareware: redistribution allowed, payment for use expected
> Promotional: free use for only some people or for some time only, or due to
>  blatantly promotional reasons (like MSIE)
> Shyware: free use and redistribution of binaries, sources not available
>  because author considers them still alpha.
> 
> 
> I don't think there are many more types. The precise terms should be available
> in the "copyright" file, but since most packages would fall in one of 
> the previous categories, it would be really useful to have that shown
> in a concise way before installing a package.
> 
> The "Original-Site" field could be optional, since it is not that necesary to
> know it in normal cases. Of course, it should always be mentioned in
> the "README.debian" file, as you propose.
> 
> In summary, I think that at least the "Author" field should be added for
> ethical reasons and it would be convenient to add the "License" field.
> If you agree that this should be part of Debian policy then we should
> have the "dpkg" authors implement it.
> 
> > 
> > It has been proposed that all packages should include some information
> > about where to get the upstream sources. Thus, I propose that we list
> > all pieces of information we want to have included in the
> > ``/usr/doc/*/README.debian'' files.
> > 
> > If we have a consensus about this, we could include a ``good example''
> > for a ``/usr/doc/*/README.debian'' file.
> > 
> > I propose that the following infos are listed in this file:
> > 
> >  - Name and email address of current Debian maintainer
> >  - specification about where to get the upstream sources
> >  - short description of all major changes to the program
> >(for example, new command line options, changed locking
> >mechanism, major bug fixes, etc.)
> >  - URL of ``official home page'' if there is one (optional)
> > 
> 
> 
> --
> TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
> [EMAIL PROTECTED] . 
> Trouble?  e-mail to [EMAIL PROTECTED] .
> 



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

File Locking

[Karl M. Hegbloom]

 Everything I know about file locking[1], I've learned from the short
chapter on it in "Beginning Linux Programming" (WROX Press), part of a
chapter that I've only skimmed in "UNIX Systems Programming for
SYSVr4" (O'Reilly), and from the manual pages to `fcntl', `flock',
`lockf', `open', and `lockfile'.  There is doubtless information in
the "POSIX Programmer's Guide" (O'Reilly), also, but I've not started
that one yet.[2]


mis en place:

 I know that there are several stand-alone programs for handling
file-locking, and that the `procmail' package has a fairly good setup
for that.  INND apparently does as well; as does `mgetty-fax'.

`lockfile' --> procmail
`shlock'   --> innd
`newslock' --> mgetty-fax

 There is also:  publib-0.26/liw/lockfile/*

** Publib looks like it might already be the library needing to be
created that was mentioned earlier... or at least a very good start.

`sysid'--> util-linux
libuuid.so --> libuuid

 It would seem to me that things like this could be gleaned from the
sources to many programs, and put together into a shared library.
That will take a lot of work, for certain.  What's in Midnight
Commander?

Q: Who will do the work?  I am doubtful of my own ability to be of
much help...  I'd like to see what gets done by the programmer though.

 Did I miss anything?  I'm reading INND manuals today...  I want to
learn how to set up a news box, so I'm going to fill a partition with
a spool.  (I wonder if I'll have it working by dark?)


Footnotes: 
[1]  I'm a beginner C programmer... strike that.  Not programmer, but
code reader, or person who attempts to understand code. ;-)

[2]  It's someplace within a heap of books... the heap without
bookmarks stuck inside any of the first few chapters, yet.

-- 
Karl M. Hegbloom <[EMAIL PROTECTED]>
http://www.inetarena.com/~karlheg
Portland, OR  USA
Debian GNU 1.3  Linux 2.1.36 AMD K5 PR-133


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Debian target audience

[joost witteveen]

> The problem of having both libc5 and libc6 run-time libraries is minor,
> the main one is that those stuck with libc5-dev cannot use other
> newly-available versions of *libraries* from hamm. 

How do you mean? You can install the *libraries* just fine, it's just
the development versions that fail to install.

And even then, why not install lib5-altdev? Then there is no problem
whatsoever.

-- 
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: what wants dpkg-gencontrol to tell me?

[Mark Eichin]

> dpkg-gencontrol: failure: chown new files list file: Illegal seek

It means that you don't have a utmp entry for that shell.  Upgrade to
a newer dpkg-dev (probably from unstable) for a version that just
whines about the lack of utmp entry, instead of actually breaking...


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: what wants dpkg-gencontrol to tell me?

[Sven Rudolph]

Christian Leutloff <[EMAIL PROTECTED]> writes:

> # dpkg-gencontrol
> dpkg-gencontrol: failure: chown new files list file: Illegal seek
> 
> I can't figure out what dpkg-gencontrol want to tell me 8-(

That's a bug, you have to use dpkg-dev from development.

Sven
-- 
Sven Rudolph <[EMAIL PROTECTED]> ; WWW : http://www.sax.de/~sr1/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Status of Debian Policy

[Mark Baker]

In article <[EMAIL PROTECTED]>,
Christian Schwarz <[EMAIL PROTECTED]> writes:

> The current structure (of packages installed on my system) is:
> 
>   Miscellaneous
>   Development
>   Document Preparation
>   Information
>   Emacs
>   Programming
>   teTeX
>   Graphics
>   Games
>   General Commands

Is this the best order?

Really the first one should be that for info itself, followed by the linux
and debian FAQs. What goes after that I don't know, but I find the current
one difficult to navigate.

> I'm sure the info docs will be available in the future! The question of
> topic 11 was which format the .deb's should ship:
> 
>- only info; html in extra .deb
>- only html; info in extra .deb
>- html _and_ info

I think either only info, or neither; I don't want to fill my hard disc with
HTML when there's perfectly good info documentation available. (HTML will be
as good as info once it's got previous, next and up commands built into the
browser: this is possible with HTML 3 but I don't know of any browsers that
implement it)

Re: Unresolved symbols with ibmtr_cs PCMCIA module

[Stephen Zander]

Brian Mays wrote:
> If anyone needs these packages now, before they can be included into
> the distribution, send me a message and I can e-mail them using either
> MIME encoding or uuencode.

Could I ftp copy from somehwere?  My fire-wall gets sensetive about large
mailings


Stephen
---
"Normality is a statistical illusion." -- me


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

what wants dpkg-gencontrol to tell me?

[Christian Leutloff]

Hello!

# dpkg-gencontrol
dpkg-gencontrol: failure: chown new files list file: Illegal seek

I can't figure out what dpkg-gencontrol want to tell me 8-(

Even old packages which build pretty fine some weeks ago, fails this
way. As there is no verbose option, I don't know where I have to look
8-((

Debian GNU/Linux dpkg-gencontrol 1.4.0.8. I'm using Debian 1.3 (or
something near to the release)

Any ideas?

Thanks
 Chrisitan

-- 
Christian Leutloff, Aachen, Germany
   eMail: [EMAIL PROTECTED]   http://www.oche.de/~leutloff/

Debian/GNU Linux! Mehr unter http://www.debian.org/



pgpIuIOIPtDZy.pgp
Description: PGP signature

Re: Status of Debian Policy

[Santiago Vila Doncel]

-BEGIN PGP SIGNED MESSAGE-

On Sun, 15 Jun 1997, Christian Schwarz wrote:

> TOPIC 11: policy about including documentation
> 
> The current policy concerning docs is:
> 
>  - HTML is the preferred format
>  - if the package includes docs than can be converted into HTML,
>the maintainer should do so
>  - if the doc files are to big, they should go into a seperate
>package
> 
> There are a few problems, though:
> 
>  - .info files can be converted into HTML on-the-fly by the CGI
>script "info2www". However, the output of ``texi2html'' is
>much better. Should we ship only HTML by default and put
>.info in a seperate package? (cf. bug #7890)

The simplest solution is to ship html in a different package. This way
the user will be able to choose to not install the html docs if he/she
believes info2www is enough.

IMHO we should not drop .info from the main package, or we would have drop
the "GNU" in "GNU/Linux" (info is GNU's standard documentation system).

>  - how "large" may doc files be until they are moved into a
>seperate package?

In general: 1 byte :-) By placing them in a separate package, the user
will be able to not install it if he/she wishes, and we will save a lot of
disk space in master, since doc packages go to binary-all.

I would change the policy from "if the doc files are to big, they should
go into a seperate package" to "if the doc files are too small, they may
go in the same package".

Thanks.

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

iQCVAgUBM6WcASqK7IlOjMLFAQFSUAP+OJuJGkVKSm/UL0mLHVlnpB+EBhWOjyvP
z88sDDvhEMpyfeVRW4tPaoQRkvdiPsurDlWtT/29UemlA6BVZVHFFCWQ8EnSwGwD
nR3R7XJesaaHyrBuobkC+WEMvn3/un8lKU6FEiqdHMCrda8rSNuaUPqNOVPOwYph
3F2IP1Hhmfc=
=bY+m
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Status of Debian Policy

[Santiago Vila Doncel]

-BEGIN PGP SIGNED MESSAGE-

On Sun, 15 Jun 1997, Christian Schwarz wrote:

> TOPIC 7: new definition of ``free software''

This is only about the "main" section.

In addition to that, I wonder why we are supporting this packages in the
`contrib' section:

 * whose copyright permission notices (or patent problems) allow only
   distribution of compiled binaries (and thus of which only binaries
   are available)
 * allow free use only for a trial period (shareware)
 * are demonstration programs lacking vital functionality
   (crippleware)

Are there many of them?

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

iQCVAgUBM6WYyiqK7IlOjMLFAQGw6AP+L6LUnhtU8/Qzs56vKy6uj+bd0W1E1IaW
Q4TYsBlhh+r5lO2QXl+t7I0X+yB+AnNhGGA9Vo87tyGgavcAwtSBoD+rtKXvlxD5
C5nj+wooqe9HaOhpePhbgSPLXq9lyOgHE5PsUNaIxzTfJu3/KeLWJjMgU79M3xmr
mQxiKZ+gM2s=
=1uNv
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Obsolete package CGI-modules (hamm)

[Scott K. Ellis]

-BEGIN PGP SIGNED MESSAGE-

On 16 Jun 1997, Manoj Srivastava wrote:

>   With the advent of perl 5.004, the package CGI-modules is now
>  obsolete (all the libraries are present in the new Perl package).
> 
>   It should be therefore removed from hamm. Could the powers
>  that be take care of this please?

Umm, actually perl5 only includes CGI.pm, and CGI::Apache, Carp, Fast,
Push, and Switch.  The libs from CGI-modules are NOT included.  So we do
still need a cgi-modules package, although perhaps in a renamed and
cleaned up state (perl-cgi-modules), here's your chance to fix the
capitilization :)

++
|   Scott K. Ellis   |   Argue for your limitations and  |
|   [EMAIL PROTECTED]   | sure enough, they're yours.   |
||-- Illusions   |
++

-BEGIN PGP SIGNATURE-
Version: 2.6.3
Charset: noconv

iQCVAwUBM6WXm6Ck2fENdzpVAQGIIQQArSE/s5vg6lLWkoeTIPsWhB5CtNo/CNge
2t4AN24RIHiSPQ200kpS+81UXi4A/D/6Z4w2wn+XP6w/W8x0NaQJfqU4MVeTg7Yv
kJsn2nSBpg+EInCPnsXvalNbtp99GeUH1xaZzg1zlei1prcQHh6IqxDyluRwRSsc
y1NNMgh3tCc=
=IC/6
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Status of Debian Policy

[Fernando]

> 
> TOPIC 8: packages have to specify their source urls
> ---
>   STATUS: DISCUSSION
>   


In addition to what you propose below, I think that "dpkg -I" should be
concerned with some of that info. Specifically, three important fields are
missing:

Author: name and email of main upstream author (copyright holder)
License: code describing license type
Original-Site: site/URL at which the package is originally stored


The "Author" field I think is important for giving due credit to whom
rightfully deserves it. Some novice Debian users might think that the
maintainer mentioned in "dpkg -I" is the author or the upstream maintainer.
That is convenient for having users contact the Debian maintainer instead
of bypassing them for the upstream author. However, I am convinced it is not
fair for the "real authors" to create this confusion. Once the package is
installed, users can check who the real author is, but they should be able
to know it from the beginning.

The License field shoud be a code taken from a list like the following:

GPL LGPL BSD Artistic: we know what they are
PD: public domain

Freeware: free use and redistribution, according to Debian policy (this will
  be used only for packages which do not follow any of the types given
  above)

Non-Free: does not comply with Debian definition of free software

We could even go further and specify the type of non-free license.
Common types are:

packages containing sources
---

Non-Commercial: free use and redistribution for non-commercial purposes
Academic: free use and redistribution for academic/research purposes
Non-Commercial-Academic: combination of previous types
Source-Shareware: redistribution allowed, but payment for use expected
Tidyware: free use, redistribution only in original form or if approved
  by author

packages without sources

Crippleware: crippled functionality, fully functional version must be purchased
Demoware: time-bombed fully functional program
Shareware: redistribution allowed, payment for use expected
Promotional: free use for only some people or for some time only, or due to
 blatantly promotional reasons (like MSIE)
Shyware: free use and redistribution of binaries, sources not available
 because author considers them still alpha.


I don't think there are many more types. The precise terms should be available
in the "copyright" file, but since most packages would fall in one of 
the previous categories, it would be really useful to have that shown
in a concise way before installing a package.

The "Original-Site" field could be optional, since it is not that necesary to
know it in normal cases. Of course, it should always be mentioned in
the "README.debian" file, as you propose.

In summary, I think that at least the "Author" field should be added for
ethical reasons and it would be convenient to add the "License" field.
If you agree that this should be part of Debian policy then we should
have the "dpkg" authors implement it.

> 
> It has been proposed that all packages should include some information
> about where to get the upstream sources. Thus, I propose that we list
> all pieces of information we want to have included in the
> ``/usr/doc/*/README.debian'' files.
> 
> If we have a consensus about this, we could include a ``good example''
> for a ``/usr/doc/*/README.debian'' file.
> 
> I propose that the following infos are listed in this file:
> 
>  - Name and email address of current Debian maintainer
>  - specification about where to get the upstream sources
>  - short description of all major changes to the program
>(for example, new command line options, changed locking
>mechanism, major bug fixes, etc.)
>  - URL of ``official home page'' if there is one (optional)
> 


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Obsolete package CGI-modules (hamm)

[Christian Schwarz]

On 16 Jun 1997, Manoj Srivastava wrote:

> Hi,
> 
>   With the advent of perl 5.004, the package CGI-modules is now
>  obsolete (all the libraries are present in the new Perl package).
> 
>   It should be therefore removed from hamm. Could the powers
>  that be take care of this please?

Guy is responsible for such things. However, he said he's offline for 4
weeks. I suggest you file this as a bug report against the package
"ftp.debian.org" so he doesn't forget about it when he cames back.


Thanks,

Chris

--  Christian Schwarz
   [EMAIL PROTECTED], [EMAIL PROTECTED]
  [EMAIL PROTECTED], [EMAIL PROTECTED]
   
PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
  
 CS Software goes online! Visit our new home page at
 http://www.schwarz-online.com


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Package priorities and dependencies.

[Santiago Vila Doncel]

-BEGIN PGP SIGNED MESSAGE-

> > So IMHO you should have added to your initial list of packages the ones on
> > which they depend, until all dependencies are satisfied. dselect does this
> > automatically. If you don't like it, it is supposed to be done by hand.
>
> If this is true then there is no purpose served by priorities and they
> should be abandoned. THIS IS NOT THE CASE.

I was not objecting to the conclusion but to the reasoning. I agree that
it would be a "nice" thing to have some self-contained subsets like
required+important. Just that every installation method (horizontal
or not) should always take Dependencies into account. Of course by
changing some priorities a little bit we can achieve to satisfy some
dependencies more easily for some subsets of packages.

I think libraries should not need priorities (or they need them much less
than ordinary program packages). So if they have more or less priority, I
really don't mind. Go ahead.

Thanks.

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

iQCVAgUBM6WNfiqK7IlOjMLFAQGadAQAtjAADH7OracMJE5/fNyBqaG74gIcRRtz
f102niYjo02t6FFomuSZxf6RefiJwOxOul0O0NB/8UUcTZN4kyCkT91afUmh1BKV
q3XM28pMZnlDAerJpIUp4ICD5ZW5FHRmB0AqPF/KxVmSULInE6Sa92ONU5f9hwx1
FoqCqpliTic=
=Xk2A
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Status of Debian Policy

[Christian Schwarz]

On 15 Jun 1997, Ardo van Rangelrooij wrote:

> I have another policy issue which is related to topic 11 (see below).
> 
> The current layout of Info entries in the main Info menu (in the file
> /usr/info/dir) looks rather messy.  I found the following "descrepencies":
> 
>  - not all packages are placed in an appropriate section
>  - the descriptions are not formatted consequently
>  - some sections are somewhat large (this is personal)
>  - some descriptions are somewhat large (this is personal too)
> 
> I believe we can do better. Therefor, I propose an extension/change to
> Section 3.2.3 of the Debian Policy Manual:

Great! Thanks for the proposal. A few points though...

>  - During install of an Info documents you MUST specify a section.
>Preferably use the section the package belongs to in the Debian
>distribution.  As a starting point the "dir" file in the base-files
>package could already contain these sections, albeit empty.
> 
>We could also use a different, sometimes more logical grouping. E.g.,
>I'm using the following sections for the development packages:
> 
> - compilers
> - linkers
> - interpreters
> - generators (i.e. bison, flex, gperf, etc.)
> - libraries
> - development tools (i.e. make, gdb, etc.)
> - internals (i.e. gdb-internals, stabs, etc.)
> 
>If the Info doc has a lot of subentries, make a separate section
>for it, as has been done for the GNU file, text, shell, and shar
>utilities.

I suggest that we define several sections which should be used. If someone
has an info file which does not fit anywhere, he has to ask on
debian-devel for it and it will eventually be added to the Policy Manual. 

The current structure (of packages installed on my system) is:

Miscellaneous
Development
Document Preparation
Information
Emacs
Programming
teTeX
Graphics
Games
General Commands

Note, that only "Miscellaneous" has a colon (:) after it. This should be
changed...

Note, that AFAIK install-info automatically removes empty sections from
the "info dir". I think this is actually very good. I don't want to have
all those empty section in the dir file of the base system.

>  - Start the description at a to-be-determined fixed position, e.g.
>first line at position 41 and second and subsequent lines at position
>43.  This unclutters the layout, but the positions should be such
>to leave enough room for a short, one-line, to-the-point decription.

Can't we simply change "install-info" to do this automatically? This would
make it a lot easier...

>  - Instead of using the upstream provided description, provide an own
>one-line one which fits on the same line as the menu entry.  A three
>line description for awk may be nice but clutters the layout, e.g.

Correct. (For example, the "Make" entry is _way_ too long.)

> In the light of topic 11 the above may be not that important anymore,
> but if we plan to keep Info docs around (I have not heard otherwise
> yet) I believe we should discuss the above.

I'm sure the info docs will be available in the future! The question of
topic 11 was which format the .deb's should ship:

   - only info; html in extra .deb
   - only html; info in extra .deb
   - html _and_ info

> I was also wondering whether we plan to organize the documentation
> under dwww in a way similar to the Info docs (sectioning, layout,
> etc.).  Anybody some thoughts on this?

I think Jim was working on such an enhancement for dwww. We should ask him
when his is back.


Cheers,

Chris

-- Christian Schwarz
Do you know [EMAIL PROTECTED], [EMAIL PROTECTED],
Debian GNU/Linux?[EMAIL PROTECTED], [EMAIL PROTECTED]
  
Visit  PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
http://www.debian.org   http://fatman.mathematik.tu-muenchen.de/~schwarz/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . Trouble? 
e-mail to [EMAIL PROTECTED] .

kernel images and psdatabase

[Manoj Srivastava]

Hi,

On debian-user, I noticed that apparently one does not need to
 carry around /boot/psdatabase, since ps can read the information from
 System.map. Is there anything at all that needs psdatabase? 

If there is no other reason to keep psdatabase, I'll modify
 kernel-package not to install an extra vmlinux file in to the
 package (it is removed in the postinst, but it does make the package
 larger).

If you are enamoured of the psdatabase, speak now or forever ..

manoj

-- 
 Without coffee he could not work, or at least he could not have
 worked in the way he did.  In addition to paper and pens, he took
 with him everywhere as an indispensable article of equipment the
 coffee machine, which was no less important to him than his table or
 his white robe. Stefan Zweigs, Biography of Balzac
Manoj Srivastava   mailto:[EMAIL PROTECTED]>
Mobile, Alabama USAhttp://www.datasync.com/%7Esrivasta/>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Obsolete package CGI-modules (hamm)

[Manoj Srivastava]

Hi,

With the advent of perl 5.004, the package CGI-modules is now
 obsolete (all the libraries are present in the new Perl package).

It should be therefore removed from hamm. Could the powers
 that be take care of this please?

manoj,
 ex-maintainer of CGI-modules
-- 
 "Infidels in all ages have battled for the rights of man, and have at
 all times been the fearless advocates of liberty and justice." Robert
 Green Ingersoll
Manoj Srivastava   mailto:[EMAIL PROTECTED]>
Mobile, Alabama USAhttp://www.datasync.com/%7Esrivasta/>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Status of Debian Policy

[Christian Schwarz]

On Mon, 16 Jun 1997, joost witteveen wrote:

[snip]
> > I'm somehow confused now. Is registering to "dwww" any different from the
> > "menu" system? Joost, perhaps you can give use some hints here (I think
> > Jim is offline now).
> 
> It used to be the same, and that's why I also asked Jim about that.
> But he seems to have something different in mind, I'm not quite sure 
> what he does have in mind though. Also I'm not sure it's better than
> what we have currently, but anyway, here's an email he sent me:
> (I hope Jim doesn't mind me reproducing it, but it seems he isn't
> telling any secrets here)
[snip]

Unfortunately, Jim is offline so he can't explain his concepts.

I hope he has good arguments for it, since I would not like to have two
concurring menu systems in Debian: menu and dwww. I think it shouldn't be
too hard to change the menu package to dwww's needs, if this should be
necessary. 

If the text of my "Policy Proposal" actually works with the current "menu"
package, I'd say we include this in the next Policy Manual. If Jim is back
and we should decide that the registering method really has to be changed,
we can simply adopt the Policy again.

Joost, is the proposed text correct?


Thanks,

Chris

-- Christian Schwarz
Do you know [EMAIL PROTECTED], [EMAIL PROTECTED],
Debian GNU/Linux?[EMAIL PROTECTED], [EMAIL PROTECTED]
  
Visit  PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
http://www.debian.org   http://fatman.mathematik.tu-muenchen.de/~schwarz/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . Trouble? 
e-mail to [EMAIL PROTECTED] .

Re: Status of Debian Policy

[Christian Schwarz]

On 16 Jun 1997, Rob Browning wrote:

> Christian Schwarz <[EMAIL PROTECTED]> writes:
> 
> > This really is an _excellent_ idea! So, we just need a volunteer to
> > implement and maintain this "upstream library". (The packaging for Debian
> > should not be a problem.)
> 
> Ideally we could provide C, perl, python, etc versions of the code.

Exactly. (If you check my original posting, you'll discover that this
comes right after building the C library.)


Chris

-- Christian Schwarz
Do you know [EMAIL PROTECTED], [EMAIL PROTECTED],
Debian GNU/Linux?[EMAIL PROTECTED], [EMAIL PROTECTED]
  
Visit  PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
http://www.debian.org   http://fatman.mathematik.tu-muenchen.de/~schwarz/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . Trouble? 
e-mail to [EMAIL PROTECTED] .

Re: When will bash 2.01 be packaged?

[Christian Schwarz]

On Mon, 16 Jun 1997 [EMAIL PROTECTED] wrote:

> Hello,
> 
> I just saw this post in comp.os.linux.x. I think this is enough reason to
> upgrade bash from 2.00 to 2.01. When will this happen?

Guy Maor is the current maintainer of the "bash" package. However, he told
us that he is offline for about 4 weeks. So I think someone else should
grab it and upload a non-maintainer (interim) release.


Thanks,

Chris

--  Christian Schwarz
 [EMAIL PROTECTED], [EMAIL PROTECTED],
Debian is looking [EMAIL PROTECTED], [EMAIL PROTECTED]
for a logo! Have a
look at our drafts PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
athttp://fatman.mathematik.tu-muenchen.de/~schwarz/debian-logo/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Package priorities and dependencies.

[Christian Schwarz]

On Mon, 16 Jun 1997, Dale Scheetz wrote:

> On Mon, 16 Jun 1997, Santiago Vila Doncel wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > 
> > On Sun, 15 Jun 1997, Dale Scheetz wrote:
> > > Two packages in the list of "important" refused to install because they
> > > declared (correctly) their dependence upon packages of lower priority.
> > > 
> > >   at  depends on  libelf0 priority: optional
> > >   groff   depends on  libg++27priority: standard
> > > 
> > > It seems to me that packages of any priority level should not be dependent
> > > upon packages of lower priority.
> > 
> > I think this reasoning is wrong: We don't want to install libelf0 and
> > libg++27 because they are "important", we want to install them to satisfy
> > dependencies! The library itself is useless if no program uses it.
> > 
> > So IMHO you should have added to your initial list of packages the ones on
> > which they depend, until all dependencies are satisfied. dselect does this
> > automatically. If you don't like it, it is supposed to be done by hand.
> > 
> If this is true then there is no purpose served by priorities and they
> should be abandoned. THIS IS NOT THE CASE. 
> As I understand it the priority scheme was designed to give a "horizontal"
> installation method. It was intended to provide another selection method
> for performing installation based on a "usefulness" criterion.
> I still argue that for this to continue to be useful it must continue to
> be modular in its design or it looses its usefulness.
> I firmly believe that dependencies should be provided within the same
> priority level or this organizational structure will fail to live up to
> the expectations for it.

100% agreed.

I think that the word "priorites" is not that good. We currently use the  
"priority" values to define several "subsystems" (cf. policy manual). For
example, the minimal system includes all packages from
"required+important". A medium sized system would contain "standard"
packages. A large system would also have the "optional" packages
installed. (Of course, the user can override these "default selections".)

So, if you enter dselect the first time, it will automatically tag all
packages with priority "important" as "to-be-installed". If you leave the
selection screen, dselect would probably bring you into the "dependency
resolution" screen and would tell you, that you will need a few shared
libraries, too.

I think the "sub-systems" defined by the priority levels should be
consistent and thus, a package should not depend on a package with lower
priority level, or the priority level of the latter has to be increased.


Thanks,

Chris

-- Christian Schwarz
[EMAIL PROTECTED], [EMAIL PROTECTED],
Don't know Perl? [EMAIL PROTECTED], [EMAIL PROTECTED]
  
Visit  PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
http://www.perl.com http://fatman.mathematik.tu-muenchen.de/~schwarz/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Unresolved symbols with ibmtr_cs PCMCIA module

[Stephen Zander]

Brian Mays wrote:
> This is caused by an incompatibility between the pcmcia modules and
> the kernel's configuration.  I've created new packages that fix this
> problem (pcmcia-cs and pcmcia-modules-2.0.30-7, both version 2.9.6-1)
> that currently are waiting to be included in the distribution.  I am
> sorry for the inconvenience.
> 
> If anyone needs these packages now, before they can be included into
> the distribution, send me a message and I can e-mail them using either
> MIME encoding or uuencode.
> 
> Brian
> 

Me please!

Do I need to replace both packages?  Also, do I need to change anything
when building a custom kernel (2.0.30) - I'd already tried this once to
see if it helped.


Stephen
---
"Normality is a statistical illusion." -- me


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Hamm: Exim + Chos standard?

[Kai Henningsen]

[EMAIL PROTECTED] (Miquel van Smoorenburg)  wrote on 16.06.97 in <[EMAIL 
PROTECTED]>:

> In article <[EMAIL PROTECTED]>,
> Kai Henningsen <[EMAIL PROTECTED]> wrote:
> [exim]
> >I also hope to figure out how to get exim to have a customer-configurable
> >spam block when acting as MX for those customers - I think they'll like
> >that very much, and it sure looks as if that should be possible.
>
> Oh yes, please look into this. I hacked up a nice solution for sendmail-
> see http://miquels.www.cistron.nl/nospam/
>
> Basically, you check when mail comes in if you are an MX for the recipient
> domain. If not, you refuse it. Hard error (5xx) if you really aren't an
> MX, soft error (4xx) if there's a DNS failure. Works great - we've been
> abused a lot as spam relay the last couple of weeks, and it has stopped
> completely now. I really get a kick out of looking at mail.log checking
> out all the rejections :)

While I'm pretty certain that exim can do this (I think smail still has  
problems), it is not what I was talking about.

I meant the possibility for a customer to request the ISP exim to reject  
any mail that comes from, say, savetrees.com. You know, what AOL does,  
except I want individual customers to be able to configure individual  
lists.


MfG Kai


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Debian's mail daemons

[Kai Henningsen]

[EMAIL PROTECTED] (Michael Alan Dorman)  wrote on 15.06.97 in <[EMAIL 
PROTECTED]>:

> My two personal reservations:
>
>  1) I think Daniel J. Bernstein (qmail's author) doesn't seem to know
> how to have a technical discussion without seeming as if he's tacking
> an implicit "you stupid idiot" on to the end of each sentence, which
> irks me.

And it's not always implicit, either. Having him on a technical mailing  
list does make for frequent flame wars, in every case I've seen.

>  2) I understand that he did measurements, and found that it was
> faster to do multiple SMTP connections than doing multiple RCPT's for
> a single message going to multiple users on a single host, but, I
> think he should have done what he basically did in every other
> instance and said, "tough shit, it's a problem with your MTA, switch
> to qmail, which does it right", and then had qmail do it right (in
> other words, quickly).

Multiple simultaneous SMTP connections are, of course, highly antisocial  
to the host at the other end. And if multiple sequential SMTP connections  
are faster, then somebody is doing something very wrong here.

> Absent those reservations, which are not serious, he's written quite a

I consider them very serious. Besides, the author's attitude problem  
applies to standards, too, another point I find unacceptable.

I find myself completely unable to trust him. So, qmail cannot be an  
option for machines I administer.

I should probably mention that I have similar trust problems with  
sendmail. Besides the sendCERTadvisories problem, I have trouble trusting  
a program when it's author admits that he purposefully inserted a back  
door in that program (it's the DEBUG hack that made the Internet Worm  
possible - it was meant to give root access to the main sendmail test  
machine, because the author didn't have the root password).

> mailing lists here at UM, using raw qmail.  It is about 1000% times
> easier to set up than sendmail, seems to have a much lower impact on
> the system, etc.

What isn't about 1000 times easier to set up than sendmail? :-)


MfG Kai


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: locale errors

[Kai Henningsen]

[EMAIL PROTECTED] (Mark Baker)  wrote on 15.06.97 in <[EMAIL PROTECTED]>:

> > perl: warning: Setting locale failed.
> > perl: warning: Please check that your locale settings:
> > LC_ALL = (unset),
> > LANG = "us"
> > are supported and installed on your system.
> > perl: warning: Falling back to the standard locale ("C").
>
> I got that (with perl only) before I installed debian; it doesn't like
> locale settings that other programs seem to get on with OK. Try removing the
> LANG variable and it ought to work. Is whatever sets LANG (your .bashrc?)
> something you copied off another system?

Removing LANG is, of course, not an option, except maybe for people from  
English-speaking countries.

MfG Kai


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

When will bash 2.01 be packaged?

[J . R . Blaakmeer]

Hello,

I just saw this post in comp.os.linux.x. I think this is enough reason to
upgrade bash from 2.00 to 2.01. When will this happen?

Remco

On 16 Jun ,[EMAIL PROTECTED] ("Greg DeFreitas") wrote about
 Re: bash upgrade killed Netscape shelling...:
> 
> In article <[EMAIL PROTECTED]>,
>   [EMAIL PROTECTED] (Andreas Steffan) writes:
>> 
>> In article <[EMAIL PROTECTED]>,
>>  Steven Richman <[EMAIL PROTECTED]> writes:
>>> I just upgraded from Slackware 3.1 to 3.2, and am now running bash
>>> 2.00.0(1). Now, whenever Netscape "sh -c"'s to execute a helper
>>> application (e.g. xanim) I get the following silly parse error:
>>> 
>>> sh: -c: line 1: missing closing ')' for arithmetic expression
>>> sh: -c: line 1: syntax error near unexpected token ';'
>>> sh: -c: line 1: '((xanim /tmp/myfile); rm /tmp/myfile )&'
>>> 
>>> I find it odd that this would have changed...
>> 
>> Configure bash with the --disable-dparen-arithmetic option.
> ...or, upgrade to:
> 
> 04:03 uniques:~/wget$ bash --version
> GNU bash, version 2.01.0(1)-release (i586-pc-linux-gnu)
> Copyright 1996 Free Software Foundation, Inc.
> ;-)


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Debian target audience

[Alex Yukhimets]

> 
> Alex Yukhimets:
> > Debian is the effort of a large number of developers and primararily
> > *for* developers.
> 
> I disagree. I think Debian is for anyone who wants a good Linux
> system, and who doesn't need much non-free software.
  ^^^
That was exactly my point. Why should Debian cut off those
who *does* need non-free software? Especially developers.

> 
> I don't agree that having both libc5 and libc6 run-time libraries
> in use at the same time is important enough to burden ourselves
> with duplicate packages.

The problem of having both libc5 and libc6 run-time libraries is minor,
the main one is that those stuck with libc5-dev cannot use other
newly-available versions of *libraries* from hamm. 

Thanks.

Alex Y.

> 
> I don't mind if someone maintains separate libc5 packages, but it
> should not be the project.
> 
> -- 
> Please read  before mailing me.
> Please don't Cc: me when replying to my message on a mailing list.
> 
> 

-- 
   _   
 _( )_
( (o___
 |  _ 7  '''
  \(")  (O O)
  / \ \ +---oOO--(_)+
 |\ __/   <--   | Alexander Yukhimets   [EMAIL PROTECTED] |
 || |   http://pages.nyu.edu/~aqy6633/  |
 (   /  +-oOO---+
  \ /  |__|__|
   )   /(_  || ||
   |  (___)ooO Ooo
\___)


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Status of Debian Policy

[Rob Browning]

Christian Schwarz <[EMAIL PROTECTED]> writes:

> This really is an _excellent_ idea! So, we just need a volunteer to
> implement and maintain this "upstream library". (The packaging for Debian
> should not be a problem.)

Ideally we could provide C, perl, python, etc versions of the code.

-- 
Rob


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Package priorities and dependencies.

[Dale Scheetz]

On Mon, 16 Jun 1997, Santiago Vila Doncel wrote:

> -BEGIN PGP SIGNED MESSAGE-
> 
> On Sun, 15 Jun 1997, Dale Scheetz wrote:
> > Two packages in the list of "important" refused to install because they
> > declared (correctly) their dependence upon packages of lower priority.
> > 
> > at  depends on  libelf0 priority: optional
> > groff   depends on  libg++27priority: standard
> > 
> > It seems to me that packages of any priority level should not be dependent
> > upon packages of lower priority.
> 
> I think this reasoning is wrong: We don't want to install libelf0 and
> libg++27 because they are "important", we want to install them to satisfy
> dependencies! The library itself is useless if no program uses it.
> 
> So IMHO you should have added to your initial list of packages the ones on
> which they depend, until all dependencies are satisfied. dselect does this
> automatically. If you don't like it, it is supposed to be done by hand.
> 
If this is true then there is no purpose served by priorities and they
should be abandoned. THIS IS NOT THE CASE. 
As I understand it the priority scheme was designed to give a "horizontal"
installation method. It was intended to provide another selection method
for performing installation based on a "usefulness" criterion.
I still argue that for this to continue to be useful it must continue to
be modular in its design or it looses its usefulness.
I firmly believe that dependencies should be provided within the same
priority level or this organizational structure will fail to live up to
the expectations for it.

Later,

Dwarf
-- 
_-_-_-_-_-_-  _-_-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (904) 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 FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Status of Debian Policy

[joost witteveen]

> On Sun, 15 Jun 1997, Jim Pick wrote:
> 
> > 
> > > >  All packages that provide HTML documentation should register these
> > > >  documents to the menu system, too. Check out section section 4.1, 
> > > > `Web
> > > >  servers and applications' for details.
> > > 
> > > Is that as well as registering with dwww?
> > 
> > I'm changing the way documents register themselves with dwww (again).
> > Hopefully, I'll get enough accomplished so that I can upload 
> > something to experimental today.  I wouldn't encourage anybody to
> > register their documents with dwww just yet, since it's all going
> > to change.  Hopefully, I'll get past the prototype stage in the
> > next month or so, and there will be a standard supported way of
> > registering documents with dwww.
> 
> I'm somehow confused now. Is registering to "dwww" any different from the
> "menu" system? Joost, perhaps you can give use some hints here (I think
> Jim is offline now).

It used to be the same, and that's why I also asked Jim about that.
But he seems to have something different in mind, I'm not quite sure 
what he does have in mind though. Also I'm not sure it's better than
what we have currently, but anyway, here's an email he sent me:
(I hope Jim doesn't mind me reproducing it, but it seems he isn't
telling any secrets here)

Jim> > Is that via menu, or directly via dwww?
Jim> 
Jim> It's going to be very similar to the way menu works (I might steal some
Jim> code).  I'm going to have a directory under /usr/lib/dwww/menudata 
Jim> which will accept files similar to the way /usr/lib/menu works.  I'll
Jim> probably have an /etc/dwww/menudata directory too, for local additions.
Jim> 
Jim> There will also be additional directories to accept "method" programs
Jim> for actually rendering the various parts of the dwww-menu heirarchy.
Jim> Also, there will be another directory for other "method" programs to
Jim> handle searching.  The idea is that any package can easily extend
Jim> or modify the behaviour of dwww.
Jim> 
Jim> Instead of pre-rendering most of the pages, dwww will call
Jim> the dwww-menu "method" programs to render the pages on the fly.
Jim> Depending on the what the "method" program does, it might simply
Jim> build a page from dwww-menu items in /usr/lib/dwww/menudata - or
Jim> it might use other data sources (even other CGI scripts).  I'll have 
Jim> to redesign the cacheing mechanism a bit - it might make sense to 
Jim> dump "dwww-cache", and use something like squid instead.
Jim> 
Jim> I've built a little program which reads all the /var/lib/dpkg/info/*.list 
Jim> files, and pumps them though the "frcode" program that comes with 
Jim> findutils.  That way, I can use the "locate" program to provide similar
Jim> functionality to "dpkg -L" and "dpkg -S", except that most queries return 
Jim> in less than 2 seconds.  It works so well, I'm thinking of making a
Jim> separate "dlocate" program so that it can be used from the command line.
Jim> 
Jim> The dwww-menu entries will probably be in a pseudo-SGML type of format.
Jim> When I get enough time to actually learn how all the SGML tools work, I
Jim> might rework it to use a real SGML DTD.  I figure that SGML will be a
Jim> good fit, since the output is going to always be HTML.
Jim> 
Jim> There are quite a few other things I want to add - when I'm done, it's
Jim> going to look nothing like the current dwww.  The nice thing is, it will
Jim> be broken into separate pieces, so it will be easy for many people to
Jim> work on it and improve it simultaneously.
Jim> 
Jim> Cheers,
Jim> 
Jim>  - Jim
Jim> 


-- 
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Debian target audience

[Alex Yukhimets]

Hello all.

Some time ago there was a posting on the list stating that typical Debian
user is of SysAdmin type. The guy received a lot of negative responses and
as a result we have now dotfile-generator in the distribution as our
statement of being friendly to novices. Good thing, but what is Debian
target audience anyway? 

Let's get serious, office worker would rather go with Caldera (if Linux at
all), ISP - with FreeBSD, newbie - with RedHat, etc. Debian is the effort
of a large number of developers and primararily *for* developers. No, we
don't forget newbies (dotfile-generator), office workers (Freedom
Desktop), ISPs (ongoing MTA discussions) but we DID forget dvelopers. Here
is why:

1) Every developer using commercially available libraries is forced to
stay with libc5 developmental tree for a while.

2) Every developer (even one NOT using commercial products) is interested
in having recent versions of the freely available libraries.

3) Every user (including developers) is interested in having recent
versions of freely available applications (editors, debuggers, viewers,
etc.)

4) It is preferable for everyone to have only one runtime library (either
libc5 or libc6). Having applications using both does eat up memory and
slow down system. (that's why we are having deadlines for converting
libc5 packages in hamm )

5) In the situation with libc5 -> libc6 transfer developer stuck
with libc5 will not be available to enjoy goddies from the 2)!!!, 3) and
4) because all new software will be compiled against libc6.

I hope you agree that situation is not acceptable. My proposition, which I
already stated, is to have in addition to "stable" and "unstable"
something called "unsupported" where would all newly available packages
(and versions) compiled against libc5 be placed. There were offers to make
sevral systems with good network connection available for compilation
libc6 and libc5 packages for the debian  maintainers. (Thanks, guys) And I
think this could really help.

Thank you.

Alex Y. 

-- 
   _   
 _( )_
( (o___
 |  _ 7  '''
  \(")  (O O)
  / \ \ +---oOO--(_)+
 |\ __/   <--   | Alexander Yukhimets   [EMAIL PROTECTED] |
 || |   http://pages.nyu.edu/~aqy6633/  |
 (   /  +-oOO---+
  \ /  |__|__|
   )   /(_  || ||
   |  (___)ooO Ooo
\___)


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Package priorities and dependencies.

[Santiago Vila Doncel]

-BEGIN PGP SIGNED MESSAGE-

On Sun, 15 Jun 1997, Dale Scheetz wrote:
> Two packages in the list of "important" refused to install because they
> declared (correctly) their dependence upon packages of lower priority.
> 
>   at  depends on  libelf0 priority: optional
>   groff   depends on  libg++27priority: standard
> 
> It seems to me that packages of any priority level should not be dependent
> upon packages of lower priority.

I think this reasoning is wrong: We don't want to install libelf0 and
libg++27 because they are "important", we want to install them to satisfy
dependencies! The library itself is useless if no program uses it.

So IMHO you should have added to your initial list of packages the ones on
which they depend, until all dependencies are satisfied. dselect does this
automatically. If you don't like it, it is supposed to be done by hand.

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

iQCVAgUBM6U1fiqK7IlOjMLFAQFGQgP/YOulOes4AYK1yAR7qHF1m4UZ/VemCy6s
ZxgbqB1nMKbTRLbNO5aM/X8xQL4r22Qji7LhCF+eyBn9wuo7XxgM3Pqei9pIYylh
DCmwXYFgg92FtQLKwttpnmPKFJ4vzp0N1Va2PiV/QE+MDQjOyjwoFLa2wkiJCSni
1z1aVmXm74k=
=7Uae
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Unresolved symbols with ibmtr_cs PCMCIA module

[Brian Mays]

Stephen Zander <[EMAIL PROTECTED]> writes:

> Further in my attempts to setup up a Thinkpad 760CD...
> 
> When attempting to load the ibmtr_cs.o mdules under the standard
> 2.0.30 kernel, I get the folliowing unresolved symbols.
> 
> netif_rx_R9117ffb8
> dev_alloc_skb_R24e337ab
> dev_kfree_skb_R7a61ae71
> dev_tint_Rcc72f6b2
> unregister_netdev_Re5a9d51a
> register_netdev_R70caa700
> tr_setup_R787bcf6f
> tr_type_trans_Rf1130552
> 
> Should I load another module to resolve these or is there
> something else I'm missing?

This is caused by an incompatibility between the pcmcia modules and
the kernel's configuration.  I've created new packages that fix this
problem (pcmcia-cs and pcmcia-modules-2.0.30-7, both version 2.9.6-1)
that currently are waiting to be included in the distribution.  I am
sorry for the inconvenience.

If anyone needs these packages now, before they can be included into
the distribution, send me a message and I can e-mail them using either
MIME encoding or uuencode.

Brian


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Debian's mail daemons

[Michael Alan Dorman]

Tim Cutts <[EMAIL PROTECTED]> writes:
> qmail is supposed to be more secure.  Theoretically, exim's design
> allegedly means there might be some security issues, but none have
> been found yet.  There has been argument about this ad nauseam on
> the exim-users mailing list.

qmail also has stronger guarantees---djb would no doubt say, "the only
guarantee"---of delivery than any of the other systems---it doesn't
return a response until it's sync'd the file to disc.

> My own feeling is that the primary disadvantage with qmail is that
> Dan decided that sendmail was awful (with some justification) and
> proceeded to change a lot of things whether they needed it or not.
> I am, for example, irritated that qmail's forwarding file is called
> .qmail.  What was the point of that?  Does changing the name from
> .forward to .qmail really improve security?

No, but it reinforces the idea that you're "not in Kansas, anymore",
which *can* be valuable.

Mike.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Status of Debian Policy

[Christian Schwarz]

On Sun, 15 Jun 1997, Jim Pick wrote:

> 
> > >  All packages that provide HTML documentation should register these
> > >  documents to the menu system, too. Check out section section 4.1, 
> > > `Web
> > >  servers and applications' for details.
> > 
> > Is that as well as registering with dwww?
> 
> I'm changing the way documents register themselves with dwww (again).
> Hopefully, I'll get enough accomplished so that I can upload 
> something to experimental today.  I wouldn't encourage anybody to
> register their documents with dwww just yet, since it's all going
> to change.  Hopefully, I'll get past the prototype stage in the
> next month or so, and there will be a standard supported way of
> registering documents with dwww.

I'm somehow confused now. Is registering to "dwww" any different from the
"menu" system? Joost, perhaps you can give use some hints here (I think
Jim is offline now).


Thanks,

Chris

-- Christian Schwarz
Do you know [EMAIL PROTECTED], [EMAIL PROTECTED],
Debian GNU/Linux?[EMAIL PROTECTED], [EMAIL PROTECTED]
  
Visit  PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
http://www.debian.org   http://fatman.mathematik.tu-muenchen.de/~schwarz/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Status of Debian Policy

[Christian Schwarz]

On 15 Jun 1997, Rob Browning wrote:

> [EMAIL PROTECTED] (Mark Baker) writes:
> 
> > Would programs _have_ to use this library, or is implementing the same thing
> > in acceptable? The latter has problems in that it forces us to keep the same
> > method, but I don't want to see lots of #ifdef debian appearing in the
> > original source; apart from anything else it doesn't look good being
> > non-standard even if what we do is superior.
> 
> I think that we should develop this library, and release it to the
> public just like any other upstream package.  We should (if possible)
> write it as a distribution independent solution to the problem and
> then package it for Debian.  Finally name it something other than
> libdebian, and we'd probably have a good chance of getting others to
> start using it in their upstream sources for all platforms.

This really is an _excellent_ idea! So, we just need a volunteer to
implement and maintain this "upstream library". (The packaging for Debian
should not be a problem.)

If I remember it correctly, someone said that he already has implemented
these locking function. Is this person listening?

BTW, there is also the "lockfile" command that's included in the procmail
distribution. Perhaps we could convert this into a "liblockfile" library?



Thanks (I'm really happy to get some feedback about these policy
questions, finally :-),

Chris

-- Christian Schwarz
[EMAIL PROTECTED], [EMAIL PROTECTED],
Don't know Perl? [EMAIL PROTECTED], [EMAIL PROTECTED]
  
Visit  PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
http://www.perl.com http://fatman.mathematik.tu-muenchen.de/~schwarz/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Debian-Policy Manual

[Christian Schwarz]

On Mon, 16 Jun 1997, Mark Baker wrote:

> 
> In article <[EMAIL PROTECTED]>,
>   David Frey <[EMAIL PROTECTED]> writes:
> 
> >>TOPIC 4: editor/pager policy
> > What is the benefit of /usr/bin/sensible-{editor,pager}?
> > Why don't we just default to EDITOR=/usr/bin/vi and PAGER=/usr/bin/more
> > if both variables are unset? (auch, don't beat me)
> 
> That might enable us to get rid of /usr/bin/{editor,pager} though it's an
> inferior solution to what we're doing at the moment. It won't enable us to
> get rid of /usr/bin/sensible-{editor,pager} which are for progams that don't
> understand EDITOR and PAGER.

Not exactly.

The files /usr/bin/{editor,pager} will be managed through alternatives.
Since alternatives can be changed by the sysadmin only, we allow the user
to define EDITOR and PAGER to override this.

That's why we need "sensible-{editor,pager}". These are two simply shell
scripts that test if EDITOR/PAGER is set and launches either that program,
or /usr/bin/{editor,pager}. 


Thanks,

Chris

-- Christian Schwarz
[EMAIL PROTECTED], [EMAIL PROTECTED],
Don't know Perl? [EMAIL PROTECTED], [EMAIL PROTECTED]
  
Visit  PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
http://www.perl.com http://fatman.mathematik.tu-muenchen.de/~schwarz/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

libc6 system for libc5-only maintainers

[joost witteveen]

If you (debian developper) need a libc6 system to compile your
packages on, but feel you are unable to upgrade your system
to libc6, I can give you an account on my system. (The connection
with the internet is only about 6kByte/second (max), so 
it may not be very usefull for big packages).

I'll send you your account info pgp-encrypted, so you will need
pgp on your system.


Thanks,

-- 
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Debian's mail daemons

[Carey Evans]

Tim Cutts <[EMAIL PROTECTED]> writes:

[snip]

> I am, for example,
> irritated that qmail's forwarding file is called .qmail.  What was the
> point of that?  Does changing the name from .forward to .qmail really
> improve security?

[snip]

> qmail does not understand anything but
> the most simple cases.

*This* is why the name was changed - because the syntax is different.
This may improve security because 1) mailing lists don't have the be
so careful with what they put in the file and 2) users unfamiliar with
both .forward and .qmail might be less likely to do something stupid
with .qmail.  I'm not so sure about (2) though.

And I bet it would be a pain switching 1000 users with shell accounts
to qmail.

-- 
Carey Evans  <*>  [EMAIL PROTECTED]

   "Our mail program accidentally deleted our remove list."
 - Real quote from UCE


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Debian-Policy Manual

[Mark Baker]

In article <[EMAIL PROTECTED]>,
David Frey <[EMAIL PROTECTED]> writes:

>>TOPIC 4: editor/pager policy
> What is the benefit of /usr/bin/sensible-{editor,pager}?
> Why don't we just default to EDITOR=/usr/bin/vi and PAGER=/usr/bin/more
> if both variables are unset? (auch, don't beat me)

That might enable us to get rid of /usr/bin/{editor,pager} though it's an
inferior solution to what we're doing at the moment. It won't enable us to
get rid of /usr/bin/sensible-{editor,pager} which are for progams that don't
understand EDITOR and PAGER.

Re: Package priorities and dependencies.

[joost witteveen]

> On Sun, 15 Jun 1997, Dale Scheetz wrote:
> 
> [snip]
> > It seems to me that packages of any priority level should not be dependent
> > upon packages of lower priority.
> 
> I totally agree to this.

Yes, I noticed this myself too (in libg++272). I didn't quite
know what to do with it at the time, and I thought "don't fix
what ain't broken", but I've changed libg++272's priority now 
to "Important"

-- 
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Debian's mail daemons

[Tim Cutts]

On 15 Jun 1997, Rob Browning wrote:

> Alexander Koch <[EMAIL PROTECTED]> writes:
> 
> > (I'd vote for exim if uucp is guaranteed to work)
> 
> Ok, so what are the arguments for exim over qmail (at least why do you
> prefer it?)
> 
> I've heard arguments for qmail and exim over sendmail.

qmail is supposed to be more secure.  Theoretically, exim's design
allegedly means there might be some security issues, but none have been
found yet.  There has been argument about this ad nauseam on the
exim-users mailing list.

My own feeling is that the primary disadvantage with qmail is that Dan
decided that sendmail was awful (with some justification) and proceeded to
change a lot of things whether they needed it or not.  I am, for example,
irritated that qmail's forwarding file is called .qmail.  What was the
point of that?  Does changing the name from .forward to .qmail really
improve security?

The bottom result of changes like this is that qmail is not a drop-in
replacement for sendmail or smail.  Exim is; it has a sophisticated
.forward syntax of its own, but it does understand pretty well any
.forward for smail or sendmail.  qmail does not understand anything but
the most simple cases.

This means that if you have a lot of users on your machine (probably not
the case for most debian sites, but it's an issue as far as I'm concerned)
you will have to re-educate them as to the new ways of qmail (once you'v
re-educated yourself as well, of course).  To be quite honest, my 1,300
users have taken a long time gwtting used to how the standard UNIX mail
system works, and they don't want to waste time learning a new one.

For a single user system of course this is not a problem.

Tim.

-- 
--
T J R Cutts   Tel: +44 1223 333596
Dept. of Biochemistry, Tennis Court Rd.,  Fax: +44 1223 766002
Cambridge, CB2 1QW, UK


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Package priorities and dependencies.

[Christian Schwarz]

On Sun, 15 Jun 1997, Dale Scheetz wrote:

[snip]
> It seems to me that packages of any priority level should not be dependent
> upon packages of lower priority.

I totally agree to this. AFAIK, the reason for the "priorities" is that
the users get "good defaults" in dselect. Thus, if someone wants to
install a new system, it should only be necessary to enter dselect and run
"install" to get all "required" and "important" packages. Of course, if an
"important" package depends on an "optional" library, the latter is
"important" too!

If there are no objections, the quoted sentence above will get into the
next Policy Manual.


Thanks,

Chris

--  Christian Schwarz
   [EMAIL PROTECTED], [EMAIL PROTECTED]
  [EMAIL PROTECTED], [EMAIL PROTECTED]
   
PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
  
 CS Software goes online! Visit our new home page at
 http://www.schwarz-online.com


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

selfhtml

[Marco Budde]

Hi!

Is anybody already working on a debian package containing the selfhtml  
manual? This is a real great description of the HTML tags in German  
language. If not I'll make a package.

I'll upload my first debian package (doc-linux-de) in the next days. Bug  
reports are welcome ;-).

cu, Marco

--
Uni: [EMAIL PROTECTED]  Fido: 2:240/5202.15
Mailbox: [EMAIL PROTECTED]http://www.tu-harburg.de/~semb2204/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Hamm: Exim + Chos standard?

[Tim Cutts]

On 16 Jun 1997, Miquel van Smoorenburg wrote:

> Ofcourse there also needs to be a file (LocalIP with sendmail) to define
> IP ranges that may use your SMTP host as a relay - for customers that
> use your host as smarthost (Eudora, pegasus, netscape, sendmail null
> clients etc).

Well, exim certainly has the capability to allow relaying from/to certain
IP ranges.  Our major mail server for example has:

sender_net_accept_relay = "131.111.0.0/255.255.0.0"

So that Eudora users within the 131.111 domain can use us as a smarthost.
I tell people that if they want to send mail from outside that domain they
will need to log into the machine using telnet/rlogin/ssh and use an MUA
on the machine itself, or arrange with a more local system to act as a
smarthost while they're not in Cambridge.

Tim.

-- 
--
T J R Cutts   Tel: +44 1223 333596
Dept. of Biochemistry, Tennis Court Rd.,  Fax: +44 1223 766002
Cambridge, CB2 1QW, UK


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

State of the "dunc" package [long]

[Richard G. Roberto]

I recently walked a friend through installing dunc-2.1 on a
slackware box (from the debian package).  The first thing we both
noticed was how easy it is to install debian software on
non-debian systems[1].  The second thing we noticed was the the
version of dialog (although the upstream version was in sync with
the debian dependency's) was incompatable -- it core dumped every
time we ran it.  So we got the debian dialog package and
installed it and all was fine.  Then we noticed (to my
embarassment) that the program never created the BASEDIR
directory and failed to run.  We also noticed that the "dppp
--help" was useless as the screen cleared before you could read
the text.

The good news was the we manually created the BASEDIR driectory
and dunc ran very well.  He hit enter a few times, typed in his
username and password, hit enter a few more times and was up and
running.  His ISP provides PAP and CHAT style connections and
both methods tested fine.  The RCFILE needed some cleaning up
after the BASEDIR was finally made though.  The problem is that
the dunc script checks for duplicate connection definition files
in $BASEDIR, but assumes $BASEDIR exists.  If it doesn't, then
$RCFILE will get updated with the connection information, but the
write to $BASEDIR/.ctn will fail.  The next time
you try to set up a connection, the name will be valid in $RCFILE
but not in $BASEDIR, thus allowing you to recreate the same
connection (i.e. use the same name.)  This lead to the first
(empty) case block of the connection name in $RCFILE being
initialized and causing more confusion during future program
runs.  The only solution was to edit $RCFILE.

The RCFILE was structured to allow one to recover lost
connections, or duplicate them, from the RCFILE.  This feature
was not implemented, however.  I haven't been able to come up
with a way to easily integrate this behavior into the script as
is.  but I read Sven's post about rewriting dinstall in C, and I
think it would much easier to deal with a lot of the stuff dunc
attempts to do in C.  Unless there are any serious objections,
the next version of dunc will deal with the above situation
better, and it will be modeled after dinstall in C(+giggle?).

There are two questions I have:

1) what would be the best way to deal with broken $RCFILEs as a
result of the previously mentioned scenerio?

2) Is there anyone knowledgeable in PPP who could stay subscribed
to the PPP list(s) and help out with the dunc implementation?
I'm willing to remain the maintainer, but I think the package
could use some help, especially moving forward with the latest
PPP.  I'd also be willing to turn the package over to someone who
could do a better job with it.  I'm unable to subscribe to the
lists and have little time to spend on development.  (one of the
other things we noticed was the there is no way in dunc to
specify a longer timeout.  The ISP defaulted to PAP, and must
have had a list of protocols to try -- chat being last.  Sometime
it was OK, but sometimes it wasn't).

[1] This is actually a very good selling point for the package
format.  Perhaps debian-publicity should start marketing the
format based on its strength (not comparing it to any other
format, of course), and ease of use.  That is, assuming we're not
dumping it for a commercial format ;)

Thanks

Richard G. Roberto
[EMAIL PROTECTED]
011-81-3-3437-7967 - Tokyo, Japan


--
***
Bear Stearns is not responsible for any recommendation, solicitation, offer or
agreement or any information about any transaction, customer account or account
activity contained in this communication.
***


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: locale errors

[Ricardas Cepas]

On Jun 15, Mark Baker wrote
> 
> In article <[EMAIL PROTECTED]>,
>   Erv Walter <[EMAIL PROTECTED]> writes:
> 
> > perl: warning: Setting locale failed.
> > perl: warning: Please check that your locale settings:
> > LC_ALL = (unset),
> > LANG = "us"
> > are supported and installed on your system.
> > perl: warning: Falling back to the standard locale ("C").
> 
> I got that (with perl only) before I installed debian; it doesn't like
> locale settings that other programs seem to get on with OK. Try removing the
> LANG variable and it ought to work. Is whatever sets LANG (your .bashrc?)
> something you copied off another system?

Just set PERL_BADLANG variable in /etc/lilo.conf and
/etc/profile and the messages will disappear.

-- 
  RiÄardas Äepas


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

PostgreSQL (formerly Postgres95)

[Oliver Elphick]

I have volunteered to become maintainer of this package, which is currently
orphaned.

I don't regard myself as particularly well qualified, so if there is anyone
else interested in maintaining it, please let me know.
-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight  http://homepages.enterprise.net/olly

In case of connection troubles, try [EMAIL PROTECTED] instead.




pgp4PkEiCmajU.pgp
Description: PGP signature

Re: Status of Debian Policy

[Ardo van Rangelrooij]

-BEGIN PGP SIGNED MESSAGE-

Hi,

I have another policy issue which is related to topic 11 (see below). 

The current layout of Info entries in the main Info menu (in the file
/usr/info/dir) looks rather messy.  I found the following "descrepencies": 

 - not all packages are placed in an appropriate section
 - the descriptions are not formatted consequently
 - some sections are somewhat large (this is personal)
 - some descriptions are somewhat large (this is personal too)

I believe we can do better. Therefor, I propose an extension/change to
Section 3.2.3 of the Debian Policy Manual: 

 - During install of an Info documents you MUST specify a section.
   Preferably use the section the package belongs to in the Debian 
   distribution.  As a starting point the "dir" file in the base-files
   package could already contain these sections, albeit empty.

   We could also use a different, sometimes more logical grouping. E.g.,
   I'm using the following sections for the development packages: 

- compilers
- linkers
- interpreters
- generators (i.e. bison, flex, gperf, etc.)
- libraries
- development tools (i.e. make, gdb, etc.)
- internals (i.e. gdb-internals, stabs, etc.)

   If the Info doc has a lot of subentries, make a separate section
   for it, as has been done for the GNU file, text, shell, and shar
   utilities. 

 - Start the description at a to-be-determined fixed position, e.g.
   first line at position 41 and second and subsequent lines at position
   43.  This unclutters the layout, but the positions should be such
   to leave enough room for a short, one-line, to-the-point decription.

 - Instead of using the upstream provided description, provide an own
   one-line one which fits on the same line as the menu entry.  A three 
   line description for awk may be nice but clutters the layout, e.g. 

In the light of topic 11 the above may be not that important anymore,
but if we plan to keep Info docs around (I have not heard otherwise
yet) I believe we should discuss the above. 

I was also wondering whether we plan to organize the documentation
under dwww in a way similar to the Info docs (sectioning, layout,
etc.).  Anybody some thoughts on this? 

Greetings,

Ardo

Christian Schwarz <[EMAIL PROTECTED]> writes:

> 
> TOPIC 11: policy about including documentation
> --
>   STATUS: DISCUSSION
>   
> 
> The current policy concerning docs is:
> 
>  - HTML is the preferred format
>  - if the package includes docs than can be converted into HTML,
>the maintainer should do so
>  - if the doc files are to big, they should go into a seperate
>package
> 
> There are a few problems, though:
> 
>  - .info files can be converted into HTML on-the-fly by the CGI
>script "info2www". However, the output of ``texi2html'' is
>much better. Should we ship only HTML by default and put
>.info in a seperate package? (cf. bug #7890)
>  - how "large" may doc files be until they are moved into a
>seperate package?
> 
> 

- -- 
Ardo van Rangelrooij
home email: [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

-BEGIN PGP SIGNATURE-
Version: 2.6.3i
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBM6Q5ST6XMRfcxSjpAQG9DAP+P7QAIjwtkwnPNzTd+GWRwoP4tK1BWXle
EXNic9qqB1W16qALB6YXNsXAqngNXcIf79C9ZuF2sZiWd+XuPl7ALYwDJWIopGEl
woFCcm1XMvX2Gr4mGVErq7iV1H60KOpPiOK4V3xFw/V+cZXL+SezdYsWRyV1Dt70
siOjdaOsHsg=
=zTMP
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Gone for a week

[Joey Hess]

Chiming in here, I'm going to be gone until the 23rd, camping on the outer
banks of North Carolina.

If any of my packages blow up, don't hesitate to release non-maintaner
versions. :-)

-- 
see shy jo


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Debian's mail daemons

[Rob Browning]

Alexander Koch <[EMAIL PROTECTED]> writes:

> (I'd vote for exim if uucp is guaranteed to work)

Ok, so what are the arguments for exim over qmail (at least why do you
prefer it?)

I've heard arguments for qmail and exim over sendmail.

-- 
Rob


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: kerneld/multicast bug (tickled by gated) (fwd)

[Michael Neuffer]

This is from Linux kernel, and it sounds to me, that there might be
versions that we can distribute with Debian.


Mike

-- Forwarded message --
Date: Sun, 15 Jun 1997 20:05:23 -0400 (EDT)
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: kerneld/multicast bug (tickled by gated)


Alan nad Linux folks:

Thanks for all the suggestions.  I will try the kernel
patch.  

Brian and I were working on OSPF.  In addition, 
I am trying to work on getting GateD running over linux
including our new multicast support and ip v6 so 
I may be back for more of your help.

I'm curious about the "bgp-4" sort of?  Please
do send bug reports we are trying to work through
the reported bugs.  We hope to be in better shape in
6 months.  And as to license, GateD we are working
on is public.  Some other versions of GateD are are probably free
to most linux users but alas you do have to sign
a piece of paper.Please.. if you have license
questions - send me a note or ask on the gated list.
I don't want to clutter up any technical list.   

Thanks,

Sue Hares
GateD maintainer 
===
Indeed. I hope the routed people aren't offended either - after all gated
is large, a little buggy and very messily licensed 8)

For the other folks

o   Routed is a simple daemon implementing modified BSD RIP routing
o   Gated is a large daemon implementing OSPF, RIP-2 , BGP4 (sort of),
and a load more protocols. Gated is sufficient to do backbone routing



idrp.merit.net:/home/skh/Mail/inbox> mail -v  [EMAIL PROTECTED]
Subject:  Re: kerneld/multicast bug (tickled by gated)

Linux folks:






--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Package priorities and dependencies.

[Clint Adams]

> I don't see your point, and you seem to have missed mine.

My point is that there's no need for a package with no user-level
functionality of its own, such as a library, to have a priority
of its own.

If an Important package such as 'at' depends on libelf0 for whatever
dubious reason, libelf0 might be important.  However, for systems
that don't install 'at,' libelf0 is pretty much useless, and its
classification as 'important' would be silly.

It makes more sense to me for libraries to not have any priority, or
more in line with your idea, have some mechanism in which the library
will inherit the highest priority of the selected packages that depend
upon it.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Hamm: Exim + Chos standard?

[Christoph Lameter]

Exim can provide UUCP capabilities. It cannot do bang path routing. I doubt
that anyone is using that though.

--
> From: John Goerzen <[EMAIL PROTECTED]>
> To: Christoph Lameter <[EMAIL PROTECTED]>;
debian-devel@lists.debian.org
> Subject: Re: Hamm: Exim + Chos standard?
> Date: Saturday, June 14, 1997 10:41 AM
> 
> Christoph Lameter <[EMAIL PROTECTED]> writes:
> 
> > 
> > It might be good if we would replace smail in hamm with exim. Exim
should 
> > be the standard mailer for hamm:
> 
> Exim doesn't provide UUCP capabilities *at all*, thus it is rather
> useless for sites that use UUCP (like me).  Right now, I am using
> sendmail.  (What, BTW, is the reason for not using sendmail?)
> 
> -- 
> John Goerzen  | Running Debian GNU/Linux (www.debian.org)
> Custom Programming| 
> [EMAIL PROTECTED] | 


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .