Hi, I have a question about release packaging: Currently you need to download three tarballs to compile dillo (fltk,dw,dillo). I doubt that any linux distribution has fltk2 packages at the moment. (and also not openembedded) What's the plan about that? Make one big tarball of everything (with some selected fltk snapshot) or do you expect the distributions to include a fltk2 package as soon as they see dillo-fltk? The question came to during thinking how to make bitbake files for openembedded. Regards, ndreas Kemnade
--- On Tue, 9/23/08, Andreas Kemnade <akemnade@tzi.de> wrote:
fltk2 has been in both FreeBSD Ports: http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11-toolkits/fltk2/ (but unfortunately you won't be able to view that with dillo2: "HTTP warning: Content-Type 'text/html' doesn't match the real data." -- fixes?) and NetBSD pkgsrc: http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/x11/fltk2/README.html for some time. I don't see it in Debian's package system or Gentoo portage at the moment, although I'm sure that they, and the other large packaging systems, would add it if asked. I'd prefer to see a separate, smaller tarball containing just dw2 and dillo2, unless fltk2 begins changing more rapidly than the other components, and repeatedly breaks builds or causes the browser to malfunction, in which case it would make sense to bundle a fltk2 snapshot that is known to work with dillo. Regards, b.
bf wrote:
"gzip" has been registered with the IANA since...since trilobites stalked the seas, and I explicitly said "gzip" for Accept-Encoding, not "x-gzip", but rfc2616 does state: For compatibility with previous implementations of HTTP, applications SHOULD consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively.
On Tue, Sep 23, 2008 at 07:52:07AM +0200, Andreas Kemnade wrote:
FLTK2's API is still not frozen, and its ABI does change quite often so we will have to supply the tarball ourselves. It would be simplest just to keep a copy of the right FLTK2 snapshot on the dillo site under a link saying "use *this* version". The problem is not that distros won't supply packages, the problem is that they *will* and it might be the wrong version. (Expect "I upgraded FLTK2 and Dillo crashed" reports!) The dw package is an awkward case. I think we should bite the bullet and either move it inside dillo2 or make it an independent package that the user installs and have dillo2 find and use the installed dw (and lose the dw-testbed symbolic link). Thoughts? Regards, Jeremy Henty
On Wed, Sep 24, 2008 at 05:44:51PM +0200, Johannes Hofmann wrote:
OK, dw2 is now inside the dillo2 tree. CVS updated and also the directions in cvs.html. Please check and test. If it works you can get rid of the old dw2, dw2-cur directories and the dw-testbed symbolic link. (It worked here). -- Cheers Jorge.-
participants (7)
-
akemnade＠tzi.de -
bf2006a＠yahoo.com -
Christian.Kellermann＠nefkom.net -
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
onepoint＠starurchin.org