February 2003 - Dillo-dev - lists.mailman3.com

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

by Jorge Arellano Cid

On Tue, 4 Feb 2003, Patrick Shanahan wrote: > > > 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"? > > There are no longer any bookmarks from the drop-down menu. There is a > bookmarks.html file in ~/.dillo but dillo is unable to access it. Also > saving a bookmark does not work ??? Go to the [CVS] link and RTFM. Jorge.-

Feb. 4, 2003

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

by Patrick Shanahan

* Jorge Arellano Cid <jcid(a)softhome.net> [02-04-03 00:49]: > > 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"? There are no longer any bookmarks from the drop-down menu. There is a bookmarks.html file in ~/.dillo but dillo is unable to access it. Also saving a bookmark does not work ??? I did checkout on the cvs at the new address and the build 02-02-03 @ 11:10pm EST (-5 hrs). -- Patrick Shanahan http://wahoo.no-ip.org Registered Linux User #207535 icq#173753138 @ http://counter.li.org

Feb. 4, 2003

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

by Jorge Arellano Cid

Micah, > > 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. I'll fix that. > 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. Is just a matter of 's/--backups=t/-b/' ? As I'm not an expert on this area, I'd appreciate a patch! > The socket test gives 'Permission denied' like it should. Good! OpenBSD and NetBSD are OK, I only need a FreeBSD test now! > Thanks for all your work! You're welcome Cheers Jorge.-

Feb. 4, 2003

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