from:"Kalle Olavi Niemitalo"

Re: [elinks-dev] update to autoconf 2.69

2013-04-08 Thread Kalle Olavi Niemitalo

Kamil Dudka  writes:

> would it be possible to use autoconf 2.69+ for creating the new releases
> of elinks in order to support the ARM 64 bit CPU architecture (aarch64)?

I'm not sure it's permitted under the GPLv2 license of configure.in.
The license requires that source files are distributed under GPLv2.
I think /usr/share/autoconf/autoconf/general.m4 may be a source file
of the resulting configure script, but in Autoconf 2.69, that file
is under GPLv3-or-later + Autoconf Configure Script Exception v3.
The exception grants permission to propagate the configure script,
but not to distribute general.m4 itself under GPLv2.

I don't see any license problems with upgrading just config.guess
and config.sub.  The patch linked from
https://bugzilla.redhat.com/show_bug.cgi?id=925306 does not
change the GPLv2-or-later license of those files.  Even if we
upgraded to the 2013-02-12 versions, which are under
GPLv3-or-later, it seems the "special exception" would allow us
to distribute them under GPLv2 as part of ELinks, which is
licensed under GPLv2 and contains a configure script generated by
Autoconf.  They don't say it has to be the latest version of
Autoconf.

pgpCC3Ar2_Zrh.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] [PATCH] rewrite: add default "ddg" dumb/smart prefixes for DuckDuckGo

2012-09-19 Thread Kalle Olavi Niemitalo

Kamil Dudka  writes:

> + INIT_OPT_SMART_PREFIX("ddg", "https://duckduckgo.com/?q=%s&t=elinks";),

ELinks can be built without SSL/TLS support, in which case it
will pop up an error message when asked to open an https URL.
This may be why all the other prefixes use http rather than
https.  If you want to use https whenever possible, you can do
this:

#ifdef CONFIG_SSL
INIT_OPT_SMART_PREFIX("ddg", "https://duckduckgo.com/?q=%s&t=elinks";),
#else
INIT_OPT_SMART_PREFIX("ddg", "http://duckduckgo.com/?q=%s&t=elinks";),
#endif

However, there is a risk that the http variant might get saved to 
~/.elinks/elinks.conf, in which case ELinks will keep using that
even if the user later installs an SSL/TLS-capable ELinks binary.
Such saving happens if the user edits the rewriting rule, or if
the user sets config.saving_style = 1 or 2.  I don't know whether
this risk is so bad you'd prefer using https unconditionally.

The "t=elinks" parameter at the end makes me feel a bit uneasy.
None of the other prefix definitions has anything like that,
perhaps indicating the prefixes were added without consulting the
webmasters.  On the other hand, because ELinks by default reveals
its name in the User-Agent header, it is OK to include "t=elinks"
here too.  It might however deserve a note in the documentation
of protocol.http.user_agent:

diff --git a/src/protocol/http/http.c b/src/protocol/http/http.c
index e58c7af..14f89f8 100644
--- a/src/protocol/http/http.c
+++ b/src/protocol/http/http.c
@@ -204,7 +204,8 @@ static struct option_info http_options[] = {
"pushing some lite version to them automagically.\n"
"\n"
"Use \" \" if you don't want any User-Agent header to be sent "
-   "at all.\n"
+   "at all. URI rewriting rules may still include parameters "
+   "that reveal you are using ELinks.\n"
"\n"
"%v in the string means ELinks version,\n"
"%s in the string means system identification,\n"


pgp50eJGmVGR2.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] Importing more recent debian/ to elinks.git

2011-08-02 Thread Kalle Olavi Niemitalo

witekfl  writes:

> I vote for the deletion of contrib/debian and elinks.spec.
> Debian and others already have such files in their repos.
> The Arch's packagers might create the elinks.desktop themselves.

elinks.desktop is useful to multiple distros.  I think it is
better to keep an official version of it in the ELinks tree than
require packagers to look for updated versions from each other.

Deleting the rest of contrib/debian/ is OK with me.  Building a
Debian package gets the version number from the changelog, which
nobody has bothered to update after the 0.11.0 release, so it
looks like nobody is building Debian packages with those files.
After we release 0.12.0, Debian will have that version in their
archive soon enough.

I see you are who last updated contrib/elinks.spec.in.
If you say it is not needed, I trust you.

Now, what should be added to AUTHORS for those Ubuntu changes of
elinks.desktop?

pgpsbjMgOOjTJ.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] Importing more recent debian/ to elinks.git

2011-07-31 Thread Kalle Olavi Niemitalo

As reported at ,
contrib/debian/elinks.desktop is in a pre-standard format that
triggers a warning from the mimeo program.  I could easily fix
that in the upstream elinks sources; however, Debian already has
an up-to-date elinks.desktop file that also includes translations
to a few languages.  To avoid needless forking, I'd like to copy
that version to the elinks-0.12 branch and later merge to master.

Then, to keep authorship information, I think I should also copy
debian/changelog, and perhaps the rest of the debian directory.
According to , the
Debian maintainer does not want us to have a debian/ directory in
the ELinks sources, so the files would go in contrib/debian/.
Does that seem reasonable to do?

Also, should I make the commit a merge (from
git://git.debian.org/git/collab-maint/elinks.git#debian/unstable),
or would that just complicate later Debian maintenance?

I suppose another solution would be to move elinks.desktop out of
contrib/debian/ and update AUTHORS accordingly.  It does look a
bit odd that the Arch Linux build script reads a file from a
Debian-specific directory.


pgpbOuIYyDPVL.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] file names in elinks/doc/manual.html-chunked/

2011-07-19 Thread Kalle Olavi Niemitalo

Recently, I wanted to link to the documentation of -remote in the
ELinks manual.  That is currently at

but the chapter number may change as the manual is edited.
To make such links more reliable in the future, I'd like to
change the file names now to more descriptive ones: for example,
this one could be remote.html.

By changing the xmlto invocation in doc/Makefile to

> %.html-chunked: %.xml
>   $(call cmd,xmlto,--stringparam use.id.as.filename=1 html)

and then changing the beginning of doc/remote.txt to

> [[remote]]
> Managing remote ELinks instances
> 

I get the remote.html file, as desired.

Now then, the other files.  Subsection 1.7 (Feature configuration file)
comes from $builddir/doc/features.txt, which begins with:

> [[features.conf]]
> Feature configuration file (`features.conf`)
> 

It appears that AsciiDoc 7.1.2 (bundled in elinks-0.12) does not
allow "features.conf" as a BlockId; the section element in the
generated manual.xml does not get any id attribute, and the file
is consequently not called features.conf.html.  The problem seems
to be in doc/tools/asciidoc/asciidoc.conf, which does not allow
dots in a bare ID:

> attributelist-pattern=(?u)(^\[\[(?P[\w\-_]+)\]\]$)|(^\[(?P.*)\]$)

If I change conf2doc to generate [id="features.conf"], then it works.
It currently does this:

> label="[[$(echo $config_name | sed 's/_/-/g')]]"

Does anyone remember what exactly was the reason for replacing
underscores with hyphen-minuses?  The change was made on
2005-05-18: "Fix config labels to make pdf building work
(s/CONFIG_FOO/CONFIG-FOO/)."  However, I just tried building a
PDF with underscores and had no problems; links worked too.


pgp80QZJi3aVC.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] strlcasestr uses c_toupper; rename to c_strlcasestr?

2011-05-08 Thread Kalle Olavi Niemitalo

In master:src/util/string.{c,h}, there are various "*case*"
functions and macros for case-insensitive string operations:

* c_strcasecmp() uses c_tolower().
* c_strcasestr() uses c_strncasecmp(), thus c_tolower().
* c_strlcasecmp() uses elinks_strlcasecmp(...,, 1), thus c_toupper().
* c_strncasecmp() uses c_tolower().
* elinks_strlcasecmp() uses c_toupper() or toupper(),
  depending on the locale_indep parameter.
* elinks_strlcasestr() uses c_strncasecmp(), thus c_tolower().
* strlcasecmp() uses elinks_strlcasecmp(..., 0), thus toupper().
* strlcasestr() uses elinks_strlcasestr(), thus c_toupper().

I think the name of strlcasestr() is misleading because it is
locale-independent even though strlcasecmp() is locale-dependent.
Should strlcasestr() be renamed to c_strlcasestr(), or should it
be changed to use toupper()?

The only function using strlcasestr() is match_cache_entry_contents(),
which searches for a user-provided string (in the terminal charset)
in a cache fragment (in the document charset).  Because the charsets
do not always match, and usually at least one of them is multibyte,
just calling toupper() would not do the right thing.


pgpaCqpl35Gu3.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] [PATCHv2] configure: Find SpiderMonkey with pkg-config

2011-04-30 Thread Kalle Olavi Niemitalo

Don't search for SpiderMonkey in hardcoded directories
(/usr /usr/local /opt/spidermonkey /opt/js), and don't support
--with-spidermonkey=DIR (which I think was never documented).
Instead, ask pkg-config for mozjs185 or mozilla-js.
Everyone who installed SpiderMonkey in an unusual place must either
set PKG_CONFIG_PATH appropriately or use --with-xulrunner-includes
and --with-xulrunner-libs.

This commit also includes a few minor changes in the SpiderMonkey
section of the configure script:
* Update the SpiderMonkey version number in "checking" messages
  from 1.5 RC3a to 1.8.5, which matches the actual checks.
* Rename --with-xulrunner_includes to --with-xulrunner-includes,
  and --with-xulrunner_libs likewise.  This only affects the
  --help output; the configure script accepts both spellings.
* Wrap the option documentation with AS_HELP_STRING.
* Use the Autoconf-generated $with_xulrunner_includes etc.
  variables directly, instead of copying $withval.
* Quote the arguments of macros more consistently.
* Warn if SpiderMonkey was requested but not found.
---
أحمد المحمودي  writes:

>   Could this be changed to a for loop that checks for either mozjs185 or 
>   mozilla-js ? In Debian, mozjs is installed as part of iceweasel, ie. 
>   firefox, and that installs a mozilla-js.pc instead of mozjs185.pc

Done.

 configure.in |  190 -
 doc/installation.txt |2 +-
 2 files changed, 125 insertions(+), 67 deletions(-)

diff --git a/configure.in b/configure.in
index 2bd6830..65c4dbf 100644
--- a/configure.in
+++ b/configure.in
@@ -623,78 +623,136 @@ fi
 # Check for SpiderMonkey, optional even if installed.
 # ===
 
-xulrunner_includes=
-xulrunner_libs=
-AC_ARG_WITH(xulrunner_includes, [  --with-xulrunner_includes=DIR
-  When set, the libmozjs of xulrunner is used instead 
of "standalone" SpiderMonkey],
-[xulrunner_includes="$withval"])
-AC_ARG_WITH(xulrunner_libs, [  --with-xulrunner_libs=OPTIONS
-  Linker options for xulrunner,
-  eg. --with-xulrunner_libs="-Wl,-R/usr/lib/xulrunner 
-L/usr/lib/xulrunner -lmozjs"],
-[xulrunner_libs="$withval"])
-AC_ARG_WITH(spidermonkey, [  --without-spidermonkey  disable SpiderMonkey 
Mozilla JavaScript engine support],
-[if test "$withval" = no; then disable_spidermonkey=yes; fi])
-
-AC_MSG_CHECKING([for SpiderMonkey (1.5 RC3a or later)])
-
+# These options set the $with_xulrunner_includes,
+# $with_xulrunner_libs, and $with_spidermonkey variables.
+AC_ARG_WITH([xulrunner-includes],
+   [AS_HELP_STRING([--with-xulrunner-includes=DIR],
+   [When set, the libmozjs of xulrunner is used instead of 
"standalone" SpiderMonkey])])
+AC_ARG_WITH([xulrunner-libs],
+   [AS_HELP_STRING([--with-xulrunner-libs=OPTIONS],
+   [Linker options for xulrunner, eg. 
--with-xulrunner-libs="-Wl,-R/usr/lib/xulrunner -L/usr/lib/xulrunner 
-lmozjs"])])
+AC_ARG_WITH([spidermonkey],
+   [AS_HELP_STRING([--without-spidermonkey],
+   [disable SpiderMonkey Mozilla JavaScript engine support])])
+
+dnl EL_LINK_SPIDERMONKEY_IFELSE(if-found, if-not-found)
+AC_DEFUN([EL_LINK_SPIDERMONKEY_IFELSE],
+   [AC_LINK_IFELSE([AC_LANG_PROGRAM(
+[[/* mozilla-js.pc may have -DXP_UNIX in Cflags.
+ * Avoid warnings about conflicting definitions.  */
+#ifndef XP_UNIX
+# define XP_UNIX 1
+#endif
+#include 
+#ifndef JS_VERSION
+# error  did not define JS_VERSION
+#elif JS_VERSION < 185
+# error too old
+#endif]], [])],
+ [$1], [$2])])
+
+# CONFIG_SPIDERMONKEY is initially blank.  We change it to "yes" or "no"
+# when we know for sure whether we're going to use SpiderMonkey or not.
+# (features.conf is not supposed to define it.)
+CONFIG_SPIDERMONKEY=
 EL_SAVE_FLAGS
-cf_result=no
 
-if test -z "$disable_spidermonkey"; then
-   if test ! -d "$withval"; then
-   withval="";
-   fi
-   if test ! -z "$xulrunner_includes"; then
-   SPIDERMONKEY_LIBS="$xulrunner_libs"
-   SPIDERMONKEY_CFLAGS="-I$xulrunner_includes"
-   LIBS="$SPIDERMONKEY_LIBS $LIBS_X"
-   CFLAGS="$CFLAGS_X $SPIDERMONKEY_CFLAGS"
-   CPPFLAGS="$CPPFLAGS_X $SPIDERMONKEY_CFLAGS"
-
-   AC_LINK_IFELSE([AC_LANG_PROGRAM([[#define XP_UNIX
-   #include ]], [[
-   #ifndef JS_VERSION
-   #error JS_VERSION
-   #endif
-   #if JS_VERSION < 185
-   #error too old
-   #endif]])],
-   [cf_result=yes],[cf_result=no])
+case "$with_spidermonkey" in
+   no)
+   # The user specified --without-spidermonkey.
+   # That overrides the other SpiderMonkey options.
+   AC_MSG_CHECKING([for SpiderMonkey])
+   AC_MSG_RESULT([disabled])
+   CONFIG_SPIDERMONKEY="no"
+

Re: [elinks-dev] [0.12 PATCH] HTML: Rewrite parsing of meta refresh

2011-04-27 Thread Kalle Olavi Niemitalo

Kalle Olavi Niemitalo  writes:

> All this is consistent with Debian Iceweasel 3.5.16.

Less consistent than I thought... my patch lost support for
content="42, http://example.org/";, which Iceweasel does support.
I'll add more test cases and perhaps post a revised patch later.


pgpHZiy9ySdgY.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] [0.12 PATCH] HTML: Rewrite parsing of meta refresh

2011-04-27 Thread Kalle Olavi Niemitalo

The URL in 
can now freely contain spaces and semicolons.  There cannot be other
parameters between the delay and the URL.  If the URL is not quoted,
then it spans to the end of the attribute, except not to trailing
spaces.  If the URL is quoted, then it ends at the first closing
quotation mark.  All this is consistent with Debian Iceweasel 3.5.16.
---
 src/document/html/Makefile   |4 +-
 src/document/html/parse-meta-refresh.c   |   97 
 src/document/html/parse-meta-refresh.h   |   21 +++
 src/document/html/parser.c   |  170 +++---
 src/document/html/test/Makefile  |9 +
 src/document/html/test/parse-meta-refresh-test.c |  174 ++
 src/document/html/test/test-parse-meta-refresh   |3 +
 7 files changed, 325 insertions(+), 153 deletions(-)
 create mode 100644 src/document/html/parse-meta-refresh.c
 create mode 100644 src/document/html/parse-meta-refresh.h
 create mode 100644 src/document/html/test/Makefile
 create mode 100644 src/document/html/test/parse-meta-refresh-test.c
 create mode 100755 src/document/html/test/test-parse-meta-refresh

diff --git a/src/document/html/Makefile b/src/document/html/Makefile
index 5f7510b..91e7e08 100644
--- a/src/document/html/Makefile
+++ b/src/document/html/Makefile
@@ -1,7 +1,7 @@
 top_builddir=../../..
 include $(top_builddir)/Makefile.config
 
-SUBDIRS = parser
-OBJS   = frames.o parser.o renderer.o tables.o
+SUBDIRS = parser test
+OBJS   = frames.o parse-meta-refresh.o parser.o renderer.o tables.o
 
 include $(top_srcdir)/Makefile.lib
diff --git a/src/document/html/parse-meta-refresh.c 
b/src/document/html/parse-meta-refresh.c
new file mode 100644
index 000..b26135a
--- /dev/null
+++ b/src/document/html/parse-meta-refresh.c
@@ -0,0 +1,97 @@
+/* Parse  */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+#include 
+
+#include "elinks.h"
+
+#include "document/html/parse-meta-refresh.h"
+#include "osdep/ascii.h"
+#include "util/string.h"
+
+#define LWS(c) ((c) == ' ' || (c) == ASCII_TAB)
+
+int
+html_parse_meta_refresh(const unsigned char *content,
+   unsigned long *delay_out,
+   unsigned char **url_out)
+{
+   const unsigned char *end_url = NULL;
+   const unsigned char *scan = content;
+   int negative = 0;
+   const unsigned char *lookahead;
+
+   *url_out = NULL;
+   *delay_out = 0;
+
+   while (LWS(*scan))
+   ++scan;
+
+   if (!*scan)
+   return -1;
+
+
+   /* Is there something that looks vaguely like a number?  */
+   lookahead = scan;
+   if (*lookahead == '-') {
+   negative = 1;
+   ++lookahead;
+   } else if (*lookahead == '+') {
+   ++lookahead;
+   }
+   if (isdigit(*lookahead) || *lookahead == '.') {
+   unsigned long delay = strtoul(lookahead, NULL, 10);
+
+   if (negative && delay != 0)
+   return -1;
+   *delay_out = delay;
+
+   while (isdigit(*lookahead) || *lookahead == '.')
+   ++lookahead;
+   scan = lookahead;
+   }
+
+   while (LWS(*scan) || *scan == ';')
+   ++scan;
+
+   /* Skip "URL=" if any.  With at least one equals sign,
+* and optional spaces.  */
+   if ((scan[0] == 'U' || scan[0] == 'u')
+   && (scan[1] == 'R' || scan[1] == 'r')
+   && (scan[2] == 'L' || scan[2] == 'l')) {
+   lookahead = scan + 3;
+
+   while (LWS(*lookahead))
+   ++lookahead;
+   if (*lookahead == '=') {
+   while (LWS(*lookahead) || *lookahead == '=')
+   ++lookahead;
+   scan = lookahead;
+   }
+   }
+
+   if (*scan == '"' || *scan == '\'') {
+   unsigned char quote = *scan++;
+
+   end_url = strchr(scan, quote);
+   if (end_url == NULL)
+   end_url = strchr(scan, '\0');
+   } else {
+   end_url = strchr(scan, '\0');
+   while (scan < end_url && LWS(end_url[-1]))
+   --end_url;
+   }
+
+   if (end_url == scan)
+   return 0;
+
+   *url_out = memacpy(scan, end_url - scan);
+   if (*url_out)
+   return 0;
+   else
+   return -1;
+}
diff --git a/src/document/html/parse-meta-refresh.h 
b/src/document/html/parse-meta-refresh.h
new file mode 100644
index 000..d81409d
--- /dev/null
+++ b/src/document/html/parse-meta-refresh.h
@@ -0,0 +1,21 @@
+#ifndef EL__DOCUMENT_HTML_PARSE_META_REFRESH_H
+#define EL__DOCUMENT_HTML_PARSE_META_REFRESH_H
+
+/** Parses a \ element.
+ *
+ * @param[in] content
+ *   The value of the content attribute, with entities already expanded.
+ * @param[out] delay
+ *   How many seconds to wait before

[elinks-dev] [0.13 PATCH] JS: Use pkg-config mozjs185, not hardcoded directories

2011-04-23 Thread Kalle Olavi Niemitalo

The --with-spidermonkey option no longer supports a DIR argument.
AFAICT, that argument was never documented anyway.

This commit also changes the SpiderMonkey version number in "checking"
messages from 1.5 RC3a to 1.8.5, which matches the actual checks.
---

Witek recently changed the master branch (ELinks 0.13.GIT) to
require SpiderMonkey 1.8.5.  The elinks-0.11 and elinks-0.12
branches do not support SpiderMonkey 1.8.5.  I'd like to be able
to build both branches, so I have installed SpiderMonkey 1.8.5 in
my home directory: ~/prefix/x86_64-unknown-linux-gnu/lib/ and
~/prefix/include/js/.  I had difficulty getting ELinks 0.13.GIT
to use SpiderMonkey from those directories, however.  Because
SpiderMonkey 1.8.5 also installs mozjs185.pc, which refers to the
correct directories, I'd like to make the configure script of
ELinks 0.13.GIT use that.  Then, only $PKG_CONFIG_PATH needs to
be set.

Please post if this patch would cause difficulty to you.
I will probably be offline for a day or two.

 configure.in |   90 -
 1 files changed, 44 insertions(+), 46 deletions(-)

diff --git a/configure.in b/configure.in
index 6055a0e..72be7f8 100644
--- a/configure.in
+++ b/configure.in
@@ -632,26 +632,25 @@ AC_ARG_WITH(xulrunner_libs, [  
--with-xulrunner_libs=OPTIONS
   Linker options for xulrunner,
   eg. --with-xulrunner_libs="-Wl,-R/usr/lib/xulrunner 
-L/usr/lib/xulrunner -lmozjs"],
 [xulrunner_libs="$withval"])
-AC_ARG_WITH(spidermonkey, [  --without-spidermonkey  disable SpiderMonkey 
Mozilla JavaScript engine support],
-[if test "$withval" = no; then disable_spidermonkey=yes; fi])
-
-AC_MSG_CHECKING([for SpiderMonkey (1.5 RC3a or later)])
+AC_ARG_WITH(spidermonkey, [  --without-spidermonkey  disable SpiderMonkey 
Mozilla JavaScript engine support])
 
+# features.conf is not supposed to define CONFIG_SPIDERMONKEY.
+CONFIG_SPIDERMONKEY=
 EL_SAVE_FLAGS
-cf_result=no
-
-if test -z "$disable_spidermonkey"; then
-   if test ! -d "$withval"; then
-   withval="";
-   fi
-   if test ! -z "$xulrunner_includes"; then
-   SPIDERMONKEY_LIBS="$xulrunner_libs"
-   SPIDERMONKEY_CFLAGS="-I$xulrunner_includes"
-   LIBS="$SPIDERMONKEY_LIBS $LIBS_X"
-   CFLAGS="$CFLAGS_X $SPIDERMONKEY_CFLAGS"
-   CPPFLAGS="$CPPFLAGS_X $SPIDERMONKEY_CFLAGS"
 
-   AC_LINK_IFELSE([AC_LANG_PROGRAM([[#define XP_UNIX
+if test "$with_spidermonkey" = "no"; then
+   AC_MSG_CHECKING([for SpiderMonkey])
+   AC_MSG_RESULT([disabled])
+   CONFIG_SPIDERMONKEY="no"
+elif test -n "$xulrunner_includes"; then
+   AC_MSG_CHECKING([for SpiderMonkey (1.8.5 or later) in xulrunner])
+   SPIDERMONKEY_LIBS="$xulrunner_libs"
+   SPIDERMONKEY_CFLAGS="-I$xulrunner_includes"
+   LIBS="$SPIDERMONKEY_LIBS $LIBS_X"
+   CFLAGS="$CFLAGS_X $SPIDERMONKEY_CFLAGS"
+   CPPFLAGS="$CPPFLAGS_X $SPIDERMONKEY_CFLAGS"
+
+   AC_LINK_IFELSE([AC_LANG_PROGRAM([[#define XP_UNIX
#include ]], [[
#ifndef JS_VERSION
#error JS_VERSION
@@ -659,39 +658,38 @@ if test -z "$disable_spidermonkey"; then
#if JS_VERSION < 185
#error too old
#endif]])],
-   [cf_result=yes],[cf_result=no])
+   [CONFIG_SPIDERMONKEY=yes],[CONFIG_SPIDERMONKEY=no])
+   AC_MSG_RESULT([$CONFIG_SPIDERMONKEY])
+else
+   AC_MSG_CHECKING([for mozjs185 (SpiderMonkey 1.8.5) in pkg-config])
+   # In pkg-config 0.25, pkg-config --exists mozjs185 returns 0 (success)
+   # even if mozjs185 depends on nspr, which has not been installed.
+   # However, pkg-config --cflags mozjs185 returns 1 then.
+   if pkg-config --cflags --libs mozjs185 > /dev/null 
2>&AS_MESSAGE_LOG_FD; then
+   SPIDERMONKEY_LIBS="$(pkg-config --libs mozjs185)"
+   SPIDERMONKEY_CFLAGS="$(pkg-config --cflags mozjs185)"
+   LIBS="$SPIDERMONKEY_LIBS $LIBS_X"
+   CFLAGS="$CFLAGS_X $SPIDERMONKEY_CFLAGS"
+   CPPFLAGS="$CPPFLAGS_X $SPIDERMONKEY_CFLAGS"
+   AC_LINK_IFELSE([AC_LANG_PROGRAM([[#define XP_UNIX
+   #include ]], [[
+   #ifndef JS_VERSION
+   #error JS_VERSION
+   #endif
+   #if JS_VERSION < 185
+   #error too old
+   #endif]])],
+   [AC_MSG_RESULT([yes])
+CONFIG_SPIDERMONKEY=yes],
+   [AC_MSG_RESULT([found but does not work])
+CONFIG_SPIDERMONKEY=no])
else
-   for spidermonkeydir in "$withval" "" /usr /usr/local 
/opt/spidermonkey /opt/js; do
-   for spidermonkeyinclude in "/include" "/include/js" 
"/include/smjs" "/include/mozjs"; do
-

[elinks-dev] Messages lost in spam filter of elinks-dev

2009-10-25 Thread Kalle Olavi Niemitalo

I made a mistake in configuring the spam filter of elinks-dev,
and it seems all messages sent here after August 11, 2009
have been lost.  I am sorry.

There was no such problem with the elinks-users list.

The Mailman software in the mailing-list server uses lists of
regular expressions for detecting spam messages.  I had added
some comments and blank lines in the list used for discarding
spam, to document the history and rationale of some of those
regexps.  Unfortunately, it seems Mailman 2.1.9 treated those
blank lines as match-all regexps.  Before the change, I had
checked from the source code that it supported comments, but
I didn't realize it didn't support blank lines.

http://mailman.svn.sourceforge.net/viewvc/mailman/tags/Release_2_1_9/Mailman/Handlers/SpamDetect.py?view=markup
http://bazaar.launchpad.net/%7Emailman-coders/mailman/2.1/revision/960


pgpa0tdLpbX3e.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] [PATCH] bug 764: Fix option_value initialization on sparc64

2009-08-10 Thread Kalle Olavi Niemitalo

Edd Barrett  writes:

> Do you have a patch?

Please test the 0.11/bug764 branch shown here:
http://repo.or.cz/w/elinks/kon.git
That should contain the required commits from elinks-0.12 and a
simple patch that fixes union option_value when ELinks start up.
(It makes some assumptions outside of standard C, but at least
the code should be more portable than in ELinks 0.11.6.)

I may make some further changes to the branch if I find a bug
there.  (That seems unlikely to happen before Friday though.)
When reporting results, please mention the commit ID you tested.

> I could try it on OpenBSD, which is mostly POSIX compatible.

If OpenBSD has dlsym(), then casts between data pointers and
function pointers have to work.

> Just out of interest, how stable is elinks "unstable".

For the last 12 months, there have been plenty of bug fixes
and almost no new features in elinks-0.12.  Crashes are rare,
especially if you keep ECMAScript disabled as is now the default.
I've been trying to keep track of regressions compared to
elinks-0.11; only bug 1066 (in IDN) is left, and I suspect
elinks-0.11 has a similar bug itself.  However, the future fixes
for bugs 1066 and 771 may cause new bugs.

pgpTLth9IG970.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] [PATCH] bug 764: Fix option_value initialization on sparc64

2009-08-09 Thread Kalle Olavi Niemitalo

Edd Barrett  writes:

> My next question is, how hard is it to put this back into the stable
> branch?

This patch itself wouldn't be too hard to apply to elinks-0.11.
A much simpler patch is also possible if we can assume that
casting function pointers or integers to data pointers and back
preserves the values.  (POSIX guarantees this for function
pointers but ELinks has been run in non-POSIX systems in the
past.  AFAIK, nothing guarantees this for data pointers.)

However, some other parts of bug 764 have already been fixed in
elinks-0.12.  So we'd first need to make a list of those commits and
backport them.  Commit 1ec1dc43be13e062e18368bf05928ac95d7b7ba5 is
one of them for sure.

pgpEqehM1AR3v.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] [PATCH] bug 764: Fix option_value initialization on sparc64

2009-08-08 Thread Kalle Olavi Niemitalo

Kalle Olavi Niemitalo  writes:

> Please try this patch.

The patch is for elinks-0.12.  I put it in Bugzilla as well:
http://bugzilla.elinks.cz/attachment.cgi?id=547&action=view


pgpe7dcHDoGaJ.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] elinks is broken on sparc64/OpenBSD!

2009-08-06 Thread Kalle Olavi Niemitalo

Edd Barrett  writes:

>>> The next problem is, if you change any preferences, they do not appear
>>> to be saved. This is likely to be related to the first problem.
>> Did you tell ELinks to save the changes?
>
> Yes

Is sparc64 big-endian with sizeof(int) < sizeof(void *)?
That would explain the problem with the options.
http://bugzilla.elinks.cz/show_bug.cgi?id=764

I don't know whether that bug could cause ELinks not to display
any web pages, though.  It may be best to fix that first, and
then try again.

pgpkiFK9xOMBV.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] elinks is broken on sparc64/OpenBSD!

2009-08-05 Thread Kalle Olavi Niemitalo

Edd Barrett  writes:

> First of all, it warns me of a deprecated config file, even though there
> is not one. Every time. Even if you blast away ~/.elinks and try again.

What is the warning exactly?

> The next problem is, if you change any preferences, they do not appear
> to be saved. This is likely to be related to the first problem.

Did you tell ELinks to save the changes?

Which compiler did you use?  Try disabling optimizations.
If that does not work around the problem right away,
the executable should at least become easier to debug.

> So basically, elinks is broken in many ways on sparc64. Are any of the
> elinks developers interested in helping me pinpoint and eliminate these
> defects?

Sure.


pgp5PPDoSSSYM.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] ELinks 0.12pre5 soon

2009-07-07 Thread Kalle Olavi Niemitalo

Because of bug 1081 (and Debian bug 536039), I think
ELinks 0.12pre5 should be released today or tomorrow.
Are there any other changes that should go in it?


pgplOdS1LpPQM.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] [resent][PATCH] elinks 0.12pre3 fails to search double-width characters

2009-06-29 Thread Kalle Olavi Niemitalo

"Yuriy M. Kaminskiy"  writes:

> Ok, fixed.

Thanks, pushed to elinks-0.12.

> Eww, fine.

An expression of disgust?


pgpT71OD2mSwi.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] [resent][PATCH] elinks 0.12pre3 fails to search double-width characters

2009-06-28 Thread Kalle Olavi Niemitalo

"Yuriy M. Kaminskiy"  writes:

>   I noticed that search for more than 1 double-width (japanese)
> character fails (search for single char works), and found that get_srch
> don't skip placeholders (UCS_NO_CHAR) for double-width character.
> Attached patch should solve this problem.

That is indeed a bug and your patch fixes it.

> PS just in case, same bug was in 0.12pre2 (not sure about earlier releases).

ELinks 0.12pre1 has the same bug.  The elinks-0.11 branch does
not support fullwidth characters.

> PPS did not checked with --disable-utf-8; should be no-op with gcc
> warning about "cond. always false", I think.

This appears to cause a warning with gcc-4.1 and gcc-4.2 but not
with gcc-4.3.  In ELinks, configure --enable-debug adds -Werror
to CFLAGS, so there must not be any warnings.  Please add #ifdef
CONFIG_UTF8.

ELinks is currently licensed under GPLv2 only.  I hope we can
eventually change the licence to also allow later versions of
GPL and permit linking with OpenSSL.  Do you allow such
relicensing for your patch?  (A more permissive licence would be
fine too.)

Do you give permission to add your name and email address to the
commit information, to the AUTHORS file, and similar places
(e.g. a list of contributors in release notes)?  The cia.vc and
ohloh.com web sites are already collecting this information and
others might do so in the future.

pgp7b4JmfSsr1.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] Line-drawing characters when dumping Web pages

2009-06-27 Thread Kalle Olavi Niemitalo

Kalle Olavi Niemitalo  writes:

> The attached patch for elinks-0.12
> (20dfdb284f9a23742800fb5b4023bef54c6ad982) implements this, but
> I'm not sure it is the right solution, because e.g. KOI8-R also
> supports line-drawing characters so the fix should preferably
> not be specific to UTF-8.

The attached new version of the patch makes elinks --dump use
line-drawing characters in all charsets where they are available.
I think this should be applied to master after the prerequisites
have been merged from elinks-0.12.

From 0dc9ac1a83f7a7d228476a4829c4b2a55daf Mon Sep 17 00:00:00 2001
From: Kalle Olavi Niemitalo 
Date: Sun, 21 Jun 2009 18:30:36 +0300
Subject: [PATCH] dump: Use box-drawing characters if available

---
 NEWS   |2 +
 src/viewer/dump/dump-specialized.h |4 +-
 src/viewer/dump/dump.c |   80 ++--
 3 files changed, 80 insertions(+), 6 deletions(-)

diff --git a/NEWS b/NEWS
index 166539a..e135750 100644
--- a/NEWS
+++ b/NEWS
@@ -88,6 +88,8 @@ includes the changes listed under ``ELinks 0.11.6.GIT now'' 
below.
 * minor bug 1017: To work around HTTP server bugs, disable
   protocol.http.compression by default, until ELinks can report
   decompression errors or automatically retry the connection.
+* enhancement: ``elinks --dump'' uses box-drawing characters if supported
+  by the charset.
 
 Bugs that should be removed from NEWS before the 0.12.0 release:
 
diff --git a/src/viewer/dump/dump-specialized.h 
b/src/viewer/dump/dump-specialized.h
index 1afbea7..b8166f7 100644
--- a/src/viewer/dump/dump-specialized.h
+++ b/src/viewer/dump/dump-specialized.h
@@ -126,8 +126,8 @@ DUMP_FUNCTION_SPECIALIZED(struct document *document, struct 
dump_output *out)
 #endif /* DUMP_COLOR_MODE_TRUE */
 
if ((attr & SCREEN_ATTR_FRAME)
-   && c >= 176 && c < 224)
-   c = frame_dumb[c - 176];
+   && c >= FRAME_CHARS_BEGIN && c < FRAME_CHARS_END)
+   c = out->frame[c - FRAME_CHARS_BEGIN];
 
 #ifdef DUMP_CHARSET_UTF8
if (!isscreensafe_ucs(c)) c = ' ';
diff --git a/src/viewer/dump/dump.c b/src/viewer/dump/dump.c
index 295a7aa..81d0382 100644
--- a/src/viewer/dump/dump.c
+++ b/src/viewer/dump/dump.c
@@ -53,6 +53,9 @@ static int dump_redir_count = 0;
 
 #define D_BUF  65536
 
+#define FRAME_CHARS_BEGIN 0xB0
+#define FRAME_CHARS_END   0xE0
+
 /** A place where dumping functions write their output.  The data
  * first goes to the buffer in this structure.  When the buffer is
  * full enough, it is flushed to a file descriptor or to a string.  */
@@ -68,10 +71,76 @@ struct dump_output {
 * flushed, or -1.  */
int fd;
 
+   /** Mapping of SCREEN_ATTR_FRAME characters.  If the target
+* codepage is UTF-8 (which is possible only if CONFIG_UTF8 is
+* defined), then the values are UTF-32.  Otherwise, they are
+* in the target codepage, even though the type may still be
+* unicode_val_T.  */
+#ifdef CONFIG_UTF8
+   unicode_val_T frame[FRAME_CHARS_END - FRAME_CHARS_BEGIN];
+#else
+   unsigned char frame[FRAME_CHARS_END - FRAME_CHARS_BEGIN];
+#endif
+
/** Bytes waiting to be flushed.  */
unsigned char buf[D_BUF];
 };
 
+/** Mapping from CP437 box-drawing characters to simpler CP437 characters.
+ * - Map mixed light/double lines to light lines or double lines,
+ *   depending on the majority; or to light lines if even.
+ * - Map double lines to light lines.
+ * - Map light and dark shades to medium, then to full blocks.
+ * - Map half blocks to full blocks.
+ * - Otherwise map to ASCII characters.  */
+static const unsigned char frame_simplify[FRAME_CHARS_END - FRAME_CHARS_BEGIN]
+= {
+   /*-0-1-2-3-4-5-6-7 */
+   /*-8-9-A-B-C-D-E-F */
+   0xB1, 0xDB, 0xB1, '|' , '+' , 0xB4, 0xB9, 0xBF, /* 0xB0...0xB7 */
+   0xC5, 0xB4, 0xB3, 0xBF, 0xD9, 0xD9, 0xD9, '+' , /* 0xB8...0xBF */
+   '+' , '+' , '+' , '+' , '-' , '+' , 0xC3, 0xCC, /* 0xC0...0xC7 */
+   0xC0, 0xDA, 0xC1, 0xC2, 0xC3, 0xC4, 0xC5, 0xCA, /* 0xC8...0xCF */
+   0xC1, 0xCB, 0xC2, 0xC0, 0xC0, 0xDA, 0xDA, 0xC5, /* 0xD0...0xD7 */
+   0xC5, '+' , '+' , '#' , 0xDB, 0xDB, 0xDB, 0xDB  /* 0xD8...0xDF */
+};
+
+static void
+dump_output_prepare_frame(struct dump_output *out, int to_cp)
+{
+   const int cp437 = get_cp_index("cp437");
+   int orig;
+   unsigned char subst;
+
+#ifdef CONFIG_UTF8
+   if (is_cp_utf8(to_cp)) {
+   for (orig = FRAME_CHARS_BEGIN; orig < FRAME_CHARS_END; orig++)
+   out->frame[orig - FRA

Re: [elinks-dev] Line-drawing characters when dumping Web pages

2009-06-08 Thread Kalle Olavi Niemitalo

(moved from elinks-users to elinks-dev because of the patch)

Karl Ove Hufthammer  writes:

> When I use ELinks interactively, table borders are drawn using nice 
> line-drawing characters. However, when I use ‘links --dump’, these are 
> replaced by ugly -, | and + ASCII characters, even if I dump to UTF-8. 
> Is there a way to retain the nice borders when dumping a Web page?

Not at the moment.  The attached patch for elinks-0.12
(20dfdb284f9a23742800fb5b4023bef54c6ad982) implements this, but
I'm not sure it is the right solution, because e.g. KOI8-R also
supports line-drawing characters so the fix should preferably
not be specific to UTF-8.  Comments?

From 827a77a6e5fad1f4dc69909090bf07fb7b84ee51 Mon Sep 17 00:00:00 2001
From: Kalle Olavi Niemitalo 
Date: Tue, 9 Jun 2009 01:48:42 +0300
Subject: [PATCH] Line-drawing characters in UTF-8 dumps

When dumping the document to a file, ELinks used to represent lines in
tables and HR elements as ASCII -+| characters.  Now, if the output
charset is UTF-8, it uses Unicode line-drawing characters instead.
This change affects elinks --dump and File -> Save formatted document,
but not the Lua current_document_formatted function.
---
 NEWS   |2 +
 src/terminal/screen.c  |2 +-
 src/terminal/terminal.h|1 +
 src/viewer/dump/dump-specialized.h |   39 +++
 4 files changed, 29 insertions(+), 15 deletions(-)

diff --git a/NEWS b/NEWS
index a84f3f9..f407c7c 100644
--- a/NEWS
+++ b/NEWS
@@ -15,6 +15,8 @@ includes the changes listed under ``ELinks 0.11.6.GIT now'' 
below.
 * minor bug 1017: To work around HTTP server bugs, disable
   protocol.http.compression by default, until ELinks can report
   decompression errors or automatically retry the connection.
+* enhancement: ``--dump'' and ``Save formatted document'' output
+  line-drawing characters if using UTF-8.
 
 ELinks 0.12pre4:
 
diff --git a/src/terminal/screen.c b/src/terminal/screen.c
index 8f838a6..34c93d8 100644
--- a/src/terminal/screen.c
+++ b/src/terminal/screen.c
@@ -41,7 +41,7 @@ static const unsigned char frame_vt100[48] =  
"aaaxuuukkuxkjjjkmvwtqnttmlvwtqnvvw
  * characters encoded in CP437.
  * When UTF-8 I/O is enabled, ELinks uses this array instead of
  * ::frame_vt100[], and converts the characters from CP437 to UTF-8.  */
-static const unsigned char frame_vt100_u[48] = {
+const unsigned char frame_vt100_u[48] = {
177, 177, 177, 179, 180, 180, 180, 191,
191, 180, 179, 191, 217, 217, 217, 191,
192, 193, 194, 195, 196, 197, 195, 195,
diff --git a/src/terminal/terminal.h b/src/terminal/terminal.h
index c2c1d79..3bf9d19 100644
--- a/src/terminal/terminal.h
+++ b/src/terminal/terminal.h
@@ -166,6 +166,7 @@ extern LIST_OF(struct terminal) terminals;
 
 
 extern const unsigned char frame_dumb[];
+extern const unsigned char frame_vt100_u[];
 
 struct terminal *init_term(int, int);
 void destroy_terminal(struct terminal *);
diff --git a/src/viewer/dump/dump-specialized.h 
b/src/viewer/dump/dump-specialized.h
index f60aeed..6d21839 100644
--- a/src/viewer/dump/dump-specialized.h
+++ b/src/viewer/dump/dump-specialized.h
@@ -41,6 +41,9 @@ DUMP_FUNCTION_SPECIALIZED(struct document *document, int fd,
unsigned char *background = &color[3];
int width = get_opt_int("document.dump.width");
 #endif /* DUMP_COLOR_MODE_TRUE */
+#ifdef DUMP_CHARSET_UTF8
+   const int cp437 = get_cp_index("cp437");
+#endif
 
for (y = 0; y < document->height; y++) {
int white = 0;
@@ -105,23 +108,11 @@ DUMP_FUNCTION_SPECIALIZED(struct document *document, int 
fd,
 
c = document->data[y].chars[x].data;
 
+#ifndef DUMP_CHARSET_UTF8
if ((attr & SCREEN_ATTR_FRAME)
&& c >= 176 && c < 224)
c = frame_dumb[c - 176];
-#ifdef DUMP_CHARSET_UTF8
-   else {
-   unsigned char *utf8_buf = encode_utf8(c);
-
-   while (*utf8_buf) {
-   if (write_char(*utf8_buf++,
-   fd, buf, &bptr)) return -1;
-   }
-
-   x += unicode_to_cell(c) - 1;
-
-   continue;
-   }
-#endif /* DUMP_CHARSET_UTF8 */
+#endif /* !DUMP_CHARSET_UTF8 */
 
if (c <= ' ') {
/* Count spaces. */
@@ -136,10 +127,30 @@ DUMP_FUNCTION_SPECIALIZED(struct document *document, int 
fd,
white--;
}
 
+#ifdef DUMP_CHARSET_UTF8
+   if ((attr & SCREE

Re: [elinks-dev] utf8 broken with -dump-color-mode other than -1,0

2009-06-08 Thread Kalle Olavi Niemitalo

Cezary Bagiński  writes:

> Dumping with color mode seems to break encoding.

This seems to be bug 1080, now fixed in elinks-0.12.
(Perhaps too late for tonight's snapshot.)


pgpgcZ2aeJnvD.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] chunked gzip fails again

2009-06-03 Thread Kalle Olavi Niemitalo

Witold Filipczyk  writes:

> Sorry, but the server sends in header: Content-Encoding: gzip,
> but the first chunk is not compressed.

You're right.  I suppose we should (1) try to get the server bug
fixed and (2) implement some workaround in ELinks.

For (1), it would be good to know whether the bug is caused by
some local configuration at www.eweek.com, or also present in the
standard Apache 1.3.37 distribution.  However, the response
headers don't list any extra modules, and I don't see any
bug-reporting address at the eWEEK or Ziff Davis Enterprise web
sites where we could ask how they have configured their server.
Perhaps someone at Apache might remember such a bug?

For (2), ELinks should preferably detect decompression errors and
blacklist the server and retry without Accept-Encoding (if the
connection is retryable).  Until that is implemented, it seems
best to set protocol.http.compression = 0 by default.

pgpzteNhInjmL.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] chunked gzip fails again

2009-06-02 Thread Kalle Olavi Niemitalo

http://www.eweek.com/c/a/Desktops-and-Notebooks/Intel-Psion-End-Dispute-Concerning-Netbook-Trademark-288875/
elinks-0.12 (cde4a2f7b3f2c62ae161b39dd391bbddfd4d3857)
--no-home --no-connect at this site results in a 9-byte body.
Headers:

HTTP/1.1 200 OK
Date: Tue, 02 Jun 2009 19:22:56 GMT
Server: Apache/1.3.37 (Unix)
Set-Cookie: sessioncookie=533e75e71f373b3637cd0a419d8c0ddf; expires=Wed, 
02-Jun-2010 19:22:56 GMT; path=/
Set-Cookie: mosvisitor=1
Content-Encoding: gzip
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Last-Modified: Tue, 02 Jun 2009 19:22:56 GMT
Cache-Control: no-store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

Disabling protocol.http.compression makes ELinks show the page correctly.
So, it seems there's still something wrong with chunked gzip, unfortunately.

ELinks 0.10.6, 0.11.0, and 0.11.5 display the beginning of the
page OK, but the end is garbage.


pgpojrVh7I0Fc.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] 0.12pre4 this weekend

2009-05-30 Thread Kalle Olavi Niemitalo

I'd like to release ELinks 0.12pre4 today or tomorrow.

A few days ago, my message to elinks-dev was rejected as spam.
So this message is also a test to see whether that still happens.
I wouldn't want the release announcement to be blocked in that way.


pgpWeYfowyGR8.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] Bug#529821: elinks: FTBFS against gnutls26 >= 2.7.x

2009-05-21 Thread Kalle Olavi Niemitalo

Andreas Metzler  writes:

> The package's ./configure script is trying to invoke libgnutls-config
> and/or libgnutls-extra-config to search for the gnutls library. Newer
> version of gnutls do not ship these scripts anymore.

I'll push the following patch to elinks-0.12 in the weekend if
nobody objects.  And then perhaps a separate one to mention the
pkg-config dependency in doc/installation.txt.

From aed0cd5e1b1ed3043fe409619d5a832b39895496 Mon Sep 17 00:00:00 2001
From: Kalle Olavi Niemitalo 
Date: Thu, 21 May 2009 22:52:57 +0300
Subject: [PATCH] Debian bug 529821: Use pkg-config, not libgnutls-config

The configure script used to run libgnutls-config in order to find the
compiler and linker options needed for using GNUTLS, but GNUTLS 2.7
apparently doesn't ship that script any more.  Use pkg-config instead.
GNUTLS 1.2.0 is the oldest version supported by ELinks, and that already
installs the gnutls.pc file required by pkg-config.

This commit also removes support for configure --with-gnutls=DIR.
The configure script used to look for libgnutls-config in DIR.
DIR thus had to be a directory where executable programs were installed,
and it's unlikely that gnutls.pc would be found there.  So, any callers
that used this feature would have to be changed anyway, and they can as
well be changed to set the PKG_CONFIG_PATH environment variable instead.
---
 NEWS |2 +
 configure.in |  110 +
 2 files changed, 50 insertions(+), 62 deletions(-)

diff --git a/NEWS b/NEWS
index 7a7ecc5..4b7a894 100644
--- a/NEWS
+++ b/NEWS
@@ -14,6 +14,8 @@ includes the changes listed under ``ELinks 0.11.6.GIT now'' 
below.
 * critical bug 1071: Fix crash in get_dom_node_child.
 * Debian build bug 526349: Include asciidoc.py from AsciiDoc 7.1.2,
   to remove all dependencies on the installed version.
+* Debian build bug 529821: Use ``pkg-config gnutls'' instead of
+  ``libgnutls-config'', which is not included in GNUTLS 2.7.x.
 * build enhancement: Recognize ``configure --without-tre''.
 
 ELinks 0.12pre3:
diff --git a/configure.in b/configure.in
index 46cbb9a..d2af322 100644
--- a/configure.in
+++ b/configure.in
@@ -1004,15 +1004,14 @@ disable_openssl=""
 disable_gnutls=""
 enable_gnutls=""
 
-AC_ARG_WITH(gnutls, [  --without-gnutlsdisable GNUTLS SSL support],
-   [if test "$with_gnutls" = no;  then disable_gnutls=yes; fi])
-AC_ARG_WITH(gnutls, [[  --with-gnutls[=DIR] enable GNUTLS SSL support]],
-   [if test "$with_gnutls" != no;  then enable_gnutls=yes; fi])
-gnutls_withval="$withval"
-
-if test "$enable_gnutls" = yes; then
-   disable_openssl=yes;
-fi
+AC_ARG_WITH(gnutls, [[  --without-gnutlsdisable GNUTLS SSL support]])
+AC_ARG_WITH(gnutls, [[  --with-gnutls   enable GNUTLS SSL support]],
+   [case "$with_gnutls" in
+   "no") disable_gnutls=yes;;
+   "yes") enable_gnutls=yes; disable_openssl=yes;;
+   *) AC_MSG_WARN([[Support for --with-gnutls=DIR has been removed.
+You may have to set the PKG_CONFIG_PATH environment variable instead.]]);;
+esac])
 
 AC_ARG_WITH(openssl, [  --without-openssl   disable OpenSSL support],
[if test "$with_openssl" = no;  then disable_openssl=yes; fi])
@@ -1071,68 +1070,55 @@ AC_MSG_RESULT($cf_result)
 
 CONFIG_GNUTLS_OPENSSL_COMPAT=no
 #  GNU TLS
-dnl We can't have AC_MSG_CHECKING here, because AC_PATH_PROG prints its own and
-dnl it looks ugly then.
-
 if test "$cf_result" = yes; then
-   cf_result="not used"
-
-else
-   EL_SAVE_FLAGS
-   cf_result="no"
+   AC_MSG_CHECKING([[for GNUTLS]])
+   AC_MSG_RESULT([[not used, because OpenSSL was chosen]])
 
-   if test -z "$disable_gnutls"; then
-   # Sure, we maybe _could_ use their macro, but how to ensure
-   # that the ./configure script won't fail if the macro won't be
-   # found..? :( --pasky
+elif test -n "$disable_gnutls"; then
+   AC_MSG_CHECKING([[for GNUTLS]])
+   AC_MSG_RESULT([[explicitly disabled]])
 
-   GNUTLS_PATH="$PATH:/usr/local/gnutls:/opt:/opt/gnutls"
-
-   if test -d "$gnutls_withval"; then
-   GNUTLS_PATH="$gnutls_withval:$GNUTLS_PATH"
-   fi
-
-   AC_PATH_PROG(LIBGNUTLS_CONFIG, libgnutls-config, no, 
$GNUTLS_PATH)
-
-   if test "$LIBGNUTLS_CONFIG" = "no" ; then
-   cf_result=no
-   else
-   GNUTLS_CFLAGS=`$LIBGNUTLS_CONFIG --cflags`
-   GNUTLS_LIBS=`$LIBGNUTLS_CONFIG --libs`
-
-   LIBS="$GNUTLS_LIBS $LIBS_X"

Re: [elinks-dev] Patch to make libtre dependency optional.

2009-05-21 Thread Kalle Olavi Niemitalo

"Hema Seetharamaiah"  writes:

> Yes, I provide explicit permission [...]

Thanks.  I pushed your patch and related changes to elinks-0.12.
They'll soon get to master too.

> On Sun, May 17, 2009 11:05 pm, Kalle Olavi Niemitalo wrote:
>> - desirable: BSD-like licence, to avoid being forced to
>>   upgrade to ever more complex versions of GNU GPL.
>
> I also explicitly license my code to be used under the modified BSD and
> X11 license.

Well, that was more a preference than a requirement :-) as the
code inherited from Links will probably prevent distributing
ELinks as a whole under a permissive licence, even if we can get
permission from all ELinks contributors.  I appreciate the grant
though.

pgp6EML15KYin.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] Patch to make libtre dependency optional.

2009-05-17 Thread Kalle Olavi Niemitalo

Hema Seetharamaiah  writes:

> I license my changes under GPL V2 or later. 
>
> Please accept the patch if this is ok.

Can you also give permission to link with OpenSSL?  I see your
patch affects only configure.in, which doesn't really become part
of the elinks executable, but anyway I think it'd be clearest to
get such permission for all ELinks-specific code.  (We don't
currently have explicit permission from all copyright holders
but I don't want to make the situation any worse.)

The FSF apparently recommends also giving explicit permission to
link with libraries licensed under LGPL:
http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs
I don't know how necessary that really is.  (It seems related
to section 3 of LGPLv2.)

Then, I'd like to store your name and email address in at least
these publicly visible places:
- In the AUTHORS file, whence the name would get to 
  http://elinks.cz/authors.html too.  The licensing notice would
  also go here.
- In related release announcements.  (Perhaps not the email
  address though.)
- In the Git commit metadata.  The cia.vc and ohloh.com web sites
  are already collecting information from there and others might
  do so in the future.
Is such use of your personal information OK with you?  I presume
it is, because you included that info in the "From:" line of the
patch, but I'd like to have explicit permission if possible.

The Linux and Git projects document similar requirements in their
SubmittingPatches files and expect contributors to add a
Signed-Off-By line to their commit messages if they grant the
necessary permissions.  ELinks doesn't currently have these
things written down; each committer apparently decides on his own
what he dares to push.

At this time, I think the licensing of any code added to ELinks
should satisfy:
- requirement: GPLv2 compatible.
- very desirable: OpenSSL compatible. 
- very desirable: GPLv3 compatible, so that the current
  libsmbclient could be used.
- desirable: GPLv2-or-later, so that when GPLv4 comes out and
  libraries switch to it, we wouldn't have to locate the
  original copyright holder's heirs.
- desirable: BSD-like licence, to avoid being forced to
  upgrade to ever more complex versions of GNU GPL.

Other ELinks developers might not share these opinions.

pgpq9Dmyktyxc.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] [gnu.org #433709] Can GPLv2-only software be compiled with GCC 4.4.0?

2009-04-29 Thread Kalle Olavi Niemitalo

The apparent incompatibility between GPLv2-only applications and
GPLv3-or-later+exception libgcc was mentioned on the gcc mailing
list already in October 2007:
http://gcc.gnu.org/ml/gcc/2007-10/msg00390.html


pgpkC8wumOz5I.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] Patch to make libtre dependency optional.

2009-04-26 Thread Kalle Olavi Niemitalo

"Hema Seetharamaiah"  writes:

> Attached is a patch that provides a new option without-tre - which can be
> used to build elinks without libtre dependency.

With that patch, configure without any TRE-related option outputs here:

checking for TRE... checking for TRE in pkg-config... yes
checking for TRE header and library... yes
no

i.e. you have nested AC_MSG_CHECKING/AC_MSG_RESULT pairs, and the
final result is also incorrect.  I think the simplest solution
would be just

if test "$with_tre" = no; then
AC_MSG_CHECKING([[for TRE]])
AC_MSG_RESULT([[not used]])
else
... put the original tests here ...
fi

Your patch also contains spaces between tabs in indentation,
and a redundant use of EL_SAVE_FLAGS.

I'm attaching a revised patch that should fix these problems.
I also renamed HAVE_TRE_REGEX_H to CONFIG_TRE because it can
now be unset even if the header and library exist all right.

I should also ask about storage of personal data and licensing
of changes but it's getting too late here.

From 3fee12ca965f3e6269800f79b054e5d26c842fb9 Mon Sep 17 00:00:00 2001
From: Kalle Olavi Niemitalo 
Date: Sun, 26 Apr 2009 23:46:17 +0300
Subject: [PATCH] Add --without-tre option

elinks-lite in Debian does not depend on any libraries (except
gnutls and the usual libc and libgcc). Including this option
will allow elinks-lite to be built without libtre dependency.

Based on a patch by Hema Seetharamaiah .
---
 configure.in |   83 --
 src/config/options.inc   |2 +-
 src/elinks.h |2 +-
 src/viewer/text/search.c |   22 ++--
 4 files changed, 64 insertions(+), 45 deletions(-)

diff --git a/configure.in b/configure.in
index 631b605..bf56d95 100644
--- a/configure.in
+++ b/configure.in
@@ -933,43 +933,62 @@ fi
 # Check for TRE library
 # ===
 
-AC_MSG_CHECKING([[for TRE in pkg-config]])
-if pkg-config tre; then
-	TRE_CFLAGS=`pkg-config --cflags tre`
-	TRE_LIBS=`pkg-config --libs tre`
-	AC_MSG_RESULT([[yes]])
+AC_ARG_WITH([[tre]], [[  --without-tre   disable TRE regex search support]])
+if test "$with_tre" = no; then
+	AC_MSG_CHECKING([[for TRE]])
+	AC_MSG_RESULT([[disabled]])
+	tre_log="no (explicitly disabled)"
 else
-	# <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=513055>
-	# "libtre-dev: /usr/lib/pkgconfig/tre.pc missing"
-	# so we look for the library even if pkg-config doesn't know about it.
-	TRE_CFLAGS=
-	TRE_LIBS=-ltre
-	AC_MSG_RESULT([[no, but let's try defaults]])
-fi
+	AC_MSG_CHECKING([[for TRE in pkg-config]])
+	if pkg-config tre; then
+		TRE_CFLAGS=`pkg-config --cflags tre`
+		TRE_LIBS=`pkg-config --libs tre`
+		AC_MSG_RESULT([[yes]])
+	else
+		# <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=513055>
+		# "libtre-dev: /usr/lib/pkgconfig/tre.pc missing"
+		# so we look for the library even if pkg-config doesn't know about it.
+		TRE_CFLAGS=
+		TRE_LIBS=-ltre
+		AC_MSG_RESULT([[no, but let's try defaults]])
+	fi
 
-AC_MSG_CHECKING([[for TRE header and library]])
-EL_SAVE_FLAGS
-CFLAGS="$TRE_CFLAGS $CFLAGS"
-LIBS="$TRE_LIBS $LIBS"
-AC_TRY_LINK([#include ],
-	[regex_t re;
-	 regmatch_t match[1];
-	 regwcomp(&re, L"zap", REG_ICASE);
-	 regwexec(&re, L"ELIZAPROGRAM", 1, match, 0);],
-	[AC_MSG_RESULT([[yes]])
-	 AC_DEFINE([HAVE_TRE_REGEX_H], [1],
-		   [Define to 1 if you have the  header file.])
-	 # TRE_CFLAGS will be used only where needed.
-	 # TRE_LIBS will be kept in LIBS and used everywhere.
-	 EL_RESTORE_FLAGS
-	 LIBS="$TRE_LIBS $LIBS"],
-	[AC_MSG_RESULT([[no]])
-	 TRE_CFLAGS=
-	 TRE_LIBS=
-	 EL_RESTORE_FLAGS])
+	AC_MSG_CHECKING([[for TRE header and library]])
+	EL_SAVE_FLAGS
+	CFLAGS="$TRE_CFLAGS $CFLAGS"
+	LIBS="$TRE_LIBS $LIBS"
+	AC_TRY_LINK([#include ],
+		[regex_t re;
+		 regmatch_t match[1];
+		 regwcomp(&re, L"zap", REG_ICASE);
+		 regwexec(&re, L"ELIZAPROGRAM", 1, match, 0);],
+		[AC_MSG_RESULT([[yes]])
+		 AC_DEFINE([CONFIG_TRE], [1],
+			   [Define as 1 to use the TRE library for regular expression searching.  This requires the  header file.])
+		 # TRE_CFLAGS will be used only where needed.
+		 # TRE_LIBS will be kept in LIBS and used everywhere.
+		 EL_RESTORE_FLAGS
+		 LIBS="$TRE_LIBS $LIBS"
+		 # Using TRE with UTF-8 in ELinks requires that wchar_t
+		 # has the same representation as unicode_val_T.  See
+		 # src/elinks.h for the check.  It would be nice to move
+		 # the check to this configure script, so that the result
+		 # could be logged, but the ac_cv_sizeof_wchar_t shell
+		 # variable set by AC_CHECK_SIZEOF is undocumented.
+		 tre_log="TRE (if wcha

Re: [elinks-dev] [gnu.org #433709] Can GPLv2-only software be compiled with GCC 4.4.0?

2009-04-26 Thread Kalle Olavi Niemitalo

Kalle Olavi Niemitalo  writes:

> Might the FSF be willing to keep providing libgcc also under
> GPLv2 (perhaps without any GCC-specific exception)?

On second thought, an exception for GPLv2 subsection 2. c) might 
be appropriate, so that GPLv2 programs based on libgcc (which is
not interactive) would not be required to display an announcement.

pgp7lHZk3I3mJ.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] Can GPLv2-only software be compiled with GCC 4.4.0?

2009-04-22 Thread Kalle Olavi Niemitalo

I am a developer of the ELinks web browser, which was originally
licensed under GPLv2-or-later but has been GPLv2-only since
ELinks 0.10.0 (released on 2004-12-24). It seems the licence of
libgcc in GCC 4.4.0 has been made incompatible with this.

In GCC 4.3.3, libgcc was licensed under GPLv2-or-later with extra
permissions.

http://gcc.gnu.org/viewcvs/tags/gcc_4_3_3_release/gcc/crtstuff.c?revision=143643&view=markup

In the recent GCC 4.4 branch, this has been changed to
GPLv3-or-later with the rather complicated GCC Runtime Library
Exception version 3.1. The GCC 4.4.0 release was then made under
these terms.

http://gcc.gnu.org/viewcvs/tags/gcc_4_4_0_release/gcc/crtstuff.c?revision=146514&view=markup
http://gcc.gnu.org/viewcvs/tags/gcc_4_4_0_release/COPYING.RUNTIME?revision=146514&view=markup
http://www.gnu.org/licenses/gcc-exception.html
http://www.gnu.org/licenses/gcc-exception-faq.html

When I build ELinks with GCC 4.3.1, several functions from
libraries provided by GCC end up in the elinks executable:

- __divdi3, __moddi3, and __udivdi3 from libgcc.a
- __do_global_dtors_aux from crtbegin.o, and
- __do_global_ctors_aux from crtend.o.

The last two functions are defined in the aforementioned
crtstuff.c. I don't know where the others are defined, or how
many inline functions get included from GCC header files.

Now suppose we build ELinks with GCC 4.4.0 and the Compilation
Process is Eligible as described in the GCC exception. With the
GCC exception, the Free Software Foundation then appears to give
permission to distribute the resulting binary under terms of our
choice. ELinks being licensed under GPLv2 only, those terms
would have to be GPLv2.

However, it seems to me that subsection 3. a) of GPLv2 requires
all the source code corresponding to the binary to be available
under GPLv2. If some of the source code comes from libgcc and
that is under GPLv3-or-later, then that requirement of GPLv2
becomes difficult to satisfy. The GCC exception only gives
permission to propagate output from the compiler; it does not
grant any permission on the source code.

GPLv2 section 3 has the "major components" exception but it does
not apply when "that component itself accompanies the
executable", which appears to be the case when e.g. Debian
distributes GCC and ELinks together. So, my understanding is
that an elinks executable built with GCC 4.4.0 cannot be legally
distributed in this way. Furthermore, dynamically linking ELinks
with libraries built using GCC 4.4.0 may be problematic too.

Is this analysis correct?

Is this an intended consequence of the GCC 4.4 licence change?

Might the FSF be willing to keep providing libgcc also under
GPLv2 (perhaps without any GCC-specific exception)?

pgp5rgcubKGT7.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] GCC Runtime Library Exception doubt

2009-04-21 Thread Kalle Olavi Niemitalo

Kalle Olavi Niemitalo  writes:

> (c) Keep compiling ELinks with older versions of GCC.
> (d) Switch to some other compiler entirely.  Perhaps TCC, or the
> (h) Make sure that ELinks does not use any libraries from GCC.

If the GPLv2 source requirement holds across dynamic linking as
the FSF would like us to believe, I think these solutions would
have to be also applied to all libraries that ELinks uses
(libidn, libgpm, libmozjs, libexpat, etc.), making them rather
difficult in practice.

pgpRRp7QzvwY8.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] GCC Runtime Library Exception doubt

2009-04-15 Thread Kalle Olavi Niemitalo

In GCC 4.3.3, libgcc was licensed under GPLv2-or-later with extra
permissions.

http://gcc.gnu.org/viewcvs/tags/gcc_4_3_3_release/gcc/config/i386/linux-unwind.h?revision=143643&view=markup

In the recent GCC 4.4 branch, this has been changed to
GPLv3-or-later with the rather complicated GCC Runtime Library
Exception version 3.1. The future GCC 4.4.0 release seems likely
to be under these terms.

http://gcc.gnu.org/viewcvs/branches/gcc-4_4-branch/gcc/config/i386/linux-unwind.h?revision=145866&view=markup
http://gcc.gnu.org/viewcvs/branches/gcc-4_4-branch/COPYING.RUNTIME?revision=145866&view=markup
http://www.gnu.org/licenses/gcc-exception.html
http://www.gnu.org/licenses/gcc-exception-faq.html

GPLv2 section 3 has the "major components" exception but I don't
see how that could apply when ELinks and GCC are being
distributed as part of the same operating system.

What to do?

(a) Find some creative interpretation that allows binaries to be
distributed.

(b) Stop distributing binaries. Well we don't have any at
http://elinks.cz/ anyway.

(d) Switch to some other compiler entirely. Perhaps TCC, or the
pcc in NetBSD, or LLVM.

(e) Relicense ELinks so it becomes GPLv3 compatible: most likely
under GPLv2-or-later. This would also allow using
libsmbclient. In the process, it might be feasible to add an
exception for OpenSSL too. (There are notes in AUTHORS about
some people already allowing such relicensing.)

(f) Relicense ELinks so it becomes GCC compatible even though not
GPLv3 compatible in general. For example, add an exception
saying that ELinks binaries can be distributed even if they
contain compiler-specific library code whose source is not
available under GPLv2, as long as that source is available
under some other version of GPL.

(g) Convince the FSF to allow distributing GCC runtime library
sources under some GPLv2 compatible licence. I guess it
can't be the same licence as in GCC 4.3.3 because of the
perceived problem with plugins. Plain GPLv2 without
exceptions might have the best chance of being accepted by
the FSF but it would also nullify any OpenSSL exception added
to ELinks in the future.

(h) Make sure that ELinks does not use any libraries from GCC.
With "gcc -Wl,-M", I'm seeing __divdi3, __moddi3, and
__udivdi3 from libgcc.a; __do_global_dtors_aux from
crtbegin.o; and __do_global_ctors_aux from crtend.o.

pgpyWc8n9zRlB.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] ELinks 0.11.6 released; please update Free Software Directory

2009-03-21 Thread Kalle Olavi Niemitalo

I have released ELinks 0.11.6 tonight.  Please update
, which currently lists
0.11.5 as the latest version.

The CVS file at
:pserver:anonym...@cvs.savannah.gnu.org:/sources/directory/directory/Elinks.txt,v
however still refers to ELinks 0.11.3.  Has the maintenance of
the Free Software Directory been shifted from CVS to somewhere
else?


pgpxpTLKM6XVN.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] release 0.11.6 this weekend, 0.12pre2 a week later?

2009-03-21 Thread Kalle Olavi Niemitalo

I'd like to release ELinks 0.11.6 this weekend.  I am making the
packages & signatures now and intend push them to the servers
early tomorrow unless someone pushes to elinks-0.11 first.
Please reply if you'd like to change this schedule.

ELinks 0.12pre3 should also be released but I'd like to delay
that to the next weekend so that there is time to fix bug 1047
(C99 inline functions).


pgpvza7wkj1NT.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] error: format string argument not a string type

2009-03-17 Thread Kalle Olavi Niemitalo

(Crossposted to gcc-help and elinks-dev)

In ELinks, we're using unsigned char almost everywhere.
This convention was apparently inherited from Links.
I think the purpose might be to reduce the need for casts
in  calls and charset conversions.

Then we have functions like

  void elinks_debug(unsigned char *fmt, ...);

that take a format string and arguments.  It would be nice to
have GCC check that the types of those arguments match the format
string.  But if I declare the function as

  void elinks_debug(unsigned char *fmt, ...)
__attribute__((format(printf, 1, 2)));

then GCC 4.3.1 rejects it, even with -Wno-pointer-sign:

/home/Kalle/src/elinks-0.12/src/util/error.h:23: error: format string argument 
not a string type

If I change the unsigned char * to char *, then this error goes
away.  But is there any other way to make GCC check the format
arguments without this error?
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] Patch for porting Elinks to OpenSolaris

2009-03-14 Thread Kalle Olavi Niemitalo

Kalle Olavi Niemitalo  writes:

> However I've now looked at C99 6.7.4p3 and it specifically
> mentions modifiable objects.  So I wonder if we could just put
> some const in elinks_ulongcat to make the objects unmodifiable.

I have pushed this change to the elinks-0.11 branch
and it is included in last night's snapshot.
http://elinks.cz/download/elinks-current-0.11.tar.gz

Can you report whether the snapshot builds on OpenSolaris?

pgpP4I3k8GYzv.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] option description wrapping

2009-03-12 Thread Kalle Olavi Niemitalo

Kalle Olavi Niemitalo  writes:

> However, these patches alter the description strings of many
> options, and the translations will have to be updated.  I
> don't know if it's right to push such changes to 0.12pre2.GIT.

Well, I pushed them there anyway: only da.po and pl.po had been
updated since 0.12pre1, so it's not like a lot of work was wasted.
It seems important to keep translations similar in elinks-0.12
and master to minimize merge conflicts that are difficult to
resolve correctly when one doesn't understand the language.

This reminds me, I read that some project removed source line
references (#: comments) from PO files in its version control
system, perhaps to avoid uninteresting merge conflicts.  Should
we do the same?  The source line references could be added in
labelled commits such as elinks-0.13.2, and again removed
immediately afterwards.

pgpX0DJ29GCSv.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] option description wrapping

2009-03-08 Thread Kalle Olavi Niemitalo

ELinks displays the description of some options in a rather ugly
way on 80x24 terminals:

   +- Info -+
   ||
   |  Name: paranoid_security   |
   |  Type: Boolean [0|1]   |
   |  Value: 0  |
   ||
   |  Description:  |
   |  When enabled, we'll require three dots in cookies domain for  |
   |  all   |
   |  non-international domains (instead of just two dots). Some|
   |  countries |
   |  have generic second level domains (eg. .com.pl, .co.uk) and   |
   |  allowing  |
   |  sites to set cookies for these generic domains could  |
   |  potentially be|
   |  very bad. Note, it is off by default as it breaks a lot of|
   |  sites.|
   ||
   |[ OK ]  |
   ++

Half of the lines are short and half are long.
I have made some patches that correct the output to:

   +- Info -+
   ||
   |  Name: paranoid_security   |
   |  Type: Boolean [0|1]   |
   |  Value: 0  |
   ||
   |  Description:  |
   |  When enabled, we'll require three dots in cookies domain for  |
   |  all non-international domains (instead of just two dots). |
   |  Some countries have generic second level domains (eg. |
   |  .com.pl, .co.uk) and allowing sites to set cookies for these  |
   |  generic domains could potentially be very bad. Note, it is|
   |  off by default as it breaks a lot of sites.   |
   ||
   |[ OK ]  |
   ++

However, these patches alter the description strings of many
options, and the translations will have to be updated.  I
don't know if it's right to push such changes to 0.12pre2.GIT.
Would it be better to push the changes to 0.13.GIT only?
Or wait for the 0.12.0 release and then push to 0.13.GIT?

These patches are now at 
branches 0.12/option-doc-wrap and 0.13/option-doc-wrap.


pgpZQqhDEwyVI.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] Patch for porting Elinks to OpenSolaris

2009-03-04 Thread Kalle Olavi Niemitalo

Muktha Narayan  writes:

> Kalle Olavi Niemitalo wrote:
>> Because ELinks is violating a C99 requirement, rather than
>> something specific to Sun, I don't think it's right to make an
>> exception for the Sun compiler.  Instead, we should make the
>> functions not inline and measure how that affects the speed.
>> If it hurts too much, then define e.g. static inline int
>> inline_elinks_ulongcat() and make both int elinks_ulongcat()
>> and int elinks_longcat() call that.  GCC should generate from
>> that approximately the same code as from the current sources.
>>   
> Attached  is the modified patch incorporating the above
> comments. Please confirm if the patch is acceptable.

Actually I hoped to see some numbers about how much slower
ELinks gets if you just drop the inline specifiers.  If the
difference is negligible, then it is better not to complicate
the source code with wrappers.

However I've now looked at C99 6.7.4p3 and it specifically
mentions modifiable objects.  So I wonder if we could just put
some const in elinks_ulongcat to make the objects unmodifiable.

diff --git a/src/session/session.c b/src/session/session.c
index 3cd9b5a..73459f2 100644
--- a/src/session/session.c
+++ b/src/session/session.c
@@ -423,7 +423,9 @@ load_ecmascript_imports(struct session *ses, struct 
document_view *doc_view)
 #define load_ecmascript_imports(ses, doc_view)
 #endif
 
-inline void
+/* can't be inline according to C99 6.7.4p3 because it uses static
+ * request_frameset() and is not itself static */
+void
 load_frames(struct session *ses, struct document_view *doc_view)
 {
struct document *document = doc_view->document;
diff --git a/src/util/conv.c b/src/util/conv.c
index 68ae545..d29a61d 100644
--- a/src/util/conv.c
+++ b/src/util/conv.c
@@ -52,9 +52,9 @@ elinks_ulongcat(unsigned char *s, unsigned int *slen,
unsigned char fillchar, unsigned int base,
unsigned int upper)
 {
-   static unsigned char unum[]= "0123456789ABCDEF";
-   static unsigned char lnum[]= "0123456789abcdef";
-   unsigned char *to_num = (unsigned char *) (upper ? &unum : &lnum);
+   static const unsigned char unum[]= "0123456789ABCDEF";
+   static const unsigned char lnum[]= "0123456789abcdef";
+   const unsigned char *to_num = (upper ? unum : lnum);
unsigned int start = slen ? *slen : 0;
unsigned int nlen = 1; /* '0' is one char, we can't have less. */
unsigned int pos = start; /* starting position of the number */


pgpAfuS5pv5di.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] BIG_READ changed from 65536 to 655360 for no reason?

2009-02-28 Thread Kalle Olavi Niemitalo

Witek, in your commit 4a2fd2d964ef92a10219a3b5e4cce3a8b3be7782 to
elinks-0.12, you changed BIG_READ from 65536 to 655360.  Was this
change necessary for bug 1017?  The commit message says you
cherry picked it from 3131de4767475097eb60bb1641b39e6b647eb289,
but there is no similar BIG_READ change in that commit.

A similar change had been made in 0.13.GIT as part of bug 1008
(uploading big files), which has not been fixed in elinks-0.12.
However, it seems the BIG_READ change in bug 1008 was actually
an accident; bug 1008 was intended to affect only POST requests,
not decompression.

Commit b8b54a53259ea15014d7595e0f9e1475ae4aecf1 is where I merged
the bug 1008 changes to ELinks 0.13.GIT.  In those changes, you
originally gave BIG_READ an additional meaning: how large blocks
ELinks should read from a file that it's streaming to a server.
At the same time, you changed it to 655360, perhaps to make
uploading faster.  However, I then added read_http_post() and
made both HTTP and CGI use it, and that function does not use
BIG_READ any more.  Instead, its callers provide a buffer of size
POST_BUFFER_SIZE.

Thus, it seems BIG_READ has been changed from 65536 to 655360 in
elinks-0.12 and master for no reason.  This consumes more memory
than before but I guess users can afford that nowadays.  However,
I worry that the large value can perhaps hide bugs in the
decompression code.  I mean, perhaps there is some bug that
occurs only when the compressed or decompressed data is over
BIG_READ bytes long.  If BIG_READ were smaller, then any such
bugs would be easier to find.


pgpIPaSPT7hti.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] Patch for porting Elinks to OpenSolaris

2009-02-18 Thread Kalle Olavi Niemitalo

"Mark A. Carlson"  writes:

> +#if defined (__SUNPRO_C)
> +static inline void
> +#else
>  inline void
> +#endif
>  load_frames(struct session *ses, struct document_view *doc_view)

This looks like .
That bug was reported against ELinks 0.12pre1 though.
I haven't heard about such problems with 0.11.5 before.
It looks like 0.10.6 has the same bug; can you confirm?

Because ELinks is violating a C99 requirement, rather than
something specific to Sun, I don't think it's right to make an
exception for the Sun compiler.  Instead, we should make the
functions not inline and measure how that affects the speed.
If it hurts too much, then define e.g. static inline int
inline_elinks_ulongcat() and make both int elinks_ulongcat()
and int elinks_longcat() call that.  GCC should generate from
that approximately the same code as from the current sources.

pgpYxI2JCG2hq.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] document_view, view_state... what's the difference?

2009-02-08 Thread Kalle Olavi Niemitalo

In ELinks, we have various interrelated structures:
- struct document
- struct view_state
- struct document_view
- struct ecmascript_interpreter
- struct location

struct document is a canvas on which a (usually HTML) document
has been rendered for some charset.  It can be displayed on a
terminal with minimal conversions.  It can be kept in the
formatted document cache when it is not being displayed.
It can be displayed in multiple tabs at the same time, I think.
But then there is also document.timeout, which AFAIK should be
local to each tab.

struct location is what is kept in the history of each tab.

I don't understand why we have both struct view_state and struct
document_view.  When we're adding a member, how do we decide in
which of the two structures it belongs?

Back in August 2008, I searched for code that connects these
structures to each other or disconnects them again, and wrote the
following notes.  But I'm sad to say that I didn't get anywhere
From there.

IIRC, this is relevant to bug 765 or 771.


struct document *document_view::document;
DETACH detach_formatted: doc_view->document = NULL;
struct view_state *document_view::vs;
ATTACH render_document: doc_view->vs = vs;
DETACH render_document: vs->doc_view->vs = NULL;
ATTACH render_document: doc_view->document = document;
DETACH ses_forward: vs->doc_view->vs = NULL;
ATTACH draw_formatted: ses->doc_view->vs = &cur_loc(ses)->vs;
ATTACH goto_mark: vs->doc_view->vs = vs;
DETACH detach_formatted: doc_view->vs = NULL;
DETACH destroy_vs: vs->doc_view->vs = NULL;
struct document_view *view_state::doc_view;
DETACH render_document: vs->doc_view = NULL;
ATTACH render_document: vs->doc_view = doc_view;
DETACH ses_forward: vs->doc_view = NULL;
ATTACH goto_mark: vs->doc_view = doc_view;
DETACH detach_formatted: doc_view->vs->doc_view = NULL;
DETACH destroy_vs: vs->doc_view = NULL;
ATTACH copy_vs: copy_struct(dst, src);
DETACH copy_vs: dst->doc_view = NULL;
struct ecmascript_interpreter *view_state::ecmascript;
DETACH ecmascript_put_interpreter: interpreter->vs->ecmascript = NULL;
ATTACH ecmascript_reset_state: vs->ecmascript = 
ecmascript_get_interpreter(vs);
RETACH goto_mark: vs->ecmascript = ecmascript;
DETACH copy_vs: dst->ecmascript = NULL;
struct view_state location::vs;
FOLLOW render_document_frames: vs = &cur_loc(ses)->vs;
FOLLOW render_document_frames: cur_loc(ses)->vs.current_link = n;
FOLLOW l_current_url: struct view_state *vs = &cur_loc(lua_ses)->vs;
FOLLOW script_hook_pre_format_html: struct view_state *vs = 
&cur_loc(ses)->vs;
FOLLOW smjs_elinks_get_view_state: vs = &cur_loc(smjs_ses)->vs;
MODIFY copy_location: copy_vs(&dst->vs, &src->vs);
MODIFY destroy_location: destroy_vs(&loc->vs, 1);
FOLLOW reload: loc->vs.ecmascript_fragile = 1;
FOLLOW ses_forward: vs = &loc->vs;
FOLLOW draw_frames: l = &cur_loc(ses)->vs.current_link;
FOLLOW next_frame: vs = &cur_loc(ses)->vs;
LIST_OF(struct frame) location::frames;
struct view_state frame::vs;
FOLLOW format_frame: vs = &frame->vs;
MODIFY try_resolve_frame: ecmascript_reset_state(&target->vs);
MODIFY copy_location: copy_vs(&new_frame->vs, &frame->vs);
MODIFY destroy_location: destroy_vs(&frame->vs, 1);
MODIFY request_frame: init_vs(&frame->vs, uri, -1);
FOLLOW reload: vs = &frame->vs;


CALLER GRAPHS
-

detach_formatted
// Parameter struct document_view *doc_view; detaches that from 
view_state and document.
render_document
// Parameters struct view_state *vs and struct document_view 
*doc_view;
// attaches those to each other, calling 
detach_formatted(doc_view) and
// detaching vs from any other document_view.
format_frame
format_frames
@format_frames
@render_document_frames
@render_document_frames
@dump_formatted
render_document_frames
update_status
change_hook_insert_mode
change_hooks...
change_hook_ui
@change_hooks
unibar_set_property
menubar_class...
statusbar_class...
init_session
init_saved_session
decode_session_info 
...
decode_session_info
handle_interlink_event ...
do_follow_url
follow_url

Re: [elinks-dev] [PATCH] Fix double-free crash if EOF immediately follows .

2008-12-30 Thread Kalle Olavi Niemitalo

Witold Filipczyk  quotes:

> Memory leak by 1 bytes
> List of blocks:
> 0xa287e58:1 @ alloc'd at link.c:973

That is bug 762, already present in ELinks 0.10.6.
If there are no other objections, I'll push the patch tomorrow.


pgpkV6wJEqGbB.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] [PATCH] Fix double-free crash if EOF immediately follows .

2008-12-29 Thread Kalle Olavi Niemitalo

look_for_link() used to return 0 both when it found the closing 
tag, and when it hit the end of the file.  In the first case, it also
added *menu to the memory_list; in the second case, it did not.  The
caller get_image_map() supposedly distinguished between these cases by
checking whether pos >= eof, and freed *menu separately if so.

However, if the  was at the very end of the HTML file, so that
not even a newline followed it, then look_for_link() left pos == eof
even though it had found the  and added *menu to the memory_list.
This made get_image_map() misinterpret the result and mem_free(*menu)
even though *menu had already been freed as part of the memory_list;
thus the crash.

To fix this, make look_for_link() return -1 instead of 0 if it hits
EOF without finding the .  Then make get_image_map() check the
return value instead of comparing pos to eof.

Alternatively, look_for_link() could have been changed to decrement
pos between finding the  and returning 0.  Then, the pos >= eof
comparison in get_image_map() would have been false.  That scheme
would however have been a bit more difficult to understand and
maintain, I think.

Reported by Paul B. Mahol.
---
 NEWS   |1 +
 src/document/html/parser.c |   17 -
 test/imgmap2.html  |5 +
 3 files changed, 18 insertions(+), 5 deletions(-)
 create mode 100644 test/imgmap2.html

diff --git a/NEWS b/NEWS
index ab36a8e..ebd7c80 100644
--- a/NEWS
+++ b/NEWS
@@ -11,6 +11,7 @@ ELinks 0.12pre2.GIT now:
 To be released as 0.12pre3, 0.12rc1, or even 0.12.0.  This branch also
 includes the changes listed under ``ELinks 0.11.5.GIT'' below.
 
+* critical: Fix double-free crash if EOF immediately follows .
 * Preserve newlines in hidden input fields, and submit them as CRLF.
   Previously, they could turn into spaces or disappear entirely.
 * Perl scripts can use modules that dynamically load C libraries, like
diff --git a/src/document/html/parser.c b/src/document/html/parser.c
index 4d8c111..d9e911a 100644
--- a/src/document/html/parser.c
+++ b/src/document/html/parser.c
@@ -615,6 +615,9 @@ look_for_tag(unsigned char **pos, unsigned char *eof,
return 0;
 }
 
+/** @return -1 if EOF is hit without the closing tag; 0 if the closing
+ * tag is found (in which case this also adds *...@a menu to *...@a ml); or
+ * 1 if this should be called again.  */
 static int
 look_for_link(unsigned char **pos, unsigned char *eof, struct menu_item **menu,
  struct memory_list **ml, struct uri *href_base,
@@ -632,7 +635,7 @@ look_for_link(unsigned char **pos, unsigned char *eof, 
struct menu_item **menu,
(*pos)++;
}
 
-   if (*pos >= eof) return 0;
+   if (*pos >= eof) return -1;
 
if (*pos + 2 <= eof && ((*pos)[1] == '!' || (*pos)[1] == '?')) {
*pos = skip_comment(*pos, eof);
@@ -647,7 +650,7 @@ look_for_link(unsigned char **pos, unsigned char *eof, 
struct menu_item **menu,
if (!c_strlcasecmp(name, namelen, "A", 1)) {
while (look_for_tag(pos, eof, name, namelen, &label));
 
-   if (*pos >= eof) return 0;
+   if (*pos >= eof) return -1;
 
} else if (!c_strlcasecmp(name, namelen, "AREA", 4)) {
/* FIXME (bug 784): options->cp is the terminal charset;
@@ -765,6 +768,7 @@ get_image_map(unsigned char *head, unsigned char *pos, 
unsigned char *eof,
 {
struct conv_table *ct;
struct string hd;
+   int look_result;
 
if (!init_string(&hd)) return -1;
 
@@ -785,10 +789,13 @@ get_image_map(unsigned char *head, unsigned char *pos, 
unsigned char *eof,
 
*ml = NULL;
 
-   while (look_for_link(&pos, eof, menu, ml, uri, target_base, ct, 
options))
-   ;
+   do {
+   /* This call can modify both *ml and *menu.  */
+   look_result = look_for_link(&pos, eof, menu, ml, uri,
+   target_base, ct, options);
+   } while (look_result > 0);
 
-   if (pos >= eof) {
+   if (look_result < 0) {
freeml(*ml);
mem_free(*menu);
return -1;
diff --git a/test/imgmap2.html b/test/imgmap2.html
new file mode 100644
index 000..e96e184
--- /dev/null
+++ b/test/imgmap2.html
@@ -0,0 +1,5 @@
+Double-free crash in USEMAP
+
+
+http://elinks.cz/"; alt="see 
this?">
+
\ No newline at end of file
-- 
1.6.0.6.4.g22c5



pgpW7qNKcoq7t.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] crash on last usemap

2008-12-29 Thread Kalle Olavi Niemitalo

أحمد المحمودي  writes:

> I confirm that I got the same problem with elinks 0.13 (20081129 
> snapshot).

ELinks 0.10.6, 0.11.0, 0.11.5, 0.12pre1, and 0.12pre2 all crash.
The trigger is that there is no newline after the final .
Small test case:

Double-free crash in USEMAP


http://elinks.cz/"; alt="see 
this?">



pgpXNf0378jHA.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] Trojan warning, and elinks-dev moderation change (was: Merry Christmas!)

2008-12-24 Thread Kalle Olavi Niemitalo

"William" writes:

> William has just posted a Xmas ecard.
> To view your eCard, click on the following link:

That site is distributing "ecard.exe" containing references to
OpenSSL and DNSAPI.dll.  It's probably a Trojan horse of some kind.

The elinks-dev list used to let through messages from
non-subscribers if they didn't look at all like spam.  That
feature has now let through three spams this month, so I've
disabled it for now; such messages will be moderated.

pgpBKkPSz4BHE.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] [PATCH] Clicking a link with the mouse exits cursor-routing mode

2008-12-23 Thread Kalle Olavi Niemitalo

Before this patch, if you first moved the cursor to link X with
move-cursor-up and similar actions, and then clicked link Y with the
mouse, ELinks would activate link X, i.e. not the one you clicked.
This happened because the NAVIGATE_CURSOR_ROUTING mode was left
enabled and made ELinks ignore the doc_view->vs->current_link
member that ELinks had updated according to the click.
Make ELinks return the session to NAVIGATE_LINKWISE mode, so that
the update takes effect.

Reported by Paul B. Mahol.
---
"Paul B. Mahol"  writes:

> Using hjkl to move cursor and after that mouse to activate another
> link will cause that it will activate link that is higlighted with
> cursor via hjkl keys(if there is no link highlighted with hjkl keys
> bug doesnt happen) and not one that is pointed with mouse.

Thanks for the report.  I think this patch (for 0.11.5.GIT but
should apply to elinks-0.12 and master too) fixes it.  If you
agree, I'll push this to elinks-0.11 and elinks-0.12.

 NEWS   |2 ++
 src/viewer/text/view.c |1 +
 2 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/NEWS b/NEWS
index dc844ab..1abf9e2 100644
--- a/NEWS
+++ b/NEWS
@@ -15,6 +15,8 @@ To be released as 0.11.6.
 * major bug 1004: ignore locales when comparing HTML element names and
   similar strings, so e.g. ``title'' matches ``TITLE'' even in the
   Turkish locale
+* minor: clicking a link with the mouse activates that link, rather
+  than the one selected with move-cursor-* actions

 ELinks 0.11.5:
 --
diff --git a/src/viewer/text/view.c b/src/viewer/text/view.c
index ca7c8d5..330cc3d 100644
--- a/src/viewer/text/view.c
+++ b/src/viewer/text/view.c
@@ -840,6 +840,7 @@ frame_ev_mouse(struct session *ses, struct document_view 
*doc_view, struct term_
enum frame_event_status status = FRAME_EVENT_REFRESH;

doc_view->vs->current_link = link - doc_view->document->links;
+   ses->navigate_mode = NAVIGATE_LINKWISE;

if (!link_is_textinput(link)) {

-- 
1.6.0.5.7.gbebc6
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] ELinks Icons

2008-12-14 Thread Kalle Olavi Niemitalo

أحمد المحمودي  writes:

>   How about Creative Commons with Share Alike license for the icons ?

I would actually prefer a non-copyleft licence for icons,
but a copyleft licence is okay too.

The licence should be compatible with GNU GPL v2-or-later
however, so that there is no doubt on whether we can include the
icon in the executable if we ever make a graphical version of
ELinks.  If CC-SA is not GPL compatible as such, the icon should
be dual licensed.


pgprpQ3IcUxCA.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] ELinks Icons

2008-12-07 Thread Kalle Olavi Niemitalo

Thanks for the proposed icons.  Two people on the elinks-dev list
have commented on them so far.  The elinks5_* icons were
preferred and elinks7_* came second.

In my view though, the lower-case "e" of elinks5_* is too similar
to the Internet Explorer logo.  Besides, it might make the
incorrect "eLinks" spelling more common.  I don't think it is
necessary to have any sort of "E" or chain in the icon.

Here are comments from someone I asked in RL, translated by me:

"elinks1: This one I like best.  The blue sphere could depict the
global dimension of elinks.  The spherical symbol would be easy
to recognize as a browser, because for example Firefox and Safari
also have roundish symbols.  However, the frame around the symbol
distinguishes it from Firefox and especially from Safari, of
which is it more reminiscent.

elinks5: My attention is caught in the e letter, in which I see
the side profile of a gray face.  The shape is bawling angrily,
with the mouth wide open and the eyes flaming.  The shape can
also look stupid, because in the place of the blue rectangular
eye, there is a hole straight to the blue background, that is,
the shape would appear to have a hollow, empty head.  Quite an
unpleasant icon, irritating even.

elinks7: A gray icon, in which there is a piece of chain.  There
it is, but it doesn't seem to reach anywhere further - sure
doesn't remind of any global dimension.  The gray icon is too
colorless.  At least in my own computer, it wouldn't be easy to
distinguish from the grey background of the dock."

Personally, I hoped to see non-rectangular icons, with
transparent backgrounds.  Although elinks7 has a rectangular
frame, it had one person liking it and nobody objecting to it, so
I could add that one to the source tree if we can agree on the
licensing.  Unless you first want to try something else, that is.

Most of ELinks is licensed under GNU GPL v2, but I think that is
too restrictive for icons because they often appear in screen
shots and people distributing those should not be required to
provide transparent or vector versions of the icons.


pgpo2V8jC5srP.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] "ELinks Graphics from Hitmeister"

2008-11-14 Thread Kalle Olavi Niemitalo

A representative of hitmeister.de contacted Fonseca and offered
to provide a logo or other graphics for ELinks, in exchange for a
link to their site.  I suggested they could create the icon that
was requested in .  The link would
then go in authors.html or credits.html.  As there used to be a
link to HSTI in credits.html, I believe this is within the
policies of the project.


pgpNj2r2AzqQm.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] [PATCH] Fixed compiler errors and warnings in src/util/random.c where CONFIG_SSL undefined

2008-11-09 Thread Kalle Olavi Niemitalo

Thank you for the patches.  The random number patch is now in the
master (0.13.GIT) branch at elinks.cz, and the CRLF patch is in
both elinks-0.12 (0.12pre2.GIT) and master.  They should get
included in tonight's snapshots, too.


pgpc5ozMx8ruQ.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] Are Unicode Data Files GPLv2 compatible?

2008-11-09 Thread Kalle Olavi Niemitalo

I got the following response from an FSF volunteer some time ago.

--- Begin Message ---

Hello,

Please accept our apologies for the delay in getting back to you. We
rely on volunteer effort and often have difficulties keeping.

> The following license is found at
> .
> Is it compatible with version 2 of the GNU General Public License?

The license at Exhibit 1 above is compatible with both versions 2 and 3
of the GNU GPL.

I hope this answer is of help, however late.

--
I am not a lawyer, the above is not legal advice

   Regards, Yoni Rabkin





--- End Message ---


pgpyq4p7inFW5.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] [PATCH] Support for newlines in hidden input fields.

2008-11-02 Thread Kalle Olavi Niemitalo

Peter Collingbourne <[EMAIL PROTECTED]> writes:

> Currently ELinks reinterprets a literal newline within the value
> attribute of a hidden input field as a space character.  This is
> inconsistent with the HTML specification and the behaviour of other
> browsers.  This patch fixes the problem.  Some changes are also
> made to ensure that these fields are URL encoded using CR LF pairs
> when submitted.

The CR LF requirements are in section 17.13.4 of HTML 4.01.

Can you provide a test case with:
- Two types of controls: hidden controls and textareas.
- Three types of newlines: CR, LF, and CRLF.
- Three ways of getting the newlines into the controls:
  character entity references, raw control characters, and
  JavaScript property assignments.
Thus making 2*3*3=18 combinations in total.
It would be great if this test could be automated.
Perhaps with local CGI support and elinks -auto-submit?

ELinks is currently licensed under GPLv2 only.  I hope we can
eventually change the licence to also allow later versions of
GPL and permit linking with OpenSSL.  Do you allow such
relicensing for your patch?

Do you give permission to add your name and email address to the
commit information, to the AUTHORS file, and similar places
(e.g. a list of contributors in release notes)?  The cia.vc and
ohloh.com web sites are already collecting this information and
others might do so in the future.

pgpQ1Ph15j7p0.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] The Links/Links2/ELinks browsers are unusable on Debian GNU/Hurd

2008-11-02 Thread Kalle Olavi Niemitalo

Fabienne Ducroquet <[EMAIL PROTECTED]> writes:

> Kalle's workaround[0] for this bug works for Links too, I put the diff 
> for Links 2.2 at the end of this e-mail in case you want to include it 
> in your package (if Kalle agrees).

I have not tested Links in GNU/Hurd, but if you think my patch
would help Links too, please go ahead and use it.  The current
licence of Links (GPLv2 or later, with OpenSSL exception) is OK.

I just added a comment about the ELinks workaround to
 and I suggest you do
the same if you alter Links.  As a reminder to revert such
workarounds when they are no longer necessary.

pgpJMomu4lvXZ.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] Message queues instead of callbacks

2008-10-31 Thread Kalle Olavi Niemitalo

Witold Filipczyk <[EMAIL PROTECTED]> writes:

> When there is no such id in the hash, that's mean that the object
> disappeared and the message is ignored.

If there is a pointer in the message, this could leak the memory
to which the pointer points.  GC would fix that, of course.

pgplVCMN7GJQR.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] Premature optimization

2008-10-14 Thread Kalle Olavi Niemitalo

Witold Filipczyk <[EMAIL PROTECTED]> wrote a few months ago:

> I read in the zziplib docs that a conditional call is ten times slower
> than an uncoditional one. Is it true?

Even if it is true for calls to known functions, it might not be
true for calls via function pointers.

> In src/document/html/parser/parse.c (start_element, end_element)
> there are:
> if (ei->open) ei->open()
> and
> if (ei->close) ei->close()
>
> Wouldn't be ELinks faster and simpler if all (close and open) functions
> be defined?

Measure it and see?
Bug 545 comment 8 shows that 78% of time was spent in CSS.
I expect this change would have a negligible effect on speed.

The calls would be a bit simpler, but there are only two of them,
so it doesn't matter much for readability.
However, the elements[] array might become a bit harder to read
if you replaced NULLs with some html_noop function pointers.
Currently, the few html_*_close functions stand out really well.
Anyway, if you want to make this change, it's OK with me.


pgpBoq4zCMd1G.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] Scrolling bittorrent items

2008-10-12 Thread Kalle Olavi Niemitalo

Witold Filipczyk <[EMAIL PROTECTED]> writes:

> Some dialog boxes dont fit on the screen.
> Here are 3 concatenated patches, which fixes that issue.
> When a dialog is displayed on the screen for the first
> time the bottom of it is shown.

You have put newer patches at:
http://repo.or.cz/w/elinks/witekfl.git?a=shortlog;h=refs/heads/scroll
git://repo.or.cz/elinks/witekfl.git scroll

I added a few commits here:
http://repo.or.cz/w/elinks/kon.git?a=shortlog;h=refs/heads/0.13/witekfl-scroll-dialog
git://repo.or.cz/elinks/kon.git witekfl-scroll-dialog

(The last commit in your branch was a merge from master.
I omitted that merge and did my own, to simplify the commit graph
a little.  The final result should be the same anyway.)

I'd like to push this to master, unless you find something wrong
with my changes.

pgpf38XrD9Sak.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] Are Unicode Data Files GPLv2 compatible?

2008-10-07 Thread Kalle Olavi Niemitalo

The following license is found at
.
Is it compatible with version 2 of the GNU General Public License?
In particular, I have doubts about point (c), which requires
notices not only in the modified files but also in documentation,
and thus appears a bit more restrictive than GPLv2 clause 2. a).
I guess it would be allowed by GPLv3 clause 7. c) though.

If this license is not GPLv2 compatible, do you know some source
From which we could get Unicode mappings for ISO 8859, KOI8-R,
and various Windows codepages under a GPLv2 compatible license?
This is for the sake of ELinks, which has a number of unclearly
licensed (and occasionally incorrect) charset mappings in its
source tree and converts the data into arrays in the executable.

I see the ICU library uses almost the same license; it just omits
requirement (c) and doesn't mention data files.  So if (c) is the
only problem, we could possibly use ICU; it would be technically
better than relying on the locale support in libc.  However, it
would be easiest for us to use Unicode data files.

--

UNICODE, INC. LICENSE AGREEMENT - DATA FILES AND SOFTWARE

Unicode Data Files include all data files under the directories
http://www.unicode.org/Public/, http://www.unicode.org/reports/, and
http://www.unicode.org/cldr/data/ . Unicode Software includes any source
code published in the Unicode Standard or under the directories
http://www.unicode.org/Public/, http://www.unicode.org/reports/, and
http://www.unicode.org/cldr/data/.

NOTICE TO USER: Carefully read the following legal agreement. BY
DOWNLOADING, INSTALLING, COPYING OR OTHERWISE USING UNICODE INC.'S DATA
FILES ("DATA FILES"), AND/OR SOFTWARE ("SOFTWARE"), YOU UNEQUIVOCALLY
ACCEPT, AND AGREE TO BE BOUND BY, ALL OF THE TERMS AND CONDITIONS OF THIS
AGREEMENT. IF YOU DO NOT AGREE, DO NOT DOWNLOAD, INSTALL, COPY,
DISTRIBUTE OR USE THE DATA FILES OR SOFTWARE.

COPYRIGHT AND PERMISSION NOTICE

Copyright © 1991-2008 Unicode, Inc. All rights reserved. Distributed
under the Terms of Use in http://www.unicode.org/copyright.html.

Permission is hereby granted, free of charge, to any person obtaining a
copy of the Unicode data files and any associated documentation (the
"Data Files") or Unicode software and any associated documentation (the
"Software") to deal in the Data Files or Software without restriction,
including without limitation the rights to use, copy, modify, merge,
publish, distribute, and/or sell copies of the Data Files or Software,
and to permit persons to whom the Data Files or Software are furnished to
do so, provided that (a) the above copyright notice(s) and this
permission notice appear with all copies of the Data Files or Software,
(b) both the above copyright notice(s) and this permission notice appear
in associated documentation, and (c) there is clear notice in each
modified Data File or in the Software as well as in the documentation
associated with the Data File(s) or Software that the data or software
has been modified.

THE DATA FILES AND SOFTWARE ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF
THIRD PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR HOLDERS
INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL INDIRECT
OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS
OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR
OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
PERFORMANCE OF THE DATA FILES OR SOFTWARE.

Except as contained in this notice, the name of a copyright holder shall
not be used in advertising or otherwise to promote the sale, use or other
dealings in these Data Files or Software without prior written
authorization of the copyright holder.


pgpXyggJ9dCp3.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] charset licences in ELinks, and debian/copyright

2008-10-07 Thread Kalle Olavi Niemitalo

Kalle Olavi Niemitalo <[EMAIL PROTECTED]> writes:

> How about:
> - We add that text into COPYING, with a list of the files to
>   which it applies.
> - We replace all the bundled charset mapping files with current
>   versions from www.unicode.org where available.
> - We add to each such file a comment like:
>   # The following data has been downloaded from
>   # <http://www.unicode.org/Public/> and is thus covered by the
>   # Unicode, Inc. License agreement included in the COPYING file
>   # of ELinks, regardless of the terms shown below.  This comment
>   # and the lines above were not in the original data.

I've pushed a preview to:
git://repo.or.cz/elinks/kon.git 0.12/unicode
http://repo.or.cz/w/elinks/kon.git?a=shortlog;h=refs/heads/0.12/unicode


pgpCBocRSeiRW.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] charset licences in ELinks, and debian/copyright

2008-10-06 Thread Kalle Olavi Niemitalo

Y Giridhar Appaji Nag <[EMAIL PROTECTED]> writes:

> Microsoft is a part of the Unicode consortium and since these files are
> distributed at unicode.org I assumed them all to be of the same license.

Oh, look here: http://www.unicode.org/copyright.html#Exhibit1

| UNICODE, INC. LICENSE AGREEMENT - DATA FILES AND SOFTWARE
|
| Unicode Data Files include all data files under the directories
| http://www.unicode.org/Public/, http://www.unicode.org/reports/, and
| http://www.unicode.org/cldr/data/ . Unicode Software includes any source
| code published in the Unicode Standard or under the directories
| http://www.unicode.org/Public/, http://www.unicode.org/reports/, and
| http://www.unicode.org/cldr/data/.
|
| NOTICE TO USER: Carefully read the following legal agreement. BY
| DOWNLOADING, INSTALLING, COPYING OR OTHERWISE USING UNICODE INC.'S DATA
| FILES ("DATA FILES"), AND/OR SOFTWARE ("SOFTWARE"), YOU UNEQUIVOCALLY
| ACCEPT, AND AGREE TO BE BOUND BY, ALL OF THE TERMS AND CONDITIONS OF THIS
| AGREEMENT. IF YOU DO NOT AGREE, DO NOT DOWNLOAD, INSTALL, COPY,
| DISTRIBUTE OR USE THE DATA FILES OR SOFTWARE.
|
| COPYRIGHT AND PERMISSION NOTICE
|
| Copyright © 1991-2008 Unicode, Inc. All rights reserved. Distributed
| under the Terms of Use in http://www.unicode.org/copyright.html.
|
| Permission is hereby granted, free of charge, to any person obtaining a
| copy of the Unicode data files and any associated documentation (the
| "Data Files") or Unicode software and any associated documentation (the
| "Software") to deal in the Data Files or Software without restriction,
| including without limitation the rights to use, copy, modify, merge,
| publish, distribute, and/or sell copies of the Data Files or Software,
| and to permit persons to whom the Data Files or Software are furnished to
| do so, provided that (a) the above copyright notice(s) and this
| permission notice appear with all copies of the Data Files or Software,
| (b) both the above copyright notice(s) and this permission notice appear
| in associated documentation, and (c) there is clear notice in each
| modified Data File or in the Software as well as in the documentation
| associated with the Data File(s) or Software that the data or software
| has been modified.
|
| THE DATA FILES AND SOFTWARE ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
| KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
| MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF
| THIRD PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR HOLDERS
| INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL INDIRECT
| OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS
| OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR
| OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
| PERFORMANCE OF THE DATA FILES OR SOFTWARE.
|
| Except as contained in this notice, the name of a copyright holder shall
| not be used in advertising or otherwise to promote the sale, use or other
| dealings in these Data Files or Software without prior written
| authorization of the copyright holder.

I guess this overrides the licence notices in the files
themselves, and also applies to the Microsoft files.  It appears
similar to the X11 licence but adds requirements (b) and (c) and
extends the warranty disclaimer a little.  Requirement (b) is
similar to clause 2 of the 3-clause BSD licence, and requirement
(c) seems similar to clause 2 of the Zlib licence, clause 3 of
the W3C Software License, or subclause 2. a) of GPLv2.  The FSF
lists those licences as GPL compatible so this one should be too.

How about:
- We add that text into COPYING, with a list of the files to
  which it applies.
- We replace all the bundled charset mapping files with current
  versions from www.unicode.org where available.
- We add to each such file a comment like:
  # The following data has been downloaded from
  #  and is thus covered by the
  # Unicode, Inc. License agreement included in the COPYING file
  # of ELinks, regardless of the terms shown below.  This comment
  # and the lines above were not in the original data.

Then it should be fully compliant?

pgpCnbj7hIgFK.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] charset licences in ELinks, and debian/copyright

2008-10-06 Thread Kalle Olavi Niemitalo

Y Giridhar Appaji Nag <[EMAIL PROTECTED]> writes:

> The license is more permissive than GPLv2 and my understanding is that
> it is in the ELinks licensing terms that there should be an exception to
> "allow" works under the Unicode Consortium licensing to be used with it.
> That is, if a copy of these have been "derived" for ELinks use.

I don't understand.  Do you mean there already is an implicit
exception, or that we should add an exception?

> That apart, I am not qualified enough to comment on 'using iconv'.

In glibc and generally in POSIX, there is an iconv function that
converts a sequence of bytes from one charset to another.
As glibc claims to be licensed under LGPL, there should be no
licence problem with using its features such as iconv.
It also supports many more charsets than ELinks currently does,
in particular stateful ones used for CJK.
http://bugzilla.elinks.cz/show_bug.cgi?id=891

> Is there an intention to license ELinks under GPLv2+?

There is no formal plan, but I hope it can be done.  I suggested
this a few times in #ELinks in 2007 and not even Pasky (who
originally changed the licence to GPLv2 only) really objected.
Of course, that does not mean he gave permission to relicence.

I don't think GPLv3 would be better than GPLv2 for ELinks as
such.  If anything, it is longer and harder to understand.
However, it is stupid that we have licence conflicts with useful
libraries like libsmbclient.  The glibc 2.5.1 and 2.6.1 release
notes also warned about a future switch to LGPLv3, although I
don't know if that will really happen.  So I've been trying not
to add any new obstacles for relicensing, and to get some idea of
the existing ones.

Actually, if we're changing the licence, we should add an OpenSSL
exception at the same time.  Links 2.2 has one.  I wonder if it
also applies to Links 0.96, from which ELinks forked.  Perhaps
the authors had to replace a lot of code before they could add
the exception.

pgpUhCruKIGbB.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] charset licences in ELinks, and debian/copyright

2008-10-05 Thread Kalle Olavi Niemitalo

This mail became pretty long, so I'm listing the most important
matters at the top and the details at the bottom.

In commit d33968506bf39500f56ee120d4a98a30b5f114d4 in
git://git.debian.org/git/collab-maint/elinks.git

you added to debian/copyright a list of non-GPLv2 licences used
in the ELinks sources and to which files they apply.  I think it
would be useful to have a similar list in the ELinks source tree,
perhaps as part of COPYING.  However, I am not sure the
information in your list is correct.

You write that "Unicode/*.cp are licensed under The Unicode
Consortium license".  Not all files there contain licence notices
to that effect; can you clarify how you checked their origins?

Is the Unicode Consortium license compatible with GNU GPL v2 and
later?  If it is, I think we should replace the bundled files
with the current versions from www.unicode.org so that the
licence notices are properly displayed.  If it is not, I think we
should remove the files and rewire ELinks to use iconv instead.

How did you find that the Unicode Consortium license also applies
to the mappings provided by Microsoft?  Does it matter that the
character names in the comments are presumably copyrighted by the
Unicode Consortium?

Some mappings have been copied from Lynx 2.8.2, which is licensed
under GPLv2 only.  This could make it more difficult to relicense
ELinks back to "GPL v2 or later".

Then the details.

Mappings licensed by the Unicode Consortium:

- Unicode/8859_1.cp: No licence notice.  Similar to
  
  but lacks control characters.  ELinks inherited this from
  Links 0.96 (GPLv2+).

- Unicode/8859_2.cp: No licence notice.  Similar to
  
  but lacks control characters.  ELinks inherited this from
  Links 0.96 (GPLv2+).

- Unicode/8859_3.cp: Unicode licence notice.  Same as
  
,
  only charset names have been added.  This was ported to ELinks
  from Links 2.1pre7 (GPLv2+).

- Unicode/8859_4.cp: No licence notice.  Similar to
  
  but lacks control characters 0x00 to 0x1F, which ELinks maps
  there anyway.  ELinks inherited this from Links 0.96 (GPLv2+),
  where it was first added in Links 0.90pre2.

- Unicode/8859_5.cp: Unicode licence notice.  Same as
  
,
  only charset names have been added.  ELinks inherited this
  from Links 0.96 (GPLv2+), where it was first added in
  Links 0.81pre3.

- Unicode/8859_6.cp: Unicode licence notice.  Same as
  
,
  only charset names have been added.  This was ported to ELinks
  from Links 2.1pre7 (GPLv2+).

- Unicode/8859_7.cp: Unicode licence notice.  Same as
  
,
  only charset names have been added.  The standard has been
  revised since then.  ELinks inherited this from Links 0.96
  (GPLv2+).

- Unicode/8859_8.cp: Unicode licence notice.  Same as
  
,
  only charset names have been added.  This was ported to ELinks
  from Links 2.1pre7 (GPLv2+).

- Unicode/8859_9.cp: Unicode licence notice.  Same as
  
,
  only charset names have been added.  ELinks inherited this from
  Links 0.96 (GPLv2+).

- Unicode/8859_10.cp: Unicode licence notice.  Same as
  
,
  only charset names have been added.  This was ported to ELinks
  from Links 2.1pre7 (GPLv2+).

- Unicode/8859_13.cp: No licence notice.  Numbers match
  

  but comments differ.  ELinks inherited this from Links 0.96
  (GPLv2+), where it was first added in Links 0.90pre2.

- Unicode/8859_14.cp: Unicode licence notice.  Almost the same as
  
,
  but a comment line differs.  This was ported to ELinks from
  Links 2.1pre7 (GPLv2+).

- Unicode/8859_15.cp: No licence notice.  Similar to
  

  but lacks control characters.  ELinks got this from
  romanian-0.96.patch posted to links-list on 2001-10-10.

- Unicode/8859_16.cp: Unicode copyright but no licence notice.
  Similar to
  

  but lacks control characters, and bytes 0xA5 and 0xAB have been
  swapped

Re: [elinks-dev] Crash when download ends (Crashes again !)

2008-10-03 Thread Kalle Olavi Niemitalo

أحمد المحمودي <[EMAIL PROTECTED]> writes:

>   This time, the crash happened with the following scenario:
>   1. in tty4, I run elinks and browsed to freshmeat.net
>   2. in tty6, I ran elinks and went to download latest 0.13 snapshot of 
>  elinks.
>   3. After the download started, I closed the elinks in tty6. 
>  Immediately the elinks in tty4 crashes (before the download 
>  finishes) giving me the following error:
>
>Link: INTERNAL ERROR at 
> /tmp/buildd/elinks-0.13~20080928/src/main/select.c:149: assertion fd >= 0 && 
> fd < FD_SETSIZE failed:
> set_handlers: handle -1 >= FD_SETSIZE 1024

I got the following from valgrind.  I'm not sure whether it was
before or after the assertion failure.

==14702==at 0x80DD791: read_from_socket (socket.c:945)
==14702==by 0x8104D0C: read_more_http_data (http.c:1180)
==14702==by 0x81052FE: read_http_data (http.c:1388)
==14702==by 0x80DD69B: read_select (socket.c:910)
==14702==by 0x80D27AA: select_loop (select.c:307)
==14702==by 0x80D1ADE: main (main.c:358)
==14702==  Address 0x4F4E598 is 56 bytes inside a block of size 81 free'd
==14702==at 0x402210F: free (vg_replace_malloc.c:233)
==14702==by 0x812BED8: debug_mem_free (memdebug.c:484)
==14702==by 0x80D7C82: done_connection (connection.c:479)
==14702==by 0x80D8A44: abort_connection (connection.c:769)
==14702==by 0x80D99CE: cancel_download (connection.c:1053)
==14702==by 0x8110EB6: abort_download (download.c:143)
==14702==by 0x81115BC: download_data_store (download.c:337)
==14702==by 0x8111AFB: download_data (download.c:446)
==14702==by 0x80D7B33: notify_connection_callbacks (connection.c:458)
==14702==by 0x80D781E: set_connection_state (connection.c:388)
==14702==by 0x80D7132: set_connection_socket_state (connection.c:234)
==14702==by 0x80DD78D: read_from_socket (socket.c:943)

Apparently, abort_connection() has closed the sockets of the
connection, and done_connection() has then freed the connection
and its sockets, but read_from_socket() does not know about that
and tries to set up a read handler for the socket again.  Because
the socket has been freed, it is not even safe to check whether
socket->fd is -1.


pgptFV5d6XnQl.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] libsmbclient GPLv3 license conflict

2008-10-01 Thread Kalle Olavi Niemitalo

Samba 3.2.0, released on 1 July 2008, switched to version 3 of
the GNU General Public License.
http://news.samba.org/releases/3.2.0/

AFAIK, this also applies to libsmbclient.  So it may be illegal
to distribute ELinks binaries linked with the current libsmbclient.

The Debian elinks 0.12~pre1-1 package is linked with libsmbclient,
but apparently with version 3.0.24, which is OK.  Also, I believe
we can legally distribute ELinks sources that use libsmbclient,
at least as long as ELinks works with some GPLv2 version of Samba.

However, it seems likely that the GPLv2 versions of Samba will
eventually become unusable because of security vulnerabilities
or Microsoft's protocol changes.  This will then force Debian
to drop SMB support from ELinks.

What can be done:

(a) Ignore the conflict.

(b) Make ELinks use the smbclient executable again, this time
with proper quoting of metacharacters.  I am very sorry
that I originally requested making ELinks use libsmbclient.

(c) Relicense ELinks so it's GPLv3 compatible.

Forking or relicensing Samba does not seem feasible.
And I don't know about any alternative library we could use.


pgpVJSI1TUroj.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] Crash when download ends

2008-09-30 Thread Kalle Olavi Niemitalo

أحمد المحمودي <[EMAIL PROTECTED]> writes:

>   Shall I file a bug on bugzilla ?

Yes, please do.


pgps6UwEyBbCE.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] Crash when download ends

2008-09-30 Thread Kalle Olavi Niemitalo

Please test these patches for 0.11.5.GIT and 0.12pre2.GIT.
(The latter should also apply to 0.13.GIT, except there's a
conflict in NEWS.)

Actually I think we should add this to Bugzilla too,
and update the commit messages and NEWS entry accordingly.

Fix crash when download ends.

ELinks attempted to display a message box on file_download.term, but
it had already closed that terminal and freed the struct terminal.  To
fix this, reset file_download.term pointers to NULL when the terminal
is about to be destroyed.  Also, assert in download_data_store() that
file_download.term is either NULL or in the global "terminals" list.

Reported by أحمد المحمودي.

---
commit b85c8a744ef7f6d75fca302afe01dc9dac65b4fe
tree 0ed2ce4704e7e8c9eb7a30afc0a43d5aadc30f54
parent 983419b6060bd97e372019c2bdfde32ad2157661
author Kalle Olavi Niemitalo <[EMAIL PROTECTED]> Tue, 30 Sep 2008 10:06:20 +0300
committer Kalle Olavi Niemitalo <[EMAIL PROTECTED]> Tue, 30 Sep 2008 10:12:09 
+0300

 NEWS|8 
 src/session/download.c  |   27 +++
 src/session/download.h  |1 +
 src/terminal/terminal.c |   16 
 src/terminal/terminal.h |6 ++
 5 files changed, 58 insertions(+), 0 deletions(-)

diff --git a/NEWS b/NEWS
index 87e6590..5ac4fdd 100644
--- a/NEWS
+++ b/NEWS
@@ -5,6 +5,14 @@ You can see the complete list of recent changes, bugfixes and 
new features
 in the http://repo.or.cz/w/elinks.git[gitweb interface]. See the ChangeLog
 file for details.
 
+ELinks 0.11.5.GIT now:
+--
+
+To be released as 0.11.6.
+
+* critical: fix crash if a download finishes after ELinks has closed
+  the terminal from which the download was started.
+
 ELinks 0.11.5:
 --
 
diff --git a/src/session/download.c b/src/session/download.c
index a34a6f8..10e5e8c 100644
--- a/src/session/download.c
+++ b/src/session/download.c
@@ -220,6 +220,29 @@ destroy_downloads(struct session *ses)
}
 }
 
+void
+detach_downloads_from_terminal(struct terminal *term)
+{
+   struct file_download *file_download, *next;
+
+   assert(term != NULL);
+   if_assert_failed return;
+
+   foreachsafe (file_download, next, downloads) {
+   if (file_download->term != term)
+   continue;
+
+   if (!file_download->external_handler) {
+   file_download->term = NULL;
+   if (file_download->ses
+   && file_download->ses->tab->term == term)
+   file_download->ses = NULL;
+   continue;
+   }
+
+   abort_download(file_download);
+   }
+}
 
 static void
 download_error_dialog(struct file_download *file_download, int saved_errno)
@@ -307,6 +330,10 @@ download_data_store(struct download *download, struct 
file_download *file_downlo
 {
struct terminal *term = file_download->term;
 
+   if (term) {
+   assert_terminal_is_in_list(term);
+   if_assert_failed term = file_download->term = NULL;
+   }
if (!term) {
/* No term here, so no beep. --Zas */
abort_download(file_download);
diff --git a/src/session/download.h b/src/session/download.h
index 1bcc4aa..b27cd3b 100644
--- a/src/session/download.h
+++ b/src/session/download.h
@@ -107,6 +107,7 @@ void create_download_file(struct terminal *, unsigned char 
*, unsigned char **,
 
 void abort_all_downloads(void);
 void destroy_downloads(struct session *);
+void detach_downloads_from_terminal(struct terminal *);
 
 int setup_download_handler(struct session *, struct download *, struct 
cache_entry *, int);
 
diff --git a/src/terminal/terminal.c b/src/terminal/terminal.c
index 895e898..3943951 100644
--- a/src/terminal/terminal.c
+++ b/src/terminal/terminal.c
@@ -115,6 +115,7 @@ destroy_terminal(struct terminal *term)
 #ifdef CONFIG_BOOKMARKS
bookmark_auto_save_tabs(term);
 #endif
+   detach_downloads_from_terminal(term);
 
while (!list_empty(term->windows))
delete_window(term->windows.next);
@@ -197,6 +198,21 @@ unblock_terminal(struct terminal *term)
textarea_edit(1, NULL, NULL, NULL, NULL);
 }
 
+#ifndef CONFIG_FASTMEM
+void
+assert_terminal_is_in_list(const struct terminal *suspect)
+{
+   struct terminal *term;
+
+   foreach (term, terminals) {
+   if (term == suspect)
+   return;
+   }
+
+   assertm(0, "Dangling pointer to struct terminal");
+}
+#endif /* !CONFIG_FASTMEM */
+
 void
 exec_on_terminal(struct terminal *term, unsigned char *path,
 unsigned char *delete, int fg)
diff --git a/src/terminal/terminal.h b/src/terminal/terminal.h
index 0689f09..c4633d0 100644
--- a/src/terminal/terminal.h
+++ b/src/terminal/terminal.h
@@ -150,6 +150,12 @@ void destroy_all_terminals(void

Re: [elinks-dev] Removing unclearly licensed test files

2008-09-28 Thread Kalle Olavi Niemitalo

Kalle Olavi Niemitalo <[EMAIL PROTECTED]> writes:

> To make future ELinks releases more legal to distribute, I would
> like to remove these files from all branches in elinks.git: dom,
> DOM_renderer, elinks-0.11, elinks-0.12, master, and witekfl.

And from the unmaintained REL_0_10 branch, too.


pgpo9rqrXwlHb.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] Crash when download ends

2008-09-28 Thread Kalle Olavi Niemitalo

Kalle Olavi Niemitalo <[EMAIL PROTECTED]> writes:

> I guess we should make destroy_terminal() search for download.term
> pointers to that terminal, and reset them to NULL.
>
> struct download is used in these structures:

I wasn't thinking straight.  The pointer is file_download.term,
not download.term.  So it does not matter if struct download is
used in other places.

destroy_session() calls destroy_downloads(), which detaches file
downloads from the session that is being destroyed and tries to
attach them to some other session on the same terminal.  Possibly
we could make destroy_session() also set file_download.term =
NULL if no other session remains on the terminal.  Then,
destroy_terminal() might not have to explicitly detach file
downloads from the terminal, because it already destroys all tab
windows and their sessions on the terminal.

However, that won't work if it is possible to keep ELinks running
on a terminal that does not have any tab windows in it, and even
add file downloads to that terminal, e.g. by selecting them from
the download manager and telling ELinks to report on that
terminal when they complete.  Perhaps it is not possible now but
I don't want to leave such a trap in the source code.  So, I
think it would be better to have destroy_terminal() detach file
downloads from the terminal, rather than rely on destroy_session().

I don't understand why the file_download.ses pointer exists at all.
It seems to be used only for check_questions_queue(file_download->ses)
in abort_download().  But why does check_questions_queue() even take
a session parameter; shouldn't the terminal be used instead?
Of the functions given to add_questions_entry(), only do_auth_dialog()
and http_error_document() really use the session parameter rather than
just the terminal.  They seem to assume that the session is the
one where the authentication is needed or the HTTP error occurred,
but as far as I can tell, these assumptions do not always hold.

pgpUdESS1mBzt.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] Removing unclearly licensed test files

2008-09-28 Thread Kalle Olavi Niemitalo

Kalle Olavi Niemitalo <[EMAIL PROTECTED]> writes:

> test/align.html: from www.czech-tv.cz, no explicit license, so you may have
>   to remove this

> test/css/idnes_mail.html: apparently from idnes.cz, no explicit license,
>   so you may have to remove this
> test/erreurs_en.htm: unclear origin, no explicit license, so you may have
>   to remove this
> test/javascript_broken.html: presumably from www.hotjobs.com, no explicit
>   license, so you may have to remove this
> test/poocs.net.html: presumably from poocs.net, no explicit license, so you
>   may have to remove this

To make future ELinks releases more legal to distribute, I would
like to remove these files from all branches in elinks.git: dom,
DOM_renderer, elinks-0.11, elinks-0.12, master, and witekfl.
I will do this next weekend if nobody objects.

(There was also the utf8 branch, but all of its commits had
already been merged to master, so I deleted it today.  It was
pointing to commit 8fa3a4c88f7c9bc2463ea9e32fc29cab845e1184,
which remains available on the elinks-0.12 and master branches.)

One could also rewrite the commit history to completely purge
these files from the Git repository, and replace previously
released tar files with censored versions.  That would however
invalidate all PGP signatures, so I'd rather do that only if
the copyright holders actually demand it.

pgpITmhO0D0f5.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] Crash when download ends

2008-09-28 Thread Kalle Olavi Niemitalo

أحمد المحمودي <[EMAIL PROTECTED]> writes:

>   ELinks 0.13 (20080915 snapshot) crashes when a download finishes, 
>   that is in the case that this download was started from a window that 
>   is closed before the download finishes. Here are the steps to 
>   reproduce the bug:
>   1] in tty1 for example, start elinks and go to the elinks download 
>  page.
>   2] in tty2 for example, start elinks (do not use --no-connect) and go 
>  to another page.
>   3] start downloading one of the snapshots in the elinks started in 
>  tty1, then close elinks that is running in tty1.
>   4] The download will continue since elinks is running in tty2, yet 
>  when the download is over, elinks will crash.

ELinks 0.11.5 crashes too.  With valgrind, it's easiest to start
the download on the terminal on which ELinks was started last.

==23545== Invalid read of size 4
==23545==at 0x806B11C: intl_set_charset (libintl.h:64)
==23545==by 0x806B0FA: _ (libintl.h:90)
==23545==by 0x806B19A: msg_text (msgbox.c:127)
==23545==by 0x80FF617: download_data_store (download.c:361)
==23545==by 0x80FF93E: download_data (download.c:421)
==23545==by 0x80CCF56: notify_connection_callbacks (connection.c:427)
==23545==by 0x80CD035: done_connection (connection.c:444)
==23545==by 0x80CD77F: add_keepalive_connection (connection.c:602)
==23545==by 0x80F5472: http_end_request (http.c:482)
==23545==by 0x80F6DBE: read_http_data_done (http.c:1140)
==23545==by 0x80F733C: read_http_data (http.c:1331)
==23545==by 0x80D1DD2: read_select (socket.c:879)
==23545==  Address 0x45218E0 is 72 bytes inside a block of size 397 free'd
==23545==at 0x402210F: free (vg_replace_malloc.c:233)
==23545==by 0x81171D3: debug_mem_free (memdebug.c:468)
==23545==by 0x810F93D: destroy_terminal (terminal.c:150)
==23545==by 0x80C794D: check_bottom_halves (select.c:115)
==23545==by 0x80C8032: select_loop (select.c:284)
==23545==by 0x80C735E: main (main.c:357)

I guess we should make destroy_terminal() search for download.term
pointers to that terminal, and reset them to NULL.

struct download is used in these structures:
- struct type_query: Each of these is associated with a dialog
  box, so there should be no such structures left when the
  terminal is being destroyed.
- struct file_download: These are in the global list "downloads".
- struct location: Can these be a problem?
- struct session: Each of these is associated with a tab window,
  so there should be no such structures left when the terminal is
  being destroyed.
- struct file_to_load: Can these be a problem?
- struct bittorrent_fetcher: It seems download.term is always
  NULL here.

And then there are also instances of struct download that are not
embedded in any larger structure, e.g. in scripting/python/load.c
and viewer/dump/dump.c.

Some ideas for fixing this:

(a) Make download_data_store() walk the "terminals" list and
check that download.term is in the list.  I don't like this
because the C standard says the value of a pointer to freed
memory is indeterminate and comparing it to anything already
results in undefined behaviour.  In practice, it could make
ELinks report completion of downloads to the wrong terminal.

(b) Assume that only struct file_download can really cause a
crash.  Make destroy_terminal() walk the "downloads" list.
Also, #ifdef CONFIG_DEBUG, make download_data_store() assert
that download.term is in the "terminals" list.

(c) Add a separate list to which _every_ struct download is
added.  Define init_download and done_download functions.
This would require changes in a number of places, I'm afraid.
However it would also make enhancement 435 easier.

(d) As in (c) but also define a linked list for each terminal,
listing the struct download instances that point to it.
All updates of download.term must go through a new function
set_download_term(), which maintains these lists.  This way,
destroy_terminal() would not have to look at downloads that
do not use the terminal.  However, this scheme would bloat
struct download and probably not speed up destroy_terminal()
noticeably.

Overall I think we should do (b) now in 0.11.5.GIT and 0.12pre2.GIT,
and (c) in 0.13.GIT after the 0.12.0 release.

pgpUI9FfYpXsc.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] [PATCH] Add support for nss_compat_ossl library (OpenSSL replacement).

2008-09-27 Thread Kalle Olavi Niemitalo

Kamil Dudka <[EMAIL PROTECTED]> writes:

> Yes, if you specify DIR manually, pkg-config is not used. I think the same 
> approach as here:
> https://fedoraproject.org/wiki/Nss_compat_ossl#Sample_Application

I see.  It's just that I had NSS in /usr from Debian but built
and installed nss_compat_ossl in a home directory.  When I
pointed --with-nss_compat_ossl=DIR to that directory, the
configure script did not use pkg-config nss but rather assumed
NSS is where Fedora puts it.  Because Debian uses different
directories, the preprocessor then didn't find nss.h, and the
build failed.

If I want to use nss_compat_ossl, I can point CFLAGS and LDFLAGS
to it before I run configure --with-nss_compat_ossl, so the
behaviour of the option is not a real problem, but anyway it was
surprising.

The GNU Coding Standards actually say:

| Do not use a ‘--with’ option to specify the file name to use to
| find certain files. That is outside the scope of what ‘--with’
| options are for.

Of course, ELinks not being a GNU program, it is not bound by
those standards.

pgpEgcVxVLu3J.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] Fw: [elinks-users] ELinks cannot run perl scripts that use perl modules.

2008-09-27 Thread Kalle Olavi Niemitalo

أحمد المحمودي <[EMAIL PROTECTED]> writes:

>   From the perlembed manpage I found this: 
>   perl -MExtUtils::Embed -e ccopts -e ldopts

The configure script of ELinks appears to do that already.
So, please try the following patch.

Let Perl scripts dynamically load libraries.

XML::LibXML::SAX appears to require this.

---
commit b0ce4adcbe970778e4082fed36a3cef35e31bd86
tree 44d444118d0fa37fad7d9f5f923e1f1d3bb79418
parent 58ebb4447b59a07c780184ee573c66354c7e4be3
author Kalle Olavi Niemitalo <[EMAIL PROTECTED]> Sat, 27 Sep 2008 21:58:08 +0300
committer Kalle Olavi Niemitalo <[EMAIL PROTECTED]> Sat, 27 Sep 2008 21:58:08 
+0300

 NEWS  |8 
 src/scripting/perl/core.c |   20 ++--
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/NEWS b/NEWS
index 6ebb649..3375d7d 100644
--- a/NEWS
+++ b/NEWS
@@ -5,6 +5,14 @@ You can see the complete list of recent changes, bugfixes and 
new features
 in the http://repo.or.cz/w/elinks.git[gitweb interface]. See the ChangeLog
 file for details.
 
+ELinks 0.12pre2.GIT now:
+
+
+To be released as 0.12pre3, 0.12rc1, or even 0.12.0.
+
+* Perl scripts can use modules that dynamically load C libraries, like
+  XML::LibXML::SAX does.
+
 ELinks 0.12pre2:
 
 
diff --git a/src/scripting/perl/core.c b/src/scripting/perl/core.c
index 85d9428..afc8d3e 100644
--- a/src/scripting/perl/core.c
+++ b/src/scripting/perl/core.c
@@ -15,6 +15,12 @@
 #include "scripting/perl/core.h"
 #include "util/file.h"
 
+/* The configure script runs "perl -MExtUtils::Embed -e ccopts -e ldopts",
+ * which should output the location of the DynaLoader.a where this function
+ * is defined.  This prototype does not appear to be in any public header
+ * file of Perl.  */
+EXTERN_C void boot_DynaLoader (pTHX_ CV* cv);
+
 #define PERL_HOOKS_FILENAME"hooks.pl"
 
 
@@ -65,6 +71,16 @@ cleanup_perl(struct module *module)
 #endif
 }
 
+/** Tell Perl about XSUBs that were linked into ELinks.  */
+static void
+xs_init(pTHX)
+{
+   /* DynaLoader is the only Perl module whose library is
+* statically linked into ELinks.  DynaLoader::bootstrap will
+* then load other libraries and register their XSUBs as
+* needed.  */
+   newXS("DynaLoader::boot_DynaLoader", boot_DynaLoader, __FILE__);
+}
 
 void
 init_perl(struct module *module)
@@ -97,9 +113,9 @@ init_perl(struct module *module)
 
perl_construct(my_perl);
if (hook_local)
-   err = perl_parse(my_perl, NULL, 2, local_argv, NULL);
+   err = perl_parse(my_perl, xs_init, 2, local_argv, NULL);
else if (hook_global)
-   err = perl_parse(my_perl, NULL, 2, global_argv, NULL);
+   err = perl_parse(my_perl, xs_init, 2, global_argv, 
NULL);
 #ifdef PERL_EXIT_DESTRUCT_END
PL_exit_flags |= PERL_EXIT_DESTRUCT_END;
 #endif


pgprF9WMmMl9p.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] [PATCH] Add support for nss_compat_ossl library (OpenSSL replacement).

2008-09-27 Thread Kalle Olavi Niemitalo

Kamil Dudka <[EMAIL PROTECTED]> writes:

> If you agree I forward this report to nss_compat_ossl
> maintainer.

OK, I see you already did.

> Support for nss_compat_ossl must be requested by user now.

I'm going to apply this version, but I noticed something odd.
It appears you made the configure script run "pkg-config nss"
only if given --with-nss_compat_ossl without the DIR argument.
When given --with-nss_compat_ossl=DIR, it does not add the output
of "pkg-config --cflags nss" to CFLAGS, for example.  Did you
intend this?  If not, please post a separate patch to fix it.

pgp01StSOIrHc.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] 0.12pre2 and 0.11.5 next weekend?

2008-09-21 Thread Kalle Olavi Niemitalo

I have done steps 1-2 of doc/release.txt for elinks-0.11.5 and
elinks-0.12pre2, i.e. the signed tags are in
http://elinks.cz/elinks.git/.  However, the elinks.cz server
isn't letting me log in, so the tarballs and signature files are
only at pasky.or.cz:~kon so far.


pgpzjMwQxlc56.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] [PATCH] Add support for nss_compat_ossl library (OpenSSL replacement).

2008-09-20 Thread Kalle Olavi Niemitalo

Kamil Dudka <[EMAIL PROTECTED]> writes:

> On Sunday 07 September 2008 02:05:07 Kalle Olavi Niemitalo wrote:
>> Because you don't consider the nss_compat_ossl support stable,
>> I think the configure script should select it only if the user
>> explicitly requests it or no other SSL library is available.
> I consider nss_compat_ossl support stable, but it has not been tested by 
> users 
> yet. If it will be used by default, we can get more experiences from users to 
> declare it stable.

Perhaps your ELinks changes are stable.  However, nss_compat_ossl
0.9.2 itself is not stable enough.  Its SSL_library_init() calls
exit(1) with no error message at all if NSS_Init(certDir) fails.
That is just ridiculous; ELinks should still be able to access
non-SSL sites.

Please change the configure script to select nss_compat_ossl only
if explicitly requested by the user.  ELinks should not use it by
default, even if no other SSL library is available.  This can be
revisited after an improved version of nss_compat_ossl has been
released and the configure script can check the version.

Also, the configure script should remove NSS from CFLAGS and LIBS
again if it notices nss_compat_ossl has not been installed.

diff --git a/configure.in b/configure.in
index 06f66db..4c52802 100644
--- a/configure.in
+++ b/configure.in
@@ -982,7 +982,9 @@ if test "$with_nss_compat_ossl" != "no"; then
AC_CHECK_LIB(nss_compat_ossl, X509_free,, [with_nss_compat_ossl=no])
 fi

-if  test "$with_nss_compat_ossl" != "no"; then
+if test "$with_nss_compat_ossl" = "no"; then
+   EL_RESTORE_FLAGS
+else
LIBS="$LIBS -lnss_compat_ossl"
EL_CONFIG(CONFIG_NSS_COMPAT_OSSL, [nss_compat_ossl])
disable_openssl="yes"

Your patch added a NEWS entry into the section about ELinks 0.11.3,
which has already been released.  I will move that to the right
place.  Also, I would like to refer to the Fedora bugzilla:

* Fedora enhancement 346861: Add support for nss_compat_ossl library
  (OpenSSL replacement).

unless you have something against this.

I had some trouble building nss_compat_ossl 0.9.2 on Debian:

- Here, the libnss3-dev package contains e.g. /usr/include/nss/ssl.h, and
  pkg-config --cflags nss outputs "-I/usr/include/nss -I/usr/include/nspr",
  but nss_compat_ossl-0.9.2/src/nss_compat_ossl.h does #include .
  As there is no actual nss3 directory, nor a symlink, this does not work.

- Likewise with #include .

- Similarly, we have /usr/lib/nss/libsoftokn3.so, but pkg-config --libs nss
  does not output any -L options, so -lsoftokn3 in
  nss_compat_ossl-0.9.2/src/Makefile.am doesn't find the library;
  however, if I remove that -lsoftokn3, then nss_compat_ossl builds.

Browsing the source code, I noticed RAND_load_file() can get
stuck in a loop if I/O errors occur: fread() and feof() both
return 0.  And RAND_write_file() should check for errors on
fwrite() and fclose().  I gave up on reviewing ssl.c because
I don't know NSPR and SSL well enough.

pgpr80pZBFGls.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] elinks 0.13-20080905 internal error with a certian HTML file.

2008-09-14 Thread Kalle Olavi Niemitalo

I have pushed to master two patches that should together fix the crash:

0f6add14f263a032d9ad2e6060d5971c24777e59 Update document.comb_x and comb_y when 
splitting lines.
8548108e39a9427f69ddba5a5256d4a38cc0f408 Make document.comb_{x,y} not relative 
to part.box.

As documented in configure --help and features.conf,
--enable-combining or CONFIG_COMBINE is an experimental feature.
Exactly what that means, I am not sure.
Perhaps it means I should have guessed CONFIG_COMBINE caused the crash.
I hope nobody is distributing binaries with this feature enabled.


pgpYAc5LMbX0h.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] 0.12pre2 and 0.11.5 next weekend?

2008-09-09 Thread Kalle Olavi Niemitalo

I would like to release ELinks 0.12pre2 and 0.11.5 next weekend
(2008-09-13 or so).  I know Fonseca didn't want any more 0.11
releases, but well, bug 698 was a regression from 0.11.3 and
there's also the libgnutls-openssl license incompatibility.
If you object to 0.11.5, I could do just 0.12pre2, but I'd rather
do both at the same time as that makes NEWS a bit simpler.

Oh, and I'm getting this for elinks.cz:

@@@
@WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now
(man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
45:a6:ad:bc:63:72:db:b1:0e:64:c6:37:88:a9:8e:2a.

Is that the right fingerprint now?  Anybody sure?


pgpuJ6p3OGe29.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] [PATCH] fix mangled indentation in configure --help

2008-09-09 Thread Kalle Olavi Niemitalo

Kamil Dudka <[EMAIL PROTECTED]> writes:

> I've searched the proper solution last hour on the web. But it seems there is 
> no proper solution while using AC_HELP_STRING - consider this thread 
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg08893.html
>
> So I've fixed the preexisting options with double quoting [[...]] - patch #1. 
> And I am also sending modified patch for NSS (patch #2), which shows [=DIR] - 
> here were used four more pairs of square brackets.

The release announcement of Autoconf 2.62 mentions:

 ** AS_HELP_STRING no longer underquotes its first argument; it also handles
 ~   the case where the first argument contains single-quoted commas.
 ~   For example, "AS_HELP_STRING([-a, [--arg[=foo]]], [bar])" produces:
 ~ "  -a, --arg[=foo] bar"
 ~   Additionally, the macro now takes two additional arguments,
 ~   indent-column and wrap-column; these should not normally be needed,
 ~   but can be used to fine-tune how the output text is wrapped.

ELinks should be kept compatible with Autoconf 2.59, but if you
add four pairs of square brackets for that, I think Autoconf 2.62
will then include too many of them in the --help output.  So the
right solution seems to be to avoid AC_HELP_STRING and instead
align the strings by hand.  Alternatively, one could define
EL_HELP_STRING, but that would probably require more effort than
it'd save.

The alignment and brackets are minor details.  If you feel they
are costing too much time, I think it'd be enough to have the
same level of correctness as in the preexisting options.
I do not want the four pairs of square brackets though.

> + if test -z "$with_nss_compat_ossl" -o "$with_nss_compat_ossl" = yes; 
> then

The Autoconf manual advises against using the -a and -o operators
of test, because of variations in precedence.  Instead:

+   if test -z "$with_nss_compat_ossl" || test "$with_nss_compat_ossl" = 
yes; then

pgpZHQcmCx16m.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] The Links/Links2/ELinks browsers are unusable on Debian GNU/Hurd

2008-09-08 Thread Kalle Olavi Niemitalo

Kalle Olavi Niemitalo <[EMAIL PROTECTED]> writes:

> Until you have a proper fix, you might also patch ELinks to work
> around the bug.

FYI, last night's elinks-0.12 snapshot (elinks-0.12-20080909)
includes a similar patch.  (This has not yet been merged to
ELinks 0.13.GIT.)  The source also no longer makes assumptions on
the range of errno values like 0.11.4 does.  So I think the lack
of /dev/random is now the only Hurd-specific problem hindering
the use of ELinks.  If you configure GnuTLS to use some
user-space entropy source, and configure ELinks to use GnuTLS,
then everything should work fine.

The Debian experimental elinks package seems stuck at
0.12~20080527-2 though?  I guess you can't have a newer version
specifically for the Hurd.

pgpm1dLKugAQS.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] [PATCH] fix mangled indentation in configure --help

2008-09-08 Thread Kalle Olavi Niemitalo

Kamil Dudka <[EMAIL PROTECTED]> writes:

> This is correct behavior. It attempts to align columns and the option is 
> longer than column, so it forces a newline. Nothing wrong I think.

I don't mean alignment.  The output should be

   --with-nss_compat_ossl[=DIR]
   NSS compatibility SSL libraries/include files

but the brackets around =DIR are missing.


pgpUUvFbxQhfQ.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] elinks 0.13-20080905 internal error with a certian HTML file.

2008-09-08 Thread Kalle Olavi Niemitalo

أحمد المحمودي <[EMAIL PROTECTED]> writes:

> Unfortunately I cannot find any *core* files after elinks crashes !

You may be able to change that with ulimit -c in bash.
However, for easily reproduceable crashes, I find it easier
to run elinks within gdb, because that way there is no core
file that I'd have to delete later.

> Btw, I just tried another thing now: if I attempt to open the file using 
> elinks from a gnome-terminal (TERM=xterm), no crash happens !

Thank you.  That was the critical hint.

With commit 80a5c6d466af4bed62d4d0f57f7a8e596b2166b3,
I get this backtrace for the write that corrupts memory:

#0  0x080ac48b in set_hline at src/document/html/renderer.c:503
#1  0x080aba89 in put_chars at src/document/html/renderer.c:1673
#2  0x080da96d in convert_string_elinks at src/intl/charsets.c:1363
#3  0x080ab814 in put_chars_conv at src/document/html/renderer.c:1396
#4  0x080a568f in put_chrs at src/document/html/parser.c:155
#5  0x080bbbd6 in parse_html at src/document/html/parser/parse.c:779
#6  0x080aeaf6 in format_html_part at src/document/html/renderer.c:2244
#7  0x080b13a7 in format_cell at src/document/html/tables.c:91
#8  0x080b15d1 in draw_table_cell at src/document/html/tables.c:883
#9  0x080b1801 in draw_table_cells at src/document/html/tables.c:932
#10 0x080b2bd8 in format_table at src/document/html/tables.c:1334
#11 0x080b6cd8 in html_table at src/document/html/parser/general.c:664
#12 0x080bc4ce in start_element at src/document/html/parser/parse.c:986
#13 0x080bc891 in process_element at src/document/html/parser/parse.c:1156
#14 0x080bbccd in parse_html at src/document/html/parser/parse.c:792
#15 0x080aeaf6 in format_html_part at src/document/html/renderer.c:2244
#16 0x080b13a7 in format_cell at src/document/html/tables.c:91
#17 0x080b15d1 in draw_table_cell at src/document/html/tables.c:883
#18 0x080b1801 in draw_table_cells at src/document/html/tables.c:932
#19 0x080b2bd8 in format_table at src/document/html/tables.c:1334
#20 0x080b6cd8 in html_table at src/document/html/parser/general.c:664
#21 0x080bc4ce in start_element at src/document/html/parser/parse.c:986
#22 0x080bc891 in process_element at src/document/html/parser/parse.c:1156
#23 0x080bbccd in parse_html at src/document/html/parser/parse.c:792
#24 0x080aeaf6 in format_html_part at src/document/html/renderer.c:2244
#25 0x080b13a7 in format_cell at src/document/html/tables.c:91
#26 0x080b15d1 in draw_table_cell at src/document/html/tables.c:883
#27 0x080b1801 in draw_table_cells at src/document/html/tables.c:932
#28 0x080b2bd8 in format_table at src/document/html/tables.c:1334
#29 0x080b6cd8 in html_table at src/document/html/parser/general.c:664
#30 0x080bc4ce in start_element at src/document/html/parser/parse.c:986
#31 0x080bc891 in process_element at src/document/html/parser/parse.c:1156
#32 0x080bbccd in parse_html at src/document/html/parser/parse.c:792
#33 0x080aeaf6 in format_html_part at src/document/html/renderer.c:2244
#34 0x080af054 in render_html_document at src/document/html/renderer.c:2350
#35 0x0809a23f in render_encoded_document at src/document/renderer.c:266
#36 0x0809a4b4 in render_document at src/document/renderer.c:346
#37 0x0809aa66 in render_document_frames at src/document/renderer.c:475
#38 0x08150d9a in draw_formatted at src/viewer/text/draw.c:351
#39 0x08131263 in display_timer at src/session/session.c:454
#40 0x081354ed in loading_callback at src/session/task.c:538
#41 0x080e796a in notify_connection_callbacks at src/network/connection.c:458
#42 0x080e7a66 in done_connection at src/network/connection.c:475
#43 0x080e887c in abort_connection at src/network/connection.c:769
#44 0x0810bf8b in file_protocol_handler at src/protocol/file/file.c:315
#45 0x080e87b3 in run_connection at src/network/connection.c:753
#46 0x080e8d2a in try_connection at src/network/connection.c:823
#47 0x080e8be0 in check_queue at src/network/connection.c:857
#48 0x080e1f12 in check_bottom_halves at src/main/select.c:115
#49 0x080e25e2 in select_loop at src/main/select.c:290
#50 0x080e1924 in main at src/main/main.c:358

Line 503 of src/document/html/renderer.c is:
POS(document->comb_x, document->comb_y).data = prev;

Interesting values:
document->comb_x = 113;
document->comb_y = 83;
part->box = {x = 17, y = 9, width = 102, height = 85};
part->document->data[part->box.y + document->comb_y].length = 119;

Witekfl, how do we fix this?  I already tried the following patch
(thinking that perhaps document->box had been changed but comb_x
and comb_y had not) but it didn't help.

diff --git a/src/document/html/renderer.c b/src/document/html/renderer.c
index bbb4e4c..6735f9f 100644
--- a/src/document/html/renderer.c
+++ b/src/document/html/renderer.c
@@ -500,7 +500,8 @@ good_char:
unicode_val_T prev = 
get_combined(document->combi, document->combi_length + 1);
 
if (prev != UCS_NO_CHAR)
-

Re: [elinks-dev] elinks 0.13-20080905 internal error with a certian HTML file.

2008-09-07 Thread Kalle Olavi Niemitalo

أحمد المحمودي <[EMAIL PROTECTED]> writes:

> 2] elinks -no-home -no-connect /path/to/
> Then I follow the link to article_17686.shtml
> So far, no trouble happened and the page did display very well.
> Then I pressed q and Enter to quit. At that point I got a crash:

It still doesn't crash here.

> 0x84ad6c0:2688 bad alloc_header block free() @ 
> /tmp/buildd/elinks-0.13~20080907/src/document/document.c:141, alloc'd at 
> /tmp/buildd/elinks-0.13~20080907/src/document/html/renderer.c:168

done_document() in src/document/document.c:

140 for (pos = 0; pos < document->height; pos++)
141*mem_free_if(document->data[pos].chars);

realloc_line() in src/document/html/renderer.c:

156 struct line *line;
168*if (!ALIGN_LINE(&line->chars, line->length, length + 1))
169 return -1;

src/document/document.h:

32  struct line {
33  struct screen_char *chars;
34  int length;
35  };

So alloc_header.magic of line.chars has somehow become corrupted.
However, it's perhaps not a simple underflow, because
alloc_header.file seems correct.  It might be an overflow of the
previous block, or a write via a stale pointer.

> --sysconfdir=/etc/elinks \

What do you have in /etc/elinks/elinks.conf?

> Compiler version: gcc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7)

What is the processor architecture? (e.g. i686 or amd64 or alpha)
If it's i686, I could perhaps examine a core dump.
(Please don't send core dumps to elinks-dev.)

> Terminal is a virtual terminal of size: 128x48

What are $TERM, $LANG, $LC_CTYPE, $LC_ALL?

Again, if you can reproduce the crash under valgrind, that will
be most helpful.  Alternatively, you might try electric-fence if
you have lots of memory.  Disabling --with-guile and other
scripting modules may speed up tests and reduce memory
consumption and irrelevant error reports from valgrind.

pgpbCD14MD03C.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] Errors in bittorent

2008-09-06 Thread Kalle Olavi Niemitalo

Witold Filipczyk <[EMAIL PROTECTED]> writes:

> + uri = get_uri(uri_string.source, URI_BASE);
> + done_string(&uri_string);
> + if (!uri) {
> + done_bittorrent_peer_connection(peer);
> + return BITTORRENT_STATE_OUT_OF_MEM;
> + }
> + uri->protocol = PROTOCOL_BITTORRENT;

Changing uri->protocol like that is not safe, I think.  get_uri()
may have returned a cached URI to which there are other references.
Because a malicious BitTorrent tracker can return arbitrary
hostnames in the peer list, and this code will then change the
protocol of the corresponding HTTP URIs to BitTorrent and affect
future accesses to those hosts, I think this needs to be fixed.
A pretty clear solution is to add a "bittorrent-peer" URI scheme
for use in these connections, but other fixes are fine too.

The following patch is also available from a Git repository:
git://repo.or.cz/elinks/kon.git 0.12/bittorrent-peer-uri

Fix blacklist crash in BitTorrent

make_bittorrent_peer_connection() used to construct a struct uri on
the stack. This was hacky but worked nicely because the struct uri
was not really accessed after make_connection() returned.  However,
since commit a83ff1f565a4a7bc25a4b8353ee26bc1b97410e3, the struct uri
is also needed when the connection is being closed.  Valgrind shows:

Invalid read of size 2
   at 0x8100764: get_blacklist_entry (blacklist.c:33)
   by 0x8100985: del_blacklist_entry (blacklist.c:64)
   by 0x80DA579: complete_connect_socket (socket.c:448)
   by 0x80DA84A: connected (socket.c:513)
   by 0x80D0DDF: select_loop (select.c:297)
   by 0x80D00C6: main (main.c:353)
 Address 0xBEC3BFAE is just below the stack ptr.  To suppress, use: 
--workaround-gcc296-bugs=yes

To fix this, allocate the struct uri on the heap instead, by
constructing a string and giving that to get_uri().  This string
cannot use the "bittorrent" URI scheme because parse_uri() does not
recognize the host and port fields in that.  (The "bittorrent" scheme
has protocol_backend.free_syntax = 1 in order to support strings like
"bittorrent:http://beta.legaltorrents.com/get/159-noisome-beasts";.)
Instead, define a new "bittorrent-peer" URI scheme for this purpose.
If the user attempts to use this URI scheme, its handler aborts the
connection with an error; but when make_bittorrent_peer_connection()
uses a bittorrent-peer URI, the handler is not called.

This change also lets get_uri() set the ipv6 flag if peer_info->ip is
an IPv6 address literal.

Reported by Witold Filipczyk.

---
commit d93bceb9bd6ab32c614ac20dc5c87e3af2a7f85f
tree a32c808927944db6717398c8595626c958008579
parent 7de8b9940c96f51c55c2706ed9aa6ad11257d7ee
author Kalle Olavi Niemitalo <[EMAIL PROTECTED]> Sun, 07 Sep 2008 06:10:52 +0300
committer Kalle Olavi Niemitalo <[EMAIL PROTECTED]> Sun, 07 Sep 2008 06:31:36 
+0300

 src/network/state.c   |1 +
 src/network/state.h   |1 +
 src/protocol/bittorrent/connection.c  |6 
 src/protocol/bittorrent/connection.h  |2 +
 src/protocol/bittorrent/peerconnect.c |   45 -
 src/protocol/protocol.c   |1 +
 src/protocol/protocol.h   |1 +
 7 files changed, 39 insertions(+), 18 deletions(-)

diff --git a/src/network/state.c b/src/network/state.c
index 3a94982..9ecd6f3 100644
--- a/src/network/state.c
+++ b/src/network/state.c
@@ -124,6 +124,7 @@ static const struct s_msg_dsc msg_dsc[] = {
{S_BITTORRENT_METAINFO, N_("The BitTorrent metainfo file contained 
errors")},
{S_BITTORRENT_TRACKER,  N_("The tracker requesting failed")},
{S_BITTORRENT_BAD_URL,  N_("The BitTorrent URL does not point to a 
valid URL")},
+   {S_BITTORRENT_PEER_URL, N_("The bittorrent-peer URL scheme is for 
internal use only")},
 #endif

/* fsp_open_session() failed but did not set errno.
diff --git a/src/network/state.h b/src/network/state.h
index 16faf41..f8358b2 100644
--- a/src/network/state.h
+++ b/src/network/state.h
@@ -103,6 +103,7 @@ enum connection_basic_state {
S_BITTORRENT_METAINFO   = -100801,
S_BITTORRENT_TRACKER= -100802,
S_BITTORRENT_BAD_URL= -100803,
+   S_BITTORRENT_PEER_URL   = -100804,

S_FSP_OPEN_SESSION_UNKN = -100900,
 };
diff --git a/src/protocol/bittorrent/connection.c 
b/src/protocol/bittorrent/connection.c
index f15bfe8..132283b 100644
--- a/src/protocol/bittorrent/connection.c
+++ b/src/protocol/bittorrent/connection.c
@@ -414,3 +414,9 @@ bittorrent_protocol_handler(struct connection *conn)
  bittorrent_metainfo_callback, conn, 0);
done_uri(uri);
 }
+
+void
+bittorrent_peer_protocol_handler(struct connection *conn)
+{
+   abort_connection(conn, connection_state(S_BITTORRENT_PEER_URL));
+}
diff --git a/src/protocol/bittorrent/connection.h

Re: [elinks-dev] [PATCH] Add support for nss_compat_ossl library (OpenSSL replacement).

2008-09-06 Thread Kalle Olavi Niemitalo

Kamil Dudka <[EMAIL PROTECTED]> writes:

> +AC_ARG_WITH(nss_compat_ossl, AC_HELP_STRING([--with-nss_compat_ossl[=DIR]],
> + [NSS compatibility SSL libraries/include files]))

I'm getting this in configure:

  --with-nss_compat_ossl=DIR
  NSS compatibility SSL libraries/include files

So apparently there aren't enough brackets.  I think you should
add a pair around the whole AC_HELP_STRING call.

The same bug is in some preexisting options too.  If you want to
fix those, please post a separate patch.

> +if test "$with_nss_compat_ossl" != "no"; then
> + if test -z "$with_nss_compat_ossl"; then
> + if pkg-config nss; then
> + CFLAGS="$CFLAGS_X `pkg-config --cflags nss`"
> + LIBS="$LIBS_X `pkg-config --libs nss`"
> + else
> + with_nss_compat_ossl=no
> + fi
> + else
> + # Without pkg-config, we'll kludge in some defaults
> + CFLAGS="$CFLAGS_X -I$with_nss_compat_ossl/include 
> -I/usr/include/nss3 -I/usr/include/nspr4"
> + LIBS="$LIBS_X -L$with_nss_compat_ossl/lib -lssl3 -lsmime3 
> -lnss3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl"
> + fi

Autoconf considers --with-nss_compat_ossl equivalent to
--with-nss_compat_ossl=yes.  Your code seems to treat that
"yes" as a directory name and skip pkg-config.

> + # TODO: Mark this as non-warning when it becomes stable
> + AC_MSG_WARN([Using nss_compat_ossl library for SSL.])

Because you don't consider the nss_compat_ossl support stable,
I think the configure script should select it only if the user
explicitly requests it or no other SSL library is available.


pgpyW3p8Ghv43.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] [PATCH] Add support for nss_compat_ossl library (OpenSSL replacement).

2008-09-06 Thread Kalle Olavi Niemitalo

Kamil Dudka <[EMAIL PROTECTED]> writes:

> +AC_ARG_WITH(nss_compat_ossl, AC_HELP_STRING([--with-nss_compat_ossl[=DIR]],
> + [NSS compatibility SSL libraries/include files]))
> +
> +# nss_compat_ossl
> +if test "$with_nss_compat_ossl" != "no"; then
> + if test -z "$with_nss_compat_ossl"; then
> + if pkg-config nss; then
> + CFLAGS="$CFLAGS_X `pkg-config --cflags nss`"
> + LIBS="$LIBS_X `pkg-config --libs nss`"

Unfortunately, this part breaks Ruby scripting support.
EL_CONFIG_SCRIPTING_RUBY saves CFLAGS and LIBS in the *_X
variables, checks for Ruby, and restores the variables if Ruby
did not work.  Now when you copy LIBS_X to LIBS, you lose the
-lruby1.8 that was added in LIBS but not in LIBS_X.
In general, each check should set the *_X variables on its own
rather than rely on values left from the previous check.

The NSS support should be mentioned in doc/installation.txt.
I was thinking of the following change, but you can do something
else if you have better ideas.

From 4e0c3737e46952d4e1edb475b6b7c0a37fa3d778 Mon Sep 17 00:00:00 2001
From: Kalle Olavi Niemitalo <[EMAIL PROTECTED]>
Date: Sun, 7 Sep 2008 01:48:19 +0300
Subject: [PATCH] Mention nss_compat_ossl in doc/installation.txt

The dependency table was originally in "fixed" format, so that
AsciiDoc took a fixed number of characters to the first column
and the rest to the second column.  However, "OpenSSL or GNU TLS
or nss_compat_ossl" did not fit in that number of characters,
and backslash line continuation did not help because AsciiDoc
apparently parses that before it counts the characters.
I could have widened the column in the AsciiDoc source but
switching to "dsv" format seems prettier.
---
 doc/installation.txt |   54 +
 1 files changed, 28 insertions(+), 26 deletions(-)

diff --git a/doc/installation.txt b/doc/installation.txt
index 25ef001..c9bddd8 100644
--- a/doc/installation.txt
+++ b/doc/installation.txt
@@ -31,40 +31,42 @@ To make use of many of ELinks features you will need to have some external
 libraries and utility programs installed on your system. It is recommended to
 have the following libraries and programs installed:
 
-`---`
-Dependency		Description
--
-Lua or Guile		Makes it possible to write scripting plugins.	\
+[separator="|"]
+`___`
+Dependency		|Description
+_
+Lua or Guile		|Makes it possible to write scripting plugins.	\
 ifdef::installation-webpage[]
-			See link:manual.html#lua-scripting[the Elinks - Lua interface]\
+			 See link:manual.html#lua-scripting[the Elinks - Lua interface]\
 endif::installation-webpage[]
 ifndef::installation-webpage[]
-			See <>\
+			 See <>   \
 endif::installation-webpage[]
-			for more info.
-zlib 1.2.0.2 or later	For handling gzip or deflate compressed documents   \
-			both locally and sent from server.
-bzip2			Likewise, for bzip2 compressed documents.
-LZMA Utils		Likewise, for LZMA compressed documents.\
-			Version 4.32.5 should work.
-OpenSSL or GNU TLS	For handling secure HTTP browsing.
-GPM			'General Purpose Mouse' for mouse support.
-expat			'XML Parser Toolkit' needed for XBEL support.
-smbclient		Program needed for smb:// protocol support.
-rxvt-unicode		For terminal emulator which supports 88 colors.
-xterm with 256 colors	Program atleast patch level  179 or rxvt program\
-			from version 2.7.9 for support of 256 colors.	\
-			Newer PuTTY also has 256 color support.
-libidn			For internationalized domain names.
-SpiderMonkey		Mozilla's JavaScript engine for getting		\	
-			JavaScript/ECMAScript support in ELinks.	\
+			 for more info.
+zlib 1.2.0.2 or later	|For handling gzip or deflate compressed documents   \
+			 both locally and sent from server.
+bzip2			|Likewise, for bzip2 compressed documents.
+LZMA Utils		|Likewise, for LZMA compressed documents.\
+			 Version 4.32.5 should work.
+OpenSSL or GNU TLS \
+or nss_compat_ossl	|For handling secure HTTP browsing.
+GPM			|'General Purpose Mouse' for mouse support.
+expat			|'XML Parser Toolkit' needed for XBEL support.
+smbclient		|Program needed for smb:// protocol support.
+rxvt-unicode		|For terminal emulator which supports 88 colors.
+xterm with 256 colors	|Program atleast patch level  179 or rxvt program   \
+			 from version 2.7.9 for support of 256 colors.	\
+			 Newer PuTTY also has 256 color support.
+libidn			|For internationalized domain names.
+SpiderM

Re: [elinks-dev] elinks 0.13-20080905 internal error with a certian HTML file.

2008-09-06 Thread Kalle Olavi Niemitalo

أحمد المحمودي <[EMAIL PROTECTED]> writes:

>   When I attempt to open a certain HTML file, elinks core dumps giving 
>   out the following error:

Unfortunately I cannot reproduce this crash with your attachment.
I ran ELinks like this:

$ LD_LIBRARY_PATH=/home/Kalle/prefix/i686-pc-linux-gnu/lib 
~Kalle/build/i686-pc-linux-gnu/elinks-0.13_O2_small/src/elinks -no-home 
-no-connect ~Kalle/trans/article_17686.shtml

ELinks displayed the page, although I guess not correctly because it
does not support right-to-left text.  Then I pressed q and Enter
to quit.  There was no crash.  I also tried a few other
configurations.  These tests were all with commit
7de8b9940c96f51c55c2706ed9aa6ad11257d7ee which I think what was
in last night's elinks-0.13 snapshot.

Please try doing the same with your elinks binary.  Do you get
the crash that way or do you have to do something else
(e.g. follow some links, enable Javascript, or load the HTML via
HTTP rather than from a file) to trigger the crash?

Please also list the options you gave to the configure script,
the version of your compiler, and the type and size (e.g. 80x25)
of your terminal.

> elinks(dump_backtrace+0x1c)[0x81324ec]
> elinks[0x80e2b4d]
> elinks[0x80e2a54]
> [0xb7fc3420]
> elinks(force_dump+0x69)[0x8132939]
> elinks(debug_mem_free+0x50)[0x8135d30]
> elinks(done_document+0x1af)[0x809488f]

Unfortunately the backtrace displayed by ELinks is not as good as
what gdb can provide.  Please try to get line numbers in the
backtrace by reproducing the crash under gdb or by running gdb on
a core file.  It would be especially interesting to know the line
number within done_document.

And if you can reproduce the crash under valgrind, the output
From that will probably show both where the memory was originally
freed and where it's being freed the second time.  That would be
very useful.

pgpWs4vMJLUgu.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] elinks 0.13 build error.

2008-09-04 Thread Kalle Olavi Niemitalo

أحمد المحمودي <[EMAIL PROTECTED]> writes:

>   Lately I was trying to build elinks 0.13 debian package, yet it fails 
>   to build giving this error:
>
> make[4]: Entering directory 
> `/tmp/buildd/elinks-0.13~20080901/build-main/src/protocol/gopher'
>   [CC]   src/protocol/gopher/gopher.o
> /tmp/buildd/elinks-0.13~20080901/src/protocol/gopher/gopher.c: In function 
> 'add_gopher_command':
> /tmp/buildd/elinks-0.13~20080901/src/protocol/gopher/gopher.c:211: error: 
> incompatible types in return

Thanks for reporting this.  I've added --enable-gopher to some of
my build scripts and pushed fixes to elinks-0.12 and master.  The
latter has not yet propagated to http://elinks.cz/elinks.git though.


pgpXxfmZYCTMY.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] [PATCH] Add support for nss_compat_ossl library (OpenSSL replacement).

2008-08-24 Thread Kalle Olavi Niemitalo

Kamil Dudka <[EMAIL PROTECTED]> writes:

> as requested in src/network/ssl/TODO support for NSS was added to elinks.

Although it is listed in TODO, I am not sure it is a good idea.
Current versions of ELinks do not check the subject names of
certificates (bug 1024), do not display detailed error messages
when SSL or TLS fails, and do not provide a way to temporarily
trust a certificate.  I fear fixing these and maintaining the
resulting code will be more difficult if there are more
alternative libraries.

Does NSS enable ELinks to share the CA trust and client
certificate settings of Mozilla browsers?  If so, that would be
a reason to support NSS.

> From: Kamil Dudka <[EMAIL PROTECTED]>

Do you give permission to add this name and email address to our
public Git repository?  Please note the cia.vc and ohloh.net web
sites already collect profiles of people and others can do so in
the future.

ELinks was originally licensed under GNU GPL v2 or later, but
since ELinks 0.10.0, only GPLv2 is allowed.  If we ever want to
change the license back (e.g. because of LGPLv3 libraries), we'll
need permission from all copyright holders, I suppose.  Do you
give such permission?

> @@ -79,6 +83,8 @@ ssl_set_no_tls(struct socket *socket)
>  
>   gnutls_protocol_set_priority(*(ssl_t *) socket->ssl, 
> protocol_priority);
>   }
> +#elif defined(CONFIG_NSS_COMPAT_OSSL)
> +#warning "ssl_setno_tls is not implemented while using nss_compat_ossl"
>  #endif
>  }

configure --enable-debug adds -Werror to CFLAGS if using GCC;
does this #warning then break the build?  Also, it's a
nonstandard directive and may hurt users of other compilers.
(There is a #warning in osdep/system.h too but it's in an #if
whose condition should never be true.)

If ssl_set_no_tls is not necessary because NSS automatically
selects the right protocol version (more reliably than GnuTLS),
then I don't think the warning should be there either.
Otherwise, ssl_set_no_tls should be implemented... or is it
impossible to implement with nss_compat_ossl?

> +#ifdef CONFIG_NSS_COMPAT_OSSL
> + INIT_OPT_STRING("connection.ssl.client_cert", N_("Certificate 
> nickname"),
> + "file", 0, "",
> +  N_("The nickname of the client certificate stored in NSS\n"
> + "database. If this value is unset, the file pointed to\n"
> + "by the X509_CLIENT_CERT variable is used instead. If\n"
> + "you have a PKCS#12 file containing client certificate,\n"
> + "you can import it into your NSS database with:\n"
> + "$ pk12util -i mycert.p12 -d /path/to/database\n\n"
> + "The NSS database location can be changed by SSL_DIR\n"
> + "environment variable.")),
> +#else
>   INIT_OPT_STRING("connection.ssl.client_cert", N_("Certificate File"),
>   "file", 0, "",
>N_("The location of a file containing the client certificate\n"
>   "and unencrypted private key in PEM format. If unset, the\n"
>   "file pointed to by the X509_CLIENT_CERT variable is used\n"
>   "instead.")),
> +#endif

You make connection.ssl.client_cert.file mean a file name if
using OpenSSL, but a nickname if using NSS.  Can the user set up
an elinks.conf that works correctly under both interpretations?
(For example, by defining a nickname that looks like a file
name.)  If not, I think it would be better to use a different
name for the nickname option.  (An elinks binary built with NSS
might then warn about unrecognized connection.ssl.client_cert.file
in elinks.conf.  That could be fixed either by unconditionally
compiling the option definitions in ELinks, or by changing the
elinks.conf parser not to warn about unrecognized options by
default.  The latter solution seems nicer because it avoids bloat
and removes annoying warnings also when SSL support or some other
module is entirely disabled.)

Your current documentation string claims that X509_CLIENT_CERT
is a file name even with NSS.  However, the code seems to use
the value of X509_CLIENT_CERT simply as a default for the option,
thus as a nickname.

pgp9KGtEjDAFJ.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] gnutls/openssl.h changed to GPLv3+

2008-08-16 Thread Kalle Olavi Niemitalo

elinks-0.12/configure.in does:

# Verify if the MD5 compatibility layer is usable.
CONFIG_GNUTLS_OPENSSL_COMPAT=yes
EL_CHECK_OPTIONAL_LIBRARY(CONFIG_GNUTLS_OPENSSL_COMPAT,
  [GNU TLS OpenSSL compatibility],
  gnutls/openssl.h, gnutls-openssl,
  MD5_Init)

In GnuTLS 2.2.0 and 2.4.1, gnutls/openssl.h is licensed under GNU
GPL v3 or later:

 * This file is part of GNUTLS-EXTRA.
 *
 * GNUTLS-EXTRA is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License as
 * published by the Free Software Foundation; either version 3 of the
 * License, or (at your option) any later version.

However, ELinks 0.10.0 and later are licensed under GNU GPL v2 only:

"This program is free software; you can redistribute it "
"and/or modify it under the terms of the GNU General Public "
"License as published by the Free Software Foundation, "
"specifically version 2 of the License."),

This looks like a conflict.  Avoiding license conflicts was the
whole reason for GnuTLS support in ELinks, so this should be fixed.

I think I should change configure.in of ELinks 0.11.4.GIT and
0.12.GIT to skip the test and always define
CONFIG_GNUTLS_OPENSSL_COMPAT=no, so that src/util/md5.c will be
compiled instead.  I would leave the uses of that macro
unchanged, so that if someone is still using an older GnuTLS and
really needs to keep the size of the elinks executable down,
he/she can define the macro by hand.  Alternatively, the
configure script could check the version number of GnuTLS, or
grep for "either version 2" in gnutls/openssl.h, but the simpler
solution is easier to test.

Personally, I would like a BSD-licensed ELinks.  GPLv2 seems to
assume that one party (FSF) has all the copyrights and can thus
waive onerous requirements and regrant terminated licenses where
reasonable.


pgpuUGWT53ajZ.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] please don't git describe in 0.12

2008-08-10 Thread Kalle Olavi Niemitalo

I have now patched Git to hide my local tags from git describe.
I am intentionally not sending this to the git mailing list
because I'm not sure I can satisfy their Signed-Off-By
requirements right away.  The "Modified on" comments are for
GPLv2 clause 2. a).


Add describe.ignoretags config variable

In my elinks.git repository, I have many annotated tags that do not
correspond to ELinks releases.  For example, a tag called
email/elinks-users/2007-07-30 refers to a commit that I posted as
a patch to elinks-users on 2007-07-30; the tag object contains the
Message-ID and some other email headers.  These tags were affecting
the result of "git describe" called by a Makefile.  Now I can
prevent that by setting describe.ignoretags in elinks.git/config.

In Git 1.5.5 and later, it was already possible to limit the set
of tags considered, with git describe --match=PATTERN.  To match
"elinks-0.11.4" and "elinks-0.12pre1", we could use
--match="elinks-*".  However, the naming scheme has been changed
in the past (from e.g. REL_0_10_6) and may be changed again in the
future.  Besides, ignoring the email tags is what I want for
interactive use of git describe as well.

There are no new tests in this commit.

---
commit c97654d02a95e6701481204121a4f4c59e8f3088
tree 9abf39a8d8dca5308ae77923702606bf630778b1
parent 71b9979bc74b66c1cf961d5c74de5c0b3cbf00a4
author Kalle Olavi Niemitalo <[EMAIL PROTECTED]> Sun, 10 Aug 2008 17:56:45 +0300
committer Kalle Olavi Niemitalo <[EMAIL PROTECTED]> Sun, 10 Aug 2008 17:56:45 
+0300

 Documentation/config.txt   |   11 +++
 Documentation/git-describe.txt |5 -
 builtin-describe.c |   29 -
 3 files changed, 43 insertions(+), 2 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index b8ec01c..c9270b5 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1,3 +1,5 @@
+// Modified on 2008-08-10 by Kalle Olavi Niemitalo
+
 CONFIGURATION FILE
 --
 
@@ -557,6 +559,15 @@ color.ui::
terminal. When more specific variables of color.* are set, they always
take precedence over this setting. Defaults to false.
 
+describe.excludetags::
+   Makes 'git-describe' ignore tags that match a pattern.  Some
+   programs call 'git-describe' at build time and display the
+   result as a version number; if you have made some annotated
+   tags for your local use, set this option to prevent them from
+   affecting the displayed version number.  The value should be a
+   pattern of tag names, e.g. `local/*`.  You can set this option
+   multiple times.
+
 diff.autorefreshindex::
When using 'git-diff' to compare with work tree
files, do not consider stat-only change as changed.
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index c4dbc2a..33a923e 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -68,7 +68,9 @@ OPTIONS
 
 --match ::
Only consider tags matching the given pattern (can be used to avoid
-   leaking private tags made from the repository).
+   leaking private tags made from the repository).  Alternatively,
+   you could set the describe.excludetags configuration variable;
+   see linkgit:git-config[1] for details.
 
 --always::
Show uniquely abbreviated commit object as fallback.
@@ -138,6 +140,7 @@ Author
 Written by Linus Torvalds <[EMAIL PROTECTED]>, but somewhat
 butchered by Junio C Hamano <[EMAIL PROTECTED]>.  Later significantly
 updated by Shawn Pearce <[EMAIL PROTECTED]>.
+Modified on 2008-08-10 by Kalle Olavi Niemitalo.
 
 Documentation
 --
diff --git a/builtin-describe.c b/builtin-describe.c
index ec404c8..4367ab9 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -1,3 +1,5 @@
+/* Modified on 2008-08-10 by Kalle Olavi Niemitalo */
+
 #include "cache.h"
 #include "commit.h"
 #include "tag.h"
@@ -5,6 +7,7 @@
 #include "builtin.h"
 #include "exec_cmd.h"
 #include "parse-options.h"
+#include "string-list.h"
 
 #define SEEN   (1u<<0)
 #define MAX_TAGS   (FLAG_BITS - 1)
@@ -22,6 +25,28 @@ static int abbrev = DEFAULT_ABBREV;
 static int max_candidates = 10;
 static const char *pattern;
 static int always;
+static struct string_list exclude_patterns = { .strdup_strings = 1 };
+
+static int git_describe_config(const char *var, const char *value, void *cb)
+{
+   if (!strcmp(var, "describe.excludetags")) {
+   if (!value)
+   return config_error_nonbool(var);
+   string_list_append(value, &exclude_patterns);
+   return 0;
+   }
+   return git_default_config(var, value, cb);
+}
+
+static int matches_any_exclude_pattern(con

[elinks-dev] Why is timeout in struct document?

2008-07-21 Thread Kalle Olavi Niemitalo

When a script in a web page calls window.setTimeout, ELinks sets
document.timeout.  So, when two tabs are displaying the same
document (e.g. test/ecmascript/scroll.html), only one of the tabs
can have a timeout at a time.  If that tab is closed, then
nothing has a timeout any more.  That does not seem right to me.

Witekfl originally added ecmascript_interpreter.timeout on
2006-10-23, but then replaced that with document.timeout in
commit 2fe0623298a5a16b6a97885de30f5aae1a44855d the next day.
Why was that?

On a related note, we should perhaps add a document_view.title
or view_state.title that ECMAScript could modify instead of
document.title.  It seems weird that document title changes
affect multiple tabs while input field changes do not.


pgp4QhRF422Ty.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] elinks crashes

2008-07-14 Thread Kalle Olavi Niemitalo

أحمد المحمودي <[EMAIL PROTECTED]> writes:

> I refresh the page http://launchpad.net/~aelmahmoudy/+archive, and while 
> the page is refreshing I open a link 
> (https://launchpad.net/~aelmahmoudy/+archive/+build/669073) in another 
> tab, then refresh this tab (in which the new links was opened), and then 
> close the tab to return to the previous tab (which contained 
> http://launchpad.net/~aelmahmoudy/+archive). At that point, when I 
> closed the tab contained the newly opened link after refresh, the crash 
> occurs.

Thank you for these clear instructions with which I could easily
reproduce the bug.  Valgrind showed the following:

==28016== Invalid read of size 4
==28016==at 0x8112C54: debug_mem_free (memdebug.c:440)
==28016==by 0x81313FF: destroy_vs (vs.c:54)
==28016==by 0x80FD41F: destroy_location (location.c:51)
==28016==by 0x80FC9B6: free_history (history.c:34)
==28016==by 0x80FC90B: destroy_history (history.c:51)
==28016==by 0x81004EF: destroy_session (session.c:1166)
==28016==by 0x8100993: tabwin_func (session.c:1260)
==28016==by 0x810CB42: delete_window (window.c:85)
==28016==by 0x810AF8B: really_close_tab (tab.c:185)
==28016==by 0x810AFF9: close_tab (tab.c:200)
==28016==by 0x8117306: do_action (action.c:539)
==28016==by 0x81307AA: send_kbd_event (view.c:1468)
==28016==  Address 0x489CED8 is 16 bytes inside a block of size 161 free'd
==28016==at 0x402210F: free (vg_replace_malloc.c:233)
==28016==by 0x8112DEC: debug_mem_free (memdebug.c:484)
==28016==by 0x81313FF: destroy_vs (vs.c:54)
==28016==by 0x80FD41F: destroy_location (location.c:51)
==28016==by 0x80FC9B6: free_history (history.c:34)
==28016==by 0x80FC90B: destroy_history (history.c:51)
==28016==by 0x81004EF: destroy_session (session.c:1166)
==28016==by 0x8100993: tabwin_func (session.c:1260)
==28016==by 0x810CB42: delete_window (window.c:85)
==28016==by 0x810AF8B: really_close_tab (tab.c:185)
==28016==by 0x810AFF9: close_tab (tab.c:200)
==28016==by 0x8117306: do_action (action.c:539)

i.e., the memory block was freed twice in exactly the same way.
I then looked for places where view_state.form_info was set, and
sure enough, copy_vs could copy the pointer from another struct
view_state and then leave it unchanged.  I think this could not
happen in releases earlier than 0.12pre1, because there was no
way for view_state.form_info_len to become 0 while
view_state.form_info was not NULL.

Please try the patch below.  Would you like "Reported by أحمد
المحمودي" or something like that in the commit message?  (I am
wary of adding such things without explicit permission, because
of the privacy laws around here.)

--
Fix crash after a tab was opened during reload.

---
commit b07fecc2be6eeb7e20e555f6128e50f1ed4ee7f9
tree 5df3f87ddb3ed9bae1126009cd755f7137c89cf6
parent 6b05cdb3a0a12e8cf8bae3860b1a59e86d3076a1
author Kalle Olavi Niemitalo <[EMAIL PROTECTED]> Tue, 15 Jul 2008 00:09:27 +0300
committer Kalle Olavi Niemitalo <[EMAIL PROTECTED]> Tue, 15 Jul 2008 00:09:27 
+0300

 NEWS |2 ++
 src/viewer/text/vs.c |6 ++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/NEWS b/NEWS
index b01a90a..7108a8e 100644
--- a/NEWS
+++ b/NEWS
@@ -18,6 +18,8 @@ generally also includes the bug fixes made in ELinks 
0.11.4.GIT.
 
 Bugs that should be removed from NEWS before the 0.12.0 release:
 
+* critical: Fix crash after a tab was opened during reload.  This was
+  triggered by the bug 620 fix in ELinks 0.12pre1.
 * major bug 1026 in user SMJS: Protect the callback of elinks.load_uri
   from the garbage collector.  The elinks.load_uri method was added in
   ELinks 0.12pre1.
diff --git a/src/viewer/text/vs.c b/src/viewer/text/vs.c
index d0bbdf5..a7978db 100644
--- a/src/viewer/text/vs.c
+++ b/src/viewer/text/vs.c
@@ -79,6 +79,12 @@ copy_vs(struct view_state *dst, struct view_state *src)
dst->ecmascript_fragile = 1;
 #endif
 
+   /* destroy_vs(vs) does mem_free_if(vs->form_info), so each
+* view_state must have its own form_info.  Normally we make a
+* copy below, but not if src->form_info_len is 0, which it
+* can be even if src->form_info is not NULL.  */
+   dst->form_info = NULL;
+
/* Clean as a baby. */
dst->doc_view = NULL;
 


pgpPDwky7eNRg.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] Why does potfiles.list go in $(srcdir)?

2008-07-04 Thread Kalle Olavi Niemitalo

I'm changing contrib/mkdist to include po/elinks.pot in the
ELinks release (not snapshot) tarballs, as recommended at
.

Because mkdist checks the source out from the Git repository,
which does not contain po/elinks.pot, it must build this file
From the source.  When po/Makefile is asked to generate
elinks.pot, it also generates potfiles.list in the source
directory.  This file has not been included in earlier ELinks
tarballs, and I don't see any reason to include it now, so I'm
changing mkdist to remove potfiles.list from the source directory
before it runs tar.

Why does po/Makefile generate potfiles.list at all?  It seems to
me that po/Makefile could just run find and pipe the resulting
list to "xgettext -f-".  Does potfiles.list serve some purpose
in dependency decisions or does it exist for debugging only?
Could I move it from the source directory to the build directory,
so that mkdist wouldn't have to explicitly delete it?


pgpH3exVaw5yE.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

[elinks-dev] ELinks 0.11.4 and 0.12pre1 update to Free Software Directory

2008-07-01 Thread Kalle Olavi Niemitalo

The Free Software Directory at  lists
ELinks 0.11.3 as the latest version.  However, ELinks 0.11.4 was
released on 2008-06-20, and ELinks 0.12pre1 was released today on
2008-07-01; please see  for details
on these releases.  I have attempted to update your Elinks.txt
file as shown below, but I could not find any documentation on
the file format, so please check these changes before putting
them in CVS.

Index: Elinks.txt
===
RCS file: /sources/directory/directory/Elinks.txt,v
retrieving revision 1.26
diff -u -r1.26 Elinks.txt
--- Elinks.txt  8 Jun 2007 13:08:06 -   1.26
+++ Elinks.txt  1 Jul 2008 13:11:23 -
@@ -43,7 +43,7 @@
 
 %%touched: 2003-05-13
 
-%%updated: 2007-06-04
+%%updated: 2008-07-01
 
 %%keywords: elinks, browser, text mode, Internet, links
 
@@ -71,7 +71,7 @@
 
 %%changelog: http://elinks.cz/release.html
 
-%%source-tarball: http://elinks.cz/download/elinks-0.11.3.tar.bz2
+%%source-tarball: http://elinks.cz/download/elinks-0.11.4.tar.bz2; 
http://elinks.cz/download/elinks-0.12pre1.tar.bz2
 
 %%source-info: http://elinks.cz/download.html
 
@@ -106,7 +106,7 @@
 
 %%source-prerequisites:
 
-%%version: 0.11.3 stable released 2007-04-15
+%%version: 0.11.4 stable released 2008-06-20; 0.12pre1 devel released 
2008-07-01
 
 %%announce-list: <[EMAIL PROTECTED]>
 


pgpMNC5aR9Dnc.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] proposed ELinks 0.12pre1 release announcement

2008-07-01 Thread Kalle Olavi Niemitalo

sing of escape sequences and control
  sequences from the terminal
* bug 948: fix wrong UTF-8 output after the charset menu was used
* bug 816: convert entity references in input/@value only once
* bug 916: if a mailcap entry has no %s, provide the file as stdin
* bug 744: don't change ``//'' to ``/'' in URIs
* bug 766: speed up CSS
* bug 355: add documents displayed via ``What to do'' dialog to the
  global history
* encode and decode filenames in FSP URLs
* don't use a busy cache entry if it has expired or should be
  reloaded.  See elinks-users mail from 28 Oct 2005.
* several accesskey fixes
* in Lua: don't write to the string returned by lua_tostring
* minor bug 972: preserve the background color and underlining in
  spaces when justifying
* minor bug 284: render closing bracket for HTML element SUB in the
  same line; don't let it fall to the next
* minor: show quote characters for HTML element Q, rather than italics
* trivial bug 387: treat 
 inside ... as a newline
* trivial bug 930: refresh status bar when key prefix is eaten
* trivial bug 776: ``elinks -remote http://elinks.cz/'' no longer clears
  the screen
* enhancement 790: If-Modified-Since and If-None-Match
* enhancement: HTTP negotiate-auth using GSSAPI
* enhancement: FSP progress indicator and password prompt
* enhancement: autocreate directories needed to download a file
* enhancement: ``Add server'' button in the cookie manager
* enhancement 887: ``Save'' in the cookie manager now saves cookies
  even if unmodified
* enhancement 145: internal clipboard support
* enhancement: new main actions move-cursor-line-start,
  move-link-down-line, move-link-left-line, move-link-right-line,
  move-link-up-line
* enhancement: new edit actions kill-word-back, move-backward-word,
  move-forward-word
* enhancements 687, 688: options ui.tabs.top, ui.show_menu_bar_always
* enhancement: highlight links as one enters link prefixes
* enhancement: backspace backs out the last digit of the prefix
* enhancement: in text type-ahead searching, don't follow current link
  on enter
* enhancement: add support for parsing space separated CSS class
  attribute values
* enhancement: make meta refresh content attribute parsing more tolerant
* enhancement: recognize meta http-equiv="cache-control" even if no
  refresh
* enhancement: mouse wheel support over GPM (contrib/gpm-wheel.patch),
  and on BSD via moused -z 4
* enhancement: 24-bit truecolor mode
* enhancement 622: -dump-color-mode
* enhancement 994: treat only termios.c_cc[VERASE] as "Backspace"
* enhancement: support Ctrl+Alt+letter key combinations
* enhancement 381: reduce memory consumption of codepages and some
  other arrays
* enhancement in user SMJS: new properties/functions elinks.action,
  elinks.execute, elinks.globhist, elinks.load_uri, elinks.vs

Build system and compile-time errors (ignore if you don't build ELinks):

* serious Debian bug 464384: fix warnings in alignof, ssl_connect, and
  printing of off_t values
* bug 725: fix version checking for Ruby in 'configure'
* enhancement: if make -k was used and a sub-Make fails, build the
  rest before propagating
* enhancement: make uninstall
* experimental enhancements: --with-python=DIRECTORY, --with-gc=DIRECTORY
* experimental enhancement: Win32 port (build with MinGW MSYS)

Changes in the experimental ECMAScript support:

* disabled by default, as mentioned under ``Incompatibilities'' above
* execute event-handler scripts as function bodies, so ``return''
  statements work as intended
* fix error ``forms.namedItem is not a function''
* enhancement: SEE ECMAScript backend, an alternative to SpiderMonkey
* enhancement: handling onsubmit
* workaround: window.open remembers the last few URLs and doesn't
  reopen them when incremental rendering reruns the onload script
* enhancement: better handling of form.action assignments
* enhancement: form[x] looks up controls also by 'id', not only 'name'
* enhancement: added document.location.href, input.selectedIndex,
  window.setTimeout, window.status

Changes in the experimental NNTP client:

* HTML escape header field values
* Add support for handling RFC2047 encoded words
* Improve listing of articles for groups

Changes in the experimental SGML/DOM implementation:

* enhancement: minimalistic RSS renderer
* enhancement: source highlighting also recognizes
  application/xhtml+xml and application/docbook+xml.  It doesn't yet
  support arbitrary XML though.
* enhancement: make it possible to use more CSS properties with the
  source highlighting
* enhancement: handle  for HTML source rendering
* enhancement: add support for scanning comment endings such as
  '--!>' correctly
* enhancement: incremental parsing
* and more.

Statistics and authors
--

It feels like a lot has changed between 0.11.0 and

[elinks-dev] proposed ELinks 0.12pre1 release announcement

2008-06-30 Thread Kalle Olavi Niemitalo

e-start,
  move-link-down-line, move-link-left-line, move-link-right-line,
  move-link-up-line
* enhancement: new edit actions kill-word-back, move-backward-word,
  move-forward-word
* enhancements 687, 688: options ui.tabs.top, ui.show_menu_bar_always
* enhancement: highlight links as one enters link prefixes
* enhancement: backspace backs out the last digit of the prefix
* enhancement: in text type-ahead searching, don't follow current link
  on enter
* enhancement: add support for parsing space separated CSS class
  attribute values
* enhancement: make meta refresh content attribute parsing more tolerant
* enhancement: recognize meta http-equiv="cache-control" even if no
  refresh
* enhancement: mouse wheel support over GPM (contrib/gpm-wheel.patch),
  and on BSD via moused -z 4
* enhancement: 24-bit truecolor mode
* enhancement 622: -dump-color-mode
* enhancement 994: treat only termios.c_cc[VERASE] as "Backspace"
* enhancement: support Ctrl+Alt+letter key combinations
* enhancement 381: reduce memory consumption of codepages and some
  other arrays
* enhancement in user SMJS: new properties/functions elinks.action,
  elinks.execute, elinks.globhist, elinks.load_uri, elinks.vs

Build system and compile-time errors (ignore if you don't build ELinks):

* serious Debian bug 464384: fix warnings in alignof, ssl_connect, and
  printing of off_t values
* bug 725: fix version checking for Ruby in 'configure'
* enhancement: if make -k was used and a sub-Make fails, build the
  rest before propagating
* enhancement: make uninstall
* experimental enhancements: --with-python=DIRECTORY, --with-gc=DIRECTORY
* experimental enhancement: Win32 port (build with MinGW MSYS)

Changes in the experimental ECMAScript support:

* disabled by default, as mentioned under ``Incompatibilities'' above
* execute event-handler scripts as function bodies, so ``return''
  statements work as intended
* fix error ``forms.namedItem is not a function''
* enhancement: SEE ECMAScript backend, an alternative to SpiderMonkey
* enhancement: handling onsubmit
* workaround: window.open remembers the last few URLs and doesn't
  reopen them when incremental rendering reruns the onload script
* enhancement: better handling of form.action assignments
* enhancement: form[x] looks up controls also by 'id', not only 'name'
* enhancement: added document.location.href, input.selectedIndex,
  window.setTimeout, window.status

Changes in the experimental NNTP client:

* HTML escape header field values
* Add support for handling RFC2047 encoded words
* Improve listing of articles for groups

Changes in the experimental SGML/DOM implementation:

* enhancement: minimalistic RSS renderer
* enhancement: source highlighting also recognizes
  application/xhtml+xml and application/docbook+xml.  It doesn't yet
  support arbitrary XML though.
* enhancement: make it possible to use more CSS properties with the
  source highlighting
* enhancement: handle  for HTML source rendering
* enhancement: add support for scanning comment endings such as
  '--!>' correctly
* enhancement: incremental parsing
* and more.

Statistics and authors
--

It feels like a lot has changed between 0.11.0 and 0.12pre1, but the
numbers show that the step from 0.10.0 to 0.11.0 was somewhat larger,
even though it took far less time.

Changes from ELinks 0.10.0 to ELinks 0.11.0:
 1040 files changed, 172844 insertions(+), 164531 deletions(-)
 372 days, 3651 commits, 14 authors

Changes from ELinks 0.11.0 to ELinks 0.11.4:
 387 files changed, 37232 insertions(+), 30019 deletions(-)
 901 days, 454 commits, 14 authors

Changes from ELinks 0.11.0 to ELinks 0.12pre1:
 768 files changed, 127854 insertions(+), 75163 deletions(-)
 910 days, 2243 commits, 19 authors as listed below:

 Adam Golebiowski
 Eric Wald
 Jens Seidel
 Jonas Fonseca
 Kalle Olavi Niemitalo
 Laurent MONIN
 M. Levinson
 Miciah Dashiel Butler Masters
 Nerijus Baliunas
 Paul B. Mahol
 Pavol Babincak
 Petr Baudis
 Rich Felker
 Russ Rowan
 Simon Josefsson
 Thomas Adam
 Timo Lindfors
 Witold Filipczyk
 Y Giridhar Appaji Nag

Looking forward
---

ELinks 0.12pre1 has the following bugs that were not in 0.11.3.
These should be fixed before the 0.12.0 release:

* Bug 765 - Opening a new tab can ask about the document of the
  previous tab
* Bug 943 - Crash: BFU points to a freed struct type_query
* Bug 955 - FORM/@onsubmit is called for reset buttons too

There are also a few other bugs scheduled for 0.12.0:

* Bug 771 - Infinite loop is not well handled
* Bug 954 - Each DOM access results in a different object
* Bug 952 - struct form_view possibly freed before ECMAScript objects

It seems unlikely that these fixes would require changing the user
interface, so now is a good time for translators to bring the PO files
up to date.


pgpDrZqezaxnv.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] Monthly snapshots

2008-06-20 Thread Kalle Olavi Niemitalo

Kalle Olavi Niemitalo <[EMAIL PROTECTED]> writes:

> I would much rather pay for hosting elsewhere.

By the way, do you have any statistics on the disk and network
usage at elinks.cz?


pgpmYBB4vqdY8.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

Re: [elinks-dev] Monthly snapshots

2008-06-20 Thread Kalle Olavi Niemitalo

Jonas Fonseca <[EMAIL PROTECTED]> writes:

> Sounds good if somebody else is interested in starting the release
> process of 0.12 and master.

Okay, I will try to follow doc/release.txt in a local branch off
elinks-0.12.

> I don't know if it would make sense to start migrating to use
> Google Code for hosting the downloads.

Personally, I am not willing to accept the confidentiality and
export control clauses in the Terms of Service of Google Code.
I would much rather pay for hosting elsewhere.

> 0.12 and master seem to have already diverged quite a bit:
>
>   180 files changed, 4400 insertions(+), 2229 deletions(-)
>
> just for src/. Any thoughts about this? In my opinion, this has always
> (at least once the number of committers grew) been ELinks' problem. The
> gab between stable/unstable are very big, which makes making new
> releases and upgrading very painful.

I don't think 0.13.GIT has many regressions compared to 0.12.GIT.
After 0.12.0 has been released, we may be able to get 0.13.0 out
in a few months.

Why do you think upgrading is painful?  AFAIK, the only
configuration incompatibility between 0.12.GIT and 0.13.GIT is
the removed protocol.fsp.sort option, and that we could mitigate
by disabling the warnings about unrecognized options.  Are there
some new library dependencies that are not listed in NEWS?

pgp0BJVodq82D.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

1 2 3 4 >

1 - 100 of 331 matches

Mail list logo