Re: [elinks-dev] update to autoconf 2.69
Kamil Dudka kdu...@redhat.com 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
Kamil Dudka kdu...@redhat.com writes:
+ INIT_OPT_SMART_PREFIX(ddg, https://duckduckgo.com/?q=%st=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=%st=elinks;),
#else
INIT_OPT_SMART_PREFIX(ddg, http://duckduckgo.com/?q=%st=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] [PATCH] bug 764: Fix option_value initialization on sparc64
Edd Barrett vex...@gmail.com 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
Edd Barrett vex...@gmail.com 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
Kalle Olavi Niemitalo k...@iki.fi 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=547action=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!
Edd Barrett vex...@gmail.com 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
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
Yuriy M. Kaminskiy yum...@gmail.com 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] Line-drawing characters when dumping Web pages
Kalle Olavi Niemitalo k...@iki.fi 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 k...@iki.fi
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 - FRAME_CHARS_BEGIN]
+ = cp2u(cp437, orig);
+ return;
+ }
+#endif /* CONFIG_UTF8 */
+
+ for (orig = FRAME_CHARS_BEGIN; orig FRAME_CHARS_END; orig++) {
+ for (subst = orig
Re: [elinks-dev] utf8 broken with -dump-color-mode other than -1,0
Cezary Bagiński cezary.bagin...@gmail.com 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] Line-drawing characters when dumping Web pages
(moved from elinks-users to elinks-dev because of the patch)
Karl Ove Hufthammer k...@huftis.org 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 k...@iki.fi
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 SCREEN_ATTR_FRAME)
+c = 176 c 224)
+ c = cp2u(cp437, frame_vt100_u[c - 176
Re: [elinks-dev] chunked gzip fails again
Witold Filipczyk wite...@poczta.onet.pl 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
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
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] Patch to make libtre dependency optional.
Hema Seetharamaiah h...@treap.net 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.
Hema Seetharamaiah h...@treap.net 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] Patch to make libtre dependency optional.
Hema Seetharamaiah h...@treap.net 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 k...@iki.fi 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 h...@treap.net. --- 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 tre/regex.h], - [regex_t re; - regmatch_t match[1]; - regwcomp(re, Lzap, REG_ICASE); - regwexec(re, LELIZAPROGRAM, 1, match, 0);], - [AC_MSG_RESULT([[yes]]) - AC_DEFINE([HAVE_TRE_REGEX_H], [1], - [Define to 1 if you have the tre/regex.h 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 tre/regex.h], + [regex_t re; + regmatch_t match[1]; + regwcomp(re, Lzap, REG_ICASE); + regwexec(re, LELIZAPROGRAM, 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 tre/regex.h 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 wchar_t is suitable)], + [AC_MSG_RESULT([[no]]) + TRE_CFLAGS= + TRE_LIBS= + EL_RESTORE_FLAGS + tre_log=no]) +fi AC_SUBST(TRE_CFLAGS) AC_SUBST(TRE_LIBS
[elinks-dev] Can GPLv2-only software be compiled with GCC 4.4.0?
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=143643view=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=146514view=markup http://gcc.gnu.org/viewcvs/tags/gcc_4_4_0_release/COPYING.RUNTIME?revision=146514view=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
Kalle Olavi Niemitalo k...@iki.fi 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
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=143643view=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=145866view=markup http://gcc.gnu.org/viewcvs/branches/gcc-4_4-branch/COPYING.RUNTIME?revision=145866view=markup http://www.gnu.org/licenses/gcc-exception.html http://www.gnu.org/licenses/gcc-exception-faq.html 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 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. (c) Keep compiling ELinks with older versions of GCC. (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] release 0.11.6 this weekend, 0.12pre2 a week later?
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
Re: [elinks-dev] option description wrapping
Kalle Olavi Niemitalo k...@iki.fi 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
Re: [elinks-dev] Patch for porting Elinks to OpenSolaris
Muktha Narayan muktha.nara...@sun.com 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?
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
Mark A. Carlson mark.carl...@sun.com 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 http://bugzilla.elinks.cz/show_bug.cgi?id=1047. 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
Re: [elinks-dev] crash on last usemap
أحمد المحمودي aelmahmo...@users.sourceforge.net 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 /MAP. Small test case: TITLEDouble-free crash in USEMAP/TITLE PIMG src=/dev/null usemap=#crasher/P MAP name=crasher AREA shape=rect coords=42,42,69,69 href=http://elinks.cz/; alt=see this? !-- no newline at the end of this line --/MAP 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!)
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
Re: [elinks-dev] Premature optimization
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
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
Re: [elinks-dev] charset licences in ELinks, and debian/copyright
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
Re: [elinks-dev] charset licences in ELinks, and debian/copyright
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 # 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. 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
[elinks-dev] charset licences in ELinks, and debian/copyright
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 http://git.debian.org/?p=collab-maint/elinks.git;a=commit;h=d33968506bf39500f56ee120d4a98a30b5f114d4 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 http://www.unicode.org/Public/MAPPINGS/ISO8859/DatedVersions/8859-1-1998.TXT but lacks control characters. ELinks inherited this from Links 0.96 (GPLv2+). - Unicode/8859_2.cp: No licence notice. Similar to http://www.unicode.org/Public/MAPPINGS/ISO8859/DatedVersions/8859-2-1999.TXT but lacks control characters. ELinks inherited this from Links 0.96 (GPLv2+). - Unicode/8859_3.cp: Unicode licence notice. Same as http://www.unicode.org/Public/MAPPINGS/ISO8859/DatedVersions/8859-3-1999.TXT, 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 http://www.unicode.org/Public/MAPPINGS/ISO8859/DatedVersions/8859-4-1998.TXT 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 http://www.unicode.org/Public/MAPPINGS/ISO8859/DatedVersions/8859-5-1999.TXT, 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 http://www.unicode.org/Public/MAPPINGS/ISO8859/DatedVersions/8859-6-1999.TXT, 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 http://www.unicode.org/Public/MAPPINGS/ISO8859/DatedVersions/8859-7-1987b.txt, 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 http://www.unicode.org/Public/MAPPINGS/ISO8859/DatedVersions/8859-8-1999.TXT, 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 http://www.unicode.org/Public/MAPPINGS/ISO8859/DatedVersions/8859-9-1999.TXT, only charset names have been added. ELinks inherited this from Links 0.96 (GPLv2+). - Unicode/8859_10.cp: Unicode licence notice. Same as http://www.unicode.org/Public/MAPPINGS/ISO8859/DatedVersions/8859-10-1998.TXT, 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 http://www.unicode.org/Public/MAPPINGS/ISO8859/DatedVersions/8859-13-1998.TXT 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 http://www.unicode.org/Public/MAPPINGS/ISO8859/DatedVersions/8859-14-1998.TXT, but a comment line differs. This was ported to ELinks from Links 2.1pre7 (GPLv2+). - Unicode/8859_15.cp: No licence notice. Similar to http://www.unicode.org/Public/MAPPINGS/ISO8859/DatedVersions/8859-15-1999.TXT 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 http://www.unicode.org/Public/MAPPINGS/ISO8859/DatedVersions/8859-16-2001.TXT but lacks control characters, and bytes 0xA5 and 0xAB have been swapped. ELinks got this from
Re: [elinks-dev] Crash when download ends (Crashes again !)
أحمد المحمودي [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
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
[elinks-dev] Removing unclearly licensed test files
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
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
Re: [elinks-dev] [PATCH] Add support for nss_compat_ossl library (OpenSSL replacement).
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] [PATCH] Add support for nss_compat_ossl library (OpenSSL replacement).
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] 0.12pre2 and 0.11.5 next weekend?
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).
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 nss3/ssl.h. As there is no actual nss3 directory, nor a symlink, this does not work. - Likewise with #include nspr4/nspr.h. - 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.
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] gnutls/openssl.h changed to GPLv3+
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
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 pattern::
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 (1u0)
#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(const char *tagname)
+{
+ unsigned int i;
+
+ for (i = 0; i exclude_patterns.nr; i++)
+ if (!fnmatch(exclude_patterns.items[i].string, tagname, 0))
+ return 1;
+ return 0;
+}
struct
[elinks-dev] Why is timeout in struct document?
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
أحمد المحمودي [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)?
I'm changing contrib/mkdist to include po/elinks.pot in the ELinks release (not snapshot) tarballs, as recommended at http://translationproject.org/html/maintainers.html. 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
Re: [elinks-dev] proposed ELinks 0.12pre1 release announcement
.../pre 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 base href= 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, 127871 insertions(+), 75184 deletions(-) 911 days, 2250 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
[elinks-dev] ELinks 0.11.4 and 0.12pre1 update to Free Software Directory
The Free Software Directory at http://directory.fsf.org/ 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 http://elinks.cz/news.html 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 @@ /pre %%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] Monthly snapshots
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] [PATCH] bzip2 still shows garbage in 0.13.GIT
Kalle Olavi Niemitalo [EMAIL PROTECTED] writes: The following patch fixes this for me. Do you think it could cause any problems? I pushed something equivalent to master and elinks-0.12. pgp0EFVPj4Axl.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Big files upload
Witold Filipczyk [EMAIL PROTECTED] writes: (b) is not acceptable. I chose /dev/urandom. Okay but please add error handling and a check that fread() got all the bytes it wanted. E.g. on Windows, there will be neither /dev/urandom nor /dev/prandom, and ELinks should detect this rather than proceed with an uninitialized and perhaps not very random buffer. I see though that encode_multipart() does not properly handle errors from e.g. add_char_to_string() either. Anyway, it's better to keep the bug in one function than spread it around. pgpwG1c8XUekA.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] [patch/rfc] grafthistory: keep the downloaded pack, speed up git gc
Jonas Fonseca [EMAIL PROTECTED] writes: +# Total size of .git/objects/pack/ was 90592 KiB without *.keep +# and 97397 KiB with *.keep. So *.keep reduced gc time by 70-80% +# but increased disk space usage by 7.5%. Maybe without this? Why, is it too revealing? I thought a user might notice the *.keep file, check where it came from, and find those measurements. Then make an informed decision not to delete the file. Or perhaps the numbers should go in the *.keep file itself? pgpibxnPJoZeZ.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
[elinks-dev] Bug#464073: elinks: 07_local-CGI-query-fix.diff patches the wrong function in 0.12
Package: elinks
Version: 0.12~20080127-1
Severity: minor
I see this in debian/patches/07_local-CGI-query-fix.diff:
--- a/src/protocol/uri.c
+++ b/src/protocol/uri.c
@@ -143,7 +143,7 @@ static int
check_whether_file_exists(unsigned char *name)
{
/* Check POST_CHAR etc ... */
- static const unsigned char chars[] = POST_CHAR_S #?;
+ static const unsigned char chars[] = POST_CHAR_S #;
int i;
int namelen = strlen(name);
The patch is based on commit e96665134ae9b5106fe0d5c30d445212d970e91b,
which modified check_uri_file(), not check_whether_file_exists().
In 0.12.GIT, commit 581ef57bb4b0ed62e13933ad8aaa8575bcc05be5 already
included that change, and 0cf15ca9d9dbc00c10f23440674fcdb832dffd75
then inlined and removed check_uri_file().
At first, I thought this change in the wrong function would break
'elinks $HOME/src/elinks-0.12/test/cgi/print-vars.sh?a=b', where
an OS-native file name (without file://) has a query-part appended.
Indeed, the patch makes ELinks just display an error message about
a missing file; curiously, the error message itself includes a full
URL for the file and the query, and copying that back to ELinks makes
it find the file properly.
However, it appears the command doesn't work entirely right without the
patch either: ELinks finds the correct file but discards the query.
I suppose that is a bug for us to fix; but anyway, please revert
07_local-CGI-query-fix.diff from 0.12.
pgpCeVfX6mPL3.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
[elinks-dev] parse_bencoding_integer does not detect all overflows
In src/protocol/bittorrent/bencoding.c, parse_bencoding_integer does:
off_t integer = 0;
...
for (; pos length isdigit(string[pos]); pos++) {
if (integer (off_t) integer * 10)
return 0;
integer = (off_t) integer * 10 + string[pos] - '0';
}
The check (integer (off_t) integer * 10) does not detect all
overflows. Examples with 32-bit off_t:
integer = 0x1C71C71D (0x1/9 rounded up)
integer * 10 = 0x11C71C722, wraps to 0x1C71C722 which is integer
integer = 0x7333
integer * 10 = 0x47FFE, wraps to 0x7FFE which is integer
Examples with 64-bit off_t:
integer = 0x1C71C71C71C71C72 (0x1/9 rounded up)
integer * 10 = 0x11C71C71C71C71C74, wraps to 0x1C71C71C71C71C74
which is integer
integer = 0x7333
integer * 10 = 0x47FFE, wraps to 0x7FFE
which is integer
So if the overflow check is necessary, it should be corrected.
If overflows can be assumed to wrap (C does not guarantee that),
then I think the following is correct and the simplest solution:
for (; pos length isdigit(string[pos]); pos++) {
off_t newint = integer * 10 + string[pos] - '0';
if (newint / 10 != integer)
return 0; /* overflow */
integer = newint;
}
OTOH, if overflows instead trap or saturate, then this won't work.
pgp2hLRG6qLjj.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Bug#337159: elinks: Does not recover from CTRL-Z
Y Giridhar Appaji Nag [EMAIL PROTECTED] writes: See also: http://bugs.debian.org/331409#57 Thank you for the pointer. However, I think it would be wrong to reopen bug 331409 for the Bash-ELinks interaction, because it was originally about a busy loop in Bash and that's not what happens in bug 337159. What is the procedure for asking the Bash maintainer whether he considers the loss of SIGCONT a bug in Bash or in ELinks (and if the latter, how else should ELinks be implemented)? I suppose I shouldn't just reassign bug 337159 to bash. pgp5TaeuBGrlu.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Bug#337159: elinks: Does not recover from CTRL-Z
Qingning Huo [EMAIL PROTECTED] writes:
So what is the real reason of this bug, elinks
is somehow confused whether it is at foreground?
The reason is that fg in Bash nowadays does not send SIGCONT to
the job if Bash has seen from waitpid() that the job is already
running. ELinks expects to receive this SIGCONT, in order to
know when it should try to take control of the terminal again.
This worked correctly in Bash 2.05 but has been broken since 2.05a.
The following patch does not revert any change between 2.05 and 2.05a
but fixes or works around the bug anyway.
diff -up /var/tmp/Kalle/Debian/bash-3.1dfsg/bash/jobs.c.\~1\~
/var/tmp/Kalle/Debian/bash-3.1dfsg/bash/jobs.c
--- /var/tmp/Kalle/Debian/bash-3.1dfsg/bash/jobs.c.~1~ 2008-01-23
00:16:33.0 +0200
+++ /var/tmp/Kalle/Debian/bash-3.1dfsg/bash/jobs.c 2008-01-23
00:17:55.0 +0200
@@ -2754,8 +2754,7 @@ start_job (job, foreground)
else
jobs[job]-flags = ~J_FOREGROUND;
- /* If the job is already running, then don't bother jump-starting it. */
- if (already_running == 0)
+ if (1)
{
jobs[job]-flags |= J_NOTIFIED;
killpg (jobs[job]-pgrp, SIGCONT);
pgpIG1btv7Zeo.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] unrecognized options in elinks.conf
Jonas Fonseca [EMAIL PROTECTED] writes: Yeah, they are probably not generally useful besides for users and developers who should be knowing what they do. But it also feels a bit wrong to simply drop the warnings. With the option you propose, maybe the a single shorter warning message is acceptable: Warnings found while parsing /.../elinks.conf. Use the --check-config option to show all warnings. Perhaps shorter than that. Well if you replace the verbose warnings with that message but keep the pause, then it'll still be as annoying as it is now. I think it should be possible to switch back and forth between ELinks versions without getting such warnings, even though old versions do not support all options that new versions may have saved in elinks.conf. A bit related to this is bug 503; fixing that would remove the parse errors that now follow each unrecognized-option warning. pgpn4l5I2VUqI.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] upcoming Debian ELinks 0.11.3-1; release 0.11.4?
Jonas Fonseca [EMAIL PROTECTED] writes: Do you or anybody else have any comments on outstanding issues for this release? There are several bugs that have been fixed in 0.12 or 0.13 and should perhaps be backported: 723 cri - After choosing a link from right frame ELinks crashes. 756 cri - assertion (cached)-object.refcount = 0 failed ... 722 maj - Elinks ignores CSS media type 956 maj - Dangling pointers to SMJS objects can be dereferenced 744 nor - ELinks changes // to / in path component of URI 766 nor - Rendering some pages may take too lng time 816 nor - doubly converts entities in input/@value 869 nor - long mailcap entry buffer overflow (non-security) when downloading 54 min - cfmakeraw() can break some exotic terminals 284 min - links uncorrectly handles sub inside pre/pre 867 enh - Use bracketed paste mode on xterm However, the important ones look rather involved and I'm not certain I could correctly backport them on the first attempt, so it would be better to release 0.11.4 first and worry about those bugs after the release when there is time to test the fixes properly. Also, any stuff needed by debian? (I didn't check if you also moved the debian/ directory in 0.11.GIT) For Debian, there is mainly: 988 min - Please remove debian directory and build generated files I've moved debian/ to contrib/debian/ in 0.11, 0.12, and 0.13, so that part should be okay now. You can remove the generated files by hand I guess, but fixing the bug ought to include updating mkdist. Then there are also bugs 991-993 which Witek reported; someone should test whether any of those are working in 0.11.3 but failing in 0.11.3.GIT. pgpqF2cRH7q6n.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
Fabienne Ducroquet [EMAIL PROTECTED] writes: On Thu, Dec 20, 2007 at 06:29:51AM +0200, Kalle Olavi Niemitalo wrote: I mean, the compiler might merely have decided to load the address of free_itrm into a register at that point, or something like that. But how could I see that? By disassembling the function and then perhaps comparing values of the program counter to the disassembly. Instead, you should find out why the select function is reporting an exceptional state for the file descriptor. According to the gdb output above select in can_read_or_write(7,1) returns 0 whereas on Linux it returns 1 in the same conditions, but why, I don't know. I'm not sure, but it seems to me that _hurd_select in glibc is using the select timeout as a timeout for the io_select RPC. So when the timeout is zero, _hurd_select has no time to receive the reply that the file descriptor is ready. You might perhaps verify this hypothesis by increasing the timeout in can_read_or_write. The behaviour of the Hurd here may be contrary to POSIX, but still, I don't see why that would cause free_itrm to be called too soon. What must I look here? the numbers between parenthesis after io_select_reply (in that case, they are always (0 1) or (0 2) or (0 0))? something completely different? hurd_types.h defines SELECT_URG as 4. In io_select_reply, the first value is return_code: kern_return_t, and the second value is select_result: int. Is the second value ever 4 or greater? If you find that, take note of the port to which the original io_select_request was sent, and search back to find how ELinks got a send right to that. In particular, did the send right come From a socket_create response? If the parameters of io_select_reply really are always (0 1), (0 2), or (0 0), then I think you'll have to trace inside _hurd_select in glibc and see why it's reporting an exception on the file descriptor even though it did not receive any io_select_reply that includes SELECT_URG. In the source code, there appear to be some error situations that default to type = SELECT_ALL;. You might put breakpoints on those, a breakpoint with condition msg.success.result 4 on int had = got;, and a breakpoint on got++; below if (type SELECT_URG). Something like the following patch? It seems to work, but perhaps it breaks something else. Probably it doesn't break anything else, but anyway I meant changing the callers of set_handlers, rather than the function itself. pgpLaU0I9VpXe.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
Fabienne Ducroquet [EMAIL PROTECTED] writes:
I've found that the function free_itrm is called later and it unsets
these modes.
free_itrm should be called only if an error or EOF occurs in
terminal handling, or when ELinks is exiting.
It is called by select_loop line 305 while i = 7 and n = 1.
I suppose you mean this part:
if (FD_ISSET(i, x_error)) {
if (threads[i].error_func) {
threads[i].error_func(threads[i].data);
check_bottom_halves();
}
k = 1;
}
Looking at pty_io_select in hurd-20040508/term/ptyio.c, I see
that it sets avail |= SELECT_URG whenever the caller is
interested in that and control_byte is nonzero. So, it appears
that ELinks interprets the presence of the tty in x_error as an
indication that an actual error has occurred, whereas the Hurd
would like to report benign TIOCPKT (packet_mode) or TIOCUCNTL
(user_ioctl_mode) related events that way.
Could pty_io_select perhaps be changed to report SELECT_URG only
if one of those modes is actually active?
Alternatively, ELinks could be changed to ignore exceptional
conditions that the select function returns for tty devices.
Specifically, all the uses of (select_handler_T) free_itrm as
the fourth argument of set_handlers would be changed to NULL.
However, I don't know the origin of that code, so I am wary of
changing it; it might be needed on some (perhaps non-POSIX) OS.
A Hurd-specific #ifdef would be doable though.
pgp8ZX8iRt8Ci.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
[elinks-dev] disable mouse (was: Sponsor development of the key motion.)
Ligesh [EMAIL PROTECTED] writes: Also I want to know if I can disable the need to press shift key while copy/pasting from/to elinks. It appears the toggle-mouse action (not bound to a key by default) would stop ELinks from requesting mouse events. However, this works on the master terminal only (the interlink protocol does not support such a request), the setting cannot be saved in elinks.conf (but some scripting modules may allow a startup script to execute the action), and I can't test it now. What type of terminal are you using? pgpLIRzuDCIzD.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
[elinks-dev] [PATCH] download.txt: No more Cogito. Describe branches.
I am not entirely satisfied with the result.
Can someone with good English or Git skills check this?
download.txt: No more Cogito. Describe branches.
---
commit 71b71d34283fe4f10dc70c15a8a31dfe0878a6d6
tree 0caddb5b0f4ff370c9b02b6d2a5258f72acf920a
parent 6317e6c9e49cd5a9b2650949331b05ec0f6d6a20
author Kalle Olavi Niemitalo [EMAIL PROTECTED] Sat, 04 Aug 2007 22:07:36 +0300
committer Kalle Olavi Niemitalo [EMAIL PROTECTED] Sat, 04 Aug 2007 22:08:17
+0300
download.html | 121 +-
download.txt | 127 -
2 files changed, 191 insertions(+), 57 deletions(-)
diff --git a/download.html b/download.html
index 30b1541..d87a489 100644
--- a/download.html
+++ b/download.html
@@ -146,47 +146,110 @@ is given in the following section./p
/div
h2ELinks via GIT/h2
div class=sectionbody
-pTo get access to ELinks via GIT you will need to have the following tools
-installed on your system:/p
+pTo get access to ELinks via GIT you will need to have GIT installed on
+your system. Please see the a href=http://git.or.cz/;GIT website/a for
pointers
+to source and binary packages and documentation. Pick the most recent
+version. (We no longer recommend
+a
href=http://article.gmane.org/gmane.comp.version-control.git/45014;Cogito/a.)/p
+pFirst, get yourself a copy of the ELinks repository by doing:/p
+table border=1 class=codetrtdpre% git clone
http://repo.or.cz/r/elinks.git
+% cd elinks/pre/td/tr/table
+p(If the operation hangs or fails, try also cloning from
+ttgit://repo.or.cz/elinks.git/tt or tthttp://elinks.cz/elinks.git/tt.
+However, your firewall may block the GIT protocol, and cloning
+from elinks.cz takes much longer. You can add more sources with
+ttgit remote add/tt after you have the clone.)/p
+pYou now have a working copy of the local #8220;master#8221; branch, which
is
+tracking the remote #8220;origin/master#8221; branch, where the unstable
+version of ELinks is kept. If you want to use some other remote
+branch, e.g. #8220;origin/elinks-0.12#8221;, create a corresponding local
+branch with this command:/p
+table border=1 class=codetrtdpre% git checkout --track -b
elinks-0.12 origin/elinks-0.12/pre/td/tr/table
+pYou can get a list of remote branches with ttgit branch -r/tt,
+ttgit remote show origin/tt, or ttgit ls-remote #8212;heads origin/tt.
+The following branches are known to exist:/p
dl
dt
-a href=http://kernel.org/pub/software/scm/git/;The GIT core/a
+master
+/dt
+dd
+The unstable version. As of August 2007, this is ELinks
+0.13.GIT, but few commits are made directly here; instead,
+they are made in #8220;elinks-0.12#8221; and later merged here.
+/dd
+dt
+elinks-0.12
+/dt
+dd
+The ELinks 0.12 series. Forked from #8220;master#8221; on 2007-04-22.
+Bug fixes only, until ELinks 0.12.0 has been released.
+/dd
+dt
+elinks-0.11
+/dt
+dd
+The ELinks 0.11 series. Mainly bug fixes are made here.
+/dd
+dt
+REL_0_10
/dt
dd
-This is a set of lowlevel tools able of accessing and modifying
-a GIT tree. Pick the most recent version.
+The ELinks 0.10 series. Unmaintained since 2007-03-17.
/dd
dt
-a href=http://kernel.org/pub/software/scm/cogito/;The Cogito tools/a
+utf8
/dt
dd
-Which is a set of bash scripts layered on top of the GIT core with the
-aim of making interacting with GIT trees more pleasent.
-Pick the most recent version.
+UTF-8 terminal support for ELinks 0.12.GIT. Forked from
+#8220;master#8221; on 2006-01-14. Was merged back to
#8220;master#8221;
+on 2006-07-21 and is no longer developed separately.
+/dd
+dt
+witekfl
+/dt
+dd
+Changes to be reviewed and then applied to #8220;master#8221; or
+#8220;elinks-0.12#8221;.
+/dd
+dt
+HEAD
+/dt
+dd
+An alias for the default branch, currently #8220;master#8221;.
/dd
/dl
-pIn the following we will only focus on getting the most recent version of
the
-stable and unstable trees. See
-a href=http://kernel.org/pub/software/scm/cogito/docs/introduction.html;the
Cogito introduction/a
-or a href=http://kernel.org/pub/software/scm/cogito/docs/;the Cogito
manpages/a.
-for information on doing more advanced things with Cogito./p
-pYou can get the latest strongunstable/strong development version by
doing:/p
-table border=1 class=codetrtdpre% cg clone
http://elinks.cz/elinks.git
-% cd elinks/pre/td/tr/table
-pYou can also get the latest strongstable/strong development version via
GIT. Note that
-development in the stable branch is more slow and mostly involves backporting
-of bug fixes. Just do this:/p
-table border=1 class=codetrtdpre% cg clone
http://elinks.cz/elinks.git#{stable-branch} {stable-branch}
-% cd {stable-branch}/pre/td/tr/table
-pThere may also be some other branches for separate development of some
larger
-experimental features etc. The old CVS history is available in a separate
-archive
Re: [elinks-dev] lua50 or lua51 in 0.12?
Witold Filipczyk [EMAIL PROTECTED] writes: Which version of LUA 5.0 or 5.1 should ELinks-0.12 use? Currently it supports only 5.0, but 5.1 is newer. IMO now is good time to switch to 5.1. Bug 742 - port elinks to lua-5.1 http://bugzilla.elinks.cz/show_bug.cgi?id=742 I think it would be good to support both Lua 5.0 and 5.1 in ELinks 0.12.0, and drop Lua 5.0 support in ELinks 0.13.GIT if it makes the code clearer. pgpnLEvewWXOt.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] onkeypress support!
Howard Kapustein [EMAIL PROTECTED] writes: Q1. How should I submit my patches? I can provide modified source files, diffs, both or other. I think diff -up would be preferred. Also please add yourself to AUTHORS. Currently ELinks is licensed under GPLv2. There has been some talk of restoring the or any later version option, for compatibility with libraries that may switch from LGPLv2 to LGPLv3. Relicensing would require permission from all copyright holders so maybe I'd better start asking now. Will you license your code under GPLv2 only, or version 2 or later? pgpEtHikn2UVk.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] ELinks 0.12 release plans
Kalle Olavi Niemitalo [EMAIL PROTECTED] writes: The bugs blocking the ELinks 0.12.0 release are listed here: http://bugzilla.elinks.cz/buglist.cgi?target_milestone=0.12-M1target_milestone=0.12-M2bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENED I think we should release 0.12pre1 when all the bugs targeted for 0.12-M1 have been fixed. Then people would update translations and test ELinks on various operating systems while we fix the 0.12-M2 bugs. Next, we'd release 0.12rc1, wait for reports, document the operating systems on which it was tested, release 0.12.0 with minimal changes, and open 0.13.GIT. That is, if the maintainer agrees. I created an elinks-0.12 branch on 2007-04-22, and changed the version number of master to 0.13.GIT. I hoped that someone else would then add some of Witek's new features to 0.13.GIT while I'd fix 0.12-M1 bugs in 0.12.GIT. Unfortunately, there has been little activity in 0.13.GIT, apart from occasional merges from 0.12.GIT. Now, only bug 620 remains for 0.12-M1. And Witek has already fixed it in his branch, so it seems we could release 0.12pre1 next week. That version we could then also submit to the Translation Project, which likes stable URLs for packages: http://translationproject.org/html/maintainers.html After 0.12pre1, we'd fix the 0.12-M2 bugs, release 0.12rc1, etc. as quoted above. Now though, instead of opening 0.13.GIT, we'd merge the changes to the existing 0.13.GIT. Fonseca, do you accept this plan? pgp60dpEs01Fp.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
[elinks-dev] fg parameter of exec_on_terminal
The last parameter of exec_on_terminal() gets values 0, 1, and 2.
These values don't seem to be documented anywhere.
To make the code easier to understand, I suggest giving them names.
While doing that, I noticed this in in_sock():
if (is_blocked() fg) {
if (*delete.source) unlink(delete.source);
goto nasty_thing;
}
And this in exec_on_terminal():
if (fg is_blocked()) {
unlink(delete);
return;
}
But in_sock() and exec_on_master_terminal() call block_itrm() and
unblock_itrm() only if fg == 1. So, if fg == 2 and ditrm has
already been blocked, then the exec fails, even though the
program to be run was not going to use the terminal. Should
the two fg checks shown above be changed to fg == 1?
Also I am not sure about the purpose of setpgid() in exec_thread().
That code was inherited from Links. Is it perhaps intended to
protect the child process when the user hits ^C and sends SIGINT
to the process group of ELinks? If so, that should be documented.
I have not pushed this patch yet, because of the fg == 1 doubt,
and because Witek seems to be working on bug 638.
Name the exec_on_terminal() fg values.
---
commit aa00b6f8e969c0c2c929e6591790283c0796aaf2
tree 6c5d84304acb74b15f6a1733aa6b9c65ba0302d9
parent eccc8c23f0901b8560f27741a631d858c04203a4
author Kalle Olavi Niemitalo [EMAIL PROTECTED] Sat, 14 Jul 2007 12:26:45 +0300
committer Kalle Olavi Niemitalo [EMAIL PROTECTED] Sat, 14 Jul 2007 12:26:45
+0300
src/dialogs/menu.c |2 +-
src/osdep/newwin.c |2 +-
src/protocol/user.c|2 +-
src/scripting/lua/core.c |5 +++--
src/scripting/smjs/elinks_object.c |2 +-
src/session/download.c |5 +++--
src/terminal/kbd.c | 10 +-
src/terminal/terminal.c| 22 +++---
src/terminal/terminal.h| 20 +++-
src/viewer/text/textarea.c |2 +-
10 files changed, 46 insertions(+), 26 deletions(-)
diff --git a/src/dialogs/menu.c b/src/dialogs/menu.c
index 0707b98..172965c 100644
--- a/src/dialogs/menu.c
+++ b/src/dialogs/menu.c
@@ -759,7 +759,7 @@ do_pass_uri_to_command(struct terminal *term, void
*command_, void *xxx)
{
unsigned char *command = command_;
- exec_on_terminal(term, command, , 0);
+ exec_on_terminal(term, command, , TERM_EXEC_BG);
mem_free(command);
}
diff --git a/src/osdep/newwin.c b/src/osdep/newwin.c
index 25e4fe1..8c92300 100644
--- a/src/osdep/newwin.c
+++ b/src/osdep/newwin.c
@@ -90,6 +90,6 @@ open_new_window(struct terminal *term, unsigned char
*exe_name,
(unsigned char *) NULL);
if (!command) return;
- exec_on_terminal(term, command, , 2);
+ exec_on_terminal(term, command, , TERM_EXEC_NEWWIN);
mem_free(command);
}
diff --git a/src/protocol/user.c b/src/protocol/user.c
index 76b466a..f0bcc5d 100644
--- a/src/protocol/user.c
+++ b/src/protocol/user.c
@@ -300,7 +300,7 @@ user_protocol_handler(struct session *ses, struct uri *uri)
if (prog) {
unsigned char *delete = empty_string_or_(filename);
- exec_on_terminal(ses-tab-term, prog, delete, 1);
+ exec_on_terminal(ses-tab-term, prog, delete, TERM_EXEC_FG);
mem_free(prog);
} else if (filename) {
diff --git a/src/scripting/lua/core.c b/src/scripting/lua/core.c
index bd1b8df..8aec3a9 100644
--- a/src/scripting/lua/core.c
+++ b/src/scripting/lua/core.c
@@ -231,7 +231,8 @@ static int
l_execute(LS)
{
if (lua_isstring(S, 1)) {
- exec_on_terminal(lua_ses-tab-term, (unsigned char *)
lua_tostring(S, 1), , 0);
+ exec_on_terminal(lua_ses-tab-term, (unsigned char *)
lua_tostring(S, 1), ,
+TERM_EXEC_BG);
lua_pushnumber(S, 0);
return 1;
}
@@ -795,7 +796,7 @@ handle_ret_run(struct session *ses)
unsigned char *cmd = (unsigned char *) lua_tostring(L, -1);
if (cmd) {
- exec_on_terminal(ses-tab-term, cmd, , 1);
+ exec_on_terminal(ses-tab-term, cmd, , TERM_EXEC_FG);
return;
}
diff --git a/src/scripting/smjs/elinks_object.c
b/src/scripting/smjs/elinks_object.c
index e017723..55d7a29 100644
--- a/src/scripting/smjs/elinks_object.c
+++ b/src/scripting/smjs/elinks_object.c
@@ -103,7 +103,7 @@ elinks_execute(JSContext *ctx, JSObject *obj, uintN argc,
jsval *argv, jsval *rv
if (!*string)
return JS_TRUE;
- exec_on_terminal(smjs_ses-tab-term, string, , 0);
+ exec_on_terminal(smjs_ses-tab-term, string, , TERM_EXEC_BG);
undef_to_jsval(ctx, rval);
return JS_TRUE;
diff --git a/src/session/download.c b/src/session/download.c
index
[elinks-dev] Submit ELinks to the Free Translation Project?
Of the thirty PO files bundled with ELinks 0.11.3, only nine are more than half complete. To attract people to complete the translations, I propose to submit ELinks to the Free Translation Project: http://www.iro.umontreal.ca/translation/HTML/maintainers.html AFAIK, maintainers of ELinks have not been asking contributors to assign copyright on code or translation updates. So I would tell the Translation Project that ELinks is not a GNU package and we do not require copyright disclaimers. The Translation Project seems picky on version numbers of POT files. For 0.12.GIT and prereleases such as 0.12.0pre1, I think we should use a 0.12b20070624 format. For actual releases such as ELinks 0.11.3, we could use 0.11.3, but it may be better to use 0.11b20070415 as this allows us to make prereleases within a stable branch (e.g. 0.11.4pre1) and have them sorted correctly. Or perhaps we don't need such prereleases and the long numbers would just confuse. I don't know whether there would be a conflict between the people who have been maintaining the ELinks translations now and the teams that would hack the PO files from the Translation Project. Personally, I am not in much contact with the Finnish team but wouldn't mind letting them take over. Appendix. Statistics from elinks-0.11.3 after make update-po (reformatted): fr: 1569 translated. pl: 1563 translated, 3 fuzzy, 3 untranslated. da: 1529 translated, 17 fuzzy, 23 untranslated. sr: 1402 translated, 91 fuzzy, 76 untranslated. hu: 1365 translated, 96 fuzzy, 108 untranslated. cs: 1269 translated, 173 fuzzy, 127 untranslated. de: 1154 translated, 256 fuzzy, 159 untranslated. it: 999 translated, 370 fuzzy, 200 untranslated. sk: 845 translated, 351 fuzzy, 373 untranslated. fi: 762 translated, 154 fuzzy, 653 untranslated. uk: 277 translated, 490 fuzzy, 802 untranslated. bg: 232 translated, 515 fuzzy, 822 untranslated. pt: 220 translated, 522 fuzzy, 827 untranslated. be: 216 translated, 519 fuzzy, 834 untranslated. es: 201 translated, 511 fuzzy, 857 untranslated. ru: 194 translated, 497 fuzzy, 878 untranslated. pt_BR: 190 translated, 498 fuzzy, 881 untranslated. ro: 172 translated, 454 fuzzy, 943 untranslated. nl: 172 translated, 454 fuzzy, 943 untranslated. id: 172 translated, 454 fuzzy, 943 untranslated. nb: 172 translated, 453 fuzzy, 944 untranslated. hr: 172 translated, 453 fuzzy, 944 untranslated. ca: 172 translated, 453 fuzzy, 944 untranslated. sv: 171 translated, 454 fuzzy, 944 untranslated. gl: 171 translated, 454 fuzzy, 944 untranslated. et: 171 translated, 454 fuzzy, 944 untranslated. el: 171 translated, 454 fuzzy, 944 untranslated. tr: 166 translated, 450 fuzzy, 953 untranslated. lt: 166 translated, 450 fuzzy, 953 untranslated. is: 166 translated, 450 fuzzy, 953 untranslated. pgpiP6BP4zF3u.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] CGI scripts using GET don't work
Witold Filipczyk [EMAIL PROTECTED] writes: Here is the patch for 0.11.3: diff --git a/src/protocol/uri.c b/src/protocol/uri.c index df22646..e9c3b39 100644 Thank you, applied. pgpA77cwgPZGK.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] pwmd patch
Ben Kibbey [EMAIL PROTECTED] writes:
+++ b/src/formhist/formhist.c
@@ -355,7 +374,21 @@ get_form_history_value(unsigned char *url, unsigned char
*name)
+ * FIXME If theres a pwmd error a message box pops up.
+ * src/viewer/text/form.c seems to call this repeatedly until
+ * it's satisfied with a value.
+ */
I think I fixed that in commit 0df5b7fdf5f819f03f33b5eb972c4880b35904d1.
+++ b/src/formhist/pwmd.c
+static void
+show_error(int ret, int error)
+{
+unsigned char *buf;
+struct terminal *term = terminals.prev;
Do not assume that terminals.prev is visible to the user, nor
that it is connected to the stdin/stdout of the elinks process.
Some of your other functions have similar assumptions.
Besides, your current libpwmd seems to block while waiting for
the user to type the password. That would prevent ELinks from
serving slave terminals.
One solution might be to make ELinks fork a subprocess for the
libpwmd calls. The stdin and stdout of this subprocess would be
pipes that the master ELinks process would forward to the slave
ELinks process serving the appropriate terminal. But that might
require more extensive changes to ELinks than you have here;
all form-history operations might have to be made asynchronous
with completion callbacks.
pgpIxEx4A1zpJ.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
[elinks-dev] ELinks 0.10.0 and later are GPLv2 only
http://directory.fsf.org/Elinks.html claims Licensed under The GNU General Public License, Version 2 or later. This seems to have been true originally. In elinks-0.9.3/src/dialogs/info.c: 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; either version 2 of the License, or (at your option) any later version.), However, in elinks-0.10.0/src/dialogs/info.c: 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.), According to ChangeLog, this was changed on 2004-01-11, thus after %%license-verified-on: 2003-01-24. There is also a further note in elinks-0.11.3/COPYING: Note that the only valid version of the GPL as far as ELinks is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly stated otherwise. That is at least the policy for all pasky's contributions and the default - if you want different policy for your patches, the best way to state it is by a patch for your AUTHORS entry. If pasky likes GPLv3, he might relicence his contributions for GPLv3 as well. The default policy should probably be that you trust pasky, Jonas, or the current maintainer of the day to do the right thing (much like it is in the Linux kernel). But this needs to be yet worked out and agreed upon. Please update the licensing information in the Free Software Directory. pgpxsdgv5ifeh.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Solaris build fixes
Witold Filipczyk [EMAIL PROTECTED] writes: On Tue, Jun 05, 2007 at 12:29:46AM +0300, Kalle Olavi Niemitalo wrote: clearerr() needs a FILE *, not a file descriptor. And gzip_open() calls fdopen() itself, so ELinks never sees the FILE *. I should have written that gz_open() in zlib calls fdopen() itself. gzip_open() in ELinks calls gzdopen(), which calls gz_open(). (b) Revert all the decompression changes from elinks-0.12, returning to what was in ELinks 0.11.3. The old code doesn't work well everywhere, so gzclearerr was added and then the decompression code was simplified (?). Where does it not work? Is there a test case? (e) Write ELinks's gzclearerr using internals of the zlib of Solaris 10. Check for gzclearerr in ./configure. If it fails use own function and warn the user. I fear that would cause crashes later when Sun upgrades zlib and changes struct gz_stream. Probably the upgrade would be to a version later than zlib 1.2.0.2 though, so recompiling ELinks would then fix the crashes. (I did implement a similar hack in do_fsp(), but that reads only an integer and not a pointer, so it won't crash even if the result is wrong.) Then there may also be other operating systems with different old versions of zlib. Does zlib 1.1.4 as shipped in Solaris 10 include any Sun patches that change the definition of struct gz_stream in gzio.c? How hard is it for Solaris 10 users to install a newer version of zlib, e.g. in /usr/local? (f) Include recent zlib sources with ELinks and link it statically if the installed version is not suitable. http://www.fsf.org/licensing/licenses/index_html says the zlib license is compatible with GNU GPL (as it should if ELinks is already linking with it). But the required changes in the build system might already be more complex than (d) rewriting the decompression code in ELinks. I wonder what happens when part of the gzip header is in the first chunk and the rest in the next one. I did not see any bugs in 0.12.GIT when I ran the test CGI with a block size of one byte (and a shorter sleep). pgpcsdLFUv6Bj.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
[elinks-dev] ELinks 0.11.3 and other changes to FSF's Free Software Directory
ELinks 0.11.3 was released on 2007-04-15. Always use elinks.cz, not elinks.or.cz. http://ftp.pld-linux.org/pool/e/elinks/ has only ELinks 0.4pre18, which is awfully old. PLD has later versions available, e.g. ftp://ftp.pld-linux.org/dists/2.0/PLD/i386/PLD/RPMS/elinks-0.11.2-2.i386.rpm but unfortunately there doesn't seem to be a list of available ELinks RPMs for different platforms. I have collected some pointers at http://elinks.cz/download.html. According to http://bugzilla.elinks.cz/show_bug.cgi?id=742, ELinks does not work with Lua 5.1. So mention just 5.0, not 5.x. The elinks-dev mailing list is gated to news:gmane.comp.web.links as seen at http://list.gmane.org/elinks-dev@linuxfromscratch.org. The name is misleading but GMANE is unable to rename newsgroups. The elinks-bugs mailing list has been down for at least 7 months. --- Elinks.txt~ 2007-06-04 20:05:22.0 +0300 +++ Elinks.txt 2007-06-04 20:20:49.0 +0300 @@ -43,7 +43,7 @@ %%touched: 2003-05-13 -%%updated: 2006-11-19 +%%updated: 2007-06-04 %%keywords: elinks, browser, text mode, Internet, links @@ -65,13 +65,13 @@ Witold Filipczyk [EMAIL PROTECTED] %%contributors: See the AUTHORS file in the distribution or -http://elinks.or.cz/authors.html for a complete list +http://elinks.cz/authors.html for a complete list %%sponsors: %%changelog: http://elinks.cz/release.html -%%source-tarball: http://elinks.cz/download/elinks-0.11.2.tar.bz2 +%%source-tarball: http://elinks.cz/download/elinks-0.11.3.tar.bz2 %%source-info: http://elinks.cz/download.html @@ -79,7 +79,7 @@ %%debian: http://packages.debian.org/unstable/web/elinks.html -%%rpm: http://ftp.pld-linux.org/pool/e/elinks/ +%%rpm: %%repository: http://elinks.cz/elinks.git @@ -87,7 +87,7 @@ %%source-language: C -%%supported-languages: lua 5.x, guile, Perl, Python, Ruby +%%supported-languages: lua 5.0, guile, Perl, Python, Ruby %%use-requirements: @@ -106,7 +106,7 @@ /pre %%source-prerequisites: -%%version: 0.11.2 stable released 2006-11-19 +%%version: 0.11.3 stable released 2007-04-15 %%announce-list: [EMAIL PROTECTED] @@ -122,11 +122,11 @@ %%dev-list: elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev/ -%%dev-news: +%%dev-news: gmane.comp.web.links %%dev-irc-channel: irc.freenode.net: #ELinks -%%bug-list: [EMAIL PROTECTED] +%%bug-list: %%bug-news: pgpgwJOs5eAQn.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Solaris build fixes
John Hawkinson [EMAIL PROTECTED] writes:
--- src/encoding/gzip.c 2007/05/31 22:40:05 1.1
+++ src/encoding/gzip.c 2007/06/02 22:22:20
@@ -33,7 +33,9 @@
static int
gzip_read(struct stream_encoded *stream, unsigned char *data, int len)
{
+#ifdef HAVE_GZCLEARERR
gzclearerr((gzFile *) stream-data);
+#endif
return gzread((gzFile *) stream-data, data, len);
}
I see. The gzclearerr function was added in zlib 1.2.0.2,
released on 2003-07-13. elinks-0.12/doc/installation.txt and
elinks-0.12/INSTALL do not currently list any version requirement
for zlib.
Have you tested the resulting binary, especially with slow sites
and Transfer-Encoding: chunked? The call was added to ELinks in
commit d2b8e06f418f99c64a1a0f7ad4b3b906ced8617f:
gzip_read: always call gzclearerr
This is necessary when using a POSIX-compliant stdio implementation, which
will set the FILE error flag when input from the pipe is exhausted, causing
all subsequent reads to fail.
Can we assume that on Solaris 10 which does not have gzclearerr,
stdio does not actually set the flag? Otherwise, can we work
around the problem by disabling Accept-Encoding: gzip when
gzclearerr is not available?
I think the encoding layer in ELinks should be rewritten to avoid
stdio entirely, but I was hoping ELinks 0.12.0 could be released
first. If 0.12.GIT with this patch truncates documents but
0.11.3 does too, then the bug is not a regression and ELinks
could be released with it. So please also test 0.11.3 (or the
upcoming 0.11.4) if possible.
pgp2A8u2tlaSi.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Memory allocation
Witold Filipczyk [EMAIL PROTECTED] writes: When there is no more memory say sorry and exit. That would be okay for noninteractive uses such as elinks -dump. However I would hate to lose state because of running out of memory. AFAIK, ui.sessions.snapshot does not save session cookies, form data, and session-specific history. ELinks will be smaller, therefore faster. I doubt the speed would change noticeably. Better algorithms would be more important. Perhaps also cache locality for allocations. Which reminds me of bug 297. Can we use libapr for memory pools? pgp5VeKzu2DDW.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] increased risk of ECMAScript crashes in ELinks 0.11.3.GIT
Jonas Fonseca [EMAIL PROTECTED] writes: Ok, thanks for the warning, however, I thought that I expressed that I do not really consider ECMAScript related crashes as something to worry about for the current stable version. 2007-05-27: paakku fonseca: Should bug 755 be fixed in 0.11.3.GIT or 0.11.4.GIT? fonseca paakku: I don't really care about ECMAScript bugs. Crashes caused by dangling pointers may be exploitable (unlike crashes caused by null pointers). I think they should be fixed regardless of whether they occur in ECMAScript support or elsewhere in ELinks. And I especially don't want to become responsible of making a release crash more than the previous one. I will try to find time to release 0.11.4 in the start of June. I don't think I'll be able to fix things properly before that, so I have now reverted the two commits from elinks-0.11. pgpdww1so9UiP.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Why utf8_linux_frame_seqs?
Witold Filipczyk [EMAIL PROTECTED] writes: You can remove utf8_linux_frame_seqs. Thank you. I have removed it. pgpFjvtg0lSVU.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
[elinks-dev] Why utf8_linux_frame_seqs?
In ELinks 0.12.GIT (f8f99cc04ea0ff1f64c0452f5232e1b2567493c2): - If UTF-8 I/O is disabled, then src/terminal/screen.c outputs normal characters in the terminal charset, and frame characters usually in a separate frame charset. To switch between the charsets, it outputs strings from screen_driver.frame_seqs[]. - If UTF-8 I/O is enabled and CONFIG_UTF8 is not defined, then src/terminal/screen.c outputs all characters in UTF-8. It converts frame characters first to some unibyte codepage that supports them (typically CP437), and then to UCS-4 and UTF-8. - If UTF-8 I/O is enabled and CONFIG_UTF8 is defined, then src/terminal/screen.c outputs normal characters in UTF-8, and frame characters usually in a separate frame charset. To switch between the charsets, it outputs strings from screen_driver.frame_seqs[], which may be utf8_linux_frame_seqs[] defined for this purpose. I would like to change src/terminal/screen.c so that UTF-8 I/O always outputs frame characters in UTF-8, regardless of whether CONFIG_UTF8 is defined. I have already implemented this but the change is currently entangled with fixes for bug 914 and separating it will take some time. However, perhaps the charset switching has some purpose I don't understand. It was added in Witekfl's UTF-8 patch v5, commit 44a1aa9c87d72bd5020e68ef6e62f5a363a54b54 on 2006-02-18. Can anyone explain? pgpfV7QpzwlXD.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Edit mode not exiting cleanly on Back
Yan Seiner [EMAIL PROTECTED] writes: What happens is that the screen is not resetting the reverse mode. If I am in an edit field and in edit mode and hit back, the reverse mode is carried over to the previous screen. If I enter that screen via a link, it displays correctly. If am not in edit mode when I hit back, it displays correctly. If I understand correctly, you mean: - Bind F2 to history-move-back. - Set document.browse.forms.insert_mode = 1. - Go to a page that contains a text field. - Select this text field. - Go to another page that contains a text field. - Select this text field. - Press Enter (ACT_EDIT_ENTER) to enter insert mode. - Press F2 (ACT_MAIN_HISTORY_MOVE_BACK) to return to the first page. - The text field in the first page is highlighted as if insert mode were enabled. - Press o. - ELinks does not insert the o to the text field but rather opens the option manager. So insert mode was not actually enabled. Can anyone shed any light on this? Where do I look to fix this? This occurs because draw_current_link redraws the text field before do_action sets ses-insert_mode = INSERT_MODE_OFF. Text fields are drawn in two steps: draw_current_link draws the attributes, and draw_form_entry draws the characters. In ELinks 0.12.GIT (d1fa336f7f390d9b51456498fac5dda8f54c18a4): (gdb) backtrace #0 draw_current_link (ses=0x8459780, doc_view=0x8450a58) at /home/Kalle/src/elinks-0.12/src/viewer/text/link.c:231 #1 0x08115f54 in draw_view_status (ses=0x8459780, doc_view=0x8450a58, active=1) at /home/Kalle/src/elinks-0.12/src/viewer/text/draw.c:175 #2 0x081165da in draw_doc (ses=0x8459780, doc_view=0x8450a58, active=1) at /home/Kalle/src/elinks-0.12/src/viewer/text/draw.c:297 #3 0x08116df3 in refresh_view (ses=0x8459780, doc_view=0x8450a58, frames=1) at /home/Kalle/src/elinks-0.12/src/viewer/text/draw.c:386 #4 0x08116dba in draw_formatted (ses=0x8459780, rerender=2) at /home/Kalle/src/elinks-0.12/src/viewer/text/draw.c:380 #5 0x080fa410 in display_timer (ses=0x8459780) at /home/Kalle/src/elinks-0.12/src/session/session.c:452 #6 0x080fe430 in loading_callback (download=0x84597b8, ses=0x8459780) at /home/Kalle/src/elinks-0.12/src/session/task.c:537 #7 0x080d044b in load_uri (uri=0x84d8480, referrer=0x0, download=0x84597b8, pri=PRI_MAIN, cache_mode=CACHE_MODE_ALWAYS, start=-1) at /home/Kalle/src/elinks-0.12/src/network/connection.c:916 #8 0x080fd069 in ses_load (ses=0x8459780, uri=0x84d8480, target_frame=0x0, target_location=0x85e8168, cache_mode=CACHE_MODE_ALWAYS, task_type=TASK_HISTORY) at /home/Kalle/src/elinks-0.12/src/session/task.c:83 #9 0x080fd532 in ses_goto (ses=0x8459780, uri=0x84d8480, target_frame=0x0, target_location=0x85e8168, cache_mode=CACHE_MODE_ALWAYS, task_type=TASK_HISTORY, redir=0) at /home/Kalle/src/elinks-0.12/src/session/task.c:221 #10 0x080f8e7d in go_history (ses=0x8459780, loc=0x85e8168) at /home/Kalle/src/elinks-0.12/src/session/history.c:156 #11 0x080f8f9a in go_history_by_n (ses=0x8459780, n=1) at /home/Kalle/src/elinks-0.12/src/session/history.c:175 #12 0x081128d5 in do_action (ses=0x8459780, action_id=ACT_MAIN_HISTORY_MOVE_BACK, verbose=0) at /home/Kalle/src/elinks-0.12/src/viewer/action.c:268 #13 0x0812b8e4 in send_kbd_event (ses=0x8459780, doc_view=0x8450a58, ev=0xbfd88574) at /home/Kalle/src/elinks-0.12/src/viewer/text/view.c:1159 #14 0x0812bb79 in send_event (ses=0x8459780, ev=0xbfd88574) at /home/Kalle/src/elinks-0.12/src/viewer/text/view.c:1224 #15 0x080fca3c in tabwin_func (tab=0x84509c0, ev=0xbfd88574) at /home/Kalle/src/elinks-0.12/src/session/session.c:1280 #16 0x08100cb2 in term_send_event (term=0x8451b68, ev=0xbfd88574) at /home/Kalle/src/elinks-0.12/src/terminal/event.c:131 #17 0x081015da in handle_interlink_event (term=0x8451b68, ilev=0x8451d18) at /home/Kalle/src/elinks-0.12/src/terminal/event.c:390 #18 0x08101981 in in_term (term=0x8451b68) at /home/Kalle/src/elinks-0.12/src/terminal/event.c:494 #19 0x080ca0c3 in select_loop (init=0x80c8c8f init) at /home/Kalle/src/elinks-0.12/src/main/select.c:289 #20 0x080c9407 in main (argc=1, argv=0xbfd88714) at /home/Kalle/src/elinks-0.12/src/main/main.c:360 (gdb) pgpX07lbcF7gW.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Edit mode not exiting cleanly on Back
Yan Seiner [EMAIL PROTECTED] writes: Thanks. Is this going to be fixed in CVS or should I just try and hack around it? I don't know if any ELinks developer is interested in fixing this bug. It has rather little impact and the fix is not obvious. If you post a patch, it may be accepted to Git (not CVS since 0.11.0). pgpVTamgQ1OsL.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
[elinks-dev] set_line() ignores wrap_nbsp when document == NULL
In ELinks 0.12.GIT (097195bef43f162627670245f07c1dac31566bf0), set_hline() respects html_context-options-wrap_nbsp when part-document != NULL, but not when part-document == NULL. Is it a bug? This code was added to set_hline() on 2003-11-27, imported as Git commit f490694e643d3b49aeef4de9ea99d19199cb458f. If I understand correctly, part-document == NULL when ELinks is deciding widths of table columns. So this could cause ELinks to make a column wider than necessary. pgpqtVz6ny6eR.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] GnuTLS improvements
Simon Josefsson [EMAIL PROTECTED] writes: Because trying to do the same handshake another time will not make it work better. If I understand the OpenSSL code part correctly, it disables TLS (i.e., then only SSL 3.0 is supported). The GnuTLS code does not disable TLS. It used to disable TLS. This was inadvertently broken on 2004-08-03. http://pasky.or.cz/gitweb.cgi?p=elinks-history.git;a=commit;h=1b9c49c30bde90824fb4a7ff1dd3b6c2d55f5b48 http://cvsweb.elinks.cz/cvsweb.cgi/elinks/src/ssl/Attic/connect.c#rev1.77 The algorithm settings looks rather similar to those in ssl.c. Not entirely identical, though... but the differences seem to be caused merely by lack of coordination, rather than by any real intention. ssl_set_no_tls (2002-07-05): http://pasky.or.cz/gitweb.cgi?p=elinks-history.git;a=commit;h=08ca765f7536f921a560433e3e2ddad59c01b71d http://cvsweb.elinks.cz/cvsweb.cgi/elinks/src/ssl/Attic/connect.c#rev1.11 init_ssl_connection (2003-09-29): http://pasky.or.cz/gitweb.cgi?p=elinks-history.git;a=commit;h=59230528ae307744fa7e212cfa2f4046725d9c3f http://cvsweb.elinks.cz/cvsweb.cgi/elinks/src/ssl/Attic/ssl.c#rev1.26 http://bugzilla.elinks.cz/show_bug.cgi?id=241 What you might want to do is to disable TLS and only use SSL 3.0 with GnuTLS too. However, unless there are documented examples of web servers that need this workaround, I'm not sure it should be added. Bug 712 says https://www-s.uiuc.edu/bluestem/notes/overview.html doesn't work with GnuTLS. Which seems reproducible here. If I disable GNUTLS_TLS1 in ssl_set_no_tls(), then it works. However, an ELinks built with OpenSSL can access this site just fine even if I remove SSL_OP_NO_TLSv1 from ssl_set_no_tls(). This site has Server: Netscape-Enterprise/3.6 SP3, which ELinks treats specially, as mentioned in bug 234. However, running with -eval set protocol.http.bugs.allow_blacklist = 0 neither averts nor causes the error. If you have some test program that can send the same HTTPS request as ELinks and then receive the data, I think that would help figure out whether the bug is in the server or in ELinks (or even in GnuTLS). Here are my request headers for reference. Sending these with openssl s_client showed that SSLv3 was used. GET /bluestem/notes/overview.html HTTP/1.1 Host: www-s.uiuc.edu User-Agent: ELinks/0.12.GIT (textmode; Linux 2.6.12-1-k7 i686; 127x49-2) Accept: */* Accept-Encoding: bzip2, gzip Accept-Language: fi Connection: Keep-Alive diff --git a/src/network/ssl/socket.c b/src/network/ssl/socket.c index 96caf8b..322a718 100644 diff --git a/src/network/ssl/ssl.c b/src/network/ssl/ssl.c index 3c38765..c14ab67 100644 I am going to apply this patch to ELinks 0.12.GIT but reinstate the gnutls_protocol_set_priority() call in ssl_set_no_tls() because it appears to fix or at least hide bug 712. If the real bug is later found elsewhere, the call can then be removed again. pgpI6MWlPuwYq.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] [PATCH] error.c: fix gcc warning (vasprintf)
Alexey Tourbin [EMAIL PROTECTED] writes: + rv = vasprintf((char **) buf, fmt, params); + if (rv 0) + buf = fmt; va_end(params); elinks_internal(assertion failed: %s, buf); if (buf) free(buf); It can then call free(fmt) and probably get a SIGSEGV. Would you be happy with the following? diff --git a/src/util/error.c b/src/util/error.c index 34e4c88..4e6afe5 100644 --- a/src/util/error.c +++ b/src/util/error.c @@ -147,17 +147,17 @@ elinks_assertm(int x, unsigned char *fmt, ...) unsigned char *buf = NULL; va_list params; if (assert_failed) return; if (!(assert_failed = !x)) return; va_start(params, fmt); - vasprintf((char **) buf, fmt, params); + (void) vasprintf((char **) buf, fmt, params); va_end(params); - elinks_internal(assertion failed: %s, buf); + elinks_internal(assertion failed: %s, buf ? buf : fmt); if (buf) free(buf); } #ifdef CONFIG_DEBUG void force_dump(void) pgpwrMcXELdv9.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] GnuTLS improvements
Simon Josefsson [EMAIL PROTECTED] writes: The patch to socket.? removes some never needed code with GnuTLS, and removes the need for the no_tls variable and the ssl_set_no_tls() function altogether by replacing each occurrence of setting the no_tls variable, and calling the function if that variable is set, with the actions done by that function (for the OpenSSL case, no such code is needed for GnuTLS). I have not tested this with OpenSSL, so please double check it. It seems wrong to me. Previously, ssl_connect() could set socket-no_tls = 1, and then call connect_socket(), which would indirectly call done_ssl_connection(), which sets socket-ssl = NULL; the next call to ssl_connect() would then construct a new ssl_t, make socket-ssl point to it, and see that socket-no_tls is 1. That is, socket-no_tls used to outlive socket-ssl. With your change, ssl_connect() now alters *socket-ssl directly, and this effect is lost in done_ssl_connection(). The no_tls flag was already present (as no_tsl) in connect.c when it was first imported to the ELinks CVS repository on 2001-10-27. I don't know why it was originally added, but I'm guessing it works around buggy servers that happily negotiate TLS but then fail to implement it properly. Could you explain why you think ELinks does not need such a workaround with GnuTLS? Of course, it is possible that all the buggy servers have already been fixed and we can remove the workaround for OpenSSL too, but even in that case it should be done as a separate patch, so it's easier to revert if necessary. If your patches are applied to ELinks, I would like to add your name and email address (as shown above) to the AUTHORS file and to the author field of the commits in the ELinks Git repository. From there, they would then propagate to an unknown number of mirrors and other systems (e.g. CIA.vc) worldwide. It would be difficult to remove this information afterwards. Do you consent to this, or would you rather like to e.g. obscure the email address? pgpvbVV6QTtGA.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Elinks crash
Yan Seiner [EMAIL PROTECTED] writes: OK, I'm playing on dangerous ground... Javascript. So elinks died... :-( Unfortunately I can't get a core as I am running on a read-only embedded system I don't see anything script-related in your backtrace. I however see parse_sgml, which is part of the SGML/DOM engine you have apparently enabled with configure --enable-html-highlight. So far, ELinks uses the SGML/DOM engine for HTML documents only when it displays the HTML source, so you would not lose any ECMAScript DOM features by disabling it. Nevertheless, the SGML/DOM engine is supposed to replace the old HTML parser in some future version of ELinks, so the crash should eventually be fixed. If you can provide an HTML file with which the crash can be reproduced, that will be useful. ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] unprotected error in call to Lua API
Alexey Tourbin [EMAIL PROTECTED] writes: Ported to lua-5.1. This seems to be ELinks bug 742. http://bugzilla.elinks.cz/show_bug.cgi?id=742 ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] witekfl branch status
Witold Filipczyk [EMAIL PROTECTED] writes: On Sun, Mar 18, 2007 at 09:12:23PM +0200, Kalle Olavi Niemitalo wrote: bug620 This resets forms when I resize the window. Not acceptable. It's difficult because it should be done only once when the document is fully loaded after reloading, but the user might type something into forms earlier. How to do that? Why must the forms be reset only after the document is fully loaded? I think it would be simplest to discard all form-related information immediately in reload(), before even requesting the file from the server, and let the renderer then incrementally rebuild the data, as if loading the document for the first time. I am however not familiar with this code, and it seems I'll need a diagram to properly understand all of the pointers between its different structures. pgpZzVKsci9YD.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] do_smb if auth-password contains '@' or '/'?
Kalle Olavi Niemitalo [EMAIL PROTECTED] writes: - Is it possible to have @ or '/' in auth-password, or would they have already been converted to %40 and %2F before do_smb runs? auth-password contains the string as typed by the user in the auth dialog; it is not converted. - If there are multiple @ signs, can libsmbclient parse the URL correctly anyway? No, libsmbclient will try to connect to the wrong server. - Should encode_uri_string be used here instead of add_to_string? Perhaps, but do_smb also calls decode_uri after this. That call should probably be entirely removed. pgpsxq4ZvtSyc.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] witekfl branch status
Witold Filipczyk [EMAIL PROTECTED] writes: ?2007-03-09 c09cc0398fb1c10c99076524782eee6c1e45fcef fsp: download resuming ?2007-03-09 967a15b7f4427dc94ddd9fe1092f6a20104caa2a smb: download resuming When one aborts dowload, may resume it later. It works for http and ftp, why not do it for fsp and smb? The question marks just meant I haven't yet examined the patches in detail. I am sorry I did not mention this. If the implementation is correct then surely these changes should go in. pgpgTBJHZrcFc.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
[elinks-dev] do_smb if auth-password contains '@' or '/'?
In do_smb, we have: add_to_string(string, smb://); add_to_string(string, auth-user); add_char_to_string(string, ':'); add_to_string(string, auth-password); add_char_to_string(string, '@'); add_to_string(string, uri_string); url = string.source; So if there is already '@' or '/' as part of auth-password, then the result seems to become ambiguous. - Is it possible to have @ or '/' in auth-password, or would they have already been converted to %40 and %2F before do_smb runs? - If there are multiple @ signs, can libsmbclient parse the URL correctly anyway? - Should encode_uri_string be used here instead of add_to_string? pgpH5u5tTLGu7.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] witekfl branch status
Witold Filipczyk [EMAIL PROTECTED] writes:
On Sun, Feb 25, 2007 at 10:52:47AM +0200, Kalle Olavi Niemitalo wrote:
acckey This seems to fix a bug; please advise how to reproduce the bug.
html
body
a href=/ accesskey=aStart/a
/body
/html
And ALT-A doesn't work.
I saved that HTML in a file and opened it with ELinks 0.12.GIT
(026e56d539099477043e499b1a7227c5a67e200f) running with the
English language. I have bound move-cursor-{down,left,right,up}
to {j,h,l,k}. My document.browse.accesskey.priority setting is 1.
I moved the cursor down from the link and pressed Alt+a. The
cursor jumped back to the first character S of the link. I
pressed Alt+a again; this did nothing. I moved the cursor three
steps to the right, to the r, and pressed Alt+a once more; this
did nothing either. I again moved the cursor down and pressed
Alt+A (note capital A). This did nothing.
I then tested c2d1952a082e2ed51dbfb6895f29c0869a89a8a3 from the
witekfl branch in the same way. The only difference I could see
was that in this version, when the cursor was already on some
character of the link, pressing Alt+a moved it to the beginning
of the link, rather than left it in place as in master. Is this
the bug you were fixing?
pgp3UWGSEuOGq.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] witekfl branch status
Witold Filipczyk [EMAIL PROTECTED] writes:
On Sun, Feb 25, 2007 at 10:52:47AM +0200, Kalle Olavi Niemitalo wrote:
spaces2 Decode %20 in local filenames and enclose them with ''.
This seems suspicious. What if there is '' or '\' in the
filename? There is add_shell_quoted_to_string for such
purposes.
Fixed. Thanks.
spaces2 handles mailcap entries like this:
application/x-tar; /bin/tar tvf -; print=/bin/tar tvf - | print text/plain:-;
copiousoutput
Unfortunately, it seems this patch is not safe to apply. The
problem is that Debian's update-mime program automatically
changes %s to '%s' in mailcap entries. See Debian bugs 90483 and
221717. When ELinks' add_shell_quoted_to_string adds another
pair of single-quotes around the file name, the quotes cancel
out, and metacharacters in the file name can then cause the shell
to run arbitrary programs.
In RFC 1524, there is a sentence about mailcap %{parameter}
expansions: The entire parameter should appear as a single
command line argument, regardless of embedded spaces. This
might be interpreted to mean that Debian does wrong. Still,
opening a security hole here would be a disservice to ELinks
users, even if it's really Debian's fault. The current code
passes the URL-encoded filename, which prevents spaces from
working, but also restricts the set of metacharacters available
and so prevents some (perhaps all) attacks.
There are a few ways to make the spaces work:
- Automatically detect whether and how the string has been
quoted, and adapt. This detection cannot be based solely on
whether the system is Debian, because the user's ~/.mailcap
may contain entries that are quoted differently. Also, if
the % is nested deeply inside backquotes and such, it may
not be obvious what should happen. In such cases, it would
be best to give an error message.
- Copy even local files to temporary files and ensure that the
name of the temporary file contains only safe characters and so
does not need to be quoted. If the temporary file is created
in $TMPDIR and $TMPDIR already contains unsafe characters, then
ELinks should refuse to run the MIME handler.
- As above but make hard or symbolic links instead of full copies.
- Disable mailcap support so that the user must manually specify
all MIME handlers in ELinks, and tell the user not to put
quotes around the % placeholder.
pgpdsssogJsRO.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
[elinks-dev] dangling pointer crash in write_to_festival (was: witekfl branch status)
Witold Filipczyk [EMAIL PROTECTED] writes: This feature does not collide with screen readers. I just want to listen to ELinks sometimes. I tried applying the speech commits to master, but it crashes if, during the speech, I close the tab and thereby cause the struct document_view to be freed: (gdb) backtrace #0 0x08115569 in write_to_festival (fest=0x81938b8) at /home/Kalle/src/elinks/src/viewer/text/festival.c:67 #1 0x08115519 in read_from_festival (fest=0x81938b8) at /home/Kalle/src/elinks/src/viewer/text/festival.c:45 #2 0x080ca26b in select_loop (init=0x80c8e23 init) at /home/Kalle/src/elinks/src/main/select.c:289 #3 0x080c95af in main (argc=1, argv=0xbffc2444) at /home/Kalle/src/elinks/src/main/main.c:365 (gdb) frame #0 0x08115569 in write_to_festival (fest=0x81938b8) at /home/Kalle/src/elinks/src/viewer/text/festival.c:67 67 if (fest-line = doc-height) (gdb) print doc $3 = (struct document *) 0x8 (gdb) list 62 int len; 63 struct document_view *doc_view = fest-doc_view; 64 struct document *doc = doc_view-document; 65 struct screen_char *data; 66 67 if (fest-line = doc-height) 68 fest-running = 0; 69 if (!fest-running) 70 return; 71 This was with the following commits applied on top of f2fc4020934621afb9584a468bd87180059ee8c8 (in this order): 4e93cbf496c82926f42c0eaf270920f126ace3f8 9064e6323b493b5614a9bd02c25729ce2f1650bf f260691ac4f58e7ce0e282d7b48bddbae8f00828 c187df9a0adcf0f9821d9b14b1dfcf43139d9bb3 e965d07055f5dd3e046469232e4b3986fb60cbaf 60fc3bd04fe3f85c66d1dadbc8ba4f56f576f611 91be2ea6b89a7514b75fa31dcba6d9a5ef6c978c 4d7c491a22c0b9a191df363504f52f8da1c639e1 0da23da6b23d25ceb78f0229132d8efb9f3d3781 I think, before the speech code is pushed to master, one should either - fix the bug. A new document-view-delete event might be a clean way to do this. or - enter the bug to bugzilla, mark the speech feature as experimental, and make it not be compiled in by default. (If you want a GIT (witekfl) version in bugzilla, I can add it.) pgp8eD8CEK37j.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] [PATCH] error.c: fix gcc warning (vasprintf)
Alexey Tourbin [EMAIL PROTECTED] writes:
va_start(params, fmt);
- vasprintf((char **) buf, fmt, params);
+ rv = vasprintf((char **) buf, fmt, params);
+ if (rv 0) {
+ perror(vasprintf);
+ return;
+ }
va_end(params);
elinks_internal(assertion failed: %s, buf);
This is wrong. va_end and elinks_internal must be called even if
vasprintf fails.
Possibilities to be handled:
(a) vasprintf returns an error and doesn't alter buf. Because
buf is initialized as NULL, this is the same as (b).
(b) vasprintf returns an error and sets buf = NULL. This NULL
should not be passed to elinks_internal because it will go
to snprintf from there and perhaps cause a crash. The NULL
could be replaced with an empty string. Displaying the
error from vasprintf may be useful but may also distract
users into reporting that error instead of the file name and
line number.
(c) vasprintf returns an error but sets buf != NULL. In this
case the string probably contains something sensible so it
should be used.
(d) vasprintf returns success but sets buf = NULL. That should
not be possible.
(e) vasprintf returns success and sets buf != NULL. This is the
usual case.
pgpkC0sNPSKBx.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] witekfl branch status
Witold Filipczyk [EMAIL PROTECTED] writes: Do you think that maintaining 3 versions of ELinks is reasonable? With this few people hacking on ELinks, I think it would be better to maintain just one stable and one development branch. Thus, the ELinks 0.10 branch should be dropped now, and the ELinks 0.11 branch should be dropped when 0.12.0 is released. (There should first be some release candidates, though.) Fonseca, you're the maintainer; do you authorize this? When a security vulnerability is found, I think it is good to test for it in many released versions, even ones that are no longer maintained and won't be fixed. pgpXQCNTDdO7V.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] witekfl branch status
acckey This seems to fix a bug; please advise how to reproduce the bug. bug844 Needs review and testing. bug916 Needs review and testing. bug927 Will merge. bug935 If you test this with UTF-8 then I'll merge it. epoll I don't think this should be merged. If ELinks has to keep supporting select() too, I think the maintenance burden outweighs any advantages epoll may have. It may be faster; but I don't believe the speedup is noticeable in practice. It is not limited by FD_SETSIZE; but threads[] still has that limit. fsp Needs review and testing. gpm Please add some documentation into gpm-wheel.patch. Does the patch fix a bug in GPM? Can it hurt compatibility with programs that use libgpm? merged These have already been merged to master. nonblk This makes local CGI pipes use nonblocking I/O. Not using nonblocking I/O is a bug, and local CGI was added in ELinks 0.9.0. Thus, the stable releases ELinks 0.10.6 and 0.11.2 may also have this bug. Please add the bug to bugzilla.elinks.or.cz so that backports can be tracked. spaces1 ftp didn't handle filenames with spaces. Does it work in 0.10.6 and 0.11.2? If not, please add this to bugzilla.elinks.or.cz. spaces2 Decode %20 in local filenames and enclose them with ''. This seems suspicious. What if there is '' or '\' in the filename? There is add_shell_quoted_to_string for such purposes. speech Needs a use case and review. Could then be merged before 0.12pre1. Is this intended to help blind people? I believe they usually have screen reader programs; why is this better? The code may also cause compilation errors on non-POSIX systems but I think we can sort those out based on test reports if there is a 0.12pre release after the merge. stpcpy Will merge. bug935 2007-02-23 f571cf509d472d47f5c77a46709a6e64da8ee3f6 bugfix 935: not tested with UTF-8, but you know at least where the bug is. merged 2007-02-23 1bb2c30f8aba0c27292448980d33ef16f51fc96f Used the builtin macro RM in place of defined UNINSTALL. bug916 2007-02-21 4a7b9415e11e2311eec4ffdc277b7023e9a94ef9 MIME: When there is no % in the handler string (no %s in the mailcap entry) spaces2 2007-02-21 469481b2725cd08a51a81ac344fd90749fea109c Decode %20 in local filenames and enclose them with ''. bug927 2007-02-20 21fd1fd10ff3f53ab670a59610d6530921000e83 Fix the memleak. Part II of the 927 bugfix. bug927 2007-02-20 088db2c3de7b611f669e92bf9974aaac60467c9e The fix for the bug 927. merged 2007-02-18 2a8bff982b2c07d7bc0c73b61f62398e48ba804c Do not show always evaluate as true warnings. merged 2007-02-18 dd34591c7472d0205ca16f9d37e132265bb46376 Revert Added macro foreach_module_builtin. Killed some warnings of gcc-4.2. merged 2007-02-18 f8c0fe013b86698e6087cc256f0e8fb373a3d5db Revert Killed warnings: uri_cache always evaluate as true merged 2007-02-17 dc1b84bafdd3337b80df92fcba7ff3b6d5356658 Do not add LUA_CFLAGS to the CPPFLAGS. merged 2007-02-17 c96ec209c15a8fcfa3027ff9087b27b2a09a3d39 Old CPPFLAGS was stored in CPPLFAGS_X. merged 2007-02-17 a35644bf3ea6e44d3f59d91fd27fe86850153339 Use PERL_CFLAGS only when necessary. merged 2007-02-17 e9a2241b1bdb30e38053508bc89e887260662c29 Do not add GUILE_CFLAGS to the CPPFLAGS. merged 2007-02-17 de73f644baab81696db59b70196003e021eb7e06 Added SEE_CFLAGS to the Makefile.config. Use SEE_CFLAGS only when necessary. bug844 2007-02-17 20048696c8594fa370e06734ca926f20fe998623 smb2: Do not use smb_options. stpcpy 2007-02-15 81ec678499c148ea0005a686f7c395f30d7881e7 stpcpy was not used in this file. merged 2007-02-15 dbd95362979af70193c20d9b2e11c0bc50f641fb Use X_CFLAGS only when necessary. acckey 2007-02-11 c2d1952a082e2ed51dbfb6895f29c0869a89a8a3 accesskey: start iterating with next link. acckey 2007-02-10 5008fb697d93569984e2163c528c6404d36bcfa9 Accesskey didn't work as it should. merged 2007-02-05 f0717304f00435239ea347032a4caf9b2487c21b Killed warnings: uri_cache always evaluate as true merged 2007-02-05 2970056976962757fdddc048bcd67b1f21240d20 Do not pollute CPPFLAGS by PYTHON_CFLAGS. bug844 2007-01-27 e40f37f80c9a9c43000dba6594ee1e97829910bb Typo. bug844 2007-01-27 c7f6f769518916dd76ba1707506be602c61cb011 fsp, smb: remember the username and the password given in the uri. bug844 2007-01-27 9aab8b0cebebd7109be8b3a0bdd359dedae1731f smb: minor optimisation. bug844 2007-01-27 a956a55f8ce276e8f4dd55e1b93bf6c68a4d0c24 smb: Encode and decode spaces in filenames. fsp 2007-01-27 8ef93ebf09bf5afc700568b55b0bb1449ad32551 fsp: call find_auth in both cases. spaces1 2007-01-27 047bf7e1c6c28210c38307d113b6bc1464cdd083 ftp: ftp didn't handle filenames with spaces. fsp 2007-01-27 86789084128aefbcd1c390e51eaf8bda38ebdd19 fsp: used strings, encode and decode filenames with spaces. bug844 2007-01-26 c16c4d06c7f83b708f211cf9b897f6379aaf0e11
Re: [elinks-dev] Question, Reproducible Error
Lydgate [EMAIL PROTECTED] writes: One question: is it possible to map the higher mouse buttons 4, 5, etc., to back and forward to elinks running in xterm? I ask because elinks seems very capable of interpreting 1 2 and 3. Would the solution be at an elinks, xterm, or X (e.g. xbindkeys) level? According to xterm-215/ctlseqs.txt, xterm can send press events for mouse buttons 1-5 and release events for buttons 1-3. Xterm does not define escape sequences for other mouse buttons and it is not obvious how they should be defined. I think the easiest solution would be to configure xterm to make the mouse buttons send the same escape sequences as some function keys (e.g. ESC [ 25 ~ for what ELinks thinks is Shift+F3) and then map those function keys to the appropriate actions within ELinks. http://linuxfromscratch.org/pipermail/links-list/2001-April/000996.html (which sets a *VT100.Translations resource to remap the mouse buttons) was already mentioned to you but you wrote it doesn't work for buttons 6 and 7. This appears to be limitation in libxt-1.0.0/src/TMparse.c, which supports only five mouse buttons. I don't know how difficult that would be to fix. You may be able to work around the limit by renumbering the buttons with xmodmap. Also, I'm getting every time I try to load this page: www.pcquest.com/content/linux/2005/105041202.asp Thanks. http://bugzilla.elinks.cz/show_bug.cgi?id=927 pgptWClMn6Cq1.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Question, Reproducible Error
Lydgate [EMAIL PROTECTED] writes: But if I understand you correctly, even adding 6 and 7 in X would not be enough, and buttons 6 and 7 would need to be defined in elinks? Although I would think that something like: Btn6Up:U\n\ would bypass that limitation (assuming default keybindings) along with binding Btn7Up to Left (although I'm not sure exactly what string this would be). If the terminal sends ESC [ D, ELinks treats that as the Left key. In C syntax, that is \033[D. I don't know whether libXt understands the same syntax. However, if you're editing an input field in ELinks and press Left, ELinks just moves the cursor to the left inside the input field, instead of going back in the history. If you want mouse button 7 to access the history in this situation too, you should translate it to a string sent by some other keystroke, and then map that keystroke to history-move-back in ELinks. These workarounds make ELinks treat buttons 6 and 7 as keyboard keys. A proper solution would let ELinks treat them as mouse buttons, but then the event would have to carry the coordinates of the mouse pointer as well, so it would probably require patching both xterm and ELinks. pgpFw4ycN2jKO.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
[elinks-dev] witekfl branch status
bzip2 Should be merged before 0.12. Needs review.
This ostensibly helps with bug 517.
epoll I don't think this should be merged.
If ELinks has to keep supporting select() too, I think the
maintenance burden outweighs any advantages epoll may have.
It may be faster; but I don't believe the speedup is
noticeable in practice. It is not limited by FD_SETSIZE;
but threads[] still has that limit.
fsp Needs review and testing.
It seems nobody in #ELinks is particulary interested in FSP.
If the changes don't fix a reported bug, I think they'll
have to wait until after 0.12pre1.
gcc-4.2 Please show the warnings and compiler options.
What warnings does this change avoid and which compiler
options did you use to get them?
gpm Please add some documentation into gpm-wheel.patch.
Does the patch fix a bug in GPM?
Can it hurt compatibility with programs that use libgpm?
merged These have already been merged to master.
speech Needs a use case and review. Could then be merged before 0.12pre1.
Is this intended to help blind people? I believe they
usually have screen reader programs; why is this better?
The code may also cause compilation errors on non-POSIX
systems but I think we can sort those out based on test
reports if there is a 0.12pre release after the merge.
fsp 2007-01-23 a17510c3770e171972c4efb80d4bc51f76828597 fsp: prompt for
password when the authentication fails.
fsp 2007-01-18 ad4dce305940e9e479383df5f5ac0cc19970d634 Removed unneded
header file accidentally included by the previous commit.
fsp 2007-01-18 d49a53b2a93dd2d12783f83d1734b709fea8f0da fsp: Pass the
filesize by ctype (stderr).
gcc-4.2 2007-01-18 99cff6aa7036c90305b71ef0a3c9c85b23c5d341 Added macro
foreach_module_builtin. Killed some warnings of gcc-4.2.
fsp 2007-01-18 036d2d84751aac669f01884bf6f8f8e8335bc3cb dup2 closes given
descriptors, so no need for the explicit close.
epoll 2007-01-08 678d52551dce3e534a5776ccf3dc102e0c844f9f epoll: use EPOLLHUP
merged 2007-01-08 753e503e26cf417c0780f283c0acbf51b9dd2c3d Removed the buggy
code.
epoll 2007-01-07 6528b3c57472bba8340d5ca1604d8839938a4fbe epoll: w_max is
number of open descriptors.
bzip2 2007-01-07 79e59e9d6fdb3b94669a34387c20704554dc8464 bzip2: buf must be
the last.
speech 2007-01-07 4d7c491a22c0b9a191df363504f52f8da1c639e1 Missing include.
epoll 2007-01-07 216d6c7ec8b4aa79135232c528ec4ac266209dff Slave terminals
work with epoll.
bzip2 2007-01-07 ef5f2638a39feae8a5c883e90084c3cb03a682ad Drop to_read.
bzip2 2007-01-07 f7b9be4aa12641221f9f5248afc6dc87f181add4 bzip2: Used the
patch from bug the 517.
merged 2007-01-03 2109be1587e42d2370409e8244f6c2ef53f7d6da warning: ctext is
used only with CONFIG_UTF8.
epoll 2007-01-03 85cb16d14c2f7c7ea84a9ee993466e5020d8bfb0 Added
ELINKS_EPOLL_SIZE to the setup.h. 128 is enough for most uses.
epoll 2006-12-31 e195690acd274e561245bddbb371cb2a48c332ac Minor optimisation
(?).
epoll 2006-12-31 87e10dd412020ccf71d723f32594ef54b56a6ec6 epoll is
fashionable.
merged 2006-12-31 38b09e44c7b0e7a9fd5b3a940c1b1a0537f3ad64 Limit the timeout
to one second only under Windows.
speech 2006-12-29 91be2ea6b89a7514b75fa31dcba6d9a5ef6c978c Use popen for flite.
speech 2006-12-29 60fc3bd04fe3f85c66d1dadbc8ba4f56f576f611 '' is used instead
of to quote text for the flite.
speech 2006-12-26 e965d07055f5dd3e046469232e4b3986fb60cbaf speech: added flite
- the alternative synthesis engine.
bzip2 2006-12-17 0ca94c10c19ef0433593705fd54d4281de278e69 bzip2: added the
configure option --enable-bzip2-encoding
gpm 2006-12-15 b5a9ac08e75a61bd46a24f89c654a743b4e24f7f gpm: ELinks can use
the wheel mouse on the Linux console.
bzip2 2006-12-15 36146ffd3baadbdce3911757660eaa27e779ba30 bzip2: removed
unclean my BZ2_bzRead2.
bzip2 2006-12-15 4eaca109fa8a841d5918feb8ed438c5bc80087f2 Decompression:
write PIPE_BUF bytes to the pipe at once if possible.
fsp 2006-12-14 512ba3ed46e761162f299285472c51bc125af64c FSP: The
preparation for the error handling.
bzip2 2006-12-12 429d9ad2d619fce3345e97b632927234ea4d2f43 Simplification.
bzf-handle is the same as data-file.
bzip2 2006-12-12 5424e001312b46aad9d8d552e705d43799bf800b BZ_bzRead2 is based
on BZ_bzRead from the bzlib library.
merged 2006-12-11 d2f55ee4114947e4c397518a1c7dcba973d72ed8 Removed outdated
entries.
bzip2 2006-12-11 fe4d44414d300914e0c0a29b6293121913738a58 The gzip
decompression simplification. gzclearerr does the job.
speech 2006-12-11 c187df9a0adcf0f9821d9b14b1dfcf43139d9bb3 Small comment
according to UTF-8.
speech 2006-12-11 f260691ac4f58e7ce0e282d7b48bddbae8f00828 Set nonblocking
mode for output.
speech 2006-12-11 9064e6323b493b5614a9bd02c25729ce2f1650bf Scrolls down one
line earlier.
speech 2006-12-11 4e93cbf496c82926f42c0eaf270920f126ace3f8 Added the
keybinding ('R' by default) for reading
Re: [elinks-dev] What to do with ELinks 0.10.6.GIT
Adam Golebiowski [EMAIL PROTECTED] writes: What about releasing 0.10.7 together with a notice that this is the last release of the 0.10.x branch and it will be no longer maintained? I don't see why anyone should want to upgrade to 0.10.7 but not to 0.11.2, especially if 0.10.7 were the last release and any new bugs introduced in it were not going to be fixed. pgpmHhBrNiTiQ.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Remove current_url parameter of Python goto_url_hook?
M. Levinson [EMAIL PROTECTED] writes: I don't expect this to be an issue. Instead of adding new arguments to the hooks, it will be simpler and more flexible to make any additional data available to them by extending the API of the embedded interpreter's builtin elinks module. In other words, rather than adding a new argument foo to any given hook, Python users should be provided with a new function elinks.get_foo() that can then be called from whichever hooks they want. That is fine for getting information about the current status of ELinks. However, I've been thinking of adding radio buttons Open in: (o) this tab, ( ) new tab, ( ) new window to the Go to URL dialog, perhaps even with a [ ] reload check box. If we wanted to pass this data to the goto_url_hook, I think it would be a bit unnatural to add an elinks.get_target function for that purpose. What would it do if called from outside the hook? On the other hand, perhaps there is no reason to tell the hook how ELinks will open the result; perhaps there should even be an elinks.set_target function for the hook; or perhaps we'll later add a goto_url_hook2 that gets more arguments and by default just calls goto_url_hook with the URL. pgplBfEl6FaP7.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
