Re: fixhrefgz - tool for converting anchors to gzipped files

[Nicolás Lichtmaier]

On Sat, 28 Jun 1997, Christian Schwarz wrote:

> Why? The files are called ".html.gz" in the file system. Thus, these links
> are valid. We only have to implement on-the-fly decompression on some web
> servers. (This functionality could be useful for others, too, so we could
> forward our patches to the upstream maintainers of the web servers as
> well.)

 So..

---
GET http://localhost/hello.html.gz
[...]
Content-Type: text/html

[uncompressed HTML]
---

 This is non-standard... the file in the HD exists, httpd is supposed to
send it as is, and using the suffix `html.gz' for every uncompressed HTML
documentation would be strange, or even annoying for a user trying to
`save as' the file in w95.

 I think that Christoph's idea is the elegant way of doing this. The www
server could even be just something like...


#!/bin/bash
read req
read
req=${req#GET }
req=${req% HTTP*}
if [ -r $req ]; then
echo HTTP/1.0 200 OK
echo Content-type: text/html
echo
cat "$req"
else
if [ -r $req.gz ]; then
echo HTTP/1.0 200 OK
echo Content-type: text/html
echo
zcat "$req.gz"
fi
echo HTTP/1.0 404 Not found
echo Content-type: text/html
echo
echo "Can't find $req here!"
fi
-
 (with `debdoc   stream  tcp nowait  nobody  /usr/sbin/tcpd
/usr/sbin/in.debdoc')

 This is only for testing, but works fast..! A VERY small C program can do
this safely...
 And connections to that service could be restricted by default to the
local machine...

-- 
Nicolás Lichtmaier.-


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

Re: Re^2: fixhrefgz - tool for converting anchors to gzipped files

[Alex Yukhimets]

> Moin Christoph!
> 
> CL> 200Mhz Pentiums are the standard fare today. And I am running
> CL> the boa webserver for example on some low memory 486DX66s with
> 
> I'm using a 486/100 and a 486SL/33. In my opinion we should avoid using  
> the server to uncompress the files. We should find another solution.
> 
> CL> excellent performance. Boa serves directly from disk unless
> CL> there is the need to gunzip something.
> 
> Right, but does all WWW server offer this feature? We can't force the user  
> to install a specific server.

Why not? This could be a part of Debian documentation system.
The only restriction would be to run it on unconventional port
and preferably from inetd.

Alex Y.
> 
> CL> The big issue here is that you want to change an existing
> CL> very public API (http protocol) to include compression which
> CL> may be a big hassle to install on many platforms and so far
> CL> has not been an issue on the more popular platforms such as
> CL> Win95 or other Unixes.
> 
> I don't see the problem. The online help system should be designed for the  
> Debian users. If a Windows, MAC, etc user want to use the help systen he  
> has to install gzip as helper application.
> 
> But maybe we would build a compressed file system using gzip and the loop  
> back device?
> 
> cu, Marco
> 
> --
> Uni: [EMAIL PROTECTED]  Fido: 2:240/5202.15
> Mailbox: [EMAIL PROTECTED]http://www.tu-harburg.de/~semb2204/
-- 
   _   
 _( )_
( (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] .

Something broke my Netscape 3.01.

[Federico Di Gregorio]

Being bored by the Netscape 4.0b5 crashes I decided to
return to the more (?) stable Netscape 3.01; only to
discover that something I did in the past moth broke
the installation. 

Last time I used the netscape_3.01-4.deb with 3.01 package
from netscape and all went good. This time netscape hangs
the entire X session as fast as it can :(

Some ideas?

Thanx,
Federico


**
* 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: fixhrefgz - tool for converting anchors to gzipped files

[Jason Gunthorpe]

On Sat, 28 Jun 1997, Richard Kaszeta wrote:

> >Exactly. So there is no problem when using web-servers.
> 
> Umm, yes, there is.  I don't want a server running on my machine for
> *security* reasons (and one of the places I put debian machines has a
> site policy against running http servers).  I have enough problems
> with security, denial of service attacks, etc that I don't need to
> aggravate the situation by placing dozens of extra http servers on my
> net.

Just a thought, but it would be possible to make the webserver bind
the the local host address only. To the outside world it would be
exactly the same as if there was no server running at all.

Jason


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

Re: fixhrefgz - tool for converting anchors to gzipped files

[Federico Di Gregorio]

> > Err... emmh... THIRD time I write this to the list:
> > 
> > if you ask boa for the file foo.html and it does not exist,
> > boa looks for boa.html.gz and if THAT exists boa DECOMPRESS it
> > and serves you the uncompressed verion, as if foo.html existed!
> > (The browser think it has just loaded foo.html, no references to
> > foo.html.gz!)
> 
> Sorry, but this does _not_ answer my question. The question is: does "boa"
> uncompress the file if "foo.html.gz" is requested (and exists)?

I am sorry I misuderstood your question... I'll try this out with both
xemacs w3 and netscape 4.0b5 tout-de-suite...

w3 -- went bad, it asked me a file name and saved an *unzipped* copy
  of the file to it...

netscape -- idem

Mmmm... this sounds pretty logical to me, if you ask for a compressed file
you want to save it... even if the server unzips it for you... snort!

Sorry again,
Federico

PS - If you dont change the links in the HTML source all goes fine,
you'll obtain what you are looking for... I cast my vote against
the modification of every foo.html link into foo.html.gz.
**
* 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: auto compiling

[Andy Mortimer]

On Jun 28, Andreas Jellinghaus wrote
> here are my auto compiling script. there is a bit more management in it,
> and i seperated the whole thing in two scripts (the basic idea was, that
> they could run on seperated machine, or the build script could run in a
> chroot environment for security...).

Thankyou, I'm sure they're very nice. But please don't send things like
this to the list: they aren't very big on their own, but some of us do
have to pay to download email, and the more people do this, the more
stuff I *have* to download that I'll probably never use.

Instead, make up a simple package of it, and stick it up for FTP
somewhere (I would suggest experimental, but that's no longer allowed, is
it? Where's the canonical place for this sort of thing now?). Then post
your changes here, and interested people can download it themselves.

Thanks for your time,

&E

-- 
Andy Mortimer, [EMAIL PROTECTED]
http://www.poboxes.com/andy.mortimer
PGP public key available on key servers
--
Your face! I'll never see you this way again.
I captured it so perfectly, as if I knew you'd disappear away.


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

Re: dc and bc in Important?

[Mark Baker]

On Sat, 28 Jun 1997, Erik Andersen wrote:

> iThis is correct, but has the unfortunate side effect of not being portable, 
> since not all /bin/sh happin to be bash. 

No, it also works with ksh. I believe posix.2 specifies that /bin/sh has to
provide various features---basically to be a clone of ksh. Although it would
be nice for scripts to work on all versions of /bin/sh, I can't see
supporting non-POSIX machines is terribly important compared to easier to
read scripts.

(If I'm wrong, and POSIX only specifies that ksh has to do all that, then
maybe we should make ksh a symlink to bash so our scipts can use that for
everything?)


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

Re: question about dpkg-source : why does it create a copy of the orig.tar.gz file ?

[Mark Baker]

On Sat, 28 Jun 1997, Andreas Jellinghaus wrote:

> dpkg-source -x /some/path/to/file_version-rev.dsc
> 
> creates not only file_version/, but also file_version.orig.tar.gz.
> why ?

So that once you've modified it you can easily package up your changed
version.


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

Re: netscape 4.0

[Brian White]

> Do we have a netscape 4.0 install package? I cannot connect with master
> right now so I cannot check it.

There used to bea 4.0-beta installer, but it didn't work for the later
betas, so I removed it.

  Brian
 ( [EMAIL PROTECTED] )

---
   Give others some insight into YOUR pages!  http://www.verisim.com/insite/



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

Re^2: End of Documentation Discussion

[Marco Budde]

Am 28.06.97 schrieb alegre # saturn.superlink.net ...

Moin Fernando!

a> 1) The default format for online documentation is HTML. A web browser
a> (lynx) and a very small web server (boa) will be in the core distribution,
a> marked important.

But a lot of people don't want to have a WWW server on their system.

a> [A web server adds a lot of flexibility. Boa adds very little overhead. Try

But it need's a lot of power.

a> 2) Documents which can be converted on-the-fly to HTML will be installed in
a> their original format. This allows users to produce nice-looking

No, no. Have you ever used converters like latex2html? Do you know how  
much load this programs produce? Do you know how long it takes to convert  
a document?
It think this discussion unnecessary, because the policy says that HTML is  
the format for documentation.

a> [In all cases mentioned, the overhead of on-the-fly conversion is
a> acceptable enough, just a little slower than formatting man pages. Users

That's a joke.

a> Please, please. Try boa before deciding a server is too much overhead.

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^2: fixhrefgz - tool for converting anchors to gzipped files

[Marco Budde]

Am 28.06.97 schrieb clameter # miriam.fuller.edu ...

Moin Christoph!

CL> 200Mhz Pentiums are the standard fare today. And I am running
CL> the boa webserver for example on some low memory 486DX66s with

I'm using a 486/100 and a 486SL/33. In my opinion we should avoid using  
the server to uncompress the files. We should find another solution.

CL> excellent performance. Boa serves directly from disk unless
CL> there is the need to gunzip something.

Right, but does all WWW server offer this feature? We can't force the user  
to install a specific server.

CL> The big issue here is that you want to change an existing
CL> very public API (http protocol) to include compression which
CL> may be a big hassle to install on many platforms and so far
CL> has not been an issue on the more popular platforms such as
CL> Win95 or other Unixes.

I don't see the problem. The online help system should be designed for the  
Debian users. If a Windows, MAC, etc user want to use the help systen he  
has to install gzip as helper application.

But maybe we would build a compressed file system using gzip and the loop  
back device?

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^2: End of Documentation Discussion

[Marco Budde]

Am 28.06.97 schrieb schwarz # monet.m.isar.de ...

Moin Christian!

CS> > Would not texi-html or html-texi be a better name?
CS> What do the others think about this?

I would vote for /usr/doc//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: RfD: Debian is not randomly installing services

[David Frey]

> But I thought most people already complain, that there are too many
> questions in the installer scripts (postinst).
> 
> What do the others think about this?

We probably should ask all questions at the end once?

Let dpkg/diety do something like this:
0. The question was already answered during an old install (and stored
   via dtxtdb or something better) -> take that answer
1a. Otherwise ask all questions at the end of the install.
1b. Better alternative, but I don't know whether this is feasible:
Ask the questions at the beginning and configure the package
just after install. This is better, since it minimizes the time window
of unconfigured packages. This would require dpkg/diety to know what
questions which package asks (new config file)

David


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

Re: dc and bc in Important?

[Erik Andersen]

On Jun 28, Carey Evans wrote
> [EMAIL PROTECTED] (Erik B. Andersen) writes:
> 
> [snip]
> 
> > For most math, expr works just fine.  Of course, expr is limited
> > to integer math, but it works and is portable.
> 
> Actually, for integer math, bash or ksh works quite well.
> 
> bash$ a=41
> bash$ let a+=1
> bash$ echo $a
> 42
> 
> -- 
> Carey Evans  <*>  [EMAIL PROTECTED]
> 

iThis is correct, but has the unfortunate side effect of not being portable, 
since not all /bin/sh happin to be bash.  If you want to allow the program
to run on non-Linux machines, or machines running ash, etc. then expr
is the most portable way.  If you don't care about using bash-isms, which
is often the case for Debian, then what you describe above is much easier.

 -Erik

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


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

Re: Some new package proposals!

[Richard Kaszeta]

>Above all i'd like to officially provide my own original package
>"equivs-1.0.3", which is a dummy package used to circumvent dpkg's
>sometimes completely undesired dependency complaints. I made this
>package because i preferred to install and maintain a teTeX tree
>different from the official Debian version in "/usr/local/" so that i
>might take advantage of Thomas Esser's update shell scripts without
>having to worry about possibly screwing up my Debian system.

I'd be interested in this, because I already have a similar situation
that is getting worse all the time---to minimize administration
overhead I use the same files for Latex2html, teTeX, and others on
both my debian and non-debian (non-Linux even) systems.

I'd like to see what you did.

-- 
Richard W Kaszeta   Graduate Student/Sysadmin
[EMAIL PROTECTED]   University of MN, ME Dept
http://www.menet.umn.edu/~kaszeta


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

Re: fixhrefgz - tool for converting anchors to gzipped files

[Richard Kaszeta]

>Exactly. So there is no problem when using web-servers.

Umm, yes, there is.  I don't want a server running on my machine for
*security* reasons (and one of the places I put debian machines has a
site policy against running http servers).  I have enough problems
with security, denial of service attacks, etc that I don't need to
aggravate the situation by placing dozens of extra http servers on my
net.

And I shouldn't have to have one when all the documentation is locally
available on the disk.

Whatever our solution, it shouldn't require a web server to operate.

-- 
Richard W Kaszeta   Graduate Student/Sysadmin
[EMAIL PROTECTED]   University of MN, ME Dept
http://www.menet.umn.edu/~kaszeta


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

Re^2: How about e2compr? Was: fixhrefgz debate

[Marco Budde]

Am 28.06.97 schrieb clameter # miriam.fuller.edu ...

Moin Christoph!

CL> : Don't worry: gzip is part of the base system. 
CL> Your word needs to be in Microsoft's and Apple's ear.

But why should a Windows User browse the Debian online documentation?

CL> I like the idea and debianized it but after I saw the compression ratios
CL> I thought it was not yet really up for prime time.

Maybe a compressed file system is a nice idea. Maybe we could build one  
using the loopback device in the kernel and gzip?

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

NEW: debian online help system (dhelp)

[Marco Budde]

Moin Moin!

Yesterday I released the first version of my Debian online help system  
called dhelp. You can download this experimental version from:

  http://www.tu-harburg.de/~rzthmb

At the moment the system is supported by doc-linux-de and selfhtml.


What's dhelp?

 dhelp is an online help system for Debian. It builds a index of all HTML
 files in /usr/doc, if their package supports dhelp. The user doesn't need a
 WWW server to browse the HTML tree.

 You can search all HTML documents in /usr/doc using dhelp and glimpse.

The .dhelp file

 Programs supporting dhelp have to install a .dhelp file in every directory
 under /usr/doc. For every HTML file that should appear in the dhelp menu the
 .dhelp file have to contain the following section:



 Defines in which section of the index the document should be linked.
 For a German HOWTO you have to use de/HOWTO, for a English FAQ FAQ and
 so on (see /usr/lib/dhelp/HTML).

 This short text appears as link text in the index. This is typical the
 filename without the .html suffix.

 The filename of the HTML file without the path.


...


 A long description of the content of the document (optional).


 You can have several  sections in one .dhelp file. At the moment the
 dhelp standard is supported by the doc-linux-de and the selfhtml packages.

If you have any comments or problems please feel free to send me an email:
[EMAIL PROTECTED]


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: Documentation stuff

[Jim Pick]

Karl wrote:
> >  Can't apache do that?  I think there's a mod-rewrite that will do
> > what we need.  Though I suppose not everyone runs apache...  You tell
> > me and we'll both know.  I think it's a good idea to have a
> > light-weight server that can launch from xinetd.

I wrote:
> The only way to straighten out the links is to change the contents of
> the web page.  dwww does this (sort of).  I think mod-rewrite only
> works on the requested URL, not the URL's in the document.  So I
> don't think Apache can do this by itself. 

I just looked at the mod-rewrite web page - it looks like it does rewrite the
documents - pretty powerful stuff.  Sorry if I misinformed anyone...

Cheers,

 - Jim



pgp58VFG49WhH.pgp
Description: PGP signature

question about dpkg-source : why does it create a copy of the orig.tar.gz file ?

[Andreas Jellinghaus]

dpkg-source -x /some/path/to/file_version-rev.dsc

creates not only file_version/, but also file_version.orig.tar.gz.
why ?

regards, andreas


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

Re: End of Documentation Discussion

[David Frey]

On Fri, Jun 27 1997 16:10 CDT John Goerzen writes:
John, I agree with the overall contents of your remarks. Just some
remarks:
 
>  * HTML cannot do very much with formatting.
[...]
>  * HTML cannot be easily printed.
[...]
>  * HTML cannot be easily grepped.
[...]

I fully agree.

[...]
> I think that other formats have the following problems:
>  * PostScript makes very nice printed output, but it difficult to
>search and requires a fairly expensive graphical monitor to be
>able to read on-screen reasonably.
And it is generally too large for its contents.

>  * LaTeX also makes nice printed output and can be converted to
>HTML as well as other formats, but such conversion on-the-fly is
>not practical due to the huge size of the LaTeX system.
And the conversion is generally poor.

>  * GNU Info has an awkward interface and is difficult to search.
>It is also nearly impossible to print an entire manual from the
>files in the info directory.
This is not meant to be. If you want to print something, convert the
.texi files to dvi!

>  * Manpages are portable, searchable, and produce nice printed ouput
>with man -t.  However, for very long manuals, they are not
>approprriate.
I agree.

> I would suggest either of the following:
>  * DVI format.  It can be converted to HTML (I think...) and plain
Nope, not possible. In DVI you have lost the structure information.


>text on-the-fly.  It can also be converted to PostScript and
>have very nice printed documentation.
Yes.

>searchable.  Downside: conversion to PostScript requires
>significant disk resources (fonts!) and can be a lengthy process.
>On second thought, maybe DVI isn't the best choice... :-)
No. DVI is not font-independent (unfortunately).
[...] 

> All packages should ideally provide manpages (although there are a few
> exceptions).  
Rewrite this to: `All packages provide manpages'.

> Packages providing additional documentation should use
> GNU info format or LinuxDoc/SGML format.  There should be a script or
GNU texinfo (in the source package)

> program available to convert SGML to HTML on-the-fly (shouldn't be
> hard since we already have the tools to do that).  Various other
> documentation provided by the upstream author should be converted to
> SGML if possible; if not, it should be included untouched.
Probably yes, although I don't exactly love SGML.

> Just to summarize: I believe that HTML is a VERY BAD choice for
> unification of documentation for the reasons outlined above. 
Agreed.

David


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

Re: How about e2compr? Was: fixhrefgz debate

[David Frey]

> I won't use killfiles on debian-devel, and I won't ask Christoph
> to leave, so I'm leaving debian-devel myself.  Given the
> temperature of my recent input, it might be just as well, since
> I don't seem to be able to write anything but flames. If anything
> important happens, I assume I will hear about it sooner or later.

Please don't leave. Just since somebody writes incoherent stuff and
lowers the SNR it's no reason to loose the intelligent people.

David


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

Re: Documentation stuff

[Jim Pick]

>  I really want the glimpse searching that TkMan has, but within the
> XEmacs interface.  `dwww' has it, but for some reason it does not find
> as many manual entries as Tkman does for the same search.  I wonder
> why?  Perhaps a generalized perl script (or pull the tcl out of tkman
> that does it?) could do the search, and spit out the links for XEmacs
> or dwww to parse and display?

I'm changing the way dwww is put together, so any type of searching
can be added.  The way searching works right now isn't great.  Remember, 
dwww is still a work in progress.

>  I'm using W3 now, so html isn't that bad an option.  I can still have
> almost everything inside the editor interface that way.  I really love
> having `webster-www' bound to {f2}, so I can look up a word in a
> really nifty fashion.

Once dwww matures a bit, it would be nice to have an emacs interface
to it (via w3-el).  That should be easy to do.
 
>  It occured to me today that it would be good to have an rfc index,
> too.  Maybe it would have the 's link through a cgi script
> that would check for a local copy, then go get a remote one if the
> local one's not around?  Perhaps it could cache them?

I'm going to build a dwww-dev package which will make it easy to
build indexes for specific packages that work with dwww and it's
upcoming documentation menu.  It's going to work just like you say.
 
>  I've got the doc-rfc package installed.  `dwww' might call on a
> module for searching that someday, perhaps.

Perhaps sooner than you think.  :-)
 
>  Gee, maybe HTML should support alternative URL's?  The first try to
> the local copy, if that's not there, then call out to a server on the
> net.  There could be  style variables in the markup to set
> up the base directories/servers.

We had the exact same discussion on the debian-doc mailing list.
 
> Jim> 4) HTML documentation, if it exists, should be gzipped.  Lynx
> Jim> and Netscape can handle the compressed files, provided that
> Jim> the links are straightened out using a tool like fixhrefgz.
> 
>  Can't apache do that?  I think there's a mod-rewrite that will do
> what we need.  Though I suppose not everyone runs apache...  You tell
> me and we'll both know.  I think it's a good idea to have a
> light-weight server that can launch from xinetd.

The only way to straighten out the links is to change the contents of
the web page.  dwww does this (sort of).  I think mod-rewrite only
works on the requested URL, not the URL's in the document.  So I
don't think Apache can do this by itself.  

Anyways, I think using a tool like fixhrefgz to fix the links in the 
source document is required if we compress docs, since it's a nice
capability of being able to surf the documents straight off the 
hard drive, without using a web server.

As for this lightweight server stuff - I tried all the web servers
when I was testing dwww - and Apache was probably the least resource
intensive and the fastest.  Of course, it was the most configurable 
too - maybe that's why it's called a "heavyweight".

Cheers,

 - Jim




pgpjsk2Ig1HH6.pgp
Description: PGP signature

Re: fixhrefgz - tool for converting anchors to gzipped files

[Jim Pick]

[ I hate to wade into this, but  ]

> >However, as you surely know, this does not work without web server, since
> >the browsers are not looking for "foo.html.gz" if "foo.html" is
> >referenced.
> 
> Yes. But if you change the references then the web-serverws will no longer
> do on the fly decompression. They will serve the links as .gz which is not
> universally supported by web-browsers not under Debians control.

For cases where people want to use a web browser that doesn't grok gzip,
we could use dwww (I think).
 
> >Thus, we are considering changing the "href's" to "foo.html.gz" and fix
> >the browsers, where possible, to uncompress the file on-the-fly. If the
> >browser cannot be fixed (for example, if we don't have the source code) we
> >could probably offer a simple web server (e.g. boa) to do this
> >automatically.
> 
> Please think about this.
> 
> You are proposing that a web-server is supposed to be searching through
> the .html code it serves and replace all links referring to .html.gz by
> .html links?

dwww does this - it's not trivial.  This is definitely not the job of
a web server.
 
So here's my stand:

- let's munch up the links to point to ".html.gz" files.  Ugly, I know,
  and a bit of work, but then we don't need to force people to install a
  web server.  I think it's pretty important that we don't force people
  to run stuff they don't want.

- we should compress html, because lots of people (like me) are using
  Debian on machines with almost no hard drive.

- Lynx and Netscape work with the compressed links (correct me if I'm wrong),
  and we could use a web server/dwww combination to allow other browsers
  to work too.

- all the documentation isn't going to be HTML anyways - just "book-like"
  stuff.  So what's the big deal anyways.  No need to start a flame-war.

- the other option would be to leave HTML full uncompressed, which would
  be easiest

Cheers,

 - Jim




pgp18O0coF5QA.pgp
Description: PGP signature

Re: End of Documentation Discussion

[John Goerzen]

[EMAIL PROTECTED] (Karl M. Hegbloom) writes:

> > "John" == John Goerzen <[EMAIL PROTECTED]> writes:
> 
> John> * GNU Info has an awkward interface and is difficult to
> John> search.  It is also nearly impossible to print an entire
> John> manual from the files in the info directory.
> 
>  Difficult to search?  Did you read its help page at all? ('?' in the
> standalone version, 'h' inside one of the emacsen.)  Press 's', and
> enter a search string/regexp, and *bang*, you're there.  You can call

I much prefer a grep-style output, listing the line (and possibly the
context) of each hit.  That way, I know immediately which ones are
relevant instead of having to continually reposition through the document.

>  Why print it?  :-)  If you want a printed copy, you start with the
> texinfo source, and make a dvi from it.

Sometimes a printed manual is much easier to work from than an
on-screen version.

How do I make a dvi from the stuff installed into /usr/info?  AFAIK,
that is not possible...

>  I think that TeXinfo is better thought out, by people with far
> greater experience, than Linuxdoc SGML is.

There is a sgml2info program.

>  It can't be that hard to learn, either.  If you can write a program,
> you can write texinfo.

-- 
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: fixhrefgz - tool for converting anchors to gzipped files

[Christian Schwarz]

On Sat, 28 Jun 1997, Christoph Lameter wrote:

> On Sat, 28 Jun 1997, Christian Schwarz wrote:
> 
> >
> >Hi!
> >
> >Christoph, please tell us why using "fixhrefgz" on "html.gz" files does
> >not work with our web servers.
> 
> Please read the other posts.

Please answer my questions! I haven't found an answer elsewhere.

> >As far as I have understood, these web servers are so intelligent that if
> >a file "foo.html" is referenced, but only "foo.html.gz" is found, they
> >uncompress the file on-the-fly and pass the decompressed version to the
> >web browser.
> 
> Exactly. So there is no problem when using web-servers.
> 
> >However, as you surely know, this does not work without web server, since
> >the browsers are not looking for "foo.html.gz" if "foo.html" is
> >referenced.
> 
> Yes. But if you change the references then the web-serverws will no longer
> do on the fly decompression. They will serve the links as .gz which is not
> universally supported by web-browsers not under Debians control.

But most of the web browser can easily be fixed. Since "boa" is really
very small and already supports on-the-fly decompression, we can include
it even in the base system so everyone out there his it installed. It can
be started on another port than 80, I think, so it doesn't conflict with
other web servers.

> >Thus, we are considering changing the "href's" to "foo.html.gz" and fix
> >the browsers, where possible, to uncompress the file on-the-fly. If the
> >browser cannot be fixed (for example, if we don't have the source code) we
> >could probably offer a simple web server (e.g. boa) to do this
> >automatically.
> 
> Please think about this.
> 
> You are proposing that a web-server is supposed to be searching through
> the .html code it serves and replace all links referring to .html.gz by
> .html links?

No. The links are adopted from ".html" to ".html.gz" where necessary by
the _maintainer_ when the ".deb" is created. We have a Perl tool to do
this. (I posted it here, yesterday.)

> >But why can't "boa" be extended to uncompress "foo.html.gz" on-the-fly
> >when _this_ file is requested, just as "foo.html" would have been
> >requested and that file does not exist?
> 
> It can certainly do this but the links are the problem
> 
> It will still serve the .html file (now uncompressed) containing .html.gz
> links which are not understood by web-servers outside of the Debian realm.

Why? The files are called ".html.gz" in the file system. Thus, these links
are valid. We only have to implement on-the-fly decompression on some web
servers. (This functionality could be useful for others, too, so we could
forward our patches to the upstream maintainers of the web servers as
well.)

Christoph, I take your objection seriously, I don't want to include
"technical nonsense" in our policy manual. So please explain to us what
difficulties you see.


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

Some new package proposals!

[Paul Seelig]

-BEGIN PGP SIGNED MESSAGE-

Hi all!

Since quite some time i've learned to make and have been been making a
few packages the Debian way and i'm considering to contribute them to
the Debian project. These packages so far are:

 * isapnptools-1.10 (see "http://www.roestock.demon.co.uk/isapnptools/";)
 * junkbuster-1.4   (see "http://internet.junkbuster.com/";)
 * xaw3d-dev-1.3(see "ftp://ftp.x.org/contrib/widgets/Xaw3d/";)

Is there already anybody working on these packages and thus making my
efforts unnecessary?

Above all i'd like to officially provide my own original package
"equivs-1.0.3", which is a dummy package used to circumvent dpkg's
sometimes completely undesired dependency complaints. I made this
package because i preferred to install and maintain a teTeX tree
different from the official Debian version in "/usr/local/" so that i
might take advantage of Thomas Esser's update shell scripts without
having to worry about possibly screwing up my Debian system.

Then there are some Debian packages already maintained by someone else
which i've started to update with the current original upstream
releases making some unofficial Debian packages. The official Debian
package maintainers are IMHO too much behind on updating the packages
provided with Debian. These packages currently are:

 * mc-4.0 (see "http://mc.blackdown.org/mc/";), currently officially
   maintained by "Fernando Alegre <[EMAIL PROTECTED]>".

 * xkeycaps-2.35 (see "http://home.netscape.com/people/jwz/xkeycaps/";),
   currently officially maintained by ???

 * wget-1.4.5 (see "ftp://gnjilux.cc.fer.hr/pub/unix/util/wget/";),
   currently officially maintained by "J. Ramos Goncalves <[EMAIL PROTECTED]>"

 * gv-3.5.8 (see "http://wwwthep.physik.uni-mainz.de/~plass/gv/";),
   currently officially maintained by "[EMAIL PROTECTED]".

If the official maintainers can't provide more current versions and
don't mind to give their packages away i'd be delighted to take them
over in the hope to make Debian much more up to date.

All these unofficial packages can be downloaded from our institute's
FTP site at "ftp://ietpd1.sowi.uni-mainz.de/pub/debian/unofficial/";.

Note that i have no programmer's background and that i'm more or less
limited to simply repackage the original upstream sources without
touching anything of their code internals. But i don't think this
should be necessary anyway.
Cheers, P. *8^)
- --
   Paul Seelig [EMAIL PROTECTED]
   African Music Archive - Institute for Ethnology and Africa Studies
   Johannes Gutenberg-University   -  Forum 6  -  55099 Mainz/Germany
   My Homepage in the WWW at the URL http://www.uni-mainz.de/~pseelig 

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1
Comment: 'finger -l [EMAIL PROTECTED]' for public key.

iQCVAwUBM7UsBegqiw1XE3/lAQHeVAP/SgDdcKGAhoKMMz42UxwTbv48rBMSn6J9
xcDI1u7sAOkrukEc6lTMTrBUB19uIz5dPdB/3mPT4r24l63OuMt2Gm1+6uN2Pz3T
8DqLRBeV7PIINU7M6xwlwg7Nhkw5gnavFkYkDpisxiKry6oxMcAtmXM3XQszEJDb
MM4x+kKU19A=
=gmN5
-END PGP SIGNATURE-


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

Lars leaving again

[Christoph Lameter]

: Christoph Lameter:
: > There are just the elect few who can handle X.

: This comes from the man that says it's OK to require people
: to have Pentium 200's... I'm sorry, but I can't really stand
: idiots, especially ones who grasp any straw they can in order
: to win a debate and have absolutely no idea of what they're
: talking about, even if they do claim to make their living
: with it.

1. You did not understand the implications of your position at the beginning.

2. Now you are using a distortion of what I said to ridicule me.

3. You have "left" before. Maybe you should ask yourself why you cannopt
tolerate someone else showing you wrong? You have been a valuable contributor
here but noone is perfect and I have put my foot in the mouth here lots of
times, too.

Take it and move on. Next time you might be right.


-- 
--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---
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: fixhrefgz - tool for converting anchors to gzipped files

[Christoph Lameter]

On Sat, 28 Jun 1997, Christian Schwarz wrote:

>
>Hi!
>
>Christoph, please tell us why using "fixhrefgz" on "html.gz" files does
>not work with our web servers.

Please read the other posts.

>As far as I have understood, these web servers are so intelligent that if
>a file "foo.html" is referenced, but only "foo.html.gz" is found, they
>uncompress the file on-the-fly and pass the decompressed version to the
>web browser.

Exactly. So there is no problem when using web-servers.

>However, as you surely know, this does not work without web server, since
>the browsers are not looking for "foo.html.gz" if "foo.html" is
>referenced.

Yes. But if you change the references then the web-serverws will no longer
do on the fly decompression. They will serve the links as .gz which is not
universally supported by web-browsers not under Debians control.

>Thus, we are considering changing the "href's" to "foo.html.gz" and fix
>the browsers, where possible, to uncompress the file on-the-fly. If the
>browser cannot be fixed (for example, if we don't have the source code) we
>could probably offer a simple web server (e.g. boa) to do this
>automatically.

Please think about this.

You are proposing that a web-server is supposed to be searching through
the .html code it serves and replace all links referring to .html.gz by
.html links?

>But why can't "boa" be extended to uncompress "foo.html.gz" on-the-fly
>when _this_ file is requested, just as "foo.html" would have been
>requested and that file does not exist?

It can certainly do this but the links are the problem

It will still serve the .html file (now uncompressed) containing .html.gz
links which are not understood by web-servers outside of the Debian realm.

--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---


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

Could anyone please explain this to me?

[Michael Meskes]

I have a binary /foo that essantially does this:

cd /
fork;
if father exit;
setsid; 
kill all processes not in own session
umount /home

This works fine, when I simply log in and start /foo as root. However,
when I first cd /home after logging in and then start /foo it cannot
unmount /home. As you might expect by now, I have to partitions: / and
/home. That means I cannot umount /home if I started the binary with cwd
on this partition although the child process doesn't even know about the
original cwd. And my login shell ahs already been killed.

What can I do to avoid this? For my example it's not that big an issue,
but imagine /usr being mounted...

Thanks in advance
Michael

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


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

Re^2: End of Documentation Discussion

[Marco Budde]

Am 27.06.97 schrieb jgoerzen # complete.org ...

Moin John!

JG>better.  And, keep in mind that TeX and SGML/LinuxDoc can be
JG>converted to HTML on-the-fly if somebody writes a simple CGI
JG>program.

That's not true. You can't convert TeX or SGML on-the-fly, because the  
converters produce a lot of errors. And latex2html produces very high load  
on the machine.

JG>  * HTML cannot be easily printed.  Things get split about into many
JG>files, there is no printed index, page numbers, etc.

That's right, but we are talking about an online help system, aren't we?

JG>  * HTML is not easily searchable at this time.  At best, you can
JG>search the current page.  Otherwise, you have to allocate lots of
JG>disk space to some sort of index.

Please test my dhelp at

  http://www.tu-harburg.de/~rzthmb

JG>work to do.  So Lynx was removed.  Other cases where this has

You can install a restricted version of lynx (option anonymous).

JG>  * DVI format.  It can be converted to HTML (I think...) and plain
JG>text on-the-fly.  It can also be converted to PostScript and

No, there's no dvi2html convert. And such converter is nearly impossible  
to write because the DVI format doesn't contain information about the  
document structure.

JG>I believe that there are also LinuxDoc to Info converters as
JG>well as LinuxDoc to Manpage converters, but I could be mistaken.

That's right.

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: fixhrefgz - tool for converting anchors to gzipped files

[branden]

-BEGIN PGP SIGNED MESSAGE-

On Fri, 27 Jun 1997, Christoph Lameter wrote:

I can sort of see both sides of this argument.

I agree that rewriting html documents to say ".html.gz" in their hrefs is
bad.

[Lars Wirzenius wrote:]
> : Being able to read documentation directly without running
> : a web server is very important.
> 
> So far I cannot discern why.

I can, and it's a good point.

In case the machine is in single-user mode, for instance. You seldom
need the docs more than when the box is at init level 1.

I have two suggestions, and they're both going to take some work. If
someone wants to organize this, I can contribute what feeble coding
skills I have to it, because I think it's important.

1) We need to make sure boa (since it looks like that's what we'll be
using) is as close to bulletproof as it can get. It needs to stay small
and fast, and it also needs to be clean, efficient, and secure. It needs
to be as ready to do its job as telnetd. (Is boa hooked into inetd or
does it run on its own? If it's a non-forking daemon, why can't it be
grafted into inetd? Answer these questions gently, folks -- I haven't
looked into the guts of inetd.) This way we don't have to screw with
rewriting HTML files.

2) We need to hack some .gz sophistication into the file: handling code
of lynx. (I.e., you feed it a filename, it looks -- can't find it?
look for filename.gz and run gzip as a filter -- still can't find it?
smack the user around) This is probably slower and less preferred, but
necessary for single user mode. Lynx already is smart enough to gunzip
files that have a .gz extension. This doesn't sound very hard, so if
people think it's a good idea, I'll have a go at modifying the source to
do this myself. Perhaps it should look for a certain flag in its config
file before behaving this way, which we can call "debian_gz_flamewar" or
something.

Anyway, I know what happens when you step in between quarrelling giants, so
I think I'll don both a hardhat and an asbestos suit.

- --
G. Branden Robinson |  It was a typical net.exercise -- a
Purdue University   |  screaming mob pounding on a greasy spot
[EMAIL PROTECTED]  |  on the pavement, where used to lie the
http://www.ecn.purdue.edu/~branden/ |  carcass of a dead horse.

-BEGIN PGP SIGNATURE-
Version: 2.6.3a
Charset: noconv

iQCVAwUBM7UUVaiRn0nSNFD5AQH5wwQAtKT5wobK8PYMe9siVh4ujRG0cU3dxFNb
VGRniXE+2Dzd+MEeP8/loaXLFIWF24aUHb/2MkmF2mfnJW7Vj2e6e6Ernbt27R96
dB6cz985yze7LApqNmBpkwZAP91jAAWZsvbQLHcVYPDe2j9fuSBfBvJuVsKt8g3p
y0ssPLz/Ocs=
=4Vrn
-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

[Kai Henningsen]

[EMAIL PROTECTED] (Rob Browning)  wrote on 23.06.97 in <[EMAIL PROTECTED]>:

> Ricardas Cepas <[EMAIL PROTECTED]> writes:
>
> > As of current documentation, you can search only current
> > .html file. This is not very usefull.
> > Lynx ( on non-gzipped docs) is much slower then info ( on
> > gzipped).
>
> Oh, right I forgot to add "recursive" to my previous comment about
> searching.  To revise: any documentation tool that doesn't support
> incremental, recursive, and regular expression searches is not
> acceptable IMO.  As far as I know, that leaves out most html browsers
> at the moment.

Well, not if your tool can (either directly or via a server) run cgi  
scripts. You can implement searching that way.

MfG Kai


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

Re: Experiences with compiling Debian

[Kai Henningsen]

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

> If you can saturate the modem with it it would be about two hours I think;
> that would be less than two UKP here, though I understand German phone
> charges are rather higher. However, the speed of some of the connections to

Two hours phone, cheapest rate (city, 21-05), is DM 3,60. No idea how much  
UKP that are, but it's a little over US$ 6 these days.

> master I've got recently, it would take rather longer than that. I suppose I
> should read the docs on uploading via chiark some time.

I've gotten very varying rates to master. Sometimes it's pretty fast  
(though never full ISDN speed), sometimes it's slow as molasses.

MfG Kai


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

Re: Policy wrt Important (was Re: dc and bc in Important?)

[Kai Henningsen]

[EMAIL PROTECTED] (John Goerzen)  wrote on 25.06.97 in <[EMAIL PROTECTED]>:

> By the current definition of Important:
>  * Sendmail should be there instead of smail since people expect
>sendmail

Nope. The sendmail interface should be there (fr example, /usr/lib/ 
sendmail), and it is provided by smail.

Further, I believe someone told me that SCO ships some other mailer, too  
(PP? Something like that).

>  * dpkg-dev should not be there since no experienced user of another
>Unix would expect it
>  * lilo should not be there because lilo is not part of UNIX

Completely irrelevant. This is not an exclusive criterion.

> And:
>  * gcc should be in Important because everybody expects a C compiler
>  * libc5-dev should be there because everybody expects working
>header files
>  * make should be there, I expect a working make in any Unix

Development stuff has not been standard in Unix for a *long* time.

>  * lpr should be there, it is standard with just about any Unix

Maybe.

>  * netbase and netstd should both be there, they are standard
>on Unix

Probably.

>  * csh/tcsh should be there (again, standard on various Unices)

I wouldn't know, I never use those. Their design is seriously broken.

>  * The list goes on...
>
> Basically, it seems that this policy doesn't quite apply correctly.

Sure doesn't look that way to me.


MfG Kai


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

Re: fixhrefgz, boa

[Karl M. Hegbloom]

This is from the `boa' README.debian:

Transparent compressed file support
---
Boa supports transparent access to gzipped files and on the fly decompression
of the served html pages. No references need to be changes to .gz. If
a file with the extension .html cannot be found then boa will try to
find a file with .html.gz. If found this will be decompressed before 
serving it to the client.

Christoph Lameter <[EMAIL PROTECTED]>, Mon, 23 Dec 1996 20:27:43 -0800


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

Re:End of Documentation Discussion

[Fernando]

Christian Schwartz wrote:

> So I'll make another proposal. This is meant to be a "compromise" that
> everyone here should be able to accept. I will _NOT_ accept simple
> "objections" this times. If you can't live with this proposal, you'll have
> to present another formulation of a paragraph or of the whole text. 
> 

Ok, I take it. I write between brackets the rationale for each point.
It is meant as an explanation of that point, not part of the proposal itself.

1) The default format for online documentation is HTML. A web browser (lynx)
and a very small web server (boa) will be in the core distribution, marked
important.

[A web server adds a lot of flexibility. Boa adds very little overhead. Try
it and only then say something. If they are part of the core distribution, just
like man is now, then we would have gained a lot of consistency.
HTML is a standard. It's use is growing. It is not Unix-specific. It allows
distributing documents among many servers very easily. Even integrating
local documents with other stored directly in www.debian.org (like security
updates to programs. It is the way of the future.]

2) Documents which can be converted on-the-fly to HTML will be installed in
their original format. This allows users to produce nice-looking hardcopies,
while at the same time keeping consistency with the rest of the documents.
Currently, the list of formats to be installed in original form includes
texinfo, man, plain text and sgml. It does not include TeX, since the
converter is not ready for prime time.

[In all cases mentioned, the overhead of on-the-fly conversion is acceptable
enough, just a little slower than formatting man pages. Users should be able
to convert docs to their preferred format without imposing on everyone 
to carry multiplicity of formats. Printed copies are best produced from
the original format. HTML is preferred for online consultation. The original
format guarantees both uses.]

3) Documents in markup format for which no on-the-fly conversion is available
will be included in both pre-processed HTML and original format. This is a
last resort measure.

[Original format should always be included. Reasons: 1) To produce printed 
copies. 2) Because I hate Ghostscript and Xdvi. I prefer reading the
markup directly (and I am not alone.) 3) Because users might want to
process the documents automatically (search engines for example)
HTML should be included so that the documents are cleanly integrated with
the rest of the documentation and for serving them to remote (W95) systems if
necessary via http.]

4) Documents originally in binary format (PS, DVI, PDF, MS-WORD) for
which no conversion is possible should be packaged separately. A file
explaining how to get the documentation (including which programs
the user will need: ghostscript, xdvi, MS Word) and a brief summary
of the document should be included in the binary package in HTML format, or
a convertible one.

[Binary documents are useful mainly for printing and they usually have a
huge size to information ratio. I hate storing junk in my systems. Online
viewing of binary documents is awful. I hate downloading a 1MB file just to
find out it does not answer my questions. Since developers must read the
document anyway, they could make a brief summary. Sometimes that would be
enough to decide whether it is worth downloading the full document or not.
Binary docs can not be integrated with the rest, they should be discouraged.
Authors should be encouraged to give out the document in the original format
in which they wrote it, which seldom is a binary one, except for MS Word]

5) The man program should be marked optional. When a user types "man something"
and man is not installed, lynx would automatically be invoked and it would
present the HTML-converted man page the user requested.

[This is almost as fast as original man but much more powerful. As it has
little overhead, it can replace the man program. But if a user still thinks
he can't stand the small overhead, man can optionally be installed.
Man depends on groff. That's a huge overhead in both size and speed.
Nowadays no one writes groff documents other than man pages. However, groff
is needed for printing man pages, but it is a bloated solution for online
consultation.]

6) The info program should be marked optional. When it is installed, it would
compile the texinfo files and place the output in /usr/info. When it is
deinstalled, it would erase the /usr/info directory. There will be a hook
in dwww to register texinfo pages so that the info directory is kept always
current.

[The preferred online way of viewing texinfo files is through the texinfo to
HTML on-the-fly converter. Info fans who prefer the crappy info interface
should still be able to install info files, but without imposing them on
everyone. The info format is awful. Texinfo is nicer. Texinfo->HTML is
optimal. Emacs fans can use the w3 mode for viewing texinfo files. Or they
can install info and use the info m

Re: fixhrefgz - tool for converting anchors to gzipped files

[Fernando]

Lars Wirzenius wrote:

> 
> We have the rather unpleasant situation that reading documentation
> requires a web server. That's a problem. Fixing it requires changing
> the .html files.
> 

I have boa installed in a 386 SX-25 and I hardly notice any overhead.
I mean for doing the same thing I would do with just a browser, but with
more flexibility.

I seriously suggest that you try it and then decide whether a web server
is such a problem.

Regards,
Fernando


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

Re: RfD: Debian is not randomly installing services

[Martin Schulze]

Christian Schwarz writes:

> > > However, we should probably distinguish between "local daemons" and
> > > "network daemons". I think it is pretty safe to start "lpd" on every
> > > machine, since the default configuration would not accept queries from
> > > foreign hosts. If I install the "lpd" package, I would not like to be
> > > asked whether this daemon should be started!
> > 
> > Really?  I haven't noticed that there is a switch at lpd similar to
> > '-r' on syslogd.  Nevertheless, even local daemon can cause security
> > problems and if the user doesn't need it why should that daemon be
> > started?
> > 
> > I could live with your addition but I would like to be prompted,
> > too.
> 
> But I thought most people already complain, that there are too many
> questions in the installer scripts (postinst).

There might be too many questions, but I believe these new ones are
essential.

Hmm, if there are really too much questions we could implement a global
installation option 'always_start_daemon' which is defaulted to 'no'
as well as add an [O]ption section to dselect and a well-defined interface
to the options.

Regards

Joey

-- 
  / Martin Schulze  *  [EMAIL PROTECTED]  *  26129 Oldenburg /
 / The MS-DOS filesystem is nice for removable media /
/ -- H. Peter Anvin /


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

Re: wwwoffle 1.2a

[Federico Di Gregorio]

Yes, I packaged 1.2a and I am waiting for the account on master
so I can upload it. I tryied to upload it to chierk but I cant
get a good connection (or a connection at all...).
Is there another site that accepts anonymous connections and
lets you upload debian packages? I that case I will upload it as
fast as I can...

Bye,
Federico

> I am no longer the maintainer for wwwoffle. Talk to 
> Federico Di Gregorio <[EMAIL PROTECTED]>
> 
> 
> On Thu, 26 Jun 1997, J Hulley-Miller wrote:
> 
> >Greetings,
> >
> >Do you have 1.2a packaged perchance ? If so, please attach it or 
> >provide a URL. Thanks...
> >
> >Jonathan

**
* 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: RfD: Debian is not randomly installing services

[Christian Schwarz]

On Sat, 28 Jun 1997, Martin Schulze wrote:

> Christian Schwarz writes:
> 
> > > > The situation looks completely different if the server has its own
> > > > package, like `msqld' for the server and `msql' for the client.
> > > 
> > > Not really -- the user should still be prompted (or have some control
> > > over it) because the daemon package probably contains the
> > > *documentation* for the daemon!  I should be able to install a package
> > > in order to read the docs, and not have to run it...
> > 
> > Seconded.
> > 
> > However, we should probably distinguish between "local daemons" and
> > "network daemons". I think it is pretty safe to start "lpd" on every
> > machine, since the default configuration would not accept queries from
> > foreign hosts. If I install the "lpd" package, I would not like to be
> > asked whether this daemon should be started!
> 
> Really?  I haven't noticed that there is a switch at lpd similar to
> '-r' on syslogd.  Nevertheless, even local daemon can cause security
> problems and if the user doesn't need it why should that daemon be
> started?
> 
> I could live with your addition but I would like to be prompted,
> too.

But I thought most people already complain, that there are too many
questions in the installer scripts (postinst).


What do the others think about this?


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: Looking for help. . .

[Carey Evans]

[EMAIL PROTECTED] (Karl M. Hegbloom) writes:

[snip]

>  Unless you really need windows for business or something, the best
> thing to do is just install Linux, and tell `fdisk' (the Linux one) to
> just turn it into an ext2fs partition.

Of course, you really mean to turn it into one ext2fs partition and
one small swap partition.  And with the bigger disks available now, it
can help to make a third even smaller partition at the _start_ of the
disk for /boot, to keep LILO happy.

On the original posters' query about Partition Magic: If you have it
make some free space on your disk, you can use Linux fdisk to create
the new Linux partitions there.  You will of course have backed up
your Windoze files anyway, since by Murphy's Law the effort you put
into this will be wasted.  Once you install Debian (good choice) you
can "mount" your old Windoze partition and read all your files from it
very easily.

-- 
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: End of Documentation Discussion

[Federico Di Gregorio]

> One questions remains: Is it possible to browse "html.gz" files _without_
> a CGI script with the usual HTML browsers (Netscape, lynx)? If so, we'll
> make it policy to gzip all html files and to adopt the references. If not,
> we'll have to install all html files gezipped--or add a cgi capable web
> server to the base system.
It's not possible if you dont coverto all the *.html links to
*.html.gz. BUT we dont need CGI scripts... the boa webserver 
(as I noted in a previous post) has the ability to de-compress
gzip-ed files before sending them to the browser and is small
enough to fit on the base disk set (.deb size = 55802 bytes, 
inst size = 151).

Bye bye,
Federico




**
* 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: Calendars

[Kai Henningsen]

[EMAIL PROTECTED] (joost witteveen)  wrote on 22.06.97 in <[EMAIL PROTECTED]>:

> > > Posix time includes leap-year-days, but does not include the finer
> > > resolution of leap-seconds. 21 leap-seconds (number 22 is coming up)
> > > have been added since New Years Day 1970 to keep clock time in synch
> > > with astronomical time.
> >
> > Actually, it probably was a bad idea to use "leap" for both. Leap days are
> > fixed by calendar design. Leap seconds are inserted or deleted (both are
> > possible) after comparing the atomic clocks to astronomical observations,
> > with no predictability at all. Two very different animals.
>
> well, depends on how you see it. The before 1752, century turns were

Make that 1582, when Gregor decided on it. Or maybe 1918, when the last  
country switched over.

> still all leap years. Now, we know the length of a year/day better, and
> only 1 in for of those turn-of-century years are leap years. Maybe that
> will change again.

And before Gaius Iulius reformed the calendar, no year had leap days.

But that's the important part. All these are calendar reforms. Leap second  
aren't calendar reforms.

> And about the seconds: we (currently, prossibly always)
> simply cannot calulate the length of a day accurately enough to know
> well in advance when to insert them. But I'd say the two animals are
> at least related, if not mother and daughter.

I think you got the reasoning wrong there. It's not that we can't  
calculate exactly enough, it's that the rotational speed of the earth  
isn't constant. It's modified by lots of influences, and these days, we  
can measure the effect.

No calendar change in history was related to changes of earth's rotational  
speed.

So, no, they most definitely are not closely related.

As to future changes, we know that the Gregorian calendar has an error of  
about one day in 3000 years; that is, the Gregorian year averages to  
365.2425 days, whereas it should be 365.2422 days. I don't know if anyone  
will ever care about that.
However, note that the difference is roughly 1/3000, whereas the leap  
second difference is roughly 1/9.

MfG Kai


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

Re: Calendars

[Kai Henningsen]

[EMAIL PROTECTED] (Alex Yukhimets)  wrote on 22.06.97 in <[EMAIL PROTECTED]>:

> > I'd expect that to be a problem for people in both parts of Jerusalem, for
> > example.
> >
>
> I am very sorry but I just don't think that debian-devel is a proper place
> to share the (mis)understanding of the locations of political and national
> borders. This could under some circumstances be very insulting in
> unpredicted way.
>
> Thank you.

I was talking about calendars, not about Israels blatant disregard for  
international law.

MfG Kai


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

Re: Debian-Policy Manual

[Kai Henningsen]

[EMAIL PROTECTED] (Francesco Tapparo)  wrote on 22.06.97 in <[EMAIL PROTECTED]>:

> On Jun 22, Kai Henningsen wrote
> > [EMAIL PROTECTED] (Christian Hudon)  wrote on 21.06.97 in
> > <[EMAIL PROTECTED]>:
> >
> > > Newbies should *not* be dumped into vi by default. It's just too
> > > user-hostile.
> >
> > There's only one text mode editor that's not just as user-hostile, and
> > that's ae. That one seems to be completely unacceptable as a default to
> > most non-newbies.
> >
>
> Joe is much better, IMO, and it's very newbie-friendly.

Well, it does mention how to get help, yes. And I do like it.

However, I fear most non-newbies won't like it any better than ae.


MfG Kai


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

Re: Calendars

[Kai Henningsen]

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

> From: [EMAIL PROTECTED] (Kai Henningsen)
> > Not everyone switched in 1752.
>
> This is Pope Gregory's calendar reform, isn't it? I think it goes back a
> century or more before 1752.
>
> > Actually, it probably was a bad idea to use "leap" for both. Leap days are
> > fixed by calendar design. Leap seconds are inserted or deleted (both are
> > possible) after comparing the atomic clocks to astronomical observations,
> > with no predictability at all. Two very different animals.
>
> Speaking of predictability, isn't 2000 a leap year? The rule is different
> for the turn of the century.
>
> System time should be counted as the number of seconds _elapsed_ since New
> Year's day 1970 (what Unix uses) or some other fixed point. These days it's
> the number of seconds elapsed minus the leap seconds, which is sort of
> silly.

Well, all the arguments have been made a dozen times over, and I'm still  
firmly convinced that your attempt to put some nebulous philosophy over  
useability is the silly one.

MfG Kai


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

Re: End of Documentation Discussion

[Christian Schwarz]

On Fri, 27 Jun 1997, Santiago Vila Doncel wrote:

> On Fri, 27 Jun 1997, Christian Schwarz wrote:
> 
> > "objections" this times. If you can't live with this proposal, you'll have
> > to present another formulation of a paragraph or of the whole text.
> >
> > [ ... ]
> >
> > /usr/doc//html-info/
> 
> Would not texi-html or html-texi be a better name?

What do the others think about this?



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: fixhrefgz - tool for converting anchors to gzipped files

[Christian Schwarz]

Hi!

Christoph, please tell us why using "fixhrefgz" on "html.gz" files does
not work with our web servers.

As far as I have understood, these web servers are so intelligent that if
a file "foo.html" is referenced, but only "foo.html.gz" is found, they
uncompress the file on-the-fly and pass the decompressed version to the
web browser.

However, as you surely know, this does not work without web server, since
the browsers are not looking for "foo.html.gz" if "foo.html" is
referenced.

Thus, we are considering changing the "href's" to "foo.html.gz" and fix
the browsers, where possible, to uncompress the file on-the-fly. If the
browser cannot be fixed (for example, if we don't have the source code) we
could probably offer a simple web server (e.g. boa) to do this
automatically.

But why can't "boa" be extended to uncompress "foo.html.gz" on-the-fly
when _this_ file is requested, just as "foo.html" would have been
requested and that file does not exist?


Thanks,

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: End of Documentation Discussion

[Karl M. Hegbloom]

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

John> * GNU Info has an awkward interface and is difficult to
John> search.  It is also nearly impossible to print an entire
John> manual from the files in the info directory.

 Difficult to search?  Did you read its help page at all? ('?' in the
standalone version, 'h' inside one of the emacsen.)  Press 's', and
enter a search string/regexp, and *bang*, you're there.  You can call
the search function from your own lisp code too.  There's a `libc'
program for the emacsen that lets you put the cursor on a C function
or symbol, and press a few keys, and *presto*, the info is before your
eyes.  It's really cool; I'm learning faster because of it.  Having
everything in the (programmable) editor like that is very handy.

 Why print it?  :-)  If you want a printed copy, you start with the
texinfo source, and make a dvi from it.

 I think that TeXinfo is better thought out, by people with far
greater experience, than Linuxdoc SGML is.

 It can't be that hard to learn, either.  If you can write a program,
you can write texinfo.

-- 
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: Documentation stuff

[Karl M. Hegbloom]

> Jim Pick writes:

Jim> dwww is meant to integrate the existing documentation
Jim> formats for convenience, but not replace all of them.

Jim> 2) All the documentation should be viewable via HTML if dwww
Jim> is installed - but it shouldn't be necessary to have HTML
Jim> versions of something that is already in info or man format.
Jim> If there is an HTML version that looks better, by all means
Jim> include it (if it's small, put it in the same package,
Jim> otherwise use a separate package).

 I agree.  I prefer to use Info in XEmacs to html, whenever
possible...  I think that the Info browser and TeXinfo could be
improved.  Someday I'll look at HyperTeX, and learn about that.  It
might be neat to have pop-up glossary balloons, and active URL's in
info.  If you don't use Emacs or XEmacs, you're not serious anyhow.

 I really want the glimpse searching that TkMan has, but within the
XEmacs interface.  `dwww' has it, but for some reason it does not find
as many manual entries as Tkman does for the same search.  I wonder
why?  Perhaps a generalized perl script (or pull the tcl out of tkman
that does it?) could do the search, and spit out the links for XEmacs
or dwww to parse and display?

 I'm using W3 now, so html isn't that bad an option.  I can still have
almost everything inside the editor interface that way.  I really love
having `webster-www' bound to {f2}, so I can look up a word in a
really nifty fashion.

Jim> 3) I'd recommend using something like Debiandoc-SGML for
Jim> documentation written directly for Debian.  But this should
Jim> be optional.  I like it because it will work nicely with dwww
Jim> (and without), plus it is fairly consistent, and can be
Jim> converted to multiple formats.  We discussed some nice
Jim> enhancements for it on the debian-doc mailing list which
Jim> should work quite nicely.

 It occured to me today that it would be good to have an rfc index,
too.  Maybe it would have the 's link through a cgi script
that would check for a local copy, then go get a remote one if the
local one's not around?  Perhaps it could cache them?

 I've got the doc-rfc package installed.  `dwww' might call on a
module for searching that someday, perhaps.

 Gee, maybe HTML should support alternative URL's?  The first try to
the local copy, if that's not there, then call out to a server on the
net.  There could be  style variables in the markup to set
up the base directories/servers.

Jim>  HTML shouldn't be used to replace info files shipped with
Jim> GNU software either.

 Right.  The two ideal documantation formats should coalesce and
become something better.

Jim> 4) HTML documentation, if it exists, should be gzipped.  Lynx
Jim> and Netscape can handle the compressed files, provided that
Jim> the links are straightened out using a tool like fixhrefgz.

 Can't apache do that?  I think there's a mod-rewrite that will do
what we need.  Though I suppose not everyone runs apache...  You tell
me and we'll both know.  I think it's a good idea to have a
light-weight server that can launch from xinetd.

Q: How do I get netscape to gunzip again???  It used to let me view
gzipped html, but now it won't do it.  I just tried W3, and it does
the same thing.  What's the MIME types recipe?

Jim> 5) It would be nice if Diety could install just
Jim> documentation, or just the binaries, and no documentation.

 Yes!

Jim> 6) dwww will let us serve documentation directly off of an
Jim> external site, so it would be nice to have a way of
Jim> installing the packages with no documentation at all.

 Sound's good... what about the ability to install a documentation
server on a LAN too?

Jim> 7) Cacheing - I'm going to split the cacheing in dwww into a
Jim> separate package.  That way, it should be easy to improve it,
Jim> not use it, or use something like squid instead.

 Ok here.  :-)(back to the bat book.)


-- 
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: RfD: Debian is not randomly installing services

[Martin Schulze]

Mark Eichin writes:
> 
> > The situation looks completely different if the server has its own
> > package, like `msqld' for the server and `msql' for the client.
> 
> Not really -- the user should still be prompted (or have some control
> over it) because the daemon package probably contains the
> *documentation* for the daemon!  I should be able to install a package
> in order to read the docs, and not have to run it...

Hmm, sounds reasonable.

Regards

Joey

-- 
  / Martin Schulze  *  [EMAIL PROTECTED]  *  26129 Oldenburg /
 / The MS-DOS filesystem is nice for removable media /
/ -- H. Peter Anvin /


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

auto compiling

[Andreas Jellinghaus]

hy.

here are my auto compiling script. there is a bit more management in it,
and i seperated the whole thing in two scripts (the basic idea was, that
they could run on seperated machine, or the build script could run in a
chroot environment for security...).

i only tried to compile my own packages (i don't have a debian source
mirror here, and also no access to a pc with such a mirror).

i started the scripts with :
cd /home/devel

if [ -f builder.pid ] 
then
kill `cat builder.pid`
rm builder.pid
fi

if [ -f manager.pid ] 
then
kill `cat manager.pid`
rm manager.pid
fi


bin/builder -W/home/devel/Work > debug.builder 2>&1 &
bin/manager -I/home/devel/Incoming -O/home/devel/Done -W/home/devel/Work \
-F/home/devel/Failed -L/home/devel/Logs > debug.manager 2>&1 &

regards, andreas
#!/bin/bash 

set -e

version="0.1"

progname="`basename \"$0\"`"

pidfile="${progname}.pid"
workdir=""
arch="`dpkg --print-architecture`"
clean=""
target="binary"
targetparam=""
makeflags=--silent

usageversion () {
cat >&2 &2 "${progname}: unknown option or argument $1"
usageversion; exit 2 ;;
esac
shift
done

if [ -z "${workdir}" ]; then
echo "you must specify a workdir with -W" >&2
exit 1
fi

if ! [ -d ${workdir} ]; then 
echo "no such directory : ${workdir}" >&2
exit 1
fi

if [ -e "${pidfile}" ]; then
echo "pidfile already exists : ${pidfile}" >&2
exit 1
fi

trap "rm -f ${pidfile}" 1 2 3 15
echo $$ > ${pidfile}

if [ -n "${makeflags}" ]; then export MAKEFLAGS="${makeflags}"; fi

cd ${workdir}

while true
do
while ! test -e todo 
do
sleep 10
done

file="`cat todo`"
fdir="`dirname ${file}`"
file="`basename ${file}`"
package="`echo ${file} |cut -d_ -f1`"
suffix="`echo ${file} |cut -d_ -f2`"
version="`basename ${suffix} .dsc`"
dirver="`echo ${version}|cut -d- -f1`"
dir="${package}-${dirver}"
changes="${package}_${version}_${arch}.changes"
orig="${package}_${dirver}.orig.tar.gz"
logfile="${package}_${version}_${arch}.buildlog"
cleanlog="/dev/null"

rm todo

if [ -n "${clean}" ]; then cleanlog="${logfile}" ; fi

rm -rf *

echo "BUILD : extracting ${package} ${version}" >> ${logfile}

if ! dpkg-source -x ${fdir}/${file} 2>&1 >> ${logfile}
then
rm -rf ${dir}
echo "BUILD : Couldn't extract ${file}" >> ${logfile}
echo "BUILD : failed ${package} ${version}" >> ${logfile}
echo "failed" > result
continue
fi

rm ${orig}

echo "BUILD : building ${package} ${version}" >> ${logfile}

cd ${dir}

if ! debian/rules build 2>> ../${logfile} >> ../${logfile}
then
build clean 2>> ../${cleanlog} >> ../${cleanlog}
cd ..
rm -rf $DIR
echo "BUILD : Couldn't compile ${file}" >> ${logfile}
echo "BUILD : failed ${package} ${version}" >> ${logfile}
echo "failed" > result
continue
fi

echo "BUILD : packaging ${package} ${version}" >> ../${logfile}

if ! build $target 2>> ../${logfile} >> ../${logfile}
then
build clean 2>> ../${cleanlog} >> ../${cleanlog}
cd ..
rm -rf ${dir}
echo "BUILD : Couldn't package ${file}" >> ${logfile}
echo "BUILD : failed ${package} ${version}" >> ${logfile}
echo "failed" > result
continue
fi

echo "BUILD : changes file ${package} ${version}" >> ../${logfile}

if ! dpkg-genchanges -b ${targetparam} > ../${changes} 2>> ../${logfile}
then
build clean 2>> ../${cleanlog} >> ../${cleanlog}
cd ..
rm -rf $DIR ${changes}
echo "BUILD : Couldn't generate changes ${file}" >> ${logfile}
echo "BUILD : failed ${package} ${version}" >> ${logfile}
echo "failed" > result
continue
fi

  

Q/A group: please consider makedev and isdnutils for 1.3.x

[Andreas Jellinghaus]

i have uploaded a new isdnutils and a new makedev.

makedev: changed /dev/console and /dev/tty0 policy 
(maybe it should go into stable. but xserver* can also
 fix this bug with old makedev).

isdnutils: beta1 release of the new isdnutils. there are worlds between
the old 2.0 release and this one, tens of bugs have been fixed in the
upstream release, and now there is at least some documentation. 

everyone using isdn should use the new kernels (2.0.30-7 or 29-7),
because there are lots of bug fixes (closed memory leaks etc.). and with
the new kernel, you need the new isdnutils (e.g. old ipppd will not run
with 2.0.29 AFAIK).

new isdnutils package will replace isdnutils, isdnlog and vbox.  there
is a bug in dpkg, so only the first package gets replaced, and dpkg may
fail to install the new isdnutils package. i don't know how we can fix
this.

please consider puting makedev and isdnutils in debian 1.3.X.

thanks.

andreas jellinghaus


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

Re: Looking for help. . .

[Karl M. Hegbloom]

> "Cory" == Cory Hafele <[EMAIL PROTECTED]> writes:

Cory> I'm willing to format the whole drive if need be.

That's the right idea. :-)

 Unless you really need windows for business or something, the best
thing to do is just install Linux, and tell `fdisk' (the Linux one) to
just turn it into an ext2fs partition.

 That's what I did about 2 years ago.  I've never regretted it.

 Welcome to the Debian GNU/Linux 'volunteer fire department'!  Learn
how, and grab a package. :-)


-- 
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: Bug#10902: Device driver 3c59x hangs

[Herbert Xu]

Mark Burgess wrote:
> 
> Hello. I am grief stricken because I cannot get debian running
> on my new PC which has a 3 com 905 XL netcard. As I understand
> it the correct driver for this card is the module 3c59x.
> This is the only driver which will install.
> 
> INstallation proceeds fine, and ifconfig -a shows that the
> interface comes up, but there is no contact with the network
> via the 10baseT connection. The same PC will run NT (spit spit).
> 
> I have seen a version of RedHat linux 2.4 run this driver
> without problems and have seen earlier complaints about
> problems with the driver. Perhaps the latest (fixed) version
> could be made available on the debian boot disks as soon
> as possible. But I don't want redhat!

The version we have is newer than the one in the standard kernel but is
not the latest one.  What do people think of v0.41 (the latest one)? Is
it stable enough compared to 0.30?
-- 
Debian GNU/Linux 1.3 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://greathan.apana.org.au/~herbert/
PGP Key: http://greathan.apana.org.au/~herbert/pubkey.txt


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

Re: RfD: Debian is not randomly installing services

[Martin Schulze]

Christian Schwarz writes:

> > > The situation looks completely different if the server has its own
> > > package, like `msqld' for the server and `msql' for the client.
> > 
> > Not really -- the user should still be prompted (or have some control
> > over it) because the daemon package probably contains the
> > *documentation* for the daemon!  I should be able to install a package
> > in order to read the docs, and not have to run it...
> 
> Seconded.
> 
> However, we should probably distinguish between "local daemons" and
> "network daemons". I think it is pretty safe to start "lpd" on every
> machine, since the default configuration would not accept queries from
> foreign hosts. If I install the "lpd" package, I would not like to be
> asked whether this daemon should be started!

Really?  I haven't noticed that there is a switch at lpd similar to
'-r' on syslogd.  Nevertheless, even local daemon can cause security
problems and if the user doesn't need it why should that daemon be
started?

I could live with your addition but I would like to be prompted,
too.

Regards

Joey

-- 
  / Martin Schulze  *  [EMAIL PROTECTED]  *  26129 Oldenburg /
 / The MS-DOS filesystem is nice for removable media /
/ -- H. Peter Anvin /


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

Re: RfD: Debian is not randomly installing services

[Christian Schwarz]

On 27 Jun 1997, Mark Eichin wrote:

> 
> > The situation looks completely different if the server has its own
> > package, like `msqld' for the server and `msql' for the client.
> 
> Not really -- the user should still be prompted (or have some control
> over it) because the daemon package probably contains the
> *documentation* for the daemon!  I should be able to install a package
> in order to read the docs, and not have to run it...

Seconded.

However, we should probably distinguish between "local daemons" and
"network daemons". I think it is pretty safe to start "lpd" on every
machine, since the default configuration would not accept queries from
foreign hosts. If I install the "lpd" package, I would not like to be
asked whether this daemon should be started!


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: dc and bc in Important?

[Carey Evans]

[EMAIL PROTECTED] (Erik B. Andersen) writes:

[snip]

> For most math, expr works just fine.  Of course, expr is limited
> to integer math, but it works and is portable.

Actually, for integer math, bash or ksh works quite well.

bash$ a=41
bash$ let a+=1
bash$ echo $a
42

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

Looking for help. . .

[Cory Hafele]

I've recently subscribed to a couple of your mailing lists to find out more
about Linux.  I have average to above "average" knowledge of the computer
using DOS, and windows95.  I'm going to be installing Linux on my hard drive
using Partition Magic.  I've visited several sites that offer Linux, and I
must say that Debian is very impressive to me.  I will probably be using
Debian on my computer.  You probably get this question all the time, but I
know nothing about programing as of yet.  I'm really trying to get started
and have gone into many chat rooms to ask question about installing linux
and what do I do first, and what do I do now type thing.  I haven't gotten
anywhere.  The main reason I'm installing Linux is because I am a mudder...
have been for years.  I want to start my own mud, and the only way I can
program source code is with Linux, or a good c++ compiler.  I'm told that
using Linux is the easiest way.  Sorry for the much chatter here... here's
my question.  What advice can you give to me?  I haven't done anything but
download a few zipped files so far.  I haven't even installed partition
magic yet.  I've been afraid that once I install partition magic... I won't
be able to access the zip'd files that I have saved in various folders in
windows.  Can I do this?  How do I put Linux specifically on my hard drive?
I'm willing to format the whole drive if need be.  Anyway, was curious if
you could give me some advice.

Thank you for your time,

Cory


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

Re: How about e2compr? Was: fixhrefgz debate

[Alex Yukhimets]

> I am really irritated by such insistence on a view "my box at home" and 
> nothing
> else matters. We are not all just hacking for fun at home. Some people 
> actually
> make their living with the stuff.
> 

I completely agree with you. But this is just some kind of a Debian
"sickness" not to think of this kind of users. I don't understand why we
should pay more attention to the "play at home" Un*x newbies than to the
people who are trying to "make their living with the stuff". 

Please, think about it guys.

Alex Y.

P.S. Yes, I *am* that kind of user.
-- 
   _   
 _( )_
( (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: End of Documentation Discussion

[John Goerzen]

Richard Kaszeta <[EMAIL PROTECTED]> writes:

> A good format, but the problem here is that the LinuxDoc/SGML source
> isn't very useful by itself, it has to be converted to another source
> to be useful.

I don't see a big problem with that because, as I said, the conversion
programs are small and fast.

> Basic fact of the matter is that we don't have a perfect solution, all
> of them have problems.  But I'd say of the available options HTML at
> least provides:
> 
> 1. A wide variety of browsers (although as discussed many times, none
> with quite the desired feature base).

We really have only one of quality (Netscape), and it is non-free.
Lynx is OK for terminals, but its interface is not as good as it could
be.

> 2. A wide variety of possible formats that can result in HTML.

> On the issue of the difficulty of doing good searches on html... Since
> we plan on distributing as much documentation as possible in html
> format, can't we simply configure 'glimpse' to provide much of this
> missing functionality?

But the problem here is that glimpse requires a lengthy process of
creating an index, space for an index, etc.  This index must also be
updated (either via cron or whenever a package is installed or
removed).  This is not acceptable in many situations.  I currently
have two older machines (a 386 and a 486/33) running Debian.  One of
the best things about it is that it requires little space and few
resources.  Glimpse would change that.  It would suck up several
megabytes at least.  It would require lengthy update processes, etc.

And, there are much more serious problems with HTML.  The most serious
is that it is extremely difficult, if not impossible, to produce
coherent printed output from documentation done in HTML.  This is, in
large part, due to the fact that HTML documentation tends to be split
up into many small files.  There also can be no real index for the
printed copy.

While HTML is good for online viewing with certain conditions, it is
not suited to a general documentation format.

-- 
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 Important (was Re: dc and bc in Important?)

[John Goerzen]

Who said anything about "working"?



Mark Eichin <[EMAIL PROTECTED]> writes:

> >  * gcc should be in Important because everybody expects a C compiler
> 
> Maybe they expect it, but these days, they don't *get* one... none of
> solaris, hpux, irix ship with a [working] C compiler...
> 

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

Documentation stuff

[Jim Pick]

Hi!

Sorry for being absent from most of the conversation, and not getting
my latest release of dwww out...  - I was working in Vancouver last 
week, came back, got sick, one of my main modems burnt out (lightning?),
I replaced it, upgraded my server, messed up PPP, didn't configure
the modem correctly, clients calling me up giving me more work, etc,
etc, etc...  - so I'm way behind schedule on dwww.

Here's my ideas for the documentation stuff:

1)  a web server, dwww, etc. should be optional - not a core part
of the system.  I hope to fix up dwww so that it is much faster,
powerful, nice, etc.  - but the HTML documentation should be
browseable without having all this stuff installed.

dwww is meant to integrate the existing documentation formats
for convenience, but not replace all of them.

2)  All the documentation should be viewable via HTML if dwww is
installed - but it shouldn't be necessary to have HTML versions
of something that is already in info or man format.  If there is an
HTML version that looks better, by all means include it (if
it's small, put it in the same package, otherwise use a
separate package).

3)  I'd recommend using something like Debiandoc-SGML for documentation
written directly for Debian.  But this should be optional.  I like
it because it will work nicely with dwww (and without), plus it is 
fairly consistent, and can be converted to multiple formats.  We 
discussed some nice enhancements for it on the debian-doc mailing 
list which should work quite nicely.

Oh yeah, we still need separate /usr/doc//README files,
and man pages too...  HTML shouldn't be used to replace these.
HTML shouldn't be used to replace info files shipped with GNU
software either.

4)  HTML documentation, if it exists, should be gzipped.  Lynx and
Netscape can handle the compressed files, provided that the links
are straightened out using a tool like fixhrefgz.  I was going to
stick that tool into a "dwww-dev" package + possibly some other
ones.  (I've got a few Debian installations on 386's and 486's
with less than 150MB of disk total)  - I'm going to experiment
with straightening out the jdk1.1 documentation...

e2compr isn't really an option, in my opinion, since it restricts 
the portability of the entire system.   

5)  It would be nice if Diety could install just documentation, or
just the binaries, and no documentation.

6)  dwww will let us serve documentation directly off of an external
site, so it would be nice to have a way of installing the packages
with no documentation at all.

7)  Cacheing - I'm going to split the cacheing in dwww into a separate
package.  That way, it should be easy to improve it, not use it,
or use something like squid instead.

That's it for now...

Cheers,

 - Jim





pgpw3ccz7lJlO.pgp
Description: PGP signature

Re: How about e2compr? Was: fixhrefgz debate

[Christoph Lameter]

: I don't get it -- why would we care if gzip is anywhere *other* than
: the debian base system?  It's not like there's any way (yet) to
: install/extract these packages on a mac, though you can sort of hack
: them open on a win32 box.  We're concerned with users who *have
: actually installed debian* reading the documentation *on that debian
: system*.  The rest is spurious.

There are just the elect few who can handle X. The rest of the world uses
Web-Browsers from commercial Operating systems to access information from Unix
(or Linux) servers. The user who has installed Debian might not be using
that box to read the documentation on. I have NO SYSTEM AT ALL on Campus
that could do what you suggest. I have an X system at home allright but even
at home I have now a Win95 box as a front end to my Linux Server. There are
barely any commercial apps for X and I need to do some work

We use Linux as a Back-End for our Campus Servers and many other people do the
same. They do not run X and they also wish to be able to access documentation
in a easy way. Requiring a gzip on the Operating Systems they use is a major
stumbling block especially for those first timers which are critical to the
success of such projects.

I am really irritated by such insistence on a view "my box at home" and nothing
else matters. We are not all just hacking for fun at home. Some people actually
make their living with the stuff.

-- 
--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---
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: How about e2compr? Was: fixhrefgz debate

[Mark Eichin]

> : Don't worry: gzip is part of the base system. 
> Your word needs to be in Microsoft's and Apple's ear.

I don't get it -- why would we care if gzip is anywhere *other* than
the debian base system?  It's not like there's any way (yet) to
install/extract these packages on a mac, though you can sort of hack
them open on a win32 box.  We're concerned with users who *have
actually installed debian* reading the documentation *on that debian
system*.  The rest is spurious.


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

Re: debmake

[Mark Eichin]

> Apparently,
> the case got taken to court and FreeBSD won against the gov't.

I've heard no evidence of this (and would find it *very* unlikely.) In
fact, the FreeBSD web pages still tell people to go to sites in South
Africa, Brazil, or Finland for the "eBones" and "secure" packages...
Even better, the handbook (updated 25 June 1997) still specifically
says "don't pull these two packages from the US..."

> We dont have the same crypto restrictions you guys do.

True -- but you also can't export stuff that has been exported from
the US (ie. you can mirror the non-us stuff from germany, but you
can't "backdoor" stuff out of the US even though you can legally get
it from here.)


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

Re: How about e2compr? Was: fixhrefgz debate

[Christoph Lameter]

In article <[EMAIL PROTECTED]> you wrote:

:   Christoph> You want me to run around Campus installing gzip on 300 machines
:   Christoph> because those users are not able to?

: Don't worry: gzip is part of the base system. 

Your word needs to be in Microsoft's and Apple's ear.

: Why don't we test e2compr better? Or zlib-compressed filesystem? That way we
: can have the cake (docs are compressed) and eat it too (no changes required
: to the docs).

e2compr compression is really bad. Just around 20% for most files.

I like the idea and debianized it but after I saw the compression ratios
I thought it was not yet really up for prime time.

Given the prices of harddrives my take on things is: Forget about all
compression and make that something dpkg can do on the fly if necessary and
configured by the sysadmin.
I often wish I had no gzipped files around. Would make life easier for 
maintainers
and also for users.

IMHO All compression should be transparently done. I wish e2compr was better.

-- 
--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---
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: XFree86 build info

[Mark Eichin]

> 1. Does debian include any additional drivers on top of the
> standard XFree source?

Nope -- you can look at the xfree86_3.3-3.diff.gz and see *exactly*
what changes we've made, but they're mostly configuration.

> 2. Does anyone know of similar development work elsewhere?
> I've contacted Xfree at xfree86@xfree86.org but not got

That's certainly the right place to ask.
_Mark_ <[EMAIL PROTECTED]>
The Herd of Kittens
Debian X Maintainer


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

How about e2compr? Was: fixhrefgz debate

[Dirk Eddelbuettel]

  Christoph> You want me to run around Campus installing gzip on 300 machines
  Christoph> because those users are not able to?

Don't worry: gzip is part of the base system. 

Why don't we test e2compr better? Or zlib-compressed filesystem? That way we
can have the cake (docs are compressed) and eat it too (no changes required
to the docs).

--
[EMAIL PROTECTED]  [EMAIL PROTECTED]  http://rosebud.sps.queensu.ca/~edd
PGP KeyID 1024/6D7F08DD Boycott Internet Spam: http://spam.abuse.net/spam/



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

Re: debmake

[SirDibos]

I couldnt help but notice that there are no Canadian or even American
(South or Central) mirrors of debian with the non-us category.  I have
been offered a T1 connect, but dont have any hardware.  If someone has a
spare machine capable of running linux, I can provide a Canadian mirror.
We dont have the same crypto restrictions you guys do.

One interesting note:  FreeBSD now distributes all crypto stuff *from the
US*.  OpenBSD does to, but doesnt count, since its Canadian.  Apparently,
the case got taken to court and FreeBSD won against the gov't.  Hence it
comes with Kerberos etc in full.  Does anyone know anything about this?
Does this mean we can do full crypto in debian without worrying about
piddly little American laws?

Don Dibos
http://www.linuxos.com/

On Fri, 27 Jun 1997, Christoph Lameter wrote:

> >> - PGP 
> >
> >Hmm.  Are you referring to the Pine pgp package?  Ill install it anyways
> 
> Ok. Go to the non-US site for Debian packages and get the security stuff.
> Read the MIRROR.non-US in the debian directory on the mirrors.
> >
> >> - ssh 
> >
> >This doesnt seem to be a debian package... typeing /ssh in dselect returns
> >nothing.
> 
> Also non-US secure stuff. Thank the Feds for making this necessary.



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

Re: fixhrefgz - tool for converting anchors to gzipped files

[Christoph Lameter]

: (Anyeay, even fast machines may be unable to run a web server,
: if they need to be secure. Running extra daemons is insecure.)

Running a web-broser on the machine may also be insecure. If
you run a 8Meg binary on the machine anyways what an issue
could 150K for a webserver be?

: > The big issue here is that you want to change an existing
: > very public API (http protocol) to include compression which

: I'm sorry, but you don't know what you're talking about.

I definitely do.

: When a web browser requests the documentation via HTTP, it
: will be uncompressed by the web server. This already works
: fine. No problem at all.

Yes and I would like to keep it that way. As I understand it you
are proposing to make serving documentation through the webserver
very problematic.

: When a web browser reads the documentation directly from disk,
: it needs to understand how to identify .html.gz as HTML, and how
: to uncompress it, so that it can display it.  This works (except
: for some versions of Netscape, and that might be fixable). The
: only problem is that the documentation contains links to other
: files. The browsers are not (yet?) capable of understanding
: that when the link is to foo.html, and foo.html doesn't exist,
: that they should look for foo.html.gz instead. Because of this,
: the link must be modified to point at foo.html.gz directly.

If you change the links in order to accomodate the Webbrowsers running
on the machine itself then that will change the files that webserver
can sever to the outside world. They are the same files right? Or
is there a separate /usr/doc for html code for webbrowsers running on
the machine?

Which means in turn that the webservers will be forced by the proposed
approach to serve links with .gz suffixes. This is what I object strongly
against because many web-browswers will not be able to handle those suffixes
without special configuration. The user friendliness of the documentation is 
gone.

: Being able to read documentation directly without running
: a web server is very important.

So far I cannot discern why.

-- 
--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---
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: "Amulet" GUI toolkit

[SirDibos]

On Fri, 27 Jun 1997, Graham C. Hughes wrote:
> trying to package scsh.  If a walkthrough was available, I'd certainly 
> appreciate it, and it would allow me to package the thing in a reasonable 
> amount of time.

Yeah, and if you give him a walk through, please forward it to me too,
because Ive been meaning to package up fetchpop (IMHO an essential program
for your average home user)

Don Dibos
http://www.linuxos.com/



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

Re: "Amulet" GUI toolkit

[Graham C. Hughes]

> Someone please package this - I need my time for other stuff.

I'd volunteer *right now*, but I don't understand the package building 
system  yet; I've used deb-make and occasionally gotten tripped up by it 
trying to package scsh.  If a walkthrough was available, I'd certainly 
appreciate it, and it would allow me to package the thing in a reasonable 
amount of time.

I've only done one partially successful Debian package (a local PGP copy 
before I discovered the official one), and it didn't adhere to any 
standards whatsoever.  That doesn't mean I'm not willing to try, tho.
-- 
Graham Hughes <[EMAIL PROTECTED]>   MIME OK, PGP preferred

from stddisclaim import footer
pgp_fingerprint = "E9 B7 5F A0 F8 88 9E 1E  7C 62 D9 88 E1 03 29 5B"




pgp1zN14YeTg8.pgp
Description: PGP signature

problems compiling plan under libc6

[Colin R. Telmer]

I really don't program in C, so I have no idea if this is something easy
to figure out or needs a great amount of reworking. Anyway, given that
debian will require all packages to be compiled with libc6 in the near
future, I thought I would see if this is fixable. The error message from
gcc is:

  gcc -s -D_POSIX_SOURCE -DNOLOCK -DLINUX -DRABBITS   -c file_r.c
  file_r.c: In function `read_mainlist':
  file_r.c:132: `S_IFDIR' undeclared (first use this function)
  file_r.c:132: (Each undeclared identifier is reported only once
  file_r.c:132: for each function it appears in.)
  make[1]: *** [file_r.o] Error 1
  make[1]: Leaving directory `/home/telmerco/debian/plan-1.6.1/src'
  make: *** [linux] Error 2 

The lines around line 132 in file_r.c are

if (!stat(user[u].path, &sbuf) && (sbuf.st_mode & S_IFDIR))
sprintf(path, "%s/%s", user[u].path, DB_FILE);

and the entire file_r.c is attached. The error message seems to be saying
that the code is trying to do a bitwise AND with something that is
undefined. However, I have no idea why this would work with libc5 and not
libc6:)

I really don't know what other information to add except for some lib and
gcc versions (below). Any help is gratefully appreciated. Cheers, Colin. 

ii  libc6   2.0.4-1The GNU C library version 2
ii  libc6-dev   2.0.4-1The GNU C library version 2
ii  libc6-doc   2.0.4-1The GNU C library version 2
ii  gcc 2.7.2.2-5  The GNU C compiler
ii  bash2.0-3  The GNU Bourne Again SHell

--
  Colin R. Telmer, Institute of Intergovernmental Relations
School of Policy Studies, Queen's University
 Kingston, Ontario, Canada, K7L-3N6
  (613)545-6000x4219   [EMAIL PROTECTED]
   PGP Public Key at http://terrapin.econ.queensu.ca>


/*
 * read the master list from the ~/.dayplan file. This file is also
 * linked into the daemon program (file_w.c is not).
 *
 *  read_mainlist() Read all files into mainlist.
 */

#include 
#include 
#include 
#ifdef MIPS
#include 
#include 
#else
#include 
#endif
#ifdef _APOLLO_SOURCE
#include 
#include 
#endif
#ifdef ULTRIX
#include 
#endif
#include 
#include 
#include 
#include 
#include 
#include "config.h"
#include "proto.h"
#include "version.h"
#ifdef PLANGROK
#include "grok.h"
#include "form.h"
#endif

#define NDAYS   28  /* must agree with cal.h */

#ifdef MIPS
extern char *getenv();
extern char *malloc();
#endif
static int  readfile();
static void make_default_user();
static void convert_dbase();

extern char *progname;  /* argv[0] */
extern struct plist *mainlist;  /* all schedule entries */
extern struct configconfig; /* global configuration data */
struct user *user;  /* user list for week view */
static int  maxusers;   /* max # of users in u list */
int nusers; /* # of users in user list */
charPrint_Spooler[100]; /* print spooling command */


/*
 * read the main list. First, read the main ~/.dayplan file, which also
 * provides the configuration data, including the user list. Next, read
 * the private dayplan file and all user dayplan files. Return a text
 * buffer with error messages; if msg is 0 print themn to stderr. This
 * file can't use create_error_popup because it is used by the daemon too.
 *
 * Depending on the mode, server connections are established after the
 * config part of the .dayplan file (including the user list and server
 * mode) was read in. The actual appointment data is then read from the
 * files or the servers.
 */

BOOL read_mainlist()
{
struct stat sbuf;   /* check for directories */
charmsgbuf[4096];   /* default message buffer */
char*msg, *p;   /* where messages are stored */
charpath[1024]; /* user file name to read */
int u;  /* user counter */
int error;

msg  = msgbuf;
*msg = 0;
destroy_list(&mainlist);/* delete appt list */
create_list(&mainlist);

if (user) { /* delete user list */
for (u=0; u < nusers; u++) {
if (user[u].name)
free((char *)user[u].name);
if (user[u].path)
free((char *)user[u].path);
if (user[u].server)
free((char *)user[u].server);
}
free((char *)user);
user = 0;
}
nusers = maxusers = 0;
 

Re: Re^2: Documentation Policy

[Alex Yukhimets]

> MB> Why should we ship info files? HTML is better format. The most
> MB> system will use HTML as their help system in the future. KDE for
> MB> example uses HTML.
> 
> The Info format is a lot better, tecnically, than HTML. That's what
> I've heard. Maybe the problem is that there is no Info browser that
> satisfies the non-Emacs adepts.
> 
> Just because a lot of people prefer HTML, does not mean it's better.
> So, we have to choose: the better or the most popular.

People usually have this kind of choice when deciding which Linux
distribution to pick (Debian or RedHat :), but note, they have the
*choice*. The best way is to give user the choice at that point 
(and ship .texi or SGML sources) but if this is considered technically
difficult to compile the proper documets on the fly, well, then I would
vote for HTML. It is not only most popular, but also *very* flexible
with all kinds of CGI scripting, MIME processing, etc. 

BUT... *Do not drop (or convert to HTML) usual man pages*
It is the least featurefull way of browsing documentation, but it is
the fastest na dmany people got accustomed to it. 

Thanks.


Alex Y.

> 
> -- 
>  Emilio C. Lopes 
> 

-- 
   _   
 _( )_
( (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: problems compiling plan under libc6

[Helmut Geyer]

Your problem is quite easy to solve: libc5 was not really
POSIX-compliant even when _POSIX_SOURCE was defined. S_IFDIR is the
macro used by BSD and SVID while POSIX uses __S_IFDIR. If you define
_BSD_SOURCE, _SVID_SOURCE or _GNU_SOURCE instead of _POSIX_SOURCE (or
simply change the macro to include the __) it should compile.

Helmut

-- 
Helmut Geyer[EMAIL PROTECTED]
public PGP key available :   finger [EMAIL PROTECTED]


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

Re: Experiences with compiling Debian

[joost witteveen]

> > Well, if we do this, we need to make sure to handle the case where
> > people do something like:
> > 
> >   chown -R 755 debian/tmp/usr/bin
> >   chown g+s debian/tmp/usr/bin/special-binary
> > 
> > i.e. later commands would have to override previous ones.  (probably
> > obvious, but I just wanted to make sure this was kept in mind).
> 
>  The new commands would edit a list of permissions, that would be later
> used by tar. We could set an env var to the path of the list...

Nearly.

What I've done so far:

A programme, "fakeroot", that works as follows:

  $ fakeroot /bin/bash

This will execute /bin/bash[1], and set environmen varable "LD_PRELOAD"
to a libfakeroot.so.0.0. This libfakeroot currently overloads
only chown and lstat[2]. Now, when you type in the thus executed shell:

$ chown root:users somefile

this will call the wrapper "chown" function. this wrapper calls 
the real chown, _and_ it sends (via SYSV IPC calls) a message
to the (still running) fakeroot "daemon". This daemon records
the new fake onerships of the file in an internal variable.

The idea is now that when you do
   
   $ ls -al somefile

ls will call lstat("somefile", &buf), again the wrapper lstat[2] function
gets executed that sends a message to the daemon, asking if it's
got any extra information about "somefile". The daemon may then
eighther return "no, don't know that file", or (as in this case)
"root:users". Thus, the ls would output that the file is owned
by root:users. Also any other programme that users (l)stat will
think so, so we don't need to modify tar or anything.

The final goal of cource is to be able to do

  $dpkg-buildpackage -rfakeroot

and build that package!

Problems: 
  - see [1], and [2]
  - yes fstat and fchown will be somewhat of a problem, but I'll
just have to overlod open() etc too, and keep a list of 
inodes/filenames.
  - I probably will go wrong for pathalogical cases like

   ln file1 file2
   chown mail:sys file2
   rm file2
   ls -al file2

I doubt whether these are important, and even if they are, I
guess it will be possible to get it right.

Non-problems:
  The above mentioned problem,
> >   chown -R 755 debian/tmp/usr/bin
> >   chown g+s debian/tmp/usr/bin/special-binary
isn't a problem: the library function chmod(2) is never
called with arguments like g+s, but only with the full permissions
(the user space programme chmod(1) does a stat(2) first).

footnotes:

[1] I currently don't have a libc6 bash, so that doesn't work. I've
been testing it with "es" (yet another shell that I never heard
of, but I'm the maintainer).

[2] Well, I've olverloaded lstat all right, but it doesn't seem to
get called don't know why yet. Why would chown() work and lstat() 
not?

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

"Amulet" GUI toolkit

[Bruce Perens]

Re: dc and bc in Important?

[Raul Miller]

Re: Experiences with compiling Debian

[Roman Hodek]

Re: Bad Maintainer Addresses

[Raul Miller]

Re: Experiences with compiling Debian

[joost witteveen]

> On Jun 25, joost witteveen wrote
> > The only problem with this is that if there are setuid binaries involved
> > in the debian/rules binary process, they will not use the LD_PRELOAD
> > stuff, and things may go wrong. (But as long as those binaries are
> > setuid root, they wouldn't need the libfakeroot).
> 
> a) are there any suid binaries used when compiling ? i looked at my
> /var/log/suid.today, but i didn't find any binaries that might be
> usefull with compiling.

Well _I_ don't use any setuid binaries, but I'm just saying
that _if_ somebody were to use setuid binaries, that may be a problem.
I don't think this is a big problem, though!

> b) will you have to modify dpkg for the build process, or will it use
> the same trap lib ? will you use a file and read / write to this file or
> a daemon or so ? (if you can trap tar the same way you can trap chown,
> you will not need these special function tar has).

Quoting from the email you were replying to:

joost> Yeah, I like that: wrap chown (and friends) _and_ stat(): then
joost> the install, chown, etc stuff in the debian/rules will go
joost> right as well as the final tar!

Does that answer your question? (I think so, but I may have misunderstood
your question).

> additional problems you might have construction this wrapper lib. :-)

Point b) is just something that makes it easier, and point a)
only shows that my setuid problem isn't that big at all -- so what
are your "additional problems"?

-- 
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 Important (was Re: dc and bc in Important?)

[Tim Sailer]

In your email to me, Bill Mitchell, you wrote:
> 
> 
> 
> On 25 Jun 1997, John Goerzen wrote:
> 
> > By the current definition of Important:
> >[...]
> >sendmail
> >  * dpkg-dev should not be there since no experienced user of another
> >Unix would expect it
> >  * lilo should not be there because lilo is not part of UNIX
> 
> I read it differently:
> 
>   ``Important programs, including those which one would expect to find
>   on any Unix-like system. If the expectation is that an experienced
>   Unix person who found it missing would go `What the F*!@<+ is going
>   on, where is foo', it should be in important. [...]
> 
> I read an implication of "including, but not limited to, ..."
> into that.
> 
> However, I could buy some of your arguments that other
> packages (providing cc, lpr, etc.) not currently considered
> Important should be considered Important by this rule because
> they pass the Unix person expectation test.

Anyone that works iwth Slowaris 2.5 or so will tell you that cc is
*not* part of the OS anymore..

Tim

-- 
 (work) [EMAIL PROTECTED] / (home) [EMAIL PROTECTED] - http://www.buoy.com/~tps
 "The squeaky wheel gets the grease,
  but gets changed at the next opportunity if it squeaks habitually."
** Disclaimer: My views/comments/beliefs, as strange as they are, are my own.**


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

Re: Policy wrt Important (was Re: dc and bc in Important?)

[Bill Mitchell]

On 25 Jun 1997, John Goerzen wrote:

> By the current definition of Important:
>[...]
>sendmail
>  * dpkg-dev should not be there since no experienced user of another
>Unix would expect it
>  * lilo should not be there because lilo is not part of UNIX

I read it differently:

  ``Important programs, including those which one would expect to find
  on any Unix-like system. If the expectation is that an experienced
  Unix person who found it missing would go `What the F*!@<+ is going
  on, where is foo', it should be in important. [...]

I read an implication of "including, but not limited to, ..."
into that.

However, I could buy some of your arguments that other
packages (providing cc, lpr, etc.) not currently considered
Important should be considered Important by this rule because
they pass the Unix person expectation test.

I think this Unix person expectation test is too subjective,
and too prone to be evaluated differently by different package
maintainers.  Perhaps it would be better to explicitly list
programs which the debian policer-setters consider Important,
and the rule would better be that one package providing those
listed programs should be prioritized as Important.



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

Re: MD5, SHA-1, RIPEMD, etc.

[Colin Plumb]

Thomas Koenig wrote:
> Using the reference you provided, I got around three Megabytes/ CPU
> second on a P133 with RIPEMD-160 (using pgcc -O6, I confess :-)  How
> fast is SHA-1 in comprarison?

The RIPEMD folks have been carefully tweaking Pentium hashing times.
A speed chart is available at http://www.esat.kuleuven.ac.be/~bosselae/
Here are their results on a P90:


   Hash functions Size (bytes)Cycles Mbit/sec Mbyte/sec
   MD4   1186   241   191.223.90
   MD5   1719   345   133.616.70
   RIPEMD2291   48595.011.88
   RIPEMD-1282941   59777.2 9.65
   SHA-1 4079   83755.1 6.88
   RIPEMD-1604801  101645.4 5.67


   Block ciphers  Cycles  Mbit/sec  Mbyte/sec
   DES  351 16.4   2.05
   DES key setup686  7.3   0.91
   IDEA 590  9.76  1.22
   Square   324 35.56  4.45

Table 1: Performance of my assembly language implementations of some
cryptographic algorithms on a 90 MHz Pentium using a 32-bit flat memory
model. 

Due to the register limitations of the x86 architecture (you only have
7 registers), 160-bit hashes (with 5 active variables) suffer some
extreme regsiter pressure, making it hard to schedule the code optimally.

There are two ways to do SHA-1: with the "key scheduling" in a separate
pre-pass, and integrated with the rounds.  Which is better depends on
a lot of things, including how many registers you have.  (With enough,
you can just load the entire input block into 16 registers and not
worry about anything else.)  I don't know which is used above.

If you want bigger hashes, you can always look at HAVAL (256 bits)...
-- 
-Colin


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

Re: dc and bc in Important?

[David Frey]

On Wed, Jun 25 1997 8:35 PDT Bill Mitchell writes:
> On Wed, 25 Jun 1997, David Frey wrote: 
> > Correlated note: It is not explicitely stated in the policy manual, but 
> > IMO we should flag all utilities mentioned in the POSIX.2 standard as 
> > 'Important' [...]
> 
> IMHO, as long as the list is of manageable size, it'd be better to
> explicitly list the "important" utilities instead of leaving this
> as a judgement call to be made (differently) by each individual
> package maintainer.

Hmm? I thought to unconditionally mark all packages which include at
least one POSIX.2 program with `Important'.
I thought the long-term goal of Debian is to get POSIX-branded, so this
is in some form a must, isn't it?

> One complicating factor here is utility vs. package granularity.
> For example: uuencode/uudecode are packaged with sharutils, and
> ar with binutils. uuencode/uudecode and ar are on your POSIX
> list, but other utilities in the packages which provide them
> are not.

Yes, I agree. There are 2 possibilities:
1. break out the needed programs if the package is exotic, or
2. (IMO the better method) mark the whole package important.

(Comments welcome)

David


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

why are shared libs chmod +x? (again)

[David Frey]

On Sun, Jun 1 1997 21:24 +0200 Christian Schwarz writes: 
> Can someone tell me why shared libs should be installed executable?
> (Actually, Christoph Lameter wants to know this, cf. #7129, but since I
> don't know this either I'll redirect the question to this list.)
> 
> This is current policy and I want to add a small note to the paragraph
> stating the reasons for this.

What was the answer, why shared libraries are mode 755?
I'd suggest to revert them back to 644:

([EMAIL PROTECTED]) ~$/lib/libreadline.so.2.1
Segmentation fault

(I'd expected a better error message like `no binary' or something
 like that).

David
-- 
David Frey  |Linux --- the choice of a GNU generation!
51F35923114FC8647D05FF173C61EFDE|GE C++ UL+++ P- W-- !w--- PGP++ [EMAIL 
PROTECTED] R D--- e++



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

Re: Documentation Policy

[Mark Baker]

On Tue, 24 Jun 1997, Joey Hess wrote:

> I haven't been following this thread closely (catching up on mail backlog
> after vacation), but the reason I've heard why it's not acceptable to ship
> only info files and convert to html on the fly is because the converter in
> dwww that does this produces crappy output. Why not just replace it with a
> better converter? This dicussion smells to me of making policy to work
> around a technical problem.

The problem with info is that it is already formatted, with hard line
breaks; an algorithm to convert this to another format nicely is very
difficult - how can you tell what can be rewrapped and what is a code
fragment?

Whereas if you go back to the original .texi file, it can be wrapped nicely,
and you can even use different fonts.

Lynx users like me will hardly notice the difference but in a graphical
browser there is a difference in that the one generated from the .texi can
use proportional fonts etc.


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

Re: Documentation Policy

[Marco Budde]

Am 23.06.97 schrieb schwarz # monet.m.isar.de ...

Moin Christian!

CS>   Option 3: We ship .texi files and produce HTML and/or info files on
CS> demand (in the postinst script).

Oh no. That's a very bad idea. All converters like latex2html, sgml-tools,  
texi2html produce not very perfect HTML code. You've to edit the HTML code  
to solve a lot of bugs.

CS> (BTW, I'm assuming that *.info.gz requires the same amount of disk space
CS> as *.html.gz. I'm sure we find a way to use .html.gz files somehow.)

There's no problem using .html.gz. The maintainers have to write sed  
scripts, to change the links in the documents itself.

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^6: Status of Debian Policy

[Marco Budde]

Am 23.06.97 schrieb pdm # informatics.muni.cz ...

Moin Milan!

MZ> - It's non-free.

That's a real problem.

MZ> - It's big.

But not bigger than xemacs!

MZ> - It can't run on text console.

But lynx can.

MZ> - Limited possibilities of handling gzip files (typing xxx.html
MZ>   doesn't find xxx.html.gz) => problems with links (may be solvable by

Right, but typing xxx.html.gz will work! We can write a litte sed script  
to change the links from xxx.html to xxx.html.gz inside the documents.

MZ> - Limited searching facilities (general problem of HTML).

Wait for my dhelp ;-).

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: fixhrefgz - tool for converting anchors to gzipped files

[Christoph Lameter]

: Christoph Lameter:
: > Web browsers are small. Dont think instantly of Apache.

: I assume you meant web servers. They may be small, but they
: make things slow. Unacceptably slow, unless you have a fast
: machine.

200Mhz Pentiums are the standard fare today. And I am running
the boa webserver for example on some low memory 486DX66s with
excellent performance. Boa serves directly from disk unless 
there is the need to gunzip something.

The big issue here is that you want to change an existing
very public API (http protocol) to include compression which
may be a big hassle to install on many platforms and so far
has not been an issue on the more popular platforms such as 
Win95 or other Unixes.

-- 
--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---
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: Documentation Policy

[Philip Hands]

> Philip Hands writes:
> > There is of course a problem with trying to install all the
> > documentation on a machine, since some conflicting packages
> > provide man pages with overlapping names.
> 
> I think that the 'alternative' mechanism could be used there.

I was thinking about the possibility of offereing _all_ Debian documentation 
on a web site --- which lpr(1) man page would you want to show?  lpr's or 
lprng's?

I think it should be possible to have both available, but I'm not quite sure 
how to do it without confusing people.

Perhaps man pages should really go in /usr/doc/package-name/man/, with 
symbolic links for /usr/man if needed --- then there wouldn't be as much of a 
problem, since

  /usr/doc/lpr/man/lpr.1

and

  /usr/doc/lprng/man/lpr.1

can both be installed without conflicting.

Cheers, Phil.



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

Re: Documentation Policy

[Manoj Srivastava]

Hi,
>>"Philip" == Philip Hands <[EMAIL PROTECTED]> writes:

Philip> I was thinking about the possibility of offereing _all_ Debian
Philip> documentation on a web site --- which lpr(1) man page would
Philip> you want to show?  lpr's or lprng's?

Philip> Perhaps man pages should really go in
Philip> /usr/doc/package-name/man/, with symbolic links for /usr/man
Philip> if needed --- then there wouldn't be as much of a problem

That is a good idea for the web site (which is what I hope you
 meant, rather than massively changing man just for Debian systems).

manoj

-- 
 The makers of fortunes have a second love of money as a creation of
 their own, resembling the affection of authors for their poems, or of
 parents for their children ... and hence they are very bad company,
 for they talk of nothing but the praises of wealth. Plato
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] .

PGP -kc forgets a key, has corrupt output?

[branden]

-BEGIN PGP SIGNED MESSAGE-

I am reposting this from comp.security.pgp.tech, where my plea was met only
with stony silence.

Can someone here help?  (Lars, do you know anything about this?)

I have read the pgp manpage and pgpdoc[12].txt files in their entirety, and
cannot figure out what the problem is.

Newsgroups: comp.security.pgp.tech
Subject: PGP -kc forgets a key, has corrupt output?
Date: 24 Jun 1997 13:05:01 GMT
Organization: Purdue University
Lines: 96
Sender: Branden Robinson <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
NNTP-Posting-Host: cartoon.ecn.purdue.edu
X-Newsreader: TIN [UNIX 1.3 unoff BETA 970622; sun4u SunOS 5.5]

Could someone enlighten me please?

I just recently signed the key of someone whose key is on my public
ring. pgp -kv on my public ring shows correct output, but pgp -kc makes
it appear that I have signed my own key twice, and leaves out the other
inidividual's information -- except for the fact that it recognizes his
signatures on my and other keys and expands it to his name.

I'm using pgp 2.6.3a from the pgp-us Debian package assembled by Lars
Wirzenius (moderator of comp.os.linux.announce, among other things).

Here is some sample output, edited for brevity.

[0] 205 apocalypse ~ > pgp -kvv | more
Pretty Good Privacy(tm) 2.6.3a - Public-key encryption for the masses.
(c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-03-04
Uses the RSAREF(tm) Toolkit, which is copyright RSA Data Security, Inc.
Distributed by the Massachusetts Institute of Technology.
Export of this software may be restricted by the U.S. government.
Current time: 1997/06/24 12:53 GMT

Key ring: '/home/branden/.pgp/pubring.pgp'
Type Bits/KeyIDDate   User ID
pub  1024/F6599E8D 1996/07/20 Bruce Perens <[EMAIL PROTECTED]>
[...]
pub  1024/D23450F9 1997/06/21 Branden Robinson <[EMAIL PROTECTED]>
sig   D190E74D Terran Lane <[EMAIL PROTECTED]>
sig   D23450F9 Branden Robinson <[EMAIL PROTECTED]>
pub  1024/D190E74D 1996/09/25 Terran Lane <[EMAIL PROTECTED]>
sig   D23450F9 Branden Robinson <[EMAIL PROTECTED]>
sig   C38884A5 (Unknown signator, can't be checked)
sig   20D3D431 (Unknown signator, can't be checked)
sig   914C58A9 (Unknown signator, can't be checked)
sig   47D738C1 (Unknown signator, can't be checked)
sig   B29DE5FD (Unknown signator, can't be checked)
sig   D7BD2F75 Timothy M. Stough <[EMAIL PROTECTED]>
sig   9C2A5CDD (Unknown signator, can't be checked)
sig   FC0C02D5 Eugene H. Spafford <[EMAIL PROTECTED]>
sig   D190E74D Terran Lane <[EMAIL PROTECTED]>
6 matching keys found.

As you see, my own key is next to last in this output, followed by Terran
Lane's, which I signed.

Now for the strange part.

[0] 206 apocalypse ~ > pgp -kc | more
Pretty Good Privacy(tm) 2.6.3a - Public-key encryption for the masses.
(c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-03-04
Uses the RSAREF(tm) Toolkit, which is copyright RSA Data Security, Inc.
Distributed by the Massachusetts Institute of Technology.
Export of this software may be restricted by the U.S. government.
Current time: 1997/06/24 12:56 GMT

Key ring: '/home/branden/.pgp/pubring.pgp'
Type Bits/KeyIDDate   User ID
pub  1024/F6599E8D 1996/07/20 Bruce Perens <[EMAIL PROTECTED]>
[...]
pub  1024/D23450F9 1997/06/21 Branden Robinson <[EMAIL PROTECTED]>
sig!  D190E74D 1997/06/24  Terran Lane <[EMAIL PROTECTED]>
sig!  D23450F9 1997/06/21  Branden Robinson <[EMAIL PROTECTED]>
sig!  D23450F9 1997/06/24  Branden Robinson <[EMAIL PROTECTED]>

And Terran Lane's key, which I signed, is completely absent from this
output.

Is this a bug in 2.6.3a, am I misinterpreting this output, or has my public
ring become corrupted?

Please help.  Apologies for not signing this message "correctly",
my newsreader does not integrate well with pgp.

Of course, pgp-signed or -encrypted mail is welcome.

- -- 
G. Branden Robinson
Purdue University
[EMAIL PROTECTED]
http://www.ecn.purdue.edu/~branden/

-BEGIN PGP SIGNATURE-
Version: 2.6.3a
Charset: noconv

iQCVAwUBM7H7qKiRn0nSNFD5AQEtggP/ZkjHBv9Ko4dANFr/orXmtXYHtwlGbHFY
YNDx8kH6zUUpfvMPyhFIuTjUX/s4roAm7lCOaX6G8BzC1DonYmK7pVIdgslev0DC
lfDkOrXPUNtSOmdVOnttIwv+wdtiS3zI6YICIg4GmOx3KyejwigDcTjvw3cxpZ4X
8XOETWqtBsM=
=vvnE
-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^6: Status of Debian Policy

[branden]

On 25 Jun 1997, Marco Budde wrote:

> Am 23.06.97 schrieb pdm # informatics.muni.cz ...
> 
> MZ> - Limited possibilities of handling gzip files (typing xxx.html
> MZ>   doesn't find xxx.html.gz) => problems with links (may be solvable by
> 
> Right, but typing xxx.html.gz will work! We can write a litte sed script  
> to change the links from xxx.html to xxx.html.gz inside the documents.

What do the popular http daemons do about this?  I think a good solution
would be:

For every .html request that comes in (or perhaps for any request in
general), look for a file fitting the traditional spec.

If that fails, look for a .gz version of that file in the same directory.

If that fails, return the usual 404 error.

Does anything already implement this?  If not, why not?

-- 
G. Branden Robinson
Purdue University
[EMAIL PROTECTED]
http://www.ecn.purdue.edu/~branden/


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

Re: Documentation Policy

[branden]

On 25 Jun 1997, Manoj Srivastava wrote:

> >>"Philip" == Philip Hands <[EMAIL PROTECTED]> writes:
> 
> Philip> I was thinking about the possibility of offereing _all_ Debian
> Philip> documentation on a web site --- which lpr(1) man page would
> Philip> you want to show?  lpr's or lprng's?
> 
> Philip> Perhaps man pages should really go in
> Philip> /usr/doc/package-name/man/, with symbolic links for /usr/man
> Philip> if needed --- then there wouldn't be as much of a problem
> 
>   That is a good idea for the web site (which is what I hope you
>  meant, rather than massively changing man just for Debian systems).

Right.  I would think /etc/alternatives handles things just fine for
end-user systems.

-- 
G. Branden Robinson
Purdue University
[EMAIL PROTECTED]
http://www.ecn.purdue.edu/~branden/


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

Re: Documentation Policy

[Fernando]

Marco Budde wrote:
> 
> CS>   Option 3: We ship .texi files and produce HTML and/or info files on
> CS> demand (in the postinst script).
> 
> Oh no. That's a very bad idea. All converters like latex2html, sgml-tools,  
> texi2html produce not very perfect HTML code. You've to edit the HTML code  
> to solve a lot of bugs.
> 

If we want to have HTML as the default we would have to put some effort into
fixing bugs in the converters. A converter fixed means many documents fixed,
while a document fixed is just one document fixed. We would have to give higher
priority to bugs in the document converters.

As for slowness, it is partially solved by caching pages. In the long term we
might have to consider tweaking the converters for speed or replacing them
with better ones. But that is secondary.


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

Re: Experiences with compiling Debian

[Nicolás Lichtmaier]

On Wed, 25 Jun 1997, joost witteveen wrote:

> > Build a shared library which wraps all calls to chown(), then set
> > LD_PRELOAD to that library.  Should be pretty foolproof.
> Yeah, I like that: wrap chown (and friends) _and_ stat(): then
> the install, chown, etc stuff in the debian/rules will go
> right as well as the final tar!

 Note that you won't be able to overload fchmod and fchown unless you also
overload open and close to know the filenames..!

 IMO we should go with the simplest solution: {chmod,chown}.sh and modify
the packages.

-- 
Nicolás Lichtmaier.-


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

Re: Experiences with compiling Debian

[Rob Browning]

Nicolás Lichtmaier <[EMAIL PROTECTED]> writes:

>  Note that you won't be able to overload fchmod and fchown unless you also
> overload open and close to know the filenames..!
>
>  IMO we should go with the simplest solution: {chmod,chown}.sh and modify
> the packages.

Well, if we do this, we need to make sure to handle the case where
people do something like:

  chown -R 755 debian/tmp/usr/bin
  chown g+s debian/tmp/usr/bin/special-binary

i.e. later commands would have to override previous ones.  (probably
obvious, but I just wanted to make sure this was kept in mind).

--
Rob


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