Re: Re^2: Status of Debian Policy

[Dirk Eddelbuettel]

  Lars> It was decided many moons ago that Debian would use HTML as its
  Lars> primary on-line documentation format. HTML should be the default.

  Marco>  That's right. But a lot of important packages like doc-linux don't
  Marco> use HTML.

Well, the maintainer (that's me) prefers info as the basis format, and dwww
(thanks to Lars and Jim !) to render the documentation into hypertext.

However, Christian Schwarz asked me to do html as well. That will be some
work as HOWTO packages comes as tar.gz files with no surcompassing
index.html.  I'll have to do some perl hacking. No promises for the June
release, maybe for July.

But let me say it again:  info files are better because they are more
versatile as a base format. And they are much smaller. Much smaller. [1] 

Finally, I can also search an entire HOWTO at once in my preferred editor
(which happens to uncompress the gzipped text on the fly).

[1] [EMAIL PROTECTED]:~> du -sS /mirror/sunsite/HOWTO/
1482/mirror/sunsite/HOWTO

is already smaller than 

[EMAIL PROTECTED]:~> du -sS /mirror/sunsite/HOWTO/other-formats/html/
1694/mirror/sunsite/HOWTO/other-formats/html

which we will have to untar and gunzip:

[EMAIL PROTECTED]:/tmp/howtos> for i in 
/mirror/sunsite/HOWTO/other-formats/html/*tar.gz; do tar xfz $i; done
[EMAIL PROTECTED]:/tmp/howtos> du -sS .
5730.

[EMAIL PROTECTED]:/tmp/howtos> echo 5730/1482 | bc -l
3.86639676113360323886   


--
 [EMAIL PROTECTED]  [EMAIL PROTECTED]  http://rosebud.sps.queensu.ca/~edd
PGP key fingerprint = B2 49 75 BF 44 2C B7 AA  50 CB 19 7D 80 F7 CB DC
--
By US Code Title 47, Sec.227(a)(2)(B), a computer/modem/printer meets the
definition of a telephone fax machine. By Sec.227(b)(1)(C), it is unlawful to
send any unsolicited advertisement to such equipment.  By Sec.227(b)(3)(C), a
violation of the aforementioned section is punishable by action to recover
actual monetary loss, or $500, whichever is greater, for each violation. 
Please read the full text at http://www.law.cornell.edu/uscode/47/227.html.


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

Policy wrt mail lockfile (section 4.3)

[John Goerzen]

Why are we using dotfile locking only?  There are much better
mechanisms (flock, etc.) that should be used instead.  I can see no
place where dotfile locking would work and flock-style locking would fail...


-- 
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] .

Re: Policy wrt mail lockfile (section 4.3)

[Rob Browning]

John Goerzen <[EMAIL PROTECTED]> writes:

> Why are we using dotfile locking only?  There are much better
> mechanisms (flock, etc.) that should be used instead.  I can see no
> place where dotfile locking would work and flock-style locking would
> fail...

I think flock can fail across NFS in certain situations, but I'm no
locking expert.

-- 
Rob


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

RE: checker libs with debugging symbols

[Michael Meskes]

Sorry but I disagree here. For a user who only wants to debug his own
program debugging symbols in the libraries are not needed. 

I'd prefer to have several packages: checker-bin, checker-libs,
checker-dbg or something like that. Remember, we do not distribute
debugging symbols in other libraries for the same reason. Instead we
provide an *-dbg package.

What do others think about this?

Michael

--
Dr. Michael Meskes, Projekt-Manager| topsystem Systemhaus GmbH
[EMAIL PROTECTED]| Europark A2, Adenauerstr. 20
[EMAIL PROTECTED]  | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux!  | Fax: (+49) 2405/4670-10

>-Original Message-
>From:  Ben Pfaff [SMTP:[EMAIL PROTECTED]
>Sent:  Thursday, June 19, 1997 10:25 PM
>To:debian-devel@lists.debian.org; Michael Meskes
>Subject:   Re: checker libs with debugging symbols
>
>Michael Meskes <[EMAIL PROTECTED]> writes:
>> Is there a reason for the checker libraries to come with debugging symbols?
>
>Yes.  There is a good, even a superlatively good reason: checker is
>for debugging programs.  It is *only* for debugging programs.  Thus,
>debugging symbols are in there intentionally.  When something goes
>wrong, even in the C library, it helps an enormous amount if one can
>find the exact line in the source that causes the problem.
>Regrettably, one must have 300MB of source code online in order to do
>this, but that is the price we pay.
>
>> I haven't used checker yet, so I don't know. But I assume that the
>>libraries
>> without debugging symbols would work.
>
>They would work.  But it isn't The Right Thing To Do.
>-- 
>Ben Pfaff <[EMAIL PROTECTED]>http://www.msu.edu/user/pfaffben
>PGP key: http://www.msu.edu/user/pfaffben/pgp.html or a keyserver near you
>Linux: choice of a GNU generation -- Debian GNU/Linux: the only free Linux


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

QA/test request

[Philippe Troin]

Hi fellow testers,

I've just uploaded diald to master, and I plan to have it in Debian 
1.3.1: it fixes many many packaging bugs and some diald bugs too.
It has also the neat feature of rewriting outbound packets' IP 
headers stored in its buffer with dynamically allocated IPs. Neat 
neat.

Can you please test it and report problems ?

I'm especially interested in upgrades from old diald versions (these 
are the ones which were problematic). Vanilla rex upgrades should be 
tested (I've tested it here, but ...).

As it might be stuck in master's incoming queue for a little while 
(because it mentions `stable'), you might want to get it from an 
alternate site (mine :-):
ftp://ftp.fifi.org/pub/debian-local/diald/

Thanks,
Phil.



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

Re: checker libs with debugging symbols

[Thomas Koenig]

Michael Meskes wrote:

>Sorry but I disagree here. For a user who only wants to debug his own
>program debugging symbols in the libraries are not needed. 

Let's take a look at the following program:

#include 

int main()
{
char buffer[20];

gets(buffer);
printf("%s",buffer);
return 0;
}

If you feed it a line that's too long, the access violation will
happen deep within the C library.  Without debugging symbols, it's
hard to know wether this is a bug in the C library (and there
could be quite a few :-) or your program.
-- 
Thomas Koenig, [EMAIL PROTECTED], [EMAIL PROTECTED]
The joy of engineering is to find a straight line on a double
logarithmic diagram.


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

Re: Policy wrt mail lockfile (section 4.3)

[Thomas Koenig]

John Goerzen wrote:

>Why are we using dotfile locking only?  There are much better
>mechanisms (flock, etc.) that should be used instead.  I can see no
>place where dotfile locking would work and flock-style locking would fail...

We don't have a lock daemon for NFS.
-- 
Thomas Koenig, [EMAIL PROTECTED], [EMAIL PROTECTED]
The joy of engineering is to find a straight line on a double
logarithmic diagram.


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

RE: checker libs with debugging symbols

[Michael Meskes]

True. But I didn't say 'get rid of these symbols'. All I'd like to see
is the chance for me to install a version without symbols.

Michael
--
Dr. Michael Meskes, Projekt-Manager| topsystem Systemhaus GmbH
[EMAIL PROTECTED]| Europark A2, Adenauerstr. 20
[EMAIL PROTECTED]  | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux!  | Fax: (+49) 2405/4670-10

>-Original Message-
>From:  Thomas Koenig [SMTP:[EMAIL PROTECTED]
>Sent:  Friday, June 20, 1997 10:33 AM
>To:debian-devel@lists.debian.org
>Cc:Die Adresse des Empfängers ist unbekannt.
>Subject:   Re: checker libs with debugging symbols
>
>Michael Meskes wrote:
>
>>Sorry but I disagree here. For a user who only wants to debug his own
>>program debugging symbols in the libraries are not needed. 
>
>Let's take a look at the following program:
>
>#include 
>
>int main()
>{
>char buffer[20];
>
>gets(buffer);
>printf("%s",buffer);
>return 0;
>}
>
>If you feed it a line that's too long, the access violation will
>happen deep within the C library.  Without debugging symbols, it's
>hard to know wether this is a bug in the C library (and there
>could be quite a few :-) or your program.
>-- 
>Thomas Koenig, [EMAIL PROTECTED], [EMAIL PROTECTED]
>The joy of engineering is to find a straight line on a double
>logarithmic diagram.
>
>
>--
>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] .

Re: Re^2: Status of Debian Policy

[Christian Schwarz]

On Thu, 19 Jun 1997, Dirk Eddelbuettel wrote:

[snip]
> However, Christian Schwarz asked me to do html as well. That will be some
> work as HOWTO packages comes as tar.gz files with no surcompassing
> index.html.  I'll have to do some perl hacking. No promises for the June
> release, maybe for July.

Just unpack all .tar.gz files in the same directory and use the file
"HOWTO-INDEX-3.html" as "index.html". It contains an overview over all
available HOWTOs and mini-HOWTOs and hyperlinks to them.


Cheers,

Chris

--  _,, Christian Schwarz
   / o \__   [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
   \  / http://fatman.mathematik.tu-muenchen.de/~schwarz/
-.-.,---,-,-..---,-,-.,.-.-
  "DIE ENTE BLEIBT DRAUSSEN!"


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

Re: Policy wrt mail lockfile (section 4.3)

[Karl M. Hegbloom]

> "Rob" == Rob Browning <[EMAIL PROTECTED]> writes:

Rob> I think flock can fail across NFS in certain situations, but
Rob> I'm no locking expert.

 You can read the man page to open(3) for a partial explaination.


-- 
Karl M. Hegbloom <[EMAIL PROTECTED]>   finger or ytalk:
http://www.inetarena.com/~karlheg   [EMAIL PROTECTED]
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: Re^2: Status of Debian Policy

[Milan Zamazal]

> "MB" == Marco Budde <[EMAIL PROTECTED]> writes:

MB: The most beginners don't like info because there's no good
MB: browser. I would vote for texi2html because it look's much
MB: better than info2html and the user doesn't need a WWW server.

There is one good info browser: GNU Emacs.  On the other side I don't
know any good browser for HTML, that's the main problem of HTML
documentation.

OK, if HTML was chosen as Debian documentation format, why not.  But I
really don't know why to waste my limited disk space for (mostly
uncompressed!) HTML documents, when (from my point of view) better
format is available.

MB: I think we should use HTML in the packages. Additional we
MB: could produce postscript files for printing.

Further wastage of disk space for many users.

I know it was said many times, but AFAIK nothing happened yet: the
best choice is to provide facility to install chosen and/or prefered
type (HTML, info, postscript, text, ...) of documentation if
available.

Milan Zamazal


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

RFC: library conventions for libc5 and libc6 in hamm Take 4

[Helmut Geyer]

Hello!

I incorporated the changes mentioned by Mark Eichin.
Furthermore I noticed that there were several issues that have not
been handlied by this proposal, so I added several sections.

These tell how to handle dependences and conflicts, source packages
and bugfixes for bo. This is a lot of new stuff. Please read it
carefully and tell me where I messed up.

Helmut

-=-=-=-=-=-=-=-=-=-=-= SNIP -=-=-=-=-=-=-=-=-=-=-=-=-=-

 Debian library policy supplement draft for libc5->libc6 migration

   This document is meant to tell what a Debian package providing a
   library should do to support both libc6 (glibc2) and libc5.
   Note that these requirements are for Debian 2.0 (codename hamm).

 Contents 
 1.  Run time packages
 2.  Development packages
 3.  Source packages
 4.  Requirements on libraries for Debian 2.0
 5.  Conflicts and Dependencies
 6.  Handling bugfix releases for Debian 1.3 (bo)
 7.  Requirements on compiler packages 

 1. Run time packages

A package providing a shared library has to support both C library
packages, libc5 and libc6 based libraries. This must be done using
two Debian packages, each depending on the correct C library
package.
The package naming convention currently suggests to name these
packages as follows. Some packages (mostly from base) may use
locations in /lib. 

   based on  | package name | library location
   
 libc6   |   libfoog [1]| /usr/lib/libfoo.so.
 libc5   |   libfoo | /usr/lib/libc5-compat/libfoo.so. [2]

If a library runtime package contains files that are needed by
both versions of the library, a new package should be made for
just these files that both other packages depend on.

This package naming convention does _not_ apply if a package uses
different sonames for libc5 and libc6 based packages

There are two exceptions from this rule. The shared linker
ld-linux.so.1 and the C library files libc.so.5 and libm.so.5
should still be located in /lib, not in /lib/libc5-compat.

Packages based on X have to use /usr/X11R6 as prefix, not /usr. 
Note that the X libraries are designed to work with both C libraries.

  2.  Development packages

The Debian policy requires that all files needed for compiling/linking
other packages with the library are in a separate package, the
development package. Up to now this package simply was called
libfoo-dev. As packages based on libc5 and libc6 usually cannot
use the same development files there has to be a clear statement
how to separate these. So for now the following packages are
required:  

  based on  | package name| hierarchy locations
  ---
  libc6 | libfoog-dev | /usr/{lib,include}
  libc5 | libfoo-altdev   | /usr/-linuxlibc1/{lib,include}
   
   Note that  usually is i486, but may not be hardcoded in
   debian/rules. It should be obtained using 
dpkg --print-gnu-build-architecture 

   Remember that the libfoo-altdev package has to include symlinks 
   /usr/-linuxlibc1/lib/libfoo.so -> /usr/lib/libc5-compat/libfoo.so.
   to enable using the shared libraries when compiling.

   All documentation that is not depending on whether the library was
   compiled for libc5 or for libc6 should be either part of the
   libfoog-dev package or be put into a separate package if it is
   large. In particular this includes manpages which _have_ to be part
   of the libfoog-dev package.

   Note that the choice to base Debian 2.0 on libc6 fixed the fact
   that the main locations will be used for libc6 packages. The
   alternate locations are used for libc5 based packages.
   This decision does not necessarily mean that by default the
   compiler uses the libc6 packages, please read section 4 for more
   information. Using a four-way approach for library locations
   (standard and alternate locations for libc6 and libc5 based
   packages) will make Debian systems inconsistent with each other,
   something we should avoid at (nearly) all costs. 


  3. Source packages

   The source package name should _not_ be modified for hamm. 

   If a bugfix for bo has to be released, use bo's source package  to
   extract the bo source and add for each hamm release a line to 
   debian/changelog stating that this release was a hamm release.
   Make your bugfix changes, including changes to the control file
   according to section 6.
   
   Then unpack the hamm source again, update debian/changelog and
   debian/control to figure the bo release, and release a new hamm
   package (including the bugfix, if it affects hamm as well). [3]

  4.  Requirements on libraries for Debian 2.0

   Libraries (regardless of which library they're compiled against) need
   to have runtime dependencies on one of libc, libdl or libm to enable
   the shared linker to determi

Re: checker libs with debugging symbols

[joost witteveen]

> >>Sorry but I disagree here. For a user who only wants to debug his own
> >>program debugging symbols in the libraries are not needed. 
> >
> >Let's take a look at the following program:
[..]
> >gets(buffer);
[..]
> >If you feed it a line that's too long, the access violation will
> >happen deep within the C library.  Without debugging symbols, it's
> >hard to know wether this is a bug in the C library (and there
> >could be quite a few :-) or your program.

> True. But I didn't say 'get rid of these symbols'. All I'd like to see
> is the chance for me to install a version without symbols.

But hey, everybody who installes checker has at least a full installation
of gcc, of libc*-dev, gdb, and probably a lot more development tools.
Now, reading the above, certainly *I* want to have the symbols in
those libs, and I am quite sure most people do.

How many people would have enough space on their development system
to install the development tools, but want to econimise badly on
their checker libs?

Creating extra checker packages will 
  - give everybody who installs debian more work, as they
now have to decide what version of checker to install
(quite a hard choice for a newbie, I'd say).
  - give the developper extra work
  - give the mirrors more work, make debian even larger

(If you want to do this, why not simply say "strip /usr/lib/*"?


-- 
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: Policy wrt mail lockfile (section 4.3)

[Christian Schwarz]

On Fri, 20 Jun 1997, Lars Wirzenius wrote:

> [ Please don't Cc: public replies to me. ]
> 
> John Goerzen:
> > Why are we using dotfile locking only?  There are much better
> > mechanisms (flock, etc.) that should be used instead.  I can see no
> > place where dotfile locking would work and flock-style locking would fail...
> 
> NFS. Scripts that use procmail's lockfile.
> 
> (If it doesn't already, the policy manual should explain the
> reasons behind policy. I'd check if it does, but I don't have
> a copy and am offline.)

The current policy manual (2.1.3.3) only says:

> Mailboxes are locked using the username.lock lockfile convention, rather
> than fcntl, flock or lockf.

This is buggy since it's not working over NFS. (I'm running into problems
every few days since I use sendmail/procmail/pine over a NFS mounted
/var/spool/mail !)

That's the exact reason why I started this discussion again.

AFAIK, there is at least one safe way to lock a file over NFS. The
procedure is partially explained in the open(2) man page and is also
implemented, for example, in your "publib" library. 

Since the procedure is not that simple, I suggested to provide a shared
library that the other packages could be linked against, so that not every
maintainer has to program this on his/her own (this is likely to produce
new bugs!). And I suggested to produce "modules" for Perl/Python etc.

Someone else mentioned that the UN*X (at least Linux) world is laking such
a library and we should therefore build not a debian specific lib, but a
new "upstream library" which can be used by the other distributions as
well. IMHO, that's a very good idea.

Note, that all programs will have to use the same locking mechanism (this
has been discussed before). Thus, we should implement the simpliest
available algorithm that is NFS-safe, since a few maintainers will
probably need to hand-code this themselves (for example, for other
programming languages, etc.). 

There are also tools available, that do locking, for example "lockfile" in
the procmail package. However, calling this program with "system" produces
IMHO too much unnecessary overhead and the source code of this program is
a bit to complicated to force all our developers to implement this.

IMHO, the code in "publib" looks very good. I suggest that we extract the
necessary files and put them together in a new package, called
"liblockfile" (or similar). This package should install a shared library
"liblockfile.so" that contains a few necessary commands to
lock/unlock/test a file.

In addition, we could create a new "lockfile" binary (just as in procmail)
that can be used by shell scripts or other programs (via "system").

We'll also provide "modules" for Perl/Python/etc.


Any comments?


(I feel like I presented these arguments several times now on this list,
but we've not got any results so far.)


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: Policy wrt mail lockfile (section 4.3)

[Thomas Koenig]

Christian Schwarz wrote:

>AFAIK, there is at least one safe way to lock a file over NFS. The
>procedure is partially explained in the open(2) man page and is also
>implemented, for example, in your "publib" library. 

I've dug deeper into the NFS protocol (RFC 1057 and RFC 1094) than is
good for me :-) and I don't think there is such a thing for NFS over UDP
without a lockd, which Linux doesn't have.

The problem is that any NFS request (CREATE, LINK, ...) can get lost, and
its ack can get lost, too.  Let's take a CREATE request.  If no ack comes
back, there are several cases the client can't tell apart:

a) Server never got the request.

b) Server got the request, but the lockfile already existed
  (status = NFSERR_EXIST), and the reply got lost

c) Server got the request, and created the lockfile (status = NFS_OK),
   but the reply got lost.

If the client retries and gets status=NFSERR_EXIST after not hearing
anything from the server, what should it assume that b) or c) happened
previously?

Yes, the server can do xid caching to a certain extent, but the
client can't rely on that.

If the protocol in the publib library has a way to get around that
problem, I'd be interesting in learning more about it (and, possibly,
dreaming up cases in which it might fail :-)
-- 
Thomas Koenig, [EMAIL PROTECTED], [EMAIL PROTECTED]
The joy of engineering is to find a straight line on a double
logarithmic diagram.


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

RFC: library conventions for libc5 and libc6 in hamm Take 4

[Helmut Geyer]

Hello!

I incorporated the changes mentioned by Mark Eichin.
Furthermore I noticed that there were several issues that have not
been handlied by this proposal, so I added several sections.

These tell how to handle dependences and conflicts, source packages
and bugfixes for bo. This is a lot of new stuff. Please read it
carefully and tell me where I messed up.

Helmut

-=-=-=-=-=-=-=-=-=-=-= SNIP -=-=-=-=-=-=-=-=-=-=-=-=-=-

 Debian library policy supplement draft for libc5->libc6 migration

   This document is meant to tell what a Debian package providing a
   library should do to support both libc6 (glibc2) and libc5.
   Note that these requirements are for Debian 2.0 (codename hamm).

 Contents 
 1.  Run time packages
 2.  Development packages
 3.  Source packages
 4.  Requirements on libraries for Debian 2.0
 5.  Conflicts and Dependencies
 6.  Handling bugfix releases for Debian 1.3 (bo)
 7.  Requirements on compiler packages 

 1. Run time packages

A package providing a shared library has to support both C library
packages, libc5 and libc6 based libraries. This must be done using
two Debian packages, each depending on the correct C library
package.
The package naming convention currently suggests to name these
packages as follows. Some packages (mostly from base) may use
locations in /lib. 

   based on  | package name | library location
   
 libc6   |   libfoog [1]| /usr/lib/libfoo.so.
 libc5   |   libfoo | /usr/lib/libc5-compat/libfoo.so. [2]

If a library runtime package contains files that are needed by
both versions of the library, a new package should be made for
just these files that both other packages depend on.

This package naming convention does _not_ apply if a package uses
different sonames for libc5 and libc6 based packages

There are two exceptions from this rule. The shared linker
ld-linux.so.1 and the C library files libc.so.5 and libm.so.5
should still be located in /lib, not in /lib/libc5-compat.

Packages based on X have to use /usr/X11R6 as prefix, not /usr. 
Note that the X libraries are designed to work with both C libraries.

  2.  Development packages

The Debian policy requires that all files needed for compiling/linking
other packages with the library are in a separate package, the
development package. Up to now this package simply was called
libfoo-dev. As packages based on libc5 and libc6 usually cannot
use the same development files there has to be a clear statement
how to separate these. So for now the following packages are
required:  

  based on  | package name| hierarchy locations
  ---
  libc6 | libfoog-dev | /usr/{lib,include}
  libc5 | libfoo-altdev   | /usr/-linuxlibc1/{lib,include}
   
   Note that  usually is i486, but may not be hardcoded in
   debian/rules. It should be obtained using 
dpkg --print-gnu-build-architecture 

   Remember that the libfoo-altdev package has to include symlinks 
   /usr/-linuxlibc1/lib/libfoo.so -> /usr/lib/libc5-compat/libfoo.so.
   to enable using the shared libraries when compiling.

   All documentation that is not depending on whether the library was
   compiled for libc5 or for libc6 should be either part of the
   libfoog-dev package or be put into a separate package if it is
   large. In particular this includes manpages which _have_ to be part
   of the libfoog-dev package.

   Note that the choice to base Debian 2.0 on libc6 fixed the fact
   that the main locations will be used for libc6 packages. The
   alternate locations are used for libc5 based packages.
   This decision does not necessarily mean that by default the
   compiler uses the libc6 packages, please read section 4 for more
   information. Using a four-way approach for library locations
   (standard and alternate locations for libc6 and libc5 based
   packages) will make Debian systems inconsistent with each other,
   something we should avoid at (nearly) all costs. 


  3. Source packages

   The source package name should _not_ be modified for hamm. 

   If a bugfix for bo has to be released, use bo's source package  to
   extract the bo source and add for each hamm release a line to 
   debian/changelog stating that this release was a hamm release.
   Make your bugfix changes, including changes to the control file
   according to section 6.
   
   Then unpack the hamm source again, update debian/changelog and
   debian/control to figure the bo release, and release a new hamm
   package (including the bugfix, if it affects hamm as well). [3]

  4.  Requirements on libraries for Debian 2.0

   Libraries (regardless of which library they're compiled against) need
   to have runtime dependencies on one of libc, libdl or libm to enable
   the shared linker to determi

RE: checker libs with debugging symbols

[Michael Meskes]

What have libc*-dev, gdb, gcc etc. in common with debugging symbols in
checkerlibs?

When I debug my program it suffices to me to know the problem came in
the call to gets() for instance. I'm not interested in seeing more
details, simply because I expect the library to be okay. Usually I
expect a bug in my software before I consider a buggy libc.

But if the common feeling is to not do that I can still strip the
libararies myself, you're right. But it'll have to be strip
/usr/i486-linuxchecker/lib/* :-)

Anyway, with your arguments you could as well ask for libc-dbg to be
fold into libc-dev again as it was earlier on.

Michael

--
Dr. Michael Meskes, Projekt-Manager| topsystem Systemhaus GmbH
[EMAIL PROTECTED]| Europark A2, Adenauerstr. 20
[EMAIL PROTECTED]  | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux!  | Fax: (+49) 2405/4670-10

>-Original Message-
>From:  [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]
>Sent:  Friday, June 20, 1997 1:17 PM
>To:debian-devel@lists.debian.org
>Cc:Die Adresse des Empfängers ist unbekannt.
>Subject:   Re: checker libs with debugging symbols
>
>But hey, everybody who installes checker has at least a full installation
>of gcc, of libc*-dev, gdb, and probably a lot more development tools.
>Now, reading the above, certainly *I* want to have the symbols in
>those libs, and I am quite sure most people do.
>
>How many people would have enough space on their development system
>to install the development tools, but want to econimise badly on
>their checker libs?
>
>Creating extra checker packages will 
>  - give everybody who installs debian more work, as they
>now have to decide what version of checker to install
>(quite a hard choice for a newbie, I'd say).
>  - give the developper extra work
>  - give the mirrors more work, make debian even larger
>
>(If you want to do this, why not simply say "strip /usr/lib/*"?
>
>
>-- 
>joost witteveen, [EMAIL PROTECTED]
>#!/usr/bin/perl -sp0777i$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
>lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
>#what's this? see http://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] .
>


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

New maintainer for the wwwoffle package.

[Federico Di Gregorio]

Apparently nobody stepped forward for the wwwoffle package, so
I think I got it... my first debian package! Now, if only can 
get an account on master... here's my data and pgp key:

Federico Di Gregorio <[EMAIL PROTECTED]>

snail mail:
Via Ormea 131 Torino -- ITALY
telephone:
+39 (0)11 6670891
 
Type Bits/KeyIDDate   User ID
pub  1024/D1B5859D 1997/06/20 Federico Di Gregorio <[EMAIL PROTECTED]>

-BEGIN PGP PUBLIC KEY BLOCK-
Version: 2.6.3ia

mQCNAzOqgp8AAAEEANmUnULlrIT9BGnVzl2OQqMEyobXBCbo6Bl2vWmgUT8birWO
87cK+HNyDjsuCCl0IsWJge8gzw9zfv6G7iyzTf3kWEdcmSp9fIIBHJjNlUzJTIbl
fqcjf/6zpf7cVXHvQqdFH68z1ImxqLps3inxRmS0f2aUDllTBWPFEcPRtYWdAAUR
tCtGZWRlcmljbyBEaSBHcmVnb3JpbyA8Zm9nQHBlcm9zYS5hbHBjb20uaXQ+iQCV
AwUQM6qCn2PFEcPRtYWdAQF1TAQA09ul3uDmz+mgH0LX3A5SpuTLV1vSVH6XOqI+
1I0pAZeB+Rd/+Pm+EjTl+Lt96mCcgYXFN+xQL3VMIHTjMw7OM7JqNQ1SAMAJexc/
2QBpzc1OS/lqgrhE49tndUaYNzajE2UBVBmNiBbwC+Ca9S5A0g0BOiTHnPuXmfQp
kVt0STY=
=1OFW
-END PGP PUBLIC KEY BLOCK-



**
* Federico Di Gregorio   |  /  the number you dialled is *
* [EMAIL PROTECTED]   | / -1   imaginary... please, rotate*
*|/  the phone PI/2 and try again!   *
**



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

Re: Rescue disk and Thinkpads (problem identified).

[Steven Bruce Dunham]

Rob Browning wrote:
> 
> I had posted earlier about a problem getting Debian 1.2/1.3 installed
> on a 365x thinkpad.  Several solutions were offered and in the end it
> turned out that the people claiming that some thinkpads could not
> handle the bzImage format were correct.  It was not the
> "floppy=thinkpad" problem.  I didn't need that at all.

> So, if it doesn't make the kernel too big, could we switch back to
> using zImages on the rescue disk rather than bzImages?  It won't hurt
> any other machines, and there are apparently a (small) number of
> machines out there (some Thinkpads and some Toshibas I think) that it
> would greatly help.

I have the same problem with my Dell Laptop.  With the same source tree
and config options, the zImage boots and the bzImage resets the machine
after loading.  If there is no convincing reason to use bzImage, we
should
switch to zImage.


Steve
[EMAIL PROTECTED]


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

FW: [NTSEC] (Fwd) DESCHALL Press Release

[Michael Meskes]

Does this mean I can remove my des-solnet?

Anyway, we didn't win but the [EMAIL PROTECTED] email address processed
the most blocks of all email addresses.

Michael

--
Dr. Michael Meskes, Projekt-Manager| topsystem Systemhaus GmbH
[EMAIL PROTECTED]| Europark A2, Adenauerstr. 20
[EMAIL PROTECTED]  | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux!  | Fax: (+49) 2405/4670-10

>-Original Message-
>From:  [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]
>Sent:  Friday, June 20, 1997 11:28 AM
>To:[EMAIL PROTECTED]
>Subject:   [NTSEC] (Fwd) DESCHALL Press Release
>
>--- Forwarded Message Follows ---
>From:  Rocke Verser <[EMAIL PROTECTED]>
>To:"[EMAIL PROTECTED]"
><[EMAIL PROTECTED]>
>Subject:   DESCHALL Press Release
>Date:  Wed, 18 Jun 1997 21:09:11 +0100
>
>INTERNET-LINKED COMPUTERS CHALLENGE DATA ENCRYPTION STANDARD
>
> LOVELAND, COLORADO (June 18, 1997).  Tens of thousands of
>computers, all across the U.S. and Canada, linked together via the
>Internet in an unprecedented cooperative supercomputing effort to
>decrypt a message encoded with the government-endorsed Data Encryption
>Standard (DES).
>
> Responding to a challenge, including a prize of $10,000, offered by
>RSA Data Security, Inc, the DESCHALL effort successfully decoded
>RSADSI's secret message.
>
> According to Rocke Verser, a contract programmer and consultant who
>developed the specialized software in his spare time, "Tens of thousands
>of computers worked cooperatively on the challenge in what is believed
>to be one of the largest supercomputing efforts ever undertaken outside
>of government."
>
> Using a technique called "brute-force", computers participating in
>the challenge simply began trying every possible decryption key.  There
>are over 72 quadrillion keys (72,057,594,037,927,936).  At the time the
>winning key was reported to RSADSI, the DESCHALL effort had searched
>almost 25% of the total.  At its peak over the recent weekend, the
>DESCHALL effort was testing 7 billion keys per second.
>
> Verser considers this project to be remarkable in two ways:
>
> One.  This is the first time anyone has publicly shown that they
>can read a message encrypted with DES.  And this was done with "spare"
>CPU time, mostly from ordinary PCs, by thousands of users who have never
>even met each other.  U.S. government and industry will have to take a
>hard look at their cryptographic policies.  "DES can no longer be
>considered secure against a determined adversary", Verser said.
>
> Two.  This project demonstrates the kind of supercomputing power
>that can be harnessed on the Internet using nothing but "spare" CPU
>time.  "Imagine what might be possible using millions of computers
>connected to the Internet!"  Aside from cryptography and other obvious
>mathematical uses, supercomputers are used in many fields of science.
>"Perhaps a cure for cancer is lurking on the Internet?", said Verser,
>"Or perhaps the Internet will become Everyman's supercomputer."
>
>
> Under current U.S. government export regulations, and underscoring
>a problem faced by the U.S. software industry, the program that searched
>the keys could not be exported, except to Canada.  A competitive effort,
>based in Sweden, sprang up well after the DESCHALL effort began.  Able
>to "market" their keysearch software around the world, the Swedish
>effort caught up quickly, and had searched nearly 10 quadrillion keys by
>the end of the contest.
>
>   
>
> Verser agrees with the sentiment voiced in RSADSI's secret message:
>"Strong cryptography makes the world a safer place."
>
> Use of strong cryptography, both domestically and internationally,
>is essential in today's electronic world.  "But not at the expense of a
>citizen's right to privacy."  Verser adds, "Recent proposals for
>'key-recovery' and for criminalization of the use of cryptography have no
>place in a free society."
>
>
> Information about the DESCHALL effort is available from the
>official DESCHALL Web site at:  
>
>
>
>MEDIA CONTACTS:
>  Matt Curtin, (908) 431-5300 x 295, <[EMAIL PROTECTED]>
>
>ALTERNATE:
>  Rocke Verser, (970) 663-5629, <[EMAIL PROTECTED]>
>
>ALTERNATE:
>  Justin Dolske, (614) 459-5194, <[EMAIL PROTECTED]>
>
>- 30 -
>
>
>
>
>
>
> INTERNET LINKED COMPUTERS CHALLENGE DATA ENCRYPTION STANDARD
> Background / Sidebar, for Release dated June 18, 1997
>
> The Data Encryption Standard, DES, is a national standard, adopted
>in 1977.  Use of DES is mandatory in most Federal agencies, except the
>military.  DES is very widely used in the private sector, as well.
>
> Interbank wire transfers, Visa transactions, your medical and
>financial rec

Awful problem with dpkg (once again)

[Martin Alonso Soto Jacome]

Hi:

Since I didn't receive any answer the first time I posted, I'm sending
this again.  Hope this time someone can help me, for I'm stuck with
the problem and the only solution I see is reinstalling everything
from the scratch (sometime I thought I would never had to do with
Debian).

Thanks a lot,

M. S.

- Original message 
Hi:

Trying to upgrade the machine of a colegue, I found and awful problem
with dpkg I haven't managed to deal with.  Apparently, the package
database got corrupted somehow, preventing me from upgrading any
package.  For example, if I try to upgrade libc5 with

  dpkg -i libc5_5.4.23-6.deb

I get

  (Reading database ... 15789 files and directories currently installed.)
  Preparing to replace libc5 5.4.20-1 (using libc5_5.4.23-6.deb) ...
  dpkg: failed to open package info file `/var/lib/dpkg/updates/07' for 
reading: No such file or directory
  dpkg: error processing libc5_5.4.23-6.deb (--install):
   subprocess pre-installation script returned error exit status 2
  Errors were encountered while processing:
   libc5_5.4.23-6.deb

Even more, upgrading dpkg doesn't work at all:

  (Reading database ... 15789 files and directories currently installed.)
  Preparing to replace dpkg 1.4.0.7 (using dpkg_1.4.0.8.deb) ...
  dpkg: failed to open package info file `/var/lib/dpkg/updates/07' for 
reading: No such file or directory
  dpkg: error processing dpkg_1.4.0.8.deb (--install):
   subprocess pre-installation script returned error exit status 2
  Errors were encountered while processing:
   dpkg_1.4.0.8.deb

Any clues on what may be happening?

Regards,

M. S.


Martin A. Soto J.   Profesor
Departamento de Ingenieria de Sistemas y Computacion
Universidad de los Andes  [EMAIL PROTECTED]



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

Re: Policy wrt mail lockfile (section 4.3)

[Christoph Lameter]

: > Mailboxes are locked using the username.lock lockfile convention, rather
: > than fcntl, flock or lockf.

: This is buggy since it's not working over NFS. (I'm running into problems
: every few days since I use sendmail/procmail/pine over a NFS mounted
: /var/spool/mail !)

I am using exim/exim/pine here over NFS mounted /var/spool/mail for around 1000 
users with no
problems at all. Some of the gizmos you are using might have a problem with
the lock scheme. I know that exim is pretty reliable with its locking and I 
also use
exim instead of procmail (build in mailfilter).


-- 
--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---
Please always CC me when replying to posts on mailing lists.


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

Re: Policy wrt mail lockfile (section 4.3)

[Karl M. Hegbloom]

> "Christian" == Christian Schwarz <[EMAIL PROTECTED]> writes:

Christian> This is buggy since it's not working over NFS. (I'm
Christian> running into problems every few days since I use
Christian> sendmail/procmail/pine over a NFS mounted
Christian> /var/spool/mail !)

Christian> That's the exact reason why I started this discussion
Christian> again.

What happens?  Can you describe the problem?  Explain your setup in
more detail, please.  I would like to know more about the problems
that are encountered with nfs.

Christian> There are also tools available, that do locking, for
Christian> example "lockfile" in the procmail package. However,
Christian> calling this program with "system" produces IMHO too
Christian> much unnecessary overhead and the source code of this
Christian> program is a bit to complicated to force all our
Christian> developers to implement this.

 Unix is designed around peicing things together from small utility
programs, and fork/exec/wait probably doesn't really "cost" that
much...  on the other hand, putting the lockfile stuff into a shared
library is more estheticly appealing.

Christian> IMHO, the code in "publib" looks very good. I suggest
Christian> that we extract the necessary files and put them
Christian> together in a new package, called "liblockfile" (or
Christian> similar). This package should install a shared library
Christian> "liblockfile.so" that contains a few necessary commands
Christian> to lock/unlock/test a file.

 Solaris has a maillock library that is cloned in `qpopper'.  A manual
page for Sun's maillock can easily be found on the web.  I think that
qpopper's algorithm is superiour to the one in publib.  Will you have
a look at it?  Publib uses the return value from the stat call, which
you're not supposed to do.  (I don't know why yet.)

Christian> In addition, we could create a new "lockfile" binary
Christian> (just as in procmail) that can be used by shell scripts
Christian> or other programs (via "system").

 I guess we should mimic the maillock library, but add a more general
function for creating a lock for any file, not just mail spools.  How
does DCE do it, I wonder?  I found libuuid in the ext2fsprogs.

 What's a lockd do?  I will search for that today.

Christian> We'll also provide "modules" for Perl/Python/etc.

 Can you use SWIG for that, once we make a .so?

-- 
Karl M. Hegbloom <[EMAIL PROTECTED]>   finger or ytalk:
http://www.inetarena.com/~karlheg   [EMAIL PROTECTED]
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: Policy wrt mail lockfile (section 4.3)

[Erik B. Andersen]

This sounds good to me.  When finished, we should announce this
on c.o.l.a. and try to see if the Red Had folks will adopt it as
well.  If we both adopt it as policy, then it will live on forever!

 -Erik

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


> 
> On Fri, 20 Jun 1997, Lars Wirzenius wrote:
> 
> > [ Please don't Cc: public replies to me. ]
> > 
> > John Goerzen:
> > > Why are we using dotfile locking only?  There are much better
> > > mechanisms (flock, etc.) that should be used instead.  I can see no
> > > place where dotfile locking would work and flock-style locking would 
> > > fail...
> > 
> > NFS. Scripts that use procmail's lockfile.
> > 
> > (If it doesn't already, the policy manual should explain the
> > reasons behind policy. I'd check if it does, but I don't have
> > a copy and am offline.)
> 
> The current policy manual (2.1.3.3) only says:
> 
> > Mailboxes are locked using the username.lock lockfile convention, rather
> > than fcntl, flock or lockf.
> 
> This is buggy since it's not working over NFS. (I'm running into problems
> every few days since I use sendmail/procmail/pine over a NFS mounted
> /var/spool/mail !)
> 
> That's the exact reason why I started this discussion again.
> 
> AFAIK, there is at least one safe way to lock a file over NFS. The
> procedure is partially explained in the open(2) man page and is also
> implemented, for example, in your "publib" library. 
> 
> Since the procedure is not that simple, I suggested to provide a shared
> library that the other packages could be linked against, so that not every
> maintainer has to program this on his/her own (this is likely to produce
> new bugs!). And I suggested to produce "modules" for Perl/Python etc.
> 
> Someone else mentioned that the UN*X (at least Linux) world is laking such
> a library and we should therefore build not a debian specific lib, but a
> new "upstream library" which can be used by the other distributions as
> well. IMHO, that's a very good idea.
> 
> Note, that all programs will have to use the same locking mechanism (this
> has been discussed before). Thus, we should implement the simpliest
> available algorithm that is NFS-safe, since a few maintainers will
> probably need to hand-code this themselves (for example, for other
> programming languages, etc.). 
> 
> There are also tools available, that do locking, for example "lockfile" in
> the procmail package. However, calling this program with "system" produces
> IMHO too much unnecessary overhead and the source code of this program is
> a bit to complicated to force all our developers to implement this.
> 
> IMHO, the code in "publib" looks very good. I suggest that we extract the
> necessary files and put them together in a new package, called
> "liblockfile" (or similar). This package should install a shared library
> "liblockfile.so" that contains a few necessary commands to
> lock/unlock/test a file.
> 
> In addition, we could create a new "lockfile" binary (just as in procmail)
> that can be used by shell scripts or other programs (via "system").
> 
> We'll also provide "modules" for Perl/Python/etc.
> 
> 
> Any comments?
> 
> 
> (I feel like I presented these arguments several times now on this list,
> but we've not got any results so far.)
> 
> 
> 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] .
> 


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

Re: Policy wrt mail lockfile (section 4.3)

[John Goerzen]

Rob Browning <[EMAIL PROTECTED]> writes:

> John Goerzen <[EMAIL PROTECTED]> writes:
> 
> > Why are we using dotfile locking only?  There are much better
> > mechanisms (flock, etc.) that should be used instead.  I can see no
> > place where dotfile locking would work and flock-style locking would
> > fail...
> 
> I think flock can fail across NFS in certain situations, but I'm no
> locking expert.

Hmm, but why would that cause a problem with mailers/programs that use
lockfile locking *and* flock/fcntl locking at the same time?

-- 
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] .

Re: routing question

[Incoming List Mail]

On Thu, 19 Jun 1997, Heiko Schlittermann wrote:

> : I seem to get caught in a routing loop at fngw-T3-prolog.NEREP.NET when I
> : try the second and third command, and it looks to me like that router is
> : misconfigured.  The ISP claims that traceroute (and ping) won't work until
> : DNS is ready. 
> 
> Nonsens.  May be they work slower, but they work.  And you can always
> use ``-n'' to traceroute w/o name resolving.  DNS is completely
> unrelated to routing.

That's what I thought.  Now they tell me that their routers (which pass
routing info via rip) can tell the presence of hosts on the other side of
my Linux router, which is using static routes, and that's the reason that
they claim I can't even get into their network.

> : I also can't seem to get out of the intranet via the Linux diald machine.
> : I'm testing stuff using tracert under WinNT, and getting *'s.  Here's the
> : output of route (I've tried cleaning it up manually, but it still doesn't
> : route):
> : 
> : Kernel IP routing table
> : Destination Gateway Genmask Flags Metric RefUse 
> Iface
> : cs10.mil.ptd.ne *   255.255.255.255 UH0  01 ppp0
>  what is this route for?  I'd assume, the default below
>  is it really necessary for diald?
> : cs10.mil.ptd.ne *   255.255.255.255 UH1  00 sl0
> ~ this should suffice, additional to the default entry below.
> If it's the host on the other end, your ISP.

This is the way that diald seems to want to work.

> : I have created some accounts for generic testing.  If any of are brave
> : enough to take a snoop on the actual machine, let me know and I'll "let
> : you in."
> 
> ... yep, but how could we reach your host?

204.186.27.145 (the modem) is an accessible host.  This weekend I'll be
building a 486/25 to be 204.186.230.3, which probably won't be available
to the internet until I get the routing right, but you could telnet to
204.186.27.145 and then telnet to 204.186.230.3, and then do whatever
testing/snooping came to mind.

Thanks,

Pete

--
Peter J. Templin, Jr.   Client Services Analyst
Computer & Communication Services   tel: (717) 524-1590
Bucknell University [EMAIL PROTECTED]



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

Correct path for upgrading to libc6-dev?

[Ben Gertzfield]

*wavewave* I'm finally ready to move my Debian box up to libc6-dev,
but it seems there are all sorts of dependancies that aren't solved by
moving to the newest version of everything (ncurses-dev, slang-dev, libg++-dev,
and libdb-dev still depend on libc5-dev..) 

I took a peek at libc5-altdev, but it depends on an older version of
libc5 than I have (5.4.23-4, while I have 5.4.23-6..) 

Should I downgrade my libc5?

Should I just remove ncurses-dev, slang-dev, libg++-dev, and
libdb-dev?

Help! :)

-- 
Brought to you by the letters A and P and the number 11.
"Porco ga daisuki!" -- Fio, "Porco Rosso"
Ben Gertzfield  Finger me for my public
PGP key. I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.


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

Re: Policy wrt mail lockfile (section 4.3)

[Scott K. Ellis]

-BEGIN PGP SIGNED MESSAGE-

On 20 Jun 1997, John Goerzen wrote:

> > I think flock can fail across NFS in certain situations, but I'm no
> > locking expert.
> 
> Hmm, but why would that cause a problem with mailers/programs that use
> lockfile locking *and* flock/fcntl locking at the same time?

You create fun deadlocks when one program does it lockfile/flock and the
other does it flock/lockfile.

++
|   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

iQCVAwUBM6rjeKCk2fENdzpVAQFN+gP+NAomXn0fmPG4YIYb4ObdHTHYuvmwMCsO
xcJ+EYPxFcBvMY/p4FG7S8Nj0ToAAkcM3Lj6vZ/ox2sjnHVX/dNd9U/WBbzgdhKB
RiYRoLMp/G7kI9P3qW4gGDT08O0IHOxnX5sVC7es+6jE8gySsH+vRlHHU5vnhxlF
WX2BX3ih1dY=
=x6Jq
-END PGP SIGNATURE-


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

Re: Rescue disk and Thinkpads (problem identified).

[Bruce Perens]

Rob, Steve, and Co.,

Is this when booting from the floppy only, or from hard disk too?
I suspect a software bug in SysLinux, the floppy bootstrap. Once I
get some more data from you I will take it up with H. Peter Anvin,
the SysLinux author.

Thanks

Bruce

Rob Browning wrote:
> 
> I had posted earlier about a problem getting Debian 1.2/1.3 installed
> on a 365x thinkpad.  Several solutions were offered and in the end it
> turned out that the people claiming that some thinkpads could not
> handle the bzImage format were correct.  It was not the
> "floppy=thinkpad" problem.  I didn't need that at all.
>
> So, if it doesn't make the kernel too big, could we switch back to
> using zImages on the rescue disk rather than bzImages?  It won't hurt
> any other machines, and there are apparently a (small) number of
> machines out there (some Thinkpads and some Toshibas I think) that it
> would greatly help.

From: Steven Bruce Dunham <[EMAIL PROTECTED]>
> I have the same problem with my Dell Laptop.  With the same source tree
> and config options, the zImage boots and the bzImage resets the machine
> after loading.  If there is no convincing reason to use bzImage, we
> should switch to zImage.

-- 
Bruce Perens K6BP   [EMAIL PROTECTED]   510-215-3502
Finger [EMAIL PROTECTED] for PGP public key.
PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6  1F 89 6A 76 95 24 87 B3 


--
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] (Marco Budde)  wrote on 16.06.97 in <[EMAIL PROTECTED]>:

> Am 16.06.97 schrieb efraim # argh.org ...
>
> Moin Alexander!

AK>> sendmail: too complicated

> That's wrong. It's very easy to configure sendmail with the m4 scripts for
> a leaf site. And professionell system adminstrators will use sendmail
> because it's the standard MTA.

I completely fail to understand why a professional system administrator  
would _want_ to use a MTA that's _that_ notorious for security holes. My  
idea of professionalism seriously clashes with this.

Of course, in many situations, he/she may have no real choice.

> And you should remember that the most Linux distributions use sendmail as
> MTA. In my opinion Debian should use sendmail as standard MTA.

People, eat shit. Millions of flies can't be wrong.

Sendmail: Just say NO.


MfG Kai


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

Re: leap second

[Kai Henningsen]

[EMAIL PROTECTED] (Bruce Perens)  wrote on 18.06.97 in <[EMAIL PROTECTED]>:

> The time is out of joint, o 'cursed spite.
>
> The U.S. National Institute of Standards and Technology will set it right
> on June 30, at one second before midnight UTC, by adding a leap second.
> Systems that run on POSIX time will ignore this. The effect is that they
> will consider the difference between the epoch and now to be 22 seconds
> less than it really is.

We already had this debate. For an OS, the POSIX time is the only  
reasonable choice.

Consider a system using "real" time. On June 31, its idea of time would be  
wrong until the next software upgrade. Then, all time stamps would  
suddenly change by one second (possibly causing FTP server remirroring and  
other unpleasant effects).

This is completely unacceptable. OS time must be predictable.


MfG Kai


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

Re: hamm and dftp

[Kai Henningsen]

[EMAIL PROTECTED] (Douglas L Stewart)  wrote on 18.06.97 in <[EMAIL PROTECTED]>:

> On 18 Jun 1997, Kai Henningsen wrote:
>
> > > ftpdir:   /debian/hamm
> >
> > This is probably the problem. The above path is relative to the /debian
> > directory. You might try
> >
> > ftpdir: /debian
> >
> > and see if that helps.
>
> I made the change:
>
> include:hamm/hamm,hamm/contrib,hamm/non-free
> exclude:
> ftpsite:ftp.debian.org
> ftpdir: /debian
>
> But I still see paths starting with "dists".

And I still think that paths starting with "dists" are *correct*. They  
sure work with other installation methods.

> Can anyone help with this?  I just want to download packages from hamm
> with dftp without having to go into contortions doing sed-type work.

Well, what is your problem, anyway? You don't actually say that. Again,  
paths starting with "dists" doesn't seem to be an error.


MfG Kai


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

Re: routing question

[Kai Henningsen]

[EMAIL PROTECTED] (Pete Templin)  wrote on 18.06.97 in <[EMAIL PROTECTED]>:

> Let me try some somewhat off-topic questions here: I really think the ISP
> is clueless and not communicating the presence of our network to its
> upstream provider.  Could a bunch of you developers please try the
> following three traceroute commands and tell me what you get?

I sent that directly, no need to bother debian-devell with long  
traceroutes. In short:

> % traceroute 204.186.27.145

Reachable.

> % traceroute 204.186.230.1
> % traceroute 204.186.230.2

ICMP Host not reachable from fngw-T3-prolog.NEREP.NET.

And all three have working PTR records, i.e. DNS _does_ work.

Telnet to the modem IP works fine:

---
[ [EMAIL PROTECTED] ] ~ $ telnet 204.186.27.145
Trying 204.186.27.145...
Connected to 204.186.27.145.
Escape character is '^]'.
Debian GNU/Linux 1.3 srv1.jdweb.com

srv1 login:
--

> I seem to get caught in a routing loop at fngw-T3-prolog.NEREP.NET when I
> try the second and third command, and it looks to me like that router is
> misconfigured.  The ISP claims that traceroute (and ping) won't work until
> DNS is ready.

That claim is complete nonsense, of course; and the router is most  
definitely misconfigured.

> I also can't seem to get out of the intranet via the Linux diald machine.

Under the circumstances, that's what I'd expect.

> I'm testing stuff using tracert under WinNT, and getting *'s.  Here's the
> output of route (I've tried cleaning it up manually, but it still doesn't
> route):

Try the following. Do a tcpdump on your modem interface (tcpdump -i ppp0).  
See if packets from the srv2 actually pass over that interface.

If yes, you just suffer from the ISP's routing problems.

If no, you also have a local problem. Next, do the tcpdump on eth0 to see  
if the packets make it to srv1. If yes, the problem is routing on srv1; if  
not, it's routing on srv2 (probably a missing route for default to srv1).

> I have created some accounts for generic testing.  If any of are brave
> enough to take a snoop on the actual machine, let me know and I'll "let
> you in."

Can do, if you want me to. In that case, drop me a line.


MfG Kai


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

Re^2: Status of Debian Policy

[Marco Budde]

Am 16.06.97 schrieb sanvila # unex.es ...

Moin Santiago!

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

Ask the users! The most people hate the info format and it's browsers. We  
should include the HTML documentation in the package.

SVD> IMHO we should not drop .info from the main package, or we would have

I think, we should ;-). The HTML format is more flexible and the output  
looks much better. All package maintainer's should convert the  
documentation from LaTeX oder Texinfo to HTML.

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: checker libs with debugging symbols

[Shaya Potter]

On Fri, 20 Jun 1997, Michael Meskes wrote:

> Sorry but I disagree here. For a user who only wants to debug his own
> program debugging symbols in the libraries are not needed. 
> 
> I'd prefer to have several packages: checker-bin, checker-libs,
> checker-dbg or something like that. Remember, we do not distribute
> debugging symbols in other libraries for the same reason. Instead we
> provide an *-dbg package.
> 
> What do others think about this?

The reason we don't distribute deugging symbols in our other libraries is
because those libraries are meant for stand alone apps, i.e. not to be
dubugged as easily, however checker, whose only purpose is debugging
should include the symbols.  

Shaya


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

Re: Rescue disk and Thinkpads (problem identified).

[Rob Browning]

Bruce Perens <[EMAIL PROTECTED]> writes:

> Is this when booting from the floppy only, or from hard disk too?
> I suspect a software bug in SysLinux, the floppy bootstrap. Once I
> get some more data from you I will take it up with H. Peter Anvin,
> the SysLinux author.

Hmm.  I don't have access to the machine right now, and I'm only
really familiar with booting from a HD via lilo.  What would I need to
do to test this if I get the machine back?

Thanks
-- 
Rob


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

Re: Rescue disk and Thinkpads (problem identified).

[Bruce Perens]

> What would I need to do to test this if I get the machine back?

Install a bzImage kernel on the hard disk using LILO, and see if it will
boot. If it boots, it's only a problem with the floppy bootstrap. All of
our kernels are bzImage, so that should be easy to test.

Thanks

Bruce
-- 
Bruce Perens K6BP   [EMAIL PROTECTED]   510-215-3502
Finger [EMAIL PROTECTED] for PGP public key.
PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6  1F 89 6A 76 95 24 87 B3 


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

Re: Re^2: Status of Debian Policy

[Scott K. Ellis]

-BEGIN PGP SIGNED MESSAGE-

On 20 Jun 1997, Marco Budde wrote:
> SVD> The simplest solution is to ship html in a different package. This way
> SVD> the user will be able to choose to not install the html docs if he/she
> SVD> believes info2www is enough.
> 
> Ask the users! The most people hate the info format and it's browsers. We  
> should include the HTML documentation in the package.

I'm sure I'd rather have info than HTML.  Info browses nicely, especially
now that we have info patched for cursor key navigation.  HTML is larger
and more cumbersome.

> SVD> IMHO we should not drop .info from the main package, or we would have
> 
> I think, we should ;-). The HTML format is more flexible and the output  
> looks much better. All package maintainer's should convert the  
> documentation from LaTeX oder Texinfo to HTML.

Okay, show me how to search a HTML version of the bash info documentation
for a concept and I'll believe you.

++
|  |  Any resemblance between the above views and those  |
|  |   of my employer, my terminal, or the view out my   |
|  |   window are purely coincidental.  Any resemblance  |
|  |between the above and my own views is|
|  Scott K. Ellis  |  non-deterministic.  The question of the existence  |
|  [EMAIL PROTECTED]  |  of views in the absence of anyone to hold them is  |
|  |  left as an exercise for the reader.  The question  |
|  | of the existence of the reader is left as an|
|  |  exercise for the second god coefficient.   |
|  |(A discussion of non-orthogonal, non-integral|
|  |   polytheism is beyond the scope of this article.)  |
++

-BEGIN PGP SIGNATURE-
Version: 2.6.3
Charset: noconv

iQCVAwUBM6sCs6Ck2fENdzpVAQHa4QP/dMAyhLFDU3scmyfcJa8dMf2W8BfsvcA7
M/nwb4nLZzX81eRlKZnurQUTn45HbCA3MQreNcRTGpYTzJHpKAmiqUo07URgzRCj
74wucMpJtvZM7b+fv0/vwtB0oy+UAGCdhFweM4lJyYfJeTrhvzDjNp+oTmDkrm6p
RgOUFYiW8p4=
=KhlN
-END PGP SIGNATURE-


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

Re: Re^2: Status of Debian Policy

[Dirk Eddelbuettel]

  Dirk> However, Christian Schwarz asked me to do html as well. That will be
  Dirk> some work as HOWTO packages comes as tar.gz files with no
  Dirk> surcompassing index.html.  I'll have to do some perl hacking. No
  Dirk> promises for the June release, maybe for July.

  Christian>  Just unpack all .tar.gz files in the same directory and use the
  Christian> file "HOWTO-INDEX-3.html" as "index.html". It contains an
  Christian> overview over all available HOWTOs and mini-HOWTOs and
  Christian> hyperlinks to them.

Excellent! Thanks. 

-- 
 [EMAIL PROTECTED]  [EMAIL PROTECTED]  http://rosebud.sps.queensu.ca/~edd
PGP key fingerprint = B2 49 75 BF 44 2C B7 AA  50 CB 19 7D 80 F7 CB DC
--
By US Code Title 47, Sec.227(a)(2)(B), a computer/modem/printer meets the
definition of a telephone fax machine. By Sec.227(b)(1)(C), it is unlawful to
send any unsolicited advertisement to such equipment.  By Sec.227(b)(3)(C), a
violation of the aforementioned section is punishable by action to recover
actual monetary loss, or $500, whichever is greater, for each violation. 
Please read the full text at http://www.law.cornell.edu/uscode/47/227.html.


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

Re: Policy wrt mail lockfile (section 4.3)

[John Goerzen]

However, why is it bad if a given program (like Elm-ME+ which I
maintain, which brought the issue to my attention this time) uses
*both* locking mechanisms?

Rob Browning <[EMAIL PROTECTED]> writes:

> John Goerzen <[EMAIL PROTECTED]> writes:
> 
> > Why are we using dotfile locking only?  There are much better
> > mechanisms (flock, etc.) that should be used instead.  I can see no
> > place where dotfile locking would work and flock-style locking would
> > fail...
> 
> I think flock can fail across NFS in certain situations, but I'm no
> locking expert.
> 
> -- 
> Rob
> 
> 
> --
> TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
> [EMAIL PROTECTED] . 
> Trouble?  e-mail to [EMAIL PROTECTED] .
> 

-- 
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] .

Re: mgetty Needs Maintainer!

[John Goerzen]

No.  What happened is this:

 * You handed the package over to me.  I uploaded several versions
   into unstable.  (Bug reports are now going to me.)  The person
   posting that message must have been using an old version, from 1.2.
   I never made a release of mgetty to stable since there were no
   serious bugs to fix.
 * Several months ago, I handed the package over to Siggy -- a couuple
   of days before he had a fire.  I finally figured out what happened,
   so I handed it over to a different person.
 * This person uploaded a new version to master, but it has been
   sitting in Incoming for over 10 days now.

Christoph Lameter <[EMAIL PROTECTED]> writes:

> : > Anyway I thought that Chrisoph Lameter is the maintainer of mgetty
> : > as the most recent uploads come from him.
> 
> Is there an imposter around? My last upload must have been half a year ago or 
> so.
> Maybe someone just forgot to change the maintainer name again.
> 
> -- 
> --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---
> Please always CC me when replying to posts on mailing lists.
> 
> 
> --
> TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
> [EMAIL PROTECTED] . 
> Trouble?  e-mail to [EMAIL PROTECTED] .
> 

-- 
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] .

Re: xemacs orphaned [Todd Walker ] RE: Account dres@scsn.net (was Re: Mail System Error - Returned Mail)

[John Goerzen]

OK, I've sent an e-mail to that address.  It's been about 24 hours
since that time now, so let's give him a few more days to respond.  In
the mean time, let's get somebody willing to take over xemacs just in
case.  IMHO, XEmacs is the most powerful editor in our system and we
really should keep it up!

Christian Schwarz <[EMAIL PROTECTED]> writes:

> On 18 Jun 1997, John Goerzen wrote:
> 
> > Hello,
> > 
> > It appears that James LewisMoss, previous maintainer of xemacs, is no
> > longer around.
> 
> I just did a `grep LewisMoss debian-devel*' through my mail archive and
> discovered a mail which he (James LewisMoss) sent on 08 May 1997 20:16:11
> -0600. He used the address 
> 
>   James LewisMoss <[EMAIL PROTECTED]>
> 
> Did you also try to reach him there? There is also a www address in the
> signature:
> 
>   @James LewisMoss <[EMAIL PROTECTED]> |  Blessed Be!
>   @http://www.dimensional.com/~dres   |  Linux is cool!
> 
> Perhaps his home page can give more info (I didn't have a look, yet).
> 
> 
> 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
> 

-- 
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] .

Re: Installing XF86 3.3-1 crashed XEmacs 19.15-3

[John Goerzen]

I have already released a non-maintainer upload of XEmacs 19.15 (named
XEmacs 19.15-3.1) to Incoming on Master.  This package fixes that problm.

Federico Di Gregorio <[EMAIL PROTECTED]> writes:

>   Then, to get better support for my gfx board I downloaded
> the XF86 3.3-1 packages (base, svga-server, lib, fonts, extensions,
> etc...) and installed them. Again all went well but... now XEmacs 19.15
> crashes and does a core dump. I tryed to mail the maintainer 
> (James LewisMoss <[EMAIL PROTECTED]>) but, apparently, the address is
> wrong. (I'll cc a copy of this  mail to his address anyway...)

-- 
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] .

Re: Re^2: Status of Debian Policy

[Dirk Eddelbuettel]

[ CC'ed to Christian for policy question, and to Manoj for VM example. ]

  Marco> Ask the users! The most people hate the info format and it's
  Marco> browsers. We should include the HTML documentation in the package.

But they get html via the dwww package! Which gives them _more_ documentation
then there is in html only.

  Scott>  I'm sure I'd rather have info than HTML.  Info browses nicely,
  Scott> especially now that we have info patched for cursor key navigation.
  Scott> HTML is larger and more cumbersome.

Seconded. Nobody answered my mail from yesterday which showed that the
doc-linux package will take up over 5 MB (instead of 1.6 MB) for the html
stuff.

  Santiago> IMHO we should not drop .info from the main package, or we would
  Santiago> have

  Marco> I think, we should ;-). 

No way. IMHO, we should add a Policy Guideline stating that html should be in
a seperate package [1] and that info should be shipped as usual. I for one
consider it a misfeature that the vm package dropped the .info for the .html.
Make it an option to add html docs, but don't make it compulsory.

[1] Unless there is very little html doc in which case we don't have to split
that package

  Marco> The HTML format is more flexible and the output looks much
  Marco> better. All package maintainer's should convert the documentation
  Marco> from LaTeX oder Texinfo to HTML.

  Scott>  Okay, show me how to search a HTML version of the bash info
  Scott> documentation for a concept and I'll believe you.

Couldn't agree more.

-- 
 [EMAIL PROTECTED]  [EMAIL PROTECTED]  http://rosebud.sps.queensu.ca/~edd
PGP key fingerprint = B2 49 75 BF 44 2C B7 AA  50 CB 19 7D 80 F7 CB DC
--
By US Code Title 47, Sec.227(a)(2)(B), a computer/modem/printer meets the
definition of a telephone fax machine. By Sec.227(b)(1)(C), it is unlawful to
send any unsolicited advertisement to such equipment.  By Sec.227(b)(3)(C), a
violation of the aforementioned section is punishable by action to recover
actual monetary loss, or $500, whichever is greater, for each violation. 
Please read the full text at http://www.law.cornell.edu/uscode/47/227.html.


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

Re: XEmacs maintainer gone???!!

[James LewisMoss]

> "John" == John Goerzen <[EMAIL PROTECTED]> writes:

 John> I just sent a message to [EMAIL PROTECTED]  This
 John> transforms (correctly) into [EMAIL PROTECTED]  scsn.net reports
 John> that there is no dres user on their system.

 John> Does this mean that the maintainer for XEMacs is gone?

No it just means my old ISP decided to remove my account without
telling me.  Nice of them eh? :)  My new address is
[EMAIL PROTECTED]

Jim

-- 
@James LewisMoss <[EMAIL PROTECTED]> |  Blessed Be!
@http://www.dimensional.com/~dres   |  Linux is cool!
@"Argue for your limitations and sure enough, they're yours." Bach


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

Re: xemacs orphaned [Todd Walker ] RE: Account dres@scsn.net (was Re: Mail System Error - Returned Mail)

[Brian White]

John Goerzen wrote:
> 
> OK, I've sent an e-mail to that address.  It's been about 24 hours
> since that time now, so let's give him a few more days to respond.  In
> the mean time, let's get somebody willing to take over xemacs just in
> case.  IMHO, XEmacs is the most powerful editor in our system and we
> really should keep it up!

The address "James LewisMoss <[EMAIL PROTECTED]>" for xemacs failed when
I did my ping test last week.

I'll be posting a list of failed addresses on Monday.  I've been waiting
to make sure there were no new bounces before posting.

  Brian
 ( [EMAIL PROTECTED] )

---
Debian GNU/Linux!  Search it at  http://insite.verisim.com/search/debian/simple



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

Re: Correct path for upgrading to libc6-dev?

[Mark Eichin]

You should certainly remove libdb-dev, since libc6-dev replaces it (as
libc6 includes libdb.)  I haven't done a libdb-altdev, and unless
someone asks probably won't bother (the libgdbm* packages are already
uploaded though.) 


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

Re: Policy wrt mail lockfile (section 4.3)

[Rob Browning]

John Goerzen <[EMAIL PROTECTED]> writes:

> However, why is it bad if a given program (like Elm-ME+ which I
> maintain, which brought the issue to my attention this time) uses
> *both* locking mechanisms?

The only problem I know of is that with two locking schemes, if all
programs don't agree on the schemes and the order of their use, you
can end up with nasty deadlock situations.

-- 
Rob


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

Re: Re^2: Status of Debian Policy

[Rob Browning]

"Scott K. Ellis" <[EMAIL PROTECTED]> writes:

> Okay, show me how to search a HTML version of the bash info documentation
> for a concept and I'll believe you.

Absolutely, anything without regex and incremental search is broken
and unacceptable for documentation purposes (IMO).

-- 
Rob


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