June 2009 - Dillo-dev - lists.mailman3.com

dillo-2.1.tar.bz2

by jcid＠dillo.org

Hi, Working on: 1.- Solve the OpenSSL license issue and upload rc3. On Thu, Jun 18, 2009 at 05:24:25PM +0200, Devid Antonio Filoni wrote: > On Wed, Jun 17, 2009 at 11:45 PM, Jorge Arellano Cid<jcid(a)dillo.org> wrote: > > On Wed, Jun 17, 2009 at 10:01:12PM +0200, Devid Antonio Filoni wrote: > > [...] > > ?Devid: please send me the .deb and its directions when done. > DONE! You can find it at https://launchpad.net/~d.filoni/+archive/ppa > . However I found an error checking my package using lintian: > > E: dillo: possible-gpl-code-linked-with-openssl > N: > N: This package appears to be covered by the GNU GPL but depends on the > N: OpenSSL libssl package and does not mention a license exemption or > N: exception for OpenSSL in its copyright file. The GPL (including version > N: 3) is incompatible with some terms of the OpenSSL license, and therefore > N: Debian does not allow GPL-licensed code linked with OpenSSL libraries > N: unless there is a license exception explicitly permitting this. > N: > N: If only the Debian packaging, or some other part of the package not > N: linked with OpenSSL, is covered by the GNU GPL, please add a lintian > N: override for this tag. Lintian currently has no good way of > N: distinguishing between that case and problematic packages. > N: > N: Severity: serious, Certainty: wild-guess > > Can you please fix it? AFAIS, the only program that links to OpenSSL is the https dpi. i.e. The ssl-enabled dillo binary doesn't link to it. https.filter.dpi links to it. IANAL, but it looks like giving permission for this dpi is enough, and it's already done in its sources (dpi/https.c): * [...] * As a special exception permission is granted to link the code of * the https dillo plugin with the OpenSSL project's "OpenSSL" * library, and distribute the linked executables, without including * the source code for OpenSSL in the source distribution. You must * obey the GNU General Public License, version 3, in all respects * for all of the code used other than "OpenSSL". * */ Please let me know if this is _really_ enough or if some extra legal formula must be added somewhere else. TIA. -- Cheers Jorge.-

June 18, 2009

dillo-2.1.tar.bz2

by jcid＠dillo.org

On Thu, Jun 18, 2009 at 05:24:25PM +0200, Devid Antonio Filoni wrote: > On Wed, Jun 17, 2009 at 11:45 PM, Jorge Arellano Cid<jcid(a)dillo.org> wrote: > > [...] > > ?BTW, the rc2 version of dillo-2.1 (hopefully final) was > > just uploaded to http://www.dillo.org/download/ so packagers > > can make the respective files. > > > > ?The idea is to make the announcement tomorrow in the morning. > > > > ?Devid: please send me the .deb and its directions when done. > DONE! You can find it at https://launchpad.net/~d.filoni/+archive/ppa > . However I found an error checking my package using lintian: > > E: dillo: possible-gpl-code-linked-with-openssl > N: > N: This package appears to be covered by the GNU GPL but depends on the > N: OpenSSL libssl package and does not mention a license exemption or > N: exception for OpenSSL in its copyright file. The GPL (including version > N: 3) is incompatible with some terms of the OpenSSL license, and therefore > N: Debian does not allow GPL-licensed code linked with OpenSSL libraries > N: unless there is a license exception explicitly permitting this. > N: > N: If only the Debian packaging, or some other part of the package not > N: linked with OpenSSL, is covered by the GNU GPL, please add a lintian > N: override for this tag. Lintian currently has no good way of > N: distinguishing between that case and problematic packages. > N: > N: Severity: serious, Certainty: wild-guess > > Can you please fix it? OK guys, don't hurry! ---------------------------------------------------- Let's make the announcement early this Saturday 20. ---------------------------------------------------- That way we have until tomorrow to sort out the packaging problem and this license issue. I'd proceed in this order: 1.- Solve the OpenSSL license issue and upload rc3. 2.- To enable-ssl or not enable-ssl (define what to do). 3.- Get to the less painful package-system for the user given the current situation. (most probably distribution repositories) 4.- Future planning: how to get dillo2 into distros to enlarge its user base. FLTK2 vs FLTK-1.3 * I have plenty of info here, but will hold on until the previous points are done. Thanks for all the help. -- Cheers Jorge.-

June 18, 2009

dillo-2.1.tar.bz2

by corvid＠lavabit.com

Kelson wrote: > http://www.hyperborea.org/software/dillo/rpms/fltk2-2.0.x.r6403-0.2.src.rpm We should use >= 6525

June 18, 2009

dillo-2.1.tar.bz2

by kelson＠pobox.com

On Jun 17, 2009, at 7:54 PM, Jorge Arellano Cid wrote: > Well in that case, I assume that no SSL as default is OK. So...no SSL for the official packages? I'll redo them. On that front, I haven't been able to get a Fedora 10 x86 LiveCD setup to install all the build requirements - it keeps crashing with I/O errors. I've been trying to set up a USB stick system, but it's the first time I've tried it and things don't seem to be working right. I've got the folowing: Fedora 10 x86_64 RHEL 3 i386 RHEL 4 x86_64 RHEL 5 i386 RHEL 5 x86_64 If anyone wants to try to build a matching RPM on Fedora 10 i686, here's the URLs to the sources... http://www.hyperborea.org/software/dillo/rpms/dillo-2.1-2.src.rpm (-3 once I turn SSL off again) http://www.hyperborea.org/software/dillo/rpms/fltk2-2.0.x.r6403-0.2.src.rpm And here's the list of build requirements I've found so far that aren't on the LiveCD yum install rpm-build openssl-devel gcc make automake automake17 automake16 automake15 libjpeg-devel libpng-devel zlib-devel xorg-x11- proto-devel libXft-devel libSM-devel libICE-devel libXt-devel libX11- devel libXi-devel libXinerama-devel libGL-devel libGLU-devel libXext- devel gcc-c++

June 18, 2009

dillo-2.1.tar.bz2

by corvid＠lavabit.com

Michal wrote: > I understand that my proposal won't be popular but switching from > FLTK2 is necessary - we hardly have FLTK2 in distributions (read: no > Dillo-2 in distribution) and that's shortening our user base. > > How hard it would be to rewrite/port Dillo-2 to FLTK-1.3? > > (I see that the speed of v1.3 development is nothing exciting, but > from what I read months ago they at least plan to have a release > ever.) > > While looking at the devel cycle of Dillo - two releases per year - > I believe this porting should be mid-term goal. Unless we wanna > spend another year out of mainstream distributions. (And frankly: > even with Dillo-2 based on FLTK-1.3 we are quite far from Dillo-2 > in distribution...) It seems to be the consensus that going to 1.3 will happen eventually. They still have some work on UTF-8 to do first: http://svn.easysw.com/public/fltk/fltk/branches/branch-1.3/TODO.utf8 Out of curiosity, I once made a dillo that compiled with 1.3. It failed to work at all because I don't know the fltk and dw code well enough in general, but I was satisfied with getting an idea of how much there was to it. - We would have to get Johannes to do dw/fltkview*. - Fonts are a bit different. I didn't dig into that. - Menus are a bit different. Didn't dig into that either. - The PackedGroup for the UI behaved differently. I fought with it for a little while, then grew impatient. The rest was mostly changing a whole lot of fltk::something to Fl_something.

June 18, 2009

dillo-2.1.tar.bz2

by newman.x＠gmail.com

On Thu, Jun 18, 2009 at 12:00 AM, Jorge Arellano Cid<jcid(a)dillo.org> wrote: > On Wed, Jun 17, 2009 at 05:45:02PM -0400, Jorge Arellano Cid wrote: >> On Wed, Jun 17, 2009 at 10:01:12PM +0200, Devid Antonio Filoni wrote: >> > On Wed, Jun 17, 2009 at 9:02 PM, Jorge Arellano Cid<jcid(a)dillo.org> wrote: >> > > Hi Michal, >> > > >> > > On Wed, Jun 17, 2009 at 03:11:44PM +0200, Michal Nowak wrote: >> > >> On Tue, Jun 16, 2009 at 11:46 PM, Kelson Vibber<kelson(a)pobox.com> wrote: >> > >> > Michal Nowak wrote: >> > >> >> >> > >> >> I'd like to create Fedora RPM's (since I am Fedora packager), the >> > >> >> problem is that fltk2 is not in Fedora (Package Review's pending [1], >> > >> >> help welcomed), so, only unofficial packages are doable now. >> > >> >> >> > >> >> Problem with Fedora 11 is that fltk2 can't be built with recent g++ [2]. I >> > >> >> might check with with F-10, it used to work. >> > >> > >> > >> > I've just built FLTK2 r6786 and Dillo 2.1 on a Fedora 10 system, so it does >> > >> > work there. >> > > >> > > ?It's ?good ?to ?see ?you're ?already ?coordinating with Kelson, >> > > because that's exactly what I was to suggest. >> > > >> > > >> > >> In http://fltk.org/str.php?L2205 I was suggested to make a code change in >> > >> FLTK2, I did so and it compiles fine now. I am not sure of the root cause >> > >> because fltk guys suggested that the problem is glibc-2.10 and pointed to >> > >> patch but the patch looks to be incorporated in F-11 glibc. >> > > >> > > ?FLTK2 is giving some confusion even to FLTK developers: >> > > http://fltk.org/newsgroups.php?s6818+gfltk.development+T1 >> > > ("pre-release thread"). >> > > >> > > ?In a nutshell (from my point of view): >> > > >> > > ? * fltk2 is not officially released, and maybe never will. >> > > ? * dillo2 uses fltk2, and this creates pressure to package it. >> > > ? * Distros have a policy against statically-linked binaries. >> > > ? * We can provide unofficial statically-linked packages until >> > > ? ? the distro provides a shared fltk2 lib. >> > > >> > > ?So, I'd suggest to package a statically-linked binary until the >> > > shared ?fltk2 ?is ?available from the distro. Once this happen we >> > > can provide a dynamic one. >> > > >> > > ?This ?avoids ?having to sort out the patching/adjusting problem >> > > of packaging a shared library, which is best solved by the distro >> > > itself. >> > > >> > > ?Now, ?it looks like you are the Fedora distro developer working >> > > on ?both ?fltk2 ?and ?dillo2, ?so in this case you can decide and >> > > suggest what looks best from your point of view. >> > > >> > > ?From ?a user perspective, it looks simpler to download a single >> > > binary ?and ?install it. If the shared way is decided, we need to >> > > provide nutshell directions. >> > > >> > > ?In ?the ?Debian ?case, I assume a statically linked deb will be >> > > produced (until the license problem is solved). >> > Yes, I preparated an FLTK2 Debian package and it is built as static >> > lib but this should be avoided if possible, the problem is that fltk2 >> > isn't stable enough so ATM it is static... The Debian license is the >> > issue that doesn't allow me to upload the fltk2 ?(and also dillo2) >> > package in Debian, there is an open bug about this >> > (http://www.fltk.org/str.php?L2198+P0+S-2+C0+I0+E0+Qlicense) >> >> ? OK. >> >> ? BTW, the rc2 version of dillo-2.1 (hopefully final) was >> just uploaded to http://www.dillo.org/download/ so packagers >> can make the respective files. >> >> ? The idea is to make the announcement tomorrow in the morning. >> >> ? Devid: please send me the .deb and its directions when done. >> >> ? Same for rpm. > > ?Last but not the least. > > ?I use "./configure --enable-ssl" bacause that way dillo is much > more ?useful (mainly for reading forums and bug trackers). So I'd > suggest ?to ?make ?the packages with SSL enabled, unless somebody > reembers a compelling reason not to do so. > > ?There're ?times ?when ?the ?certificate asking dialog bombs the > user, ?but maybe not so often, or annoyingly enough, to avoid the > SSL dpi. > > ?Comments? > Generally speaking for Fedora, we won't turn on options which are not turned on by default in upstream - it usually brings divergence from upstream and comments in upstream mailing lists (not this one :) ) like: "That poor distroX turned on --enable-coolness so we are not supporting users of this distro at all." Turning on SSL in upstream means more pressure for fixing it, usually :). But I am reading dillo-dev long enough to know it's not that easy. > > -- > ?Cheers > ?Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

June 18, 2009

dillo-2.1.tar.bz2

by newman.x＠gmail.com

On Wed, Jun 17, 2009 at 9:02 PM, Jorge Arellano Cid<jcid(a)dillo.org> wrote: > Hi Michal, Hola Jorge, > > On Wed, Jun 17, 2009 at 03:11:44PM +0200, Michal Nowak wrote: >> On Tue, Jun 16, 2009 at 11:46 PM, Kelson Vibber<kelson(a)pobox.com> wrote: >> > Michal Nowak wrote: >> >> >> >> I'd like to create Fedora RPM's (since I am Fedora packager), the >> >> problem is that fltk2 is not in Fedora (Package Review's pending [1], >> >> help welcomed), so, only unofficial packages are doable now. >> >> >> >> Problem with Fedora 11 is that fltk2 can't be built with recent g++ [2]. I >> >> might check with with F-10, it used to work. >> > >> > I've just built FLTK2 r6786 and Dillo 2.1 on a Fedora 10 system, so it does >> > work there. > > ?It's ?good ?to ?see ?you're ?already ?coordinating with Kelson, > because that's exactly what I was to suggest. > > >> In http://fltk.org/str.php?L2205 I was suggested to make a code change in >> FLTK2, I did so and it compiles fine now. I am not sure of the root cause >> because fltk guys suggested that the problem is glibc-2.10 and pointed to >> patch but the patch looks to be incorporated in F-11 glibc. > > ?FLTK2 is giving some confusion even to FLTK developers: > http://fltk.org/newsgroups.php?s6818+gfltk.development+T1 > ("pre-release thread"). Yes. While I did not read the license yet, if Debian feels the fltk2 one is problematic, Fedora legal will feel probably the same (aka blocker). > > ?In a nutshell (from my point of view): > > ? * fltk2 is not officially released, and maybe never will. > ? * dillo2 uses fltk2, and this creates pressure to package it. > ? * Distros have a policy against statically-linked binaries. Definitely agree. The first and the second one can be somehow sorted out and fltk2 pushed to distribution, the last one is blocker. > ? * We can provide unofficial statically-linked packages until > ? ? the distro provides a shared fltk2 lib. > That's of course possible and doable but pita anyway. We can't ever make package for every distro out there, that's obvious. > ?So, I'd suggest to package a statically-linked binary until the > shared ?fltk2 ?is ?available from the distro. Once this happen we > can provide a dynamic one. > I can do F-11 builds if needed. > ?This ?avoids ?having to sort out the patching/adjusting problem > of packaging a shared library, which is best solved by the distro > itself. > > ?Now, ?it looks like you are the Fedora distro developer working > on ?both ?fltk2 ?and ?dillo2, ?so in this case you can decide and > suggest what looks best from your point of view. > I'm behind fltk2 in Fedora, Dillo is maintained by someone else but is prepared for bump to Dillo-2 (there's bugzilla for this) when is fltk2 in place... > ?From ?a user perspective, it looks simpler to download a single > binary ?and ?install it. If the shared way is decided, we need to > provide nutshell directions. I believe the simplest way for user how to get distro conforming packages is via distribution repositories (+ receives security, in-between-release problems solving, not necessary to check third party websites, etc). You greatly outlined the problems with having Dillo-2 in distribution; the problem is FLTK2. While watching at "changes" in FLTK2 snapshots I can't thing that the development is stalled or even stopped. I understand that my proposal won't be popular but switching from FLTK2 is necessary - we hardly have FLTK2 in distributions (read: no Dillo-2 in distribution) and that's shortening our user base. How hard it would be to rewrite/port Dillo-2 to FLTK-1.3? (I see that the speed of v1.3 development is nothing exciting, but from what I read months ago they at least plan to have a release ever.) While looking at the devel cycle of Dillo - two releases per year - I believe this porting should be mid-term goal. Unless we wanna spend another year out of mainstream distributions. (And frankly: even with Dillo-2 based on FLTK-1.3 we are quite far from Dillo-2 in distribution...) > > ?In ?the ?Debian ?case, I assume a statically linked deb will be > produced (until the license problem is solved). > > ?Comments? > > -- > ?Cheers > ?Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

June 18, 2009

dillo-2.1.tar.bz2

by jcid＠dillo.org

On Wed, Jun 17, 2009 at 11:09:16PM +0000, corvid wrote: > Jorge wrote: > > I use "./configure --enable-ssl" bacause that way dillo is much > > more useful (mainly for reading forums and bug trackers). So I'd > > suggest to make the packages with SSL enabled, unless somebody > > reembers a compelling reason not to do so. > > > > There're times when the certificate asking dialog bombs the > > user, but maybe not so often, or annoyingly enough, to avoid the > > SSL dpi. > > > > Comments? > > iirc it stops giving you those messages if the dpi can find > a directory containing certificates, in which case the fact > that we don't check (I don't think we do, anyway) that the > server is presenting _its_ certificate is a problem. *Sigh* Well in that case, I assume that no SSL as default is OK. OTOH packagers may provide an enabled version with the warning that no certificates are being checked. -- Cheers Jorge.-

June 18, 2009

dillo-2.1.tar.bz2

by corvid＠lavabit.com

Jorge wrote: > I use "./configure --enable-ssl" bacause that way dillo is much > more useful (mainly for reading forums and bug trackers). So I'd > suggest to make the packages with SSL enabled, unless somebody > reembers a compelling reason not to do so. > > There're times when the certificate asking dialog bombs the > user, but maybe not so often, or annoyingly enough, to avoid the > SSL dpi. > > Comments? iirc it stops giving you those messages if the dpi can find a directory containing certificates, in which case the fact that we don't check (I don't think we do, anyway) that the server is presenting _its_ certificate is a problem.

June 18, 2009

dillo-2.1.tar.bz2

by jcid＠dillo.org

On Wed, Jun 17, 2009 at 05:45:02PM -0400, Jorge Arellano Cid wrote: > On Wed, Jun 17, 2009 at 10:01:12PM +0200, Devid Antonio Filoni wrote: > > On Wed, Jun 17, 2009 at 9:02 PM, Jorge Arellano Cid<jcid(a)dillo.org> wrote: > > > Hi Michal, > > > > > > On Wed, Jun 17, 2009 at 03:11:44PM +0200, Michal Nowak wrote: > > >> On Tue, Jun 16, 2009 at 11:46 PM, Kelson Vibber<kelson(a)pobox.com> wrote: > > >> > Michal Nowak wrote: > > >> >> > > >> >> I'd like to create Fedora RPM's (since I am Fedora packager), the > > >> >> problem is that fltk2 is not in Fedora (Package Review's pending [1], > > >> >> help welcomed), so, only unofficial packages are doable now. > > >> >> > > >> >> Problem with Fedora 11 is that fltk2 can't be built with recent g++ [2]. I > > >> >> might check with with F-10, it used to work. > > >> > > > >> > I've just built FLTK2 r6786 and Dillo 2.1 on a Fedora 10 system, so it does > > >> > work there. > > > > > > ?It's ?good ?to ?see ?you're ?already ?coordinating with Kelson, > > > because that's exactly what I was to suggest. > > > > > > > > >> In http://fltk.org/str.php?L2205 I was suggested to make a code change in > > >> FLTK2, I did so and it compiles fine now. I am not sure of the root cause > > >> because fltk guys suggested that the problem is glibc-2.10 and pointed to > > >> patch but the patch looks to be incorporated in F-11 glibc. > > > > > > ?FLTK2 is giving some confusion even to FLTK developers: > > > http://fltk.org/newsgroups.php?s6818+gfltk.development+T1 > > > ("pre-release thread"). > > > > > > ?In a nutshell (from my point of view): > > > > > > ? * fltk2 is not officially released, and maybe never will. > > > ? * dillo2 uses fltk2, and this creates pressure to package it. > > > ? * Distros have a policy against statically-linked binaries. > > > ? * We can provide unofficial statically-linked packages until > > > ? ? the distro provides a shared fltk2 lib. > > > > > > ?So, I'd suggest to package a statically-linked binary until the > > > shared ?fltk2 ?is ?available from the distro. Once this happen we > > > can provide a dynamic one. > > > > > > ?This ?avoids ?having to sort out the patching/adjusting problem > > > of packaging a shared library, which is best solved by the distro > > > itself. > > > > > > ?Now, ?it looks like you are the Fedora distro developer working > > > on ?both ?fltk2 ?and ?dillo2, ?so in this case you can decide and > > > suggest what looks best from your point of view. > > > > > > ?From ?a user perspective, it looks simpler to download a single > > > binary ?and ?install it. If the shared way is decided, we need to > > > provide nutshell directions. > > > > > > ?In ?the ?Debian ?case, I assume a statically linked deb will be > > > produced (until the license problem is solved). > > Yes, I preparated an FLTK2 Debian package and it is built as static > > lib but this should be avoided if possible, the problem is that fltk2 > > isn't stable enough so ATM it is static... The Debian license is the > > issue that doesn't allow me to upload the fltk2 (and also dillo2) > > package in Debian, there is an open bug about this > > (http://www.fltk.org/str.php?L2198+P0+S-2+C0+I0+E0+Qlicense) > > OK. > > BTW, the rc2 version of dillo-2.1 (hopefully final) was > just uploaded to http://www.dillo.org/download/ so packagers > can make the respective files. > > The idea is to make the announcement tomorrow in the morning. > > Devid: please send me the .deb and its directions when done. > > Same for rpm. Last but not the least. I use "./configure --enable-ssl" bacause that way dillo is much more useful (mainly for reading forums and bug trackers). So I'd suggest to make the packages with SSL enabled, unless somebody reembers a compelling reason not to do so. There're times when the certificate asking dialog bombs the user, but maybe not so often, or annoyingly enough, to avoid the SSL dpi. Comments? -- Cheers Jorge.-

June 18, 2009