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:
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?
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:
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?)
"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 Wed, Sep 24, 2008 at 06:09:44AM +0000, corvid wrote:
bf wrote:
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?)
"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.
Committed. -- Cheers Jorge.-
On Tue, Sep 23, 2008 at 07:52:07AM +0200, Andreas Kemnade wrote:
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?
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
* Jeremy Henty <onepoint@starurchin.org> [080923 15:57]:
On Tue, Sep 23, 2008 at 07:52:07AM +0200, Andreas Kemnade wrote:
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).
Sorry for this interruption but what is the reason dw exists? I never understood that. Thanks for your time, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)
On Tue, Sep 23, 2008 at 04:15:01PM +0200, Christian Kellermann wrote:
* Jeremy Henty <onepoint@starurchin.org> [080923 15:57]:
On Tue, Sep 23, 2008 at 07:52:07AM +0200, Andreas Kemnade wrote:
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).
Sorry for this interruption but what is the reason dw exists? I never understood that.
Dw2 can also be used for other projects. Sometime ago, having independent trees allowed Sebastian and me to work comfortably. but now, AFAIS, dw2 fits better inside dillo2's tree. -- Cheers Jorge.-
On Tue, Sep 23, 2008 at 02:54:10PM +0100, Jeremy Henty wrote:
On Tue, Sep 23, 2008 at 07:52:07AM +0200, Andreas Kemnade wrote:
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?
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?
I'd move dw2 inside dillo2's tree (as it was before), and have a recommended FLTK2 tarball in our site. Please somebody send me a patch with this code move. That way I can focus on Tabs... -- Cheers Jorge.-
Jorge wrote:
On Tue, Sep 23, 2008 at 02:54:10PM +0100, Jeremy Henty wrote:
On Tue, Sep 23, 2008 at 07:52:07AM +0200, Andreas Kemnade wrote:
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?
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?
I'd move dw2 inside dillo2's tree (as it was before), and have a recommended FLTK2 tarball in our site.
Please somebody send me a patch with this code move. That way I can focus on Tabs...
I will.
On Tue, Sep 23, 2008 at 07:11:03PM -0400, Jorge Arellano Cid wrote:
On Tue, Sep 23, 2008 at 02:54:10PM +0100, Jeremy Henty wrote:
On Tue, Sep 23, 2008 at 07:52:07AM +0200, Andreas Kemnade wrote:
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?
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?
I'd move dw2 inside dillo2's tree (as it was before), and have a recommended FLTK2 tarball in our site.
That sounds good! Cheers, Johannes
On Wed, Sep 24, 2008 at 05:44:51PM +0200, Johannes Hofmann wrote:
On Tue, Sep 23, 2008 at 07:11:03PM -0400, Jorge Arellano Cid wrote:
On Tue, Sep 23, 2008 at 02:54:10PM +0100, Jeremy Henty wrote:
On Tue, Sep 23, 2008 at 07:52:07AM +0200, Andreas Kemnade wrote:
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?
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?
I'd move dw2 inside dillo2's tree (as it was before), and have a recommended FLTK2 tarball in our site.
That sounds good!
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.-
On Wed, Sep 24, 2008 at 02:16:22PM -0400, Jorge Arellano Cid wrote:
On Wed, Sep 24, 2008 at 05:44:51PM +0200, Johannes Hofmann wrote:
On Tue, Sep 23, 2008 at 07:11:03PM -0400, Jorge Arellano Cid wrote:
On Tue, Sep 23, 2008 at 02:54:10PM +0100, Jeremy Henty wrote:
On Tue, Sep 23, 2008 at 07:52:07AM +0200, Andreas Kemnade wrote:
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?
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?
I'd move dw2 inside dillo2's tree (as it was before), and have a recommended FLTK2 tarball in our site.
That sounds good!
OK, dw2 is now inside the dillo2 tree.
CVS updated and also the directions in cvs.html.
Please check and test.
Yes, it works fine! Cheers, Johannes
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