[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
> "Rob" == Rob Browning <[EMAIL PROTECTED]> writes:
Rob> 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).
> > "ghughes" == ghughes <[EMAIL PROTECTED]> writes:
> ghughes> True. However, it can't handle gzipped pages, and
> ghughes> hacking it to do so seems a) special case (because
> Ermm... on my system it can. lynx 2.7-1 (self compiled).
> netscape also handles it very well. I can't say
> "ghughes" == ghughes <[EMAIL PROTECTED]> writes:
ghughes> [1 ] On Jun 22, Bruce Perens
ghughes> wrote
>> Lynx can browse files directly, and can execute CGI scripts
>> directly.
ghughes> True. However, it can't handle gzipped pages, and
ghughes> hacking it to do s
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
On Jun 22, Bruce Perens wrote
> Lynx can browse files directly, and can execute CGI scripts directly.
True. However, it can't handle gzipped pages, and hacking it to do so
seems a) special case (because chimera, w3, netscape and all the others
still don't) and b) outside of its domain of relevanc
[EMAIL PROTECTED] (Marco Budde) wrote on 21.06.97 in <[EMAIL PROTECTED]>:
> But this requires a www server! Not a good idea for slow systems like my
> notebook. And the result doesn't look great.
From: [EMAIL PROTECTED] (Kai Henningsen)
> Isn't there a mini www server in Perl's web modules
Lynx
On 22 Jun 1997, Kai Henningsen wrote:
> [EMAIL PROTECTED] (Marco Budde) wrote on 21.06.97 in <[EMAIL PROTECTED]>:
>
> > But this requires a www server! Not a good idea for slow systems like my
> > notebook. And the result doesn't look great.
>
> There are other options. Getting a minimal, fast
[EMAIL PROTECTED] (Marco Budde) wrote on 21.06.97 in <[EMAIL PROTECTED]>:
> But this requires a www server! Not a good idea for slow systems like my
> notebook. And the result doesn't look great.
Isn't there a mini www server in Perl's web modules, about one or two
screend of Perl? (I don't re
-BEGIN PGP SIGNED MESSAGE-
Christian Schwarz <[EMAIL PROTECTED]> writes:
>
> On 15 Jun 1997, Ardo van Rangelrooij wrote:
>
> > I have another policy issue which is related to topic 11 (see below).
> >
> > The current layout of Info entries in the main Info menu (in the file
> > /usr/in
On Jun 17, Christian Schwarz wrote:
> > > Original-Site: site/URL at which the package is originally stored
>
> Ok. I think "Original-Site" is used in the .lsm entries. Wouldn't
> something like "Upstream-Site" be better?
It is important that more than one "Upstream-Site" field is allowed.
Not fo
[EMAIL PROTECTED] (Fernando) wrote:
>Author: name and email of main upstream author (copyright holder)
>License: code describing license type
>Original-Site: site/URL at which the package is originally stored
Yes.
>We could even go further and specify the type of non-free license.
>Common types
On Jun 17, Santiago Vila Doncel wrote
> Sorry, I didn't explain well. I said:
>
> *---
> I wonder why we are supporting this packages in the `contrib' section:
>
> * whose copyright permission notices (or patent problems) al
-BEGIN PGP SIGNED MESSAGE-
Sorry, I didn't explain well. I said:
*---
I wonder why we are supporting this packages in the `contrib' section:
* whose copyright permission notices (or patent problems) allow only
On Mon, 16 Jun 1997, Santiago Vila Doncel wrote:
> On Sun, 15 Jun 1997, Christian Schwarz wrote:
>
> > TOPIC 7: new definition of ``free software''
>
> This is only about the "main" section.
>
> In addition to that, I wonder why we are supporting this packages in the
> `contrib' section:
>
>
On Mon, 16 Jun 1997, Erik B. Andersen wrote:
> I cannot agree more. We should definatly add these fields to the
> .deb package format! This will involve a bit of work, but will be
> VERY worth it. No more licensing surprises, for instance.
I second that!
This would even make my proposed READM
Santiago Vila Doncel <[EMAIL PROTECTED]> writes:
[snip]
> The simplest solution is to ship html in a different package. This way
> the user will be able to choose to not install the html docs if he/she
> believes info2www is enough.
It might be nice if different types of duplicate documentation
I cannot agree more. We should definatly add these fields to the
.deb package format! This will involve a bit of work, but will be
VERY worth it. No more licensing surprises, for instance.
-Erik
--
Erik B. Andersen Web:http://www.inconnect.com/~andersen/
email: [EMA
In article <[EMAIL PROTECTED]>,
Christian Schwarz <[EMAIL PROTECTED]> writes:
> The current structure (of packages installed on my system) is:
>
> Miscellaneous
> Development
> Document Preparation
> Information
> Emacs
> Programming
> teTeX
>
-BEGIN PGP SIGNED MESSAGE-
On Sun, 15 Jun 1997, Christian Schwarz wrote:
> TOPIC 11: policy about including documentation
>
> The current policy concerning docs is:
>
> - HTML is the preferred format
> - if the package includes docs than can be converted into HTML,
>th
-BEGIN PGP SIGNED MESSAGE-
On Sun, 15 Jun 1997, Christian Schwarz wrote:
> TOPIC 7: new definition of ``free software''
This is only about the "main" section.
In addition to that, I wonder why we are supporting this packages in the
`contrib' section:
* whose copyright permission n
>
> TOPIC 8: packages have to specify their source urls
> ---
> STATUS: DISCUSSION
>
In addition to what you propose below, I think that "dpkg -I" should be
concerned with some of that info. Specifically, three important fields are
missing:
A
On 15 Jun 1997, Ardo van Rangelrooij wrote:
> I have another policy issue which is related to topic 11 (see below).
>
> The current layout of Info entries in the main Info menu (in the file
> /usr/info/dir) looks rather messy. I found the following "descrepencies":
>
> - not all packages are p
On Mon, 16 Jun 1997, joost witteveen wrote:
[snip]
> > I'm somehow confused now. Is registering to "dwww" any different from the
> > "menu" system? Joost, perhaps you can give use some hints here (I think
> > Jim is offline now).
>
> It used to be the same, and that's why I also asked Jim about t
On 16 Jun 1997, Rob Browning wrote:
> Christian Schwarz <[EMAIL PROTECTED]> writes:
>
> > This really is an _excellent_ idea! So, we just need a volunteer to
> > implement and maintain this "upstream library". (The packaging for Debian
> > should not be a problem.)
>
> Ideally we could provide C
Christian Schwarz <[EMAIL PROTECTED]> writes:
> This really is an _excellent_ idea! So, we just need a volunteer to
> implement and maintain this "upstream library". (The packaging for Debian
> should not be a problem.)
Ideally we could provide C, perl, python, etc versions of the code.
--
Rob
> On Sun, 15 Jun 1997, Jim Pick wrote:
>
> >
> > > > All packages that provide HTML documentation should register these
> > > > documents to the menu system, too. Check out section section 4.1,
> > > > `Web
> > > > servers and applications' for details.
> > >
> > > Is that as wel
On Sun, 15 Jun 1997, Jim Pick wrote:
>
> > > All packages that provide HTML documentation should register these
> > > documents to the menu system, too. Check out section section 4.1,
> > > `Web
> > > servers and applications' for details.
> >
> > Is that as well as registering w
On 15 Jun 1997, Rob Browning wrote:
> [EMAIL PROTECTED] (Mark Baker) writes:
>
> > Would programs _have_ to use this library, or is implementing the same thing
> > in acceptable? The latter has problems in that it forces us to keep the same
> > method, but I don't want to see lots of #ifdef debia
-BEGIN PGP SIGNED MESSAGE-
Hi,
I have another policy issue which is related to topic 11 (see below).
The current layout of Info entries in the main Info menu (in the file
/usr/info/dir) looks rather messy. I found the following "descrepencies":
- not all packages are placed in an ap
Miquel van Smoorenburg wrote:
>SystemV has standard library functions for this. Qpopper can use them if
>compiled under Solaris. So for qpopper, I just created those functions myself.
>It might be a good idea to put them in a small (not shared) library, so
>other programs can use them. And the cha
In article <[EMAIL PROTECTED]>,
Mark Baker <[EMAIL PROTECTED]> wrote:
>
>In article <[EMAIL PROTECTED]>,
> Christian Schwarz <[EMAIL PROTECTED]> writes:
>Currently some packages do one and some the other.
>
>> 2. Build a shared library ``libdebian'', that contains
>> functions
> > All packages that provide HTML documentation should register these
> > documents to the menu system, too. Check out section section 4.1, `Web
> > servers and applications' for details.
>
> Is that as well as registering with dwww?
I'm changing the way documents register themse
[EMAIL PROTECTED] (Mark Baker) writes:
> Would programs _have_ to use this library, or is implementing the same thing
> in acceptable? The latter has problems in that it forces us to keep the same
> method, but I don't want to see lots of #ifdef debian appearing in the
> original source; apart fro
In article <[EMAIL PROTECTED]>,
Christian Schwarz <[EMAIL PROTECTED]> writes:
> All packages that provide HTML documentation should register these
> documents to the menu system, too. Check out section section 4.1, `Web
> servers and applications' for details.
Is that as w
35 matches
Mail list logo
