- Dillo-dev - lists.mailman3.com

Dillo Packages

by kelson＠pobox.com

Jorge Arellano Cid wrote: > I'd like to have packages for Debian and some RPMs. > Kelson already committed himself with the RPMs, and although > I can make i32 and i64 Debian packages, I'm a newbie on it. Here's the status on the RPMs. I've built the following: Fedora 9, x86_64 RHEL 3, x86 RHEL 4, x86 and x86_64 RHEL 5, x86 and x86_64 Unfortunately I don't have access to any 32-bit Fedora boxes right now, but I should be able to build it with mock if I can figure out how to convince it to install the fltk package I've built. My old build system is in storage (way in the back, under a bunch of boxes, so not easy to get at), so it will be a while before I can build/test on any other distributions. If anyone here has a 32-bit Fedora 9 box and would like to contribute an RPM, or another RPM-based distribution (SuSE, Mandriva, etc.), here are the source RPMs I'm using. http://www.hyperborea.org/software/dillo/rpms/fltk2-2.0.x.r6403-0.1.src.rpm http://www.hyperborea.org/software/dillo/rpms/dillo-2.0-1.src.rpm Directions for building the Dillo RPM: 1. Ideally, set up an RPM build tree in your home directory so you can build as yourself and not as root. (I think directions are up at rpm.org) 2. Build the fltk RPM: rpmbuild --rebuild fltk2-2.0.x.r6403-0.1.src.rpm 3. Install the fltk RPM (as root, or sudo) rpm -ivh /path/to/rpm/file 4. Build the dillo RPM: rpmbuild --rebuild dillo-2.0-1.src.rpm 5. Install the dillo RPM: rpm -ivh /path/to/rpm/file Possible issues with these SRPMS; - I don't have all the build dependencies set properly. - Distro-specific code on the Dillo SRPM may be out of date. - If you already have FLTK2 installed, you can skip the FLTK RPM and add --nodeps to the commandline in step 4. -- Kelson Vibber Hyperborea.org - SpeedForce.org - AlternativeBrowserAlliance.com

Oct. 13, 2008

Dillo Packages

by jcid＠dillo.org

On Mon, Oct 13, 2008 at 11:09:25PM +0200, Andreas Kemnade wrote: > Hi, > > On Mon, 13 Oct 2008 15:27:19 -0300 > Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > Hi, > > > > I'd like to have packages for Debian and some RPMs. > > Kelson already committed himself with the RPMs, and although > > I can make i32 and i64 Debian packages, I'm a newbie on it. > > > I played a bit with the deb stuff and created a .deb for debian testing. > I have put a .deb file in http://misc.andi.de1.cc/dillo > I installed the correct fltk snapshot before using the usual ./configure && make && make install, > and built the .deb after that. This handling of the fltk dependancy is > not very clean... I guess the cleaner one would be to have > fltk2 packages, but as fltk2 is linked statically against dillo, > at least the .deb package should work. > I basically took the old .diff.gz for dillo 0.8.6 from deb-lenny and deleted the i18n stuff. Great Andreas. I added the link to that page. Would you mind packing it with "make install-strip"? -- Cheers Jorge.-

Oct. 13, 2008

Dillo Packages

by akemnade＠tzi.de

Hi, On Mon, 13 Oct 2008 15:27:19 -0300 Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Hi, > > I'd like to have packages for Debian and some RPMs. > Kelson already committed himself with the RPMs, and although > I can make i32 and i64 Debian packages, I'm a newbie on it. > I played a bit with the deb stuff and created a .deb for debian testing. I have put a .deb file in http://misc.andi.de1.cc/dillo I installed the correct fltk snapshot before using the usual ./configure && make && make install, and built the .deb after that. This handling of the fltk dependancy is not very clean... I guess the cleaner one would be to have fltk2 packages, but as fltk2 is linked statically against dillo, at least the .deb package should work. I basically took the old .diff.gz for dillo 0.8.6 from deb-lenny and deleted the i18n stuff. Greetings Andreas Kemnade

Oct. 13, 2008

Altavista search does not work

by francis＠daoine.org

On Mon, Oct 13, 2008 at 05:06:23PM +0000, corvid wrote: > Francis wrote: > > On Fri, Oct 10, 2008 at 12:43:59PM +0000, corvid wrote: > > > Christopher wrote: > > > > Doing web searches using www.altavista.com does not work. It is as > > > > if the search terms are not submitted. > > > > Searching for "Images", "MP3/Audio", or "Video" instead of "Web" > > > > or "News" works well. > > It's a problem with altavista, in that their HTML is invalid, and > > therefore they rely on browser-fixups to get the result they probably > > wanted. > > > > It's a problem with dillo, in that the submit button (presumably) works > > for most other browsers. > > > > More specifically, the main difference between the (working) images page > > and the (failing) web page is the presence of an explicit close-table-cell > > </td> tag. > > > > If you remove the </td> on line 68 of the altavista index.html page, > > then the submit button works. > > > > So presumably dillo is handling "explicit </td> before <td>" differently > > from "no </td> immediately before <td>", at least in this case. > > I think dillo sees <td> ... <form> ... </td> > and closes the form, which seems like the right behavior. Yes; it is "a" right behaviour. Because the markup is incorrect, pretty much anything dillo does is right. But what dillo does, is it sees <table><tr><td><form><input></td><td> and (correctly) closes the form when it sees "</td>". And on the "images" search page, dillo sees the (I think) exactly equivalent <table><tr><td><form><input><tr> and (also correctly) does not close the form when it sees "<tr>" which implies "</td>" and "</tr>". That was the difference I was trying to point out. The html is broken in each case. Dillo's handling of it is valid in each case. But the second example results in "friendlier" response to the user (in this case. Under other circumstances, showing the brokenness may be "friendlier"). f -- Francis Daly francis(a)daoine.org

Oct. 13, 2008

Dillo Packages

by jcid＠dillo.org

Hi, I'd like to have packages for Debian and some RPMs. Kelson already committed himself with the RPMs, and although I can make i32 and i64 Debian packages, I'm a newbie on it. Volunteers? -- Cheers Jorge.-

Oct. 13, 2008

Altavista search does not work

by jcid＠dillo.org

On Mon, Oct 13, 2008 at 05:41:20PM +0100, Francis Daly wrote: > On Fri, Oct 10, 2008 at 12:43:59PM +0000, corvid wrote: > > Christopher wrote: > > Hi there, > > > > Doing web searches using www.altavista.com does not work. It is as > > > if the search terms are not submitted. The following HTML errors > > > are detected: > > > > > > HTML warning: line 2, the required DOCTYPE declaration is missing (or invalid) > > > HTML warning: line 68, - forcing close of open tag: <form> > > > HTML warning: line 68, FORM lacks a Submit button > > > HTML warning: line 94, unexpected closing tag: </form>. -- expected </table> > > > > > > Searching for "Images", "MP3/Audio", or "Video" instead of "Web" > > > or "News" works well. > > > > > > Is this a problem with altavista rather than with dillo? > > > > It looks like altavista just threw together their form and table tags > > rather than nesting them. > > It's a problem with altavista, in that their HTML is invalid, and > therefore they rely on browser-fixups to get the result they probably > wanted. Yes. Both validators WDG and W3C (bug meter's right-click menu), explain this bug. In simple terms, the form declaration should be outside the table. Otherwise, following HTML rules, the form is closed. -- Cheers Jorge.-

Oct. 13, 2008

Altavista search does not work

by corvid＠lavabit.com

Francis wrote: > On Fri, Oct 10, 2008 at 12:43:59PM +0000, corvid wrote: > > Christopher wrote: > > Hi there, > > > > Doing web searches using www.altavista.com does not work. It is as > > > if the search terms are not submitted. The following HTML errors > > > are detected: > > > > > > HTML warning: line 2, the required DOCTYPE declaration is missing (or invalid) > > > HTML warning: line 68, - forcing close of open tag: <form> > > > HTML warning: line 68, FORM lacks a Submit button > > > HTML warning: line 94, unexpected closing tag: </form>. -- expected </table> > > > > > > Searching for "Images", "MP3/Audio", or "Video" instead of "Web" > > > or "News" works well. > > > > > > Is this a problem with altavista rather than with dillo? > > > > It looks like altavista just threw together their form and table tags > > rather than nesting them. > > It's a problem with altavista, in that their HTML is invalid, and > therefore they rely on browser-fixups to get the result they probably > wanted. > > It's a problem with dillo, in that the submit button (presumably) works > for most other browsers. > > More specifically, the main difference between the (working) images page > and the (failing) web page is the presence of an explicit close-table-cell > </td> tag. > > If you remove the </td> on line 68 of the altavista index.html page, > then the submit button works. > > So presumably dillo is handling "explicit </td> before <td>" differently > from "no </td> immediately before <td>", at least in this case. I think dillo sees <td> ... <form> ... </td> and closes the form, which seems like the right behavior. > (dillo1 acts the same, except it doesn't show the input field or the > search button at all in the first case.) > > It doesn't look like a significant v1-v2 regression to me, apart from > the fact that it now looks like it might submit something.

Oct. 13, 2008

Altavista search does not work

by francis＠daoine.org

On Fri, Oct 10, 2008 at 12:43:59PM +0000, corvid wrote: > Christopher wrote: Hi there, > > Doing web searches using www.altavista.com does not work. It is as > > if the search terms are not submitted. The following HTML errors > > are detected: > > > > HTML warning: line 2, the required DOCTYPE declaration is missing (or invalid) > > HTML warning: line 68, - forcing close of open tag: <form> > > HTML warning: line 68, FORM lacks a Submit button > > HTML warning: line 94, unexpected closing tag: </form>. -- expected </table> > > > > Searching for "Images", "MP3/Audio", or "Video" instead of "Web" > > or "News" works well. > > > > Is this a problem with altavista rather than with dillo? > > It looks like altavista just threw together their form and table tags > rather than nesting them. It's a problem with altavista, in that their HTML is invalid, and therefore they rely on browser-fixups to get the result they probably wanted. It's a problem with dillo, in that the submit button (presumably) works for most other browsers. More specifically, the main difference between the (working) images page and the (failing) web page is the presence of an explicit close-table-cell </td> tag. If you remove the </td> on line 68 of the altavista index.html page, then the submit button works. So presumably dillo is handling "explicit </td> before <td>" differently from "no </td> immediately before <td>", at least in this case. (dillo1 acts the same, except it doesn't show the input field or the search button at all in the first case.) It doesn't look like a significant v1-v2 regression to me, apart from the fact that it now looks like it might submit something. f -- Francis Daly francis(a)daoine.org

Oct. 13, 2008

aclocal.m4 and autom4te.cache in CVS

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeremy Henty wrote: > Yes you're right, they're not in CVS/Entries . I've started managing > my dillo development by tracking the CVS checkout in one git > repository (the "remote") and developing in a cloned repository (the > "local"). So the remote repository should stay pristine, but it > didn't. Looks like I screwed up and ran autogen.sh in the remote at > some point. Apologies for the noise. > > BTW, is anyone else using git like this? I thought I saw some patches > on the list that looked git-generated. I am using bzr with a similar setup. Justus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjzaCIACgkQoPmwNWhsaZYENgCfSNnEZutmw0RoUbS7u4W+6r1P 8woAnjIPqNcBtZ5tAIY3jm4wW6mRa17p =LtQk -----END PGP SIGNATURE-----

Oct. 13, 2008

dillo-2.0 rc1 is in CVS

by jcid＠dillo.org

On Mon, Oct 13, 2008 at 06:45:23AM -0700, bf wrote: > The message about re-enabling https support (on line 667) in revision 1.3 of > dpi/https.c should refer to line 72, not line 65. Changed. > Ironically, > > http://cvs.auriga.wearlab.de/cgi-bin/cvsweb.cgi/~checkout~/dillo/dillo2/dpi… > > fails with "Error: Unsupported content type: text/x-c++src". Maybe some > of dillo's type-checking needs to be revisited. Also problematic are some > other kinds of text files. Please post some other URLs. To be reviewed in the release after this one... -- Cheers Jorge.-

Oct. 13, 2008