- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] Very close to a new release!

by Jorge Arellano Cid

Andreas, > > The point is: testing it. Sadly I didn't received more than a > > single comment of its working. Now I'm asking again: please > > download the latest CVS, the bookmarks server, intall them, play > > with them, test and report how it works for you. > > With the CVS verion as of > > $ date -u > Mon Feb 3 16:38:33 UTC 2003 > > It works almost out of the box for FreeBSD (the latest stable) > The only thing : autogen.sh should be a /bin/sh script, > not a /bin/bash script to make it portable. > > Same for the small convert script for the bm_dpi. > I'll change those. > > Ah, if someone here has NFS mounted accounts (from another > > machine), I want to know how it works there. As unix domain > > sockets are accessible only to the local machine, and it listens > > on /tmp, it should work, but we need the proof! > > The NFS part works between 2 FreeBSD machines. Thanks for testing. May I bother you with the socket access test? > There is just one problem : dillo waits 128 cycles for > the plugin to get online. > On my machine, this seems to be not long enough. I > set it to 256, and then it says it waits 90-190 cycles to get > online ... weird ... and then it works. > Maybe this hard coded waiting is not such a great idea. Yes. The problem is the time gap between 'exec' and the dpi-program being operative. It should be minimal when the programs is on a local HD, but NFS may take some time. I added the wait cycles for this case, and don't know the "canonical" way to do it. Yes it could be done with a gtk-timeout function or something akin but the wait cycles were the simplest thing to begin with. ;) Cheers Jorge.-

Feb. 4, 2003

Re: [Dillo-dev] Very close to a new release!

by Jorge Arellano Cid

On Mon, 3 Feb 2003, TheStar wrote: > > > > > Note to all/self: Dillo will *not* work with autoconf-2.13. > > > > > > Please test our latest CVS. It should work with the old autoconf. > > > > Works fine now, thanks. :) I've been using 0.7.0-pre since last night; > > it works beautifully so far. Can't wait for the release! > > > > Same here, although I'd much prefer having the plugins in some generic place > such as /usr/share/dillo so that I don't have to make sure that each user has > the correct plugin, etc... (Can I do that already?) You can place them anywhere in your PATH or in ~/.dillo/ > I'd also _really_ like to have a "open link with..." dialog/menu/etc... ;) Dpi is the gateway to those extensions. > Great job, Once the cut & paste and downloading are finished, it will > be better than the graphical links! Thanks. Cheers Jorge.-

Feb. 4, 2003

Re: [Dillo-dev] Very close to a new release!

by Jorge Arellano Cid

Livio, > Hello there! > > I have tested today's CVS + DPI bookmarks and things seem very well! Good! Did you use `convert` or started from scratch? Or wrote a simple script to import from elsewhere? :) > Jorge Arellano Cid writes: > > [...] > > > With respect to staying alive, I also think it should end after > > closing dillo. Maybe sending a termination request at exit time > > could work fine, but I need some time to think about it... > > One small suggestion is that this termination be dealt with unix > signals. I don't see clearly what are the advantages of using sockets > for DPI's over pipes (expect running the server and the browser > in different machines, but... is that useful?). Sockets are two-way channels and, BTW, unix domain sockets allow access from the local machine only... > Anyway, since we're > using unix domain sockets, I'll assume we are local users only, and > I'll also assume that signals are ok. > > The advantage of using signals for termination (instead of a > "proper" DPI request) is that anyone can "safely" terminate a specific > server. If Dillo crashes, or if it is buggy the server may dangle > alive. But if you (Dillo or a user) kill with -TERM, we can have the > servers set up the termination code inside the -TERM signal handler, > and hence free it's resources correctly (unsaved files, opened ftp > connections, etc.). I understand. BTW, bm_srv12 has a SIGTERM handler (just in case the server is killed or brought down with Ctrl-C). The problem is that dillo should keep track of the process ID of each server (and those can be taken down and re-launched without dillo's intervention). As you see, both schemes have some glitches; if you find an easy way to deliver the signals, I'd be all for it. Cheers Jorge.-

Feb. 4, 2003

Re: [Dillo-dev] Very close to a new release!

by Melvin Hadasht

[Sorry for the incomplete previous message] Hi Melvin, on Mon, 3 Feb 2003 19:38:25 +0100 Melvin Hadasht <melvin.hadasht(a)free.fr> wrote: > > My `info libc` didn't mention an explicit need to do that > > (except for getsockopt and getsockname); BUT the example > > initialized the one for accept!!! According to my "man accept" page, the length "should" be initialised (at least if addr is not NULL) The same source indicates that the addrlen should contain the allocated size of the structure pointed by addr (or more precisely, the sizeof() that structure). In the case of struct sockaddr_un, that size is 110, where 2 bytes are for the sa_family_t and 108 for the char array that holds the name. It seems the length is used to check if the function will not do a buffer overflow when filling it. accept() will then update the addrlen to inform the caller about the real length of the client info. In case of a Unix socket, it seems that it is used (but the string sun_path is of zero length), hence addrlen is returned with the value 2. In our case, as the client address is not used, we could just use NULL for both addr and addrlen. Anyway, in our case, libc info does not say that addrlen need to be initialized if addr is not NULL. > > Well this isn't too surprising as the same source explains two > > equivalent ways to calculate the size of the address, and when > > tested they are different! :) Concerning the SUN_LEN, the formula you used takes into account the trailing NUL byte of the string, which is wrong according to info libc: "You should compute the LENGTH parameter for a socket address in the local namespace as the sum of the size of the `sun_family' component and the string length (_not_ the allocation size!) of the file name string". *But* the man page says the addrlen argument to accept() should contain the "size of the structure pointed to by addr", so in this case, the SUN_LEN is not the candidate, but rather the "sizeof(struct sockaddr_un)". > > Should we report that? You mean reporting that accept() needs addrlen initialized if addr is not NULL? I don't know, as it seems that my system is the only one with that symptom. Farvel (Danish: Farewell) -- Melvin Hadasht

Feb. 3, 2003

Re: [Dillo-dev] aclocal version for cvs build?

by John Bradford

> > I've just checked out the current CVS tree, and running aclocal, (from > > the autogen.sh script), gives the error: > > > > aclocal: configure.in: 36: macro `AM_PATH_GTK' not found in library > > You need to install the devel packages of Gtk (the 1.2.x version) (this will > install the gtk.m4 file in the aclocal system directory. This gtk.m4 contains > the macro AM_PATH_GTK.) Ah, for some reason gtk.m4 was not in the default search path for aclocal, and it wasn't finding it. Using -I on the command line fixed it. Thanks. The current CVS tree has built fine and seems to be working here, using gcc 2.95.3, on Linux-2.4.20. By the way, has anybody tried running Dillo with Valgrind to find memory allocation bugs? http://developer.kde.org/~sewardj/ John.

Feb. 3, 2003

Re: [Dillo-dev] Very close to a new release!

by Melvin Hadasht

Hi Jorge, on Mon, 3 Feb 2003 08:39:43 -0300 (CLST) Jorge Arellano Cid <jcid(a)softhome.net> wrote: > > Melvin, > > > Jorge Arellano Cid <jcid(a)softhome.net> wrote: > > > > > In the meanwhile, I [...] also > > > initialized "addrsize" as Melvin pointed out. AFAIU this doesn't > > > affect those using GNU/Linux. > > > > The uninitialized "addrsize" affected my system wich is a GNU/Linux 2.4.19 > > (+perfctr patch) using glibc 2.2.5. The compiler used is gcc 2.95.4. This is > > an Intel platform. > > Quite interesting! Yes, especially that we both have the same glibc and a GNU/Linux system, but only me has a problem with uninitialized addrlen. > My `info libc` didn't mention an explicit need to do that > (except for getsockopt and getsockname); BUT the example > initialized the one for accept!!! > > Well this isn't too surprising as the same source explains two > equivalent ways to calculate the size of the address, and when > tested they are different! :) > > Should we report that? > > Cheers > Jorge.- > > > PS: I'm also using glibc-2.2.5, and gcc-2.95.3. Waliki (Bolivian: See you later) -- Melvin Hadasht

Feb. 3, 2003

Re: [Dillo-dev] aclocal version for cvs build?

by Melvin Hadasht

Hi John, on Mon, 3 Feb 2003 14:43:24 +0000 (GMT) John Bradford <john(a)grabjohn.com> wrote: > Hi, > > I've just checked out the current CVS tree, and running aclocal, (from > the autogen.sh script), gives the error: > > aclocal: configure.in: 36: macro `AM_PATH_GTK' not found in library You need to install the devel packages of Gtk (the 1.2.x version) (this will install the gtk.m4 file in the aclocal system directory. This gtk.m4 contains the macro AM_PATH_GTK.) > Has the current procedure for building from CVS changed? Yes. Now automatically generated files are not in the CVS anymore. So you need to create the configure script by running autogen.sh. Sa moce (Fijian: Goodbye) -- Melvin Hadasht

Feb. 3, 2003

Re: [Dillo-dev] Very close to a new release!

by Micah Stetson

> Note: the new bookmarks server tarball has a short program and > instructions to test permissions on *BSD machines. Someone please > give it a try. I'm using NetBSD 1.6. First, some GNUisms: Autogen.sh starts '#!/bin/bash' when /bin/sh works just fine. Convert in the dpi tarball has the same problem. Also, Makefile.am uses the GNU-specific '--backups=t' option to install. A '-b' will make both GNU and BSD install make backups according to their default scheme. If simple backups are enough (why not?) then that's fine. Otherwise, you may have to resort to some configure trickery to decide whether to use '--backups=t' or '-b -B ".%d"' or some such. Other that that, it works great. The socket test gives 'Permission denied' like it should. Thanks for all your work! Micah

Feb. 3, 2003

Re: [Dillo-dev] something's wrong with configure.in

by John Bradford

> hans@jorgen dillo$ ./autogen.sh > aclocal Found. > autoheader Found. > autoconf Found. > automake Found. > [Checks passed] > Generating... > aclocal: configure.in: 36: macro `AM_PATH_GTK' not found in library As far as I can tell, everything after this is caused by aclocal not running correctly. John.

Feb. 3, 2003

something's wrong with configure.in

by Jan Stary

This is what I get with automake 1.6.3 and autoconf 2.5.7 hans$ cvs -z3 -d :pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo co dillo cvs server: Updating dillo U dillo/AUTHORS [ ... ] U dillo/src/IO/proto.c hans@jorgen src$ cd dillo hans@jorgen dillo$ ./autogen.sh aclocal Found. autoheader Found. autoconf Found. automake Found. [Checks passed] Generating... aclocal: configure.in: 36: macro `AM_PATH_GTK' not found in library autoheader: error: AC_CONFIG_HEADERS not found in configure.in configure.in:4: error: possibly undefined macro: AM_INIT_AUTOMAKE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.in:5: error: possibly undefined macro: AM_CONFIG_HEADER configure.in:28: error: possibly undefined macro: AM_PROG_CC_STDC configure.in:36: error: possibly undefined macro: AM_PATH_GTK configure.in:4: no proper implementation of AM_INIT_AUTOMAKE was found, configure.in:4: probably because aclocal.m4 is missing... configure.in:4: You should run aclocal to create this file, then configure.in:4: run automake again. configure.in: installing `./install-sh' configure.in: installing `./mkinstalldirs' configure.in: installing `./missing' configure.in:5: required file `./config.h.in' not found src/IO/Makefile.am: installing `./depcomp' /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/lang-compile.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/lang-compile.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/lang-compile.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/lang-compile.am: AMDEP does not appear in AM_CONDITIONAL Jan

Feb. 3, 2003

aclocal version for cvs build?

by John Bradford

Hi, I've just checked out the current CVS tree, and running aclocal, (from the autogen.sh script), gives the error: aclocal: configure.in: 36: macro `AM_PATH_GTK' not found in library Has the current procedure for building from CVS changed? John.

Feb. 3, 2003

Re: [Dillo-dev] [Sin Título]

by Jorge Arellano Cid

On Mon, 3 Feb 2003, Blue Geek wrote: > > I've tested the bookmarks PI and I must say, as a dillo user, that I > personaly don't like the new way of managing bookmarks. I doesn't fit in > the simplicity of dillo because introduces more complexity. Also I find > the interface not very usable because it's based in HTML forms. > > What I would prefered is an optional external program for managing the > bookmarks in GTK like http://rm-f.net/~cout/hubcap/gtkbookmark/ or the > dialog included in SkipStone > http://www.muhri.net/skipstone/images/screenshots/skipstone-bookmarks.jpg > > Please keep Dillo simple and usable. The point of dpi is interfacing dillo with external programs. The current server is just one possible instance I wrote, not THE one and only way around. You can write your own bookmarks handler or a gateway to the ones you like, but I guess you never read the docs. Cheers Jorge.-

Feb. 3, 2003

Re: [Dillo-dev] Very close to a new release!

by Jorge Arellano Cid

Melvin, > Jorge Arellano Cid <jcid(a)softhome.net> wrote: > > > In the meanwhile, I [...] also > > initialized "addrsize" as Melvin pointed out. AFAIU this doesn't > > affect those using GNU/Linux. > > The uninitialized "addrsize" affected my system wich is a GNU/Linux 2.4.19 > (+perfctr patch) using glibc 2.2.5. The compiler used is gcc 2.95.4. This is an > Intel platform. Quite interesting! My `info libc` didn't mention an explicit need to do that (except for getsockopt and getsockname); BUT the example initialized the one for accept!!! Well this isn't too surprising as the same source explains two equivalent ways to calculate the size of the address, and when tested they are different! :) Should we report that? Cheers Jorge.- PS: I'm also using glibc-2.2.5, and gcc-2.95.3.

Feb. 3, 2003

Re: [Dillo-dev] [Sin Título]

by Ralph Slooten

On Mon, 03 Feb 2003 09:25:03 GMT Blue Geek <bluegeek(a)eresmas.com> wrote: > I've tested the bookmarks PI and I must say, as a dillo user, that I > personaly don't like the new way of managing bookmarks. I doesn't fit > in the simplicity of dillo because introduces more complexity. Also I > find the interface not very usable because it's based in HTML forms. > > What I would prefered is an optional external program for managing the > bookmarks in GTK like http://rm-f.net/~cout/hubcap/gtkbookmark/ or the > dialog included in SkipStone > http://www.muhri.net/skipstone/images/screenshots/skipstone-bookmarks.jpg > > Please keep Dillo simple and usable. I agree with this, to a point. In terms of usage, the new concept is hard to use (or should I say "not handy"), however for bookmark editing it's quite OK. Would it not be an idea to have the current bookmarks converted/translated to a gtk drop-down menu (like it used to be, however this time with submenu support), and editing to be done in the current way (via html)? Just my 5 cents, Greetings Ralph -- http://tuxpower.f2g.net/ http://axljab.homelinux.org:8080/ "Linux is not The Answer. Yes is the answer. Linux is The Question"

Feb. 3, 2003

Re: [Dillo-dev] autoconf/automake stuff in CVS

by Jorge Arellano Cid

Patrick, > * Jorge Arellano Cid <jcid(a)softhome.net> [02-02-03 17:00]: > > > > and wrote a simple autogen.sh script to remake them. > > > > Now you'll need autoconf and automake installed. > > Built ok on SuSE 8.1, i586(686), but lost bookmarks access. Did I miss > this being mentioned earlier? What do you mean by "lost bookmarks access"? Cheers Jorge.-

Feb. 3, 2003

Re: [Dillo-dev] Very close to a new release!

by Melvin Hadasht

Hi Jorge, on Sun, 2 Feb 2003 19:46:53 -0300 (CLST) Jorge Arellano Cid <jcid(a)softhome.net> wrote: > In the meanwhile, I [...] also > initialized "addrsize" as Melvin pointed out. AFAIU this doesn't > affect those using GNU/Linux. The uninitialized "addrsize" affected my system wich is a GNU/Linux 2.4.19 (+perfctr patch) using glibc 2.2.5. The compiler used is gcc 2.95.4. This is an Intel platform. Cheers -- Melvin Hadasht

Feb. 3, 2003

[Sin Título]

by Blue Geek

Feb. 3, 2003

Re: [Dillo-dev] Very close to a new release!

by TheStar

> > > Note to all/self: Dillo will *not* work with autoconf-2.13. > > > > Please test our latest CVS. It should work with the old autoconf. > > Works fine now, thanks. :) I've been using 0.7.0-pre since last night; > it works beautifully so far. Can't wait for the release! > Same here, although I'd much prefer having the plugins in some generic place such as /usr/share/dillo so that I don't have to make sure that each user has the correct plugin, etc... (Can I do that already?) I'd also _really_ like to have a "open link with..." dialog/menu/etc... ;) Great job, Once the cut & paste and downloading are finished, it will be better than the graphical links!

Feb. 3, 2003

autoconf/automake stuff in CVS

by Patrick Shanahan

* Jorge Arellano Cid <jcid(a)softhome.net> [02-02-03 17:00]: > > and wrote a simple autogen.sh script to remake them. > > Now you'll need autoconf and automake installed. Built ok on SuSE 8.1, i586(686), but lost bookmarks access. Did I miss this being mentioned earlier? -- Patrick Shanahan http://wahoo.no-ip.org Registered Linux User #207535 icq#173753138 @ http://counter.li.org

Feb. 3, 2003

Re: [Dillo-dev] Very close to a new release!

by Livio Baldini Soares

Hello there! I have tested today's CVS + DPI bookmarks and things seem very well! Jorge Arellano Cid writes: [...] > With respect to staying alive, I also think it should end after > closing dillo. Maybe sending a termination request at exit time > could work fine, but I need some time to think about it... One small suggestion is that this termination be dealt with unix signals. I don't see clearly what are the advantages of using sockets for DPI's over pipes (expect running the server and the browser in different machines, but... is that useful?). Anyway, since we're using unix domain sockets, I'll assume we are local users only, and I'll also assume that signals are ok. The advantage of using signals for termination (instead of a "proper" DPI request) is that anyone can "safely" terminate a specific server. If Dillo crashes, or if it is buggy the server may dangle alive. But if you (Dillo or a user) kill with -TERM, we can have the servers set up the termination code inside the -TERM signal handler, and hence free it's resources correctly (unsaved files, opened ftp connections, etc.). If, on the other hand, there is an interest in making server and browser work on separate machines, then I would suggest to besides normal DPI termination methods, the signal termination handler still be used, as to always let the user clean things up when needed. just my 0.02 reais (which won't buy anything these days :-((( -- Livio <livio(a)ime.usp.br>

Feb. 3, 2003

Re: [Dillo-dev] Very close to a new release!

by Telent

> Note: the new bookmarks server tarball has a short program and > instructions to test permissions on *BSD machines. Someone please > give it a try. Tested on OpenBSD 3.2-current; permission denied. There's no issue there. I don't have NetBSD or FreeBSD boxes, but Open is fine. -Sunny Raspet

Feb. 3, 2003

Re: [Dillo-dev] Very close to a new release!

by Telent

> > Note to all/self: Dillo will *not* work with autoconf-2.13. > > Please test our latest CVS. It should work with the old autoconf. Works fine now, thanks. :) I've been using 0.7.0-pre since last night; it works beautifully so far. Can't wait for the release! -Sunny Raspet

Feb. 3, 2003

Re: [Dillo-dev] Very close to a new release!

by Jorge Arellano Cid

Hi there, > > The point is: testing it. Sadly I didn't received more than a > > single comment of its working. Now I'm asking again: please > > download the latest CVS, the bookmarks server, intall them, play > > with them, test and report how it works for you. > > Update'd, and it seems to work. bm_serv started automatically and > "View bookmarks", "Bookmark this page" menu commands worked. Removing > bookmarks also worked. Only problem noticed so far, is that the bm_serv > stays alive after closeing dillo (imho it shouldn't). Thanks for the feedback! (now with autoconf/automake stuff renewed in CVS, and the new bookmarks server tarball I hope it get easier to test and send some feedback!) With respect to staying alive, I also think it should end after closing dillo. Maybe sending a termination request at exit time could work fine, but I need some time to think about it... In the meanwhile, I changed the "sun" variable and also initialized "addrsize" as Melvin pointed out. AFAIU this doesn't affect those using GNU/Linux. Now you can download the latest bookmarks server and test all the stuff. Note: the new bookmarks server tarball has a short program and instructions to test permissions on *BSD machines. Someone please give it a try. Regards Jorge.- > Nice work done :) Thanks!

Feb. 2, 2003

Re: [Dillo-dev] autoconf/automake stuff in CVS

by Jorge Arellano Cid

Hi all! Considering all the troubles we've had with autoconf/automake stuff, I eliminated all these files from the CVS: Makefile.in doc/Makefile.in src/Makefile.in src/IO/Makefile.in aclocal.m4 install-sh mkinstalldirs missing depcomp (as Jörgen and others more or less suggested) and wrote a simple autogen.sh script to remake them. Now you'll need autoconf and automake installed. Ah, as the new configure.in was only working with newer versions of autoconf, I downgraded it to the same format as 0.6.6 had. I tested as far as I could here, and it should work again with older autoconf/automake pairs. Please test it and tell me. BTW, next I'll updtate the bookmars server tarball. Cheers Jorge.-

Feb. 2, 2003

Re: [Dillo-dev] autoconf/automake stuff in CVS

by Nicola Girardi

> > Makefile.in doc/Makefile.in src/Makefile.in src/IO/Makefile.in > > config.h.in configure > > aclocal.m4 (generated by aclocal) > install-sh mkinstalldirs missing depcomp (generated by automake -a) This list seems OK to me. Thanks Jorge.

Feb. 2, 2003

Re: [Dillo-dev] autoconf/automake stuff in CVS

by Jorgen Viksell

> Hi there! Hi, > Sometime ago someone suggested removing some configuration > files from the CVS. Considering all the trouble those files > generate (to allow compiling by just: ./configure; make), it > looks as a good idea. > > I'd remove: > > Makefile.in doc/Makefile.in src/Makefile.in src/IO/Makefile.in > config.h.in configure aclocal.m4 (generated by aclocal) install-sh mkinstalldirs missing depcomp (generated by automake -a) > From then, after checkout, you should run: > > autoheader; autoconf; automake; ./configure; make > > some more steps, but a lot less trouble! I think the standard way is to have an autogen.sh file that does it for you. for example: http://cvs.gnome.org/lxr/source/gob/autogen.sh So, after a checkout from cvs, you'd run ./autogen.sh --prefix=/usr ... After that it's ./configure as usual. HTH, Jörgen

Feb. 2, 2003

Re: [Dillo-dev] Very close to a new release!

by Telent

> telent@frodo:/telent/dillo% rm configure > telent@frodo:/telent/dillo% autoconf > autoconf: Undefined macros: > configure.in:153:AC_CONFIG_FILES([Makefile doc/Makefile src/Makefile > src/IO/Makefile]) > configure.in:4:AC_CONFIG_SRCDIR([src/dillo.c]) > telent@frodo:/telent/dillo% gmake > cd . && \ > /bin/sh /telent/dillo/missing --run automake --gnu Makefile > /bin/sh ./config.status --recheck > running /bin/sh ./configure --no-create --no-recursion > loading cache ./config.cache > ./configure[549]: syntax error: `src/dillo.c' unexpected > gmake: *** [config.status] Error 1 > telent@frodo:/telent/dillo% And... In the grand tradition of replying to one's own post... Yes, all my fault. Note to all/self: Dillo will *not* work with autoconf-2.13. -Sunny Raspet

Feb. 2, 2003

Re: [Dillo-dev] Very close to a new release!

by slymer＠slymer.org

On Sat, 1 Feb 2003 17:16:36 -0500 Telent <telent(a)mordac.info> wrote: > I'm running OpenBSD 3.2-current on i386. If you need further > details, I can get them. I'm sure it's just a stupid error of > mine. Get the configure script from CVS, and type: touch configure, it worked for me. -- Registered Linux user #298569 Always borrow money from a pessimist; he doesn't expect to be paid back.

Feb. 2, 2003

Re: [Dillo-dev] Very close to a new release!

by slymer＠slymer.org

On Sat, 1 Feb 2003 09:54:34 -0300 (CLST) Jorge Arellano Cid <jcid(a)softhome.net> wrote: > I'll be expecting your feedback! Latest cvs works ok for me so far, but one q though, when will we be able to copy text from the pages without making dillo revel the source of the page... -- Registered Linux user #298569 There is always one thing to remember: writers are always selling somebody out. -- Joan Didion, "Slouching Towards Bethlehem"

Feb. 2, 2003

Re: [Dillo-dev] Very close to a new release!

by Madis Janson

On Sat, 1 Feb 2003, Melvin Hadasht wrote: > I got one problem: the bm_srv12 displayed the following when it was attempted to > open the bookmark page: > bm_srv12: accepting connections... > [accept]: Invalid argument > > checking why, I found the bug was that the accept() function was called with an > uninitialized *addrlen (third) argument. According to the man page on GNU/Linux, > "The addrlen argument is a value-result parameter: it should > initially contain the size of the structure pointed to by addr; on return > it will contain the actual length (in bytes) of the address returned. When > addr is NULL nothing is filled in." > > So I made the following patch: > --- bm_srv12.c Fri Jan 31 17:22:36 2003 > +++ bm_srv12_modified.c Sat Feb 1 22:00:23 2003 > @@ -1694,7 +1694,7 @@ int main (void) { > struct sockaddr_un pun; > int sock_descriptor; > int temp_sock_descriptor; > - int address_size; > + int address_size = sizeof(struct sockaddr_un); > char buf[16384]; > int st, code; Looked bm_srv code now and discovered variable named "sun" before pun in main function. Which is not a good variable name, when you want to compile it on solaris (solaris c library headers contain something like #define sun 1).

Feb. 2, 2003

autoconf/automake stuff in CVS

by Jorge Arellano Cid

Hi there! Sometime ago someone suggested removing some configuration files from the CVS. Considering all the trouble those files generate (to allow compiling by just: ./configure; make), it looks as a good idea. I'd remove: Makefile.in doc/Makefile.in src/Makefile.in src/IO/Makefile.in config.h.in configure From then, after checkout, you should run: autoheader; autoconf; automake; ./configure; make some more steps, but a lot less trouble! If someone knows beter, please say so. I haven't removed the files yet and will wait for a replay before changing it. Cheers Jorge.-

Feb. 1, 2003

Re: [Dillo-dev] Very close to a new release!

by Telent

> The point is: testing it. Sadly I didn't received more than a > single comment of its working. Now I'm asking again: please > download the latest CVS, the bookmarks server, intall them, play > with them, test and report how it works for you. I am most likely just stupid, but a fresh download from CVS doesn't work for me. Output from ./configure: telent@frodo:/telent/dillo% ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets ${MAKE}... yes checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for style of include used by make... GNU checking dependency style of gcc... gcc checking for gcc option to accept ANSI C... none needed checking for ranlib... ranlib checking for gtk-config... /usr/local/bin/gtk-config checking for GTK - version >= 1.2.0... yes checking for jpeg_destroy_decompress in -ljpeg... yes checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking jpeglib.h usability... yes checking jpeglib.h presence... yes checking for jpeglib.h... yes checking jconfig.h usability... yes checking jconfig.h presence... yes checking for jconfig.h... yes checking jerror.h usability... yes checking jerror.h presence... yes checking for jerror.h... yes checking jmorecfg.h usability... yes checking jmorecfg.h presence... yes checking for jmorecfg.h... yes checking whether threads work with -pthread... yes checking for zlibVersion in -lz... yes checking for png_check_sig in -lpng... yes checking for ANSI C header files... (cached) yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking sys/uio.h usability... yes checking sys/uio.h presence... yes checking for sys/uio.h... yes checking for socket... yes configure: creating ./config.status config.status: creating Makefile config.status: creating doc/Makefile config.status: creating src/Makefile config.status: creating src/IO/Makefile config.status: creating config.h config.status: executing default-1 commands telent@frodo:/telent/dillo% make cd . && /bin/sh /telent/dillo/missing --run autoheader cd . && /bin/sh /telent/dillo/missing --run autoconf autoconf: Undefined macros: configure.in:153:AC_CONFIG_FILES([Makefile doc/Makefile src/Makefile src/IO/Makefile]) configure.in:4:AC_CONFIG_SRCDIR([src/dillo.c]) WARNING: `autoconf' is missing on your system. You should only need it if you modified `configure.in'. You might want to install the `Autoconf' and `GNU m4' packages. Grab them from any GNU archive site. /bin/sh ./config.status --recheck running /bin/sh ./configure --no-create --no-recursion creating cache ./config.cache ./configure[549]: syntax error: `src/dillo.c' unexpected *** Error code 1 Stop in /telent/dillo (line 108 of Makefile). telent@frodo:/telent/dillo% I *do* have autoconf installed, both 2.13 and 2.52, and I didn't make any changes to configure.in. When I remove ``configure'' and regenerate it with autoconf, I get this: telent@frodo:/telent/dillo% rm configure telent@frodo:/telent/dillo% autoconf autoconf: Undefined macros: configure.in:153:AC_CONFIG_FILES([Makefile doc/Makefile src/Makefile src/IO/Makefile]) configure.in:4:AC_CONFIG_SRCDIR([src/dillo.c]) telent@frodo:/telent/dillo% gmake cd . && \ /bin/sh /telent/dillo/missing --run automake --gnu Makefile /bin/sh ./config.status --recheck running /bin/sh ./configure --no-create --no-recursion loading cache ./config.cache ./configure[549]: syntax error: `src/dillo.c' unexpected gmake: *** [config.status] Error 1 telent@frodo:/telent/dillo% I'm running OpenBSD 3.2-current on i386. If you need further details, I can get them. I'm sure it's just a stupid error of mine. -Sunny Raspet

Feb. 1, 2003

Re: [Dillo-dev] Very close to a new release!

by Melvin Hadasht

Hi Jorge, on Sat, 1 Feb 2003 09:54:34 -0300 (CLST) Jorge Arellano Cid <jcid(a)softhome.net> wrote: > The point is: testing it. Sadly I didn't received more than a > single comment of its working. Now I'm asking again: please > download the latest CVS, the bookmarks server, intall them, play > with them, test and report how it works for you. Everything compiled without problems on i686 GNU/Linux. I got one problem: the bm_srv12 displayed the following when it was attempted to open the bookmark page: bm_srv12: accepting connections... [accept]: Invalid argument checking why, I found the bug was that the accept() function was called with an uninitialized *addrlen (third) argument. According to the man page on GNU/Linux, "The addrlen argument is a value-result parameter: it should initially contain the size of the structure pointed to by addr; on return it will contain the actual length (in bytes) of the address returned. When addr is NULL nothing is filled in." So I made the following patch: --- bm_srv12.c Fri Jan 31 17:22:36 2003 +++ bm_srv12_modified.c Sat Feb 1 22:00:23 2003 @@ -1694,7 +1694,7 @@ int main (void) { struct sockaddr_un pun; int sock_descriptor; int temp_sock_descriptor; - int address_size; + int address_size = sizeof(struct sockaddr_un); char buf[16384]; int st, code; Concerning Unix sockets, I read on GNU/Linux' "man 7 unix", that many BSD derivatives do not guarantee the permissions, so anyone could read and modify the bookmarks of another user. That is, unless I missed something. " NOTES In the Linux implementation, sockets which are visible in the filesystem honour the permissions of the directory they are in. Their owner, group and their permissions can be changed. Creation of a new socket will fail if the process does not have write and search (execute) permis sion on the directory the socket is created in. Connect ing to the socket object requires read/write permission. This behavior differs from many BSD derived systems which ignore permissions for Unix sockets. Portable programs should not rely on this feature for security. " However, I do not have any suggestions here. Farvel (Danish: Farewell) -- Melvin Hadasht

Feb. 1, 2003

Very close to a new release!

by Jorge Arellano Cid

Hi there! It's been a hard time for me trying to get an Internet connection from where I'm temporary living now. That's the main reason for my abscence (as anticipated). Well, I kept working on the plugins stuff and it shows. Now the CVS has the new code (with unix domain sockets) and the CVS.html page holds the new bookmarks-server tarball. Now dillo launches it automatically and before the release the dpi code for the bookmarks server will be a part of the main tarball. The point is: testing it. Sadly I didn't received more than a single comment of its working. Now I'm asking again: please download the latest CVS, the bookmarks server, intall them, play with them, test and report how it works for you. I want to know how the whole thing looks and feels before making the release. This should be a short span, depending on feedback. Ah, if someone here has NFS mounted accounts (from another machine), I want to know how it works there. As unix domain sockets are accessible only to the local machine, and it listens on /tmp, it should work, but we need the proof! That's all by now guys. I'll be expecting your feedback! Cheers* Jorge.- PS: I'll try to answer some pending issues, but roughly, this CVS plus some cosmetic will be 0.7.0. Pending patches will go to 0.7.1.

Feb. 1, 2003

can't compile dillo

by Gerhard Stroehlein

hi, it's the first time that I am trying to compile something under cygwin. I installed gtk 1.2 and glib and I am using gcc 3.2.3. I've downloaded dillo 0.6.6. After running the configure script which states that the pthread check is okay I started make. make aborted with the error message that -pthread is an unsupported option of gcc. Any ideas how to overcome the problem? Thanks for your help in advance, Gerhard

Jan. 31, 2003

patch repository

by Andrés Mujica - Linux SEAQ

Hi!! where can i find a developed patches lists? and a download site? help in advance

Jan. 27, 2003

Re: [Dillo-dev] Q: showing all HTTP traffic...

by higuita

On Sat, 25 Jan 2003 23:54:34 +0100, Basile STARYNKEVITCH <basile(a)starynkevitch.net> wrote: > (I am working on POESIA - see www.poesia-filter.org - which is an > opensource Internet content filter; and this motivate the following > question) do you know privoxy, it does the same thing... maybe joining forces? higuita -- There is a great discovery still to be made in Literature: that of paying literary men by the quantity they do NOT write. Caravela.homelinux.net@Portugal: 22:17:15 up 3 days, 11:41, 1 user, load average: 2.67, 1.09, 0.62

Jan. 26, 2003

Re: [Dillo-dev] Q: showing all HTTP traffic...

by Miernik

On Sat, Jan 25, 2003 at 11:54:34PM +0100, Basile STARYNKEVITCH wrote: > I would like patch dillo (the latest CVS preferably) so that it could > (optionally) show all the HTTP traffic (HTTP requests to web servers > or proxys and responses from them). I am interested in looking at all > the HTTP traffic. You could consider the links-hacked browser for this. It has a compile time option to log all HTTP trafic to a file. However it is not GTK. It does not use any widget library. It is a full featured graphics browser, with SSL and JavaScript. To comile it you need to read http://www.stud.fh-dortmund.de/~jkorte/links/install-links-hacked.html links-hacked can be a little tricky to compile, and there are no precompiled packages avialable, so if you have any problems, ask. Then about the HTTP traffic log feature read my post here: http://archive.linuxfromscratch.org/mail-archives/links-list/2003/01/0053.h… -- Miernik ____________________________________________________ ___ ICQ: 4004001 ___/___ tel.: +48608233394 ___/ mailto:miernik@ctnet.pl No Iraq war! http://www.globalexchange.org/campaigns/iraq/invadeIraq082702.html Please call the White House +1-202-456-1111 or fax +1-202-456-2461 and say no!

Jan. 26, 2003

Q: showing all HTTP traffic...

by Basile STARYNKEVITCH

Dear All I am new to the dillo list (I am working on POESIA - see www.poesia-filter.org - which is an opensource Internet content filter; and this motivate the following question) I would like patch dillo (the latest CVS preferably) so that it could (optionally) show all the HTTP traffic (HTTP requests to web servers or proxys and responses from them). I am interested in looking at all the HTTP traffic. So the idea would be to just have a read-only GTK text widget displaying all the HTTP traffic. What whould be the easiest way to do this? (GWIW, I do know GTK quite well). Assuming the latest CVS code of dillo, would I need to hack just dillo/src/IO/http.c or should I look elsewhere? I would suppose that displaying the full HTTP traffic should interest other hackers (in particular coders of HTTP servers). (Yes, I know about muffin, but POESIA uses already Squid/Icap as a proxy and I would avoid having several proxies serially) Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net alias: basile<at>tunes<dot>org 8, rue de la Faïencerie, 92340 Bourg La Reine, France

Jan. 25, 2003

Re: [Dillo-dev] external helpers patch

by Ralph Slooten

On Wed, 22 Jan 2003 15:24:29 +0100 Ernest Frigola <bulk1(a)eresmas.com> wrote: > Hi! > > This patch adds a new option to the page popup menu ("Open with > external browser") that allows to open the current page in another > browser (defaults to mozilla and can be configured using the > "external_browser" option in your dillorc file). You'l find this patch > usefull If you usually start browsing with dillo and when you arrive > to a page that dillo can't render you have to copy & paste the current > link to another browse (ie mozilla). > > Also adds another option in the link popup menu ("Download with > external utility") that executes a command for dowloading the current > link (defaults to "xterm -e wget -c" and can be configured using the > "external_downloader" option). > > The patch has been testet with today CVS tarball. > > -- Ernest Frigola <bulk1 at eresmas.com> > Wow, this is great! Works like a charm here... maybe something to consider for future development of Dillo? There was talk of this a while ago, but I haven't ever gotten the chance to test it out... and yeah, it works really great, and is very configurable. Thanks for the effort! Greetings Ralph -- http://tuxpower.f2g.net/ http://axljab.homelinux.org:8080/ "I have opinions of my own, strong opinions, but I don't always agree with them." - George H. W. Bush

Jan. 22, 2003

Re: [Dillo-dev] external helpers patch

by Grigory Bakunov

On Wed, 22 Jan 2003 15:24:29 +0100 Ernest Frigola <bulk1(a)eresmas.com> wrote: EF> Hi! EF> This patch adds a new option to the page popup menu ("Open with external EF> browser") that allows to open the current page in another browser (defaults EF> to mozilla and can be configured using the "external_browser" option in your EF> dillorc file). You'l find this patch usefull If you usually start browsing EF> with dillo and when you arrive to a page that dillo can't render you have to EF> copy & paste the current link to another browse (ie mozilla). EF> Also adds another option in the link popup menu ("Download with external EF> utility") that executes a command for dowloading the current link (defaults EF> to "xterm -e wget -c" and can be configured using the "external_downloader" EF> option). EF> The patch has been testet with today CVS tarball. YES! IT'S WORK!!!!!! Very, very nice, i wait for this patch something about half year :) Thank you ........................................................................ IRC: irc.freenode.net #asplinux Grigory Bakunov EMAIL: black(a)asplinux.ru ASPLinux Support Team ICQ: 51369901 http://www.asplinux.ru -----BEGIN GEEK CODE BLOCK----- GCS/MU d-(--) s:- a- C+++>++$ UBLAVSX+++$ P+ L++++$ E++$ W++ N+>- o? K? w-- O- M V-(--) PS+ PE+ !Y PGP+>++++ t+ 5++ X+++ R+++ tv+>-- b+++ ?DI D+ G++ e>++$ h- r++ y+ z++(+++) ------END GEEK CODE BLOCK------

Jan. 22, 2003

external helpers patch

by Ernest Frigola

Hi! This patch adds a new option to the page popup menu ("Open with external browser") that allows to open the current page in another browser (defaults to mozilla and can be configured using the "external_browser" option in your dillorc file). You'l find this patch usefull If you usually start browsing with dillo and when you arrive to a page that dillo can't render you have to copy & paste the current link to another browse (ie mozilla). Also adds another option in the link popup menu ("Download with external utility") that executes a command for dowloading the current link (defaults to "xterm -e wget -c" and can be configured using the "external_downloader" option). The patch has been testet with today CVS tarball. -- Ernest Frigola <bulk1 at eresmas.com>

Jan. 22, 2003

Please disregard submitted patch

by Voland0 De Caribilla

Greetings with wishes of health and peace. Please disregard the patch I submitted against version 0.6.6 to correct the links in about:splash . I found that the CVS version, 0.7.0 , I believe, already has the links corrected. -- _______________________________________________ Get your free email from http://mymail.operamail.com Powered by Outblaze

Jan. 21, 2003

Patch for correcting links on about:splash

by Voland0 De Caribilla

Greetings with wishes of health and peace. Attached is a patch for correcting links on about:splash from the old server, dillo.cipsga.org.br , to the new, dillo.auriga.wearlab.de . The patched source is 0.6.6 . The edit is so minor -just URL text- that I'm submitting it without testing, because I've got to work through a long list of errors and warnings when compiling. I probably need to apply the patch that came with the source when I apt-get'ted source from Debian. -- _______________________________________________ Get your free email from http://mymail.operamail.com Powered by Outblaze

Jan. 21, 2003

Re: [Dillo-dev] Baby steps for patch submission?

by Livio Baldini Soares

Hello Volando! Voland0 De Caribilla writes: > Greetings with wishes of health and peace. [...] To start of you can read this text from the site: http://dillo.auriga.wearlab.de/developer.html > I've now made to small edits necessary to correct the links > on the about:splash, and need to know the best way to > create and submit a patch. I made the edits in a copy of > the source for 0.6.6 that I obtained through Debian. Is > the best diff to diff -pru <mySrcDir> <origSrcDir>, or just > to diff the edited file with the original file? Actually the diff command must contain the original dir first, then your source. To diff the entire directory is the recommended if you have changed more than one/few files. Of course, if you have only changed one file, it's ok to do: diff -pru dillo.orig/this_file dillo.my.version/this_file Oh, and it is prefered if you diff against current CVS not old versions. Check here: http://cvs.auriga.wearlab.de/cgi-bin/cvsweb.cgi/dillo/ to see if the files in question were changed. > Do I email the patch, or check it in to the CVS server? You can't really check it into the CVS. The CVS is only public for reading, only Jorge and Sebastian have access for writing. If the patch is "small" (I'm guessing like 10-20KB, but maybe Jorge has a different opinion) I guess it's ok to send it directly to the list. If it's bigger, than you should put it up somewhere in the Internet. best regards, -- Livio <livio(a)ime.usp.br>

Jan. 20, 2003

Baby steps for patch submission?

by Voland0 De Caribilla

Greetings with wishes of health and peace. I've been programming for a long time, but have never contributed to a project. My programming has been building mouse driver and graphics acceleration libraries using X86 assembly for DOS programs, serial communications (simple terminal emulator) using Mix PowerC atop DOS, file-manipulation utilities using Sun cc, and Perl/CGI with DBI. I've now made to small edits necessary to correct the links on the about:splash, and need to know the best way to create and submit a patch. I made the edits in a copy of the source for 0.6.6 that I obtained through Debian. Is the best diff to diff -pru <mySrcDir> <origSrcDir>, or just to diff the edited file with the original file? Do I email the patch, or check it in to the CVS server? -- _______________________________________________ Get your free email from http://mymail.operamail.com Powered by Outblaze

Jan. 20, 2003

[PATCH] Limit size of Cache

by Livio Baldini Soares

Hello everyone! A long, long time ago I sent in a patch for limiting the size of the Cache in Dillo. Here is a very precise description of what I had done: http://sourceforge.net/mailarchive/message.php?msg_id=1642897 I have been using this patch for daily use for the past 6 months. I haven't experienced a single crash. So I think it is high time I rediffed my patch for current CVS. The patch can be found here: http://www.ime.usp.br/~livio/dillo/patches/cache-size-limit.20020119.diff The diffstat output: dillorc | 15 ++++++-- src/IO/about.c | 10 +++-- src/browser.h | 3 + src/cache.c | 102 +++++++++++++++++++++++++++++++++++++++++++++++++++++++- src/cache.h | 2 - src/interface.c | 4 +- src/prefs.c | 5 ++ src/prefs.h | 2 + 8 files changed, 130 insertions(+), 13 deletions(-) There are some changes from this version to the previous. First, I have removed the about:cache-clean functionality. I have had private discussions with some users and we've concluded it was not a very good idea. The about:cache functionality is still there, though. I think it's nice. Oh, and I had to "undo" the changes with respect to num_bw and browser_window variables in browser.h and interface.c; they are now global again. This could be easily changed if wanted - just make a helper function in interface.c which returns a copy of browser_window. Jorge, please consider applying this patch. Any problems, don't hesitate to e-mail. best wishes, -- Livio <livio(a)ime.usp.br>

Jan. 19, 2003

copy from page

by slymer＠slymer.org

When will dillo enable it's user to copy from the pages it renders ? I read somewhere on the dillo site that this has been fixed, but latest cvs build doesn't seem to be enable me to copy text. -- People tend to make rules for others and exceptions for themselves. Registered Linux user #298569

Jan. 19, 2003

Re: [Dillo-dev] hi

by Sebastian Geerken

On Sat, Jan 18, Andr?s Mujica - Linux SEAQ wrote: > i want to share with all of u this article.. sorry if it was already > reported... > > > http://freshmeat.net/articles/view/695/ Was already reported, and has been added to the press page. > by the way, dillo is a great, great browser.. is the one i use all time.. Thanks. Sebastian

Jan. 18, 2003

Re: [Dillo-dev] Web pages - compatibility

by Sebastian Geerken

On Thu, Jan 09, Andreas Schweitzer wrote: > Since I'm not quite sure who is maintainig the web pages > I send it here : > The Compatibility page should list the BSD's as follows > >  > > <LI> NetBSD (in pkgsrc) > <li> FreeBSD (in the ports) > <li> OpenBSD (in the ports) > >  > > I.e. OpenBSD certainly is not restricted to Version 2.9. Also > the phrases in the parantheses mean something to BSD users :-) > (essentially that dillo is part of the OS in a broader sense). > > Also, for the handhelds : NetBSD has binaries for the > StrongARM and the MIPS based handhelds on their ftp sites. Done. I also added a section in the "Packages" section, on the "Download" page. Sebastian

Jan. 18, 2003