Place the new, fltk2-based version of dillo into www/dillo2, keeping the old version around for those who still want a GTK1-based browser. The original www/dillo will require a small patch that I will send in a follow-up message. Fix: Patch attached with submission follows:
Responsible Changed From-To: freebsd-ports-bugs->miwi miwi@ wants his PRs (via the GNATS Auto Assign Tool)
The related patch for www/dillo. www/dillo-i18n should also get a LATEST_LINK.
Darn, you were faster than me :) Here's my version of a port. Notable changes: - Optional SSL - Automatic config file handling - Installing some documentation Also I think your port is overoptionized. COOKIES and WITH_THREADED_DNS should just be removed (those features are on by default and don't introduce any extra dependencies/noticeable increase of compile time). PROFILE is only needed for developers, who will much more likely work with dillo sourcecode from VCS, do I don't see the need for it in the port; same for RTFL, but I guess rtfl feature may be enabled if the port is compiled WITH_DEBUG (without adding an option for DEBUG of course) so if the port is rebuilt WITH_DEBUG both debug symbols and verbose logging will be available. --- dillo2-2.0.shar begins here --- # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # dillo2 # dillo2/Makefile # dillo2/pkg-descr # dillo2/pkg-plist # dillo2/distinfo # echo c - dillo2 mkdir -p dillo2 > /dev/null 2>&1 echo x - dillo2/Makefile sed 's/^X//' >dillo2/Makefile << 'END-of-dillo2/Makefile' X# New ports collection makefile for: dillo2 X# Date created: 15 Oct 2008 X# Whom: Dmitry Marakasov <amdmi3@FreeBSD.org> X# X# $FreeBSD$ X# X XPORTNAME= dillo XPORTVERSION= 2.0 XCATEGORIES= www ipv6 XMASTER_SITES= http://www.dillo.org/download/ X XMAINTAINER= amdmi3@FreeBSD.org XCOMMENT= Multi-platform graphical web browser known for its speed and small size X XBUILD_DEPENDS= ${LOCALBASE}/lib/libfltk2.a:${PORTSDIR}/x11-toolkits/fltk2 XRUN_DEPENDS= ${LOCALBASE}/lib/libfltk2.a:${PORTSDIR}/x11-toolkits/fltk2 XLIB_DEPENDS= png.5:${PORTSDIR}/graphics/png \ X jpeg.9:${PORTSDIR}/graphics/jpeg \ X XUSE_BZIP2= yes XUSE_ICONV= yes XGNU_CONFIGURE= yes X XPORTDOCS= * X XOPTIONS= IPV6 "Enable IPv6 support" on \ X SSL "Enable SSL (HTTPS) support" on X X.include <bsd.port.pre.mk> X X.if !defined(WITHOUT_IPV6) XCONFIGURE_ARGS+= --enable-ipv6 X.endif X X.if defined(WITHOUT_SSL) XCONFIGURE_ARGS+= --disable-ssl X.else XUSE_OPENSSL= yes X.endif X Xpost-patch: X @${REINPLACE_CMD} -e '/sysconfDATA_INSTALL/ s|/$$$$f|&.dist|' \ X ${WRKSRC}/Makefile.in X @${REINPLACE_CMD} -e '/echo/ s|dpidrc$$|&.dist|' \ X ${WRKSRC}/dpid/Makefile.in X Xpost-install: X if [ ! -f ${PREFIX}/etc/dillorc ]; then \ X ${INSTALL_DATA} ${PREFIX}/etc/dillorc.dist \ X ${PREFIX}/etc/dillorc; \ X fi X if [ ! -f ${PREFIX}/etc/dpidrc ]; then \ X ${INSTALL_DATA} ${PREFIX}/etc/dpidrc.dist \ X ${PREFIX}/etc/dpidrc; \ X fi X.if !defined(NOPORTDOCS) X ${MKDIR} ${DOCSDIR} X ${INSTALL_DATA} ${WRKSRC}/doc/* ${DOCSDIR} X.endif X X.include <bsd.port.post.mk> END-of-dillo2/Makefile echo x - dillo2/pkg-descr sed 's/^X//' >dillo2/pkg-descr << 'END-of-dillo2/pkg-descr' XDillo aims to be a multiplatform browser alternative that's small, Xstable, developer-friendly, usable, fast, and extensible. X XWWW: http://www.dillo.org/ END-of-dillo2/pkg-descr echo x - dillo2/pkg-plist sed 's/^X//' >dillo2/pkg-plist << 'END-of-dillo2/pkg-plist' Xbin/dillo Xbin/dpid Xbin/dpidc X@unexec if cmp -s %D/etc/dillorc.dist %D/etc/dillorc; then rm -f %D/etc/dillorc; fi Xetc/dillorc.dist X@exec if [ ! -f %B/dillorc ]; then cp -p %D/%F %B/dillorc; fi X@unexec if cmp -s %D/etc/dpidrc.dist %D/etc/dpidrc; then rm -f %D/etc/dpidrc; fi Xetc/dpidrc.dist X@exec if [ ! -f %B/dpidrc ]; then cp -p %D/%F %B/dpidrc; fi Xlib/dillo/dpi/bookmarks/bookmarks.dpi Xlib/dillo/dpi/cookies/cookies.dpi Xlib/dillo/dpi/datauri/datauri.filter.dpi Xlib/dillo/dpi/downloads/downloads.dpi Xlib/dillo/dpi/file/file.dpi Xlib/dillo/dpi/ftp/ftp.filter.dpi Xlib/dillo/dpi/hello/hello.filter.dpi Xlib/dillo/dpi/https/https.filter.dpi X@dirrm lib/dillo/dpi/https X@dirrm lib/dillo/dpi/hello X@dirrm lib/dillo/dpi/ftp X@dirrm lib/dillo/dpi/file X@dirrm lib/dillo/dpi/downloads X@dirrm lib/dillo/dpi/datauri X@dirrm lib/dillo/dpi/cookies X@dirrm lib/dillo/dpi/bookmarks X@dirrm lib/dillo/dpi X@dirrm lib/dillo END-of-dillo2/pkg-plist echo x - dillo2/distinfo sed 's/^X//' >dillo2/distinfo << 'END-of-dillo2/distinfo' XMD5 (dillo-2.0.tar.bz2) = bb9999cabeb4db3d915687de465dbeb0 XSHA256 (dillo-2.0.tar.bz2) = 847d1db31bd68ab9ab94b642b0cd40ac8d3cf816900f5d5652124986601df1e9 XSIZE (dillo-2.0.tar.bz2) = 551569 END-of-dillo2/distinfo exit --- dillo2-2.0.shar ends here --- -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru
> Darn, you were faster than me :) :) > > Here's my version of a port. > > Notable changes: > - Optional SSL This is a good idea, but needs some small changes. dillo's https.c needs the change in my Makefile if ssl is to be used, and in bsd.port.mk USE_OPENSSL is handled relatively early, so just defining USE_OPENSSL conditionally while checking OPTIONS is insufficient. (portlint issues a warning about this.) Something more along the lines of, for example, what is done in ftp/wget's Makefile is needed. > - Automatic config file handling For the first installation this is a little bit more convenient than my original suggestion. > - Installing some documentation Well, these are mostly of interest only to developers, but that's fine. > > Also I think your port is overoptionized. > COOKIES and WITH_THREADED_DNS should just be removed (those features > are on by default and don't introduce any extra dependencies/noticeable > increase of compile time). Yes, but these are not the only considerations. Both of these options introduce important functional changes. Cookies raise security and privacy concerns, and some people prefer to dispense with them entirely. Most other browsers make this possible. If there is a run-time switch to disable them, then we can remove the option. Otherwise, I strongly advise that we keep it. (Cookie handling through dillorc would be a good thing to suggest to the dillo developers.) The re-entrant DNS had been reported to cause problems with some *BSD, and the dillo developers had suggested using a single-threaded resolver on some of these systems, so I included it. Some people may experience problems, and have to fall back to it, and it would be best to make this as easy as possible. The overhead incurred by an extra OPTION or two isn't great, especially when weighed against the convenience for some users. > PROFILE is only needed for developers, who will much more likely > work with dillo sourcecode from VCS, do I don't see the need for > it in the port; same for RTFL, but I guess rtfl feature may be > enabled if the port is compiled WITH_DEBUG (without adding an option for DEBUG of course) so if the port is rebuilt WITH_DEBUG both debug symbols and verbose logging will be available. My version was based on the one I was using with the code in dillo CVS, as you can probably tell. I've no objection to consolidating the two debugging-related options, which seems to be a good idea, but in any event I think that they should probably be easily available for a while to make error detection and reporting easy. The new dillo code hasn't been exposed to large number of users yet, and we can expect some problems to arise. I'm assuming that your Makefile was an outline to show what you think ought to be done differently, and not necessarily a suggestion for the finished product, but just to be explicit, it would have needed CONFLICTS, consideration of wget as a dependency, etc. I've attached my revised proposal for the port, incorporating some of your suggestions. Regards, b.
* bf (bf2006a@yahoo.com) wrote: > > - Automatic config file handling > For the first installation this is a little bit more convenient than my > original suggestion. That's not only for the first installation. Please note 4 exec/unexec lines in my plist. exec's do the same thing as the port, but for package installation, and unexec lines remove config files on deinstallation if they were not changed. I think it's the most clean way to handle configs. Also I think .default/.dist suffix is more appropriate here (sorry for being a nitpick ;) > > Also I think your port is overoptionized. > > COOKIES and WITH_THREADED_DNS should just be removed (those features > > are on by default and don't introduce any extra dependencies/noticeable > > increase of compile time). > Yes, but these are not the only considerations. Both of these options > introduce important functional changes. Cookies raise security and > privacy concerns, and some people prefer to dispense with them entirely. > Most other browsers make this possible. If there is a run-time switch to > disable them, then we can remove the option. Otherwise, I strongly advise > that we keep it. Agreed. > The re-entrant DNS had been reported to cause problems with some *BSD, and > the dillo developers had suggested using a single-threaded resolver on > some of these systems, so I included it. Some people may experience > problems, and have to fall back to it, and it would be best to make this > as easy as possible. Seems reasonable as well. Althrough it would be better to know what exactly the problems are, so maybe add OSVERSION/ARCH condititional. But option is good enough for now. > > PROFILE is only needed for developers, who will much more likely > > work with dillo sourcecode from VCS, do I don't see the need for > > it in the port; same for RTFL, but I guess rtfl feature may be > > enabled if the port is compiled WITH_DEBUG (without adding an option > > for DEBUG of course) so if the port is rebuilt WITH_DEBUG both debug > > symbols and verbose logging will be available. > My version was based on the one I was using with the code in dillo CVS, as > you can probably tell. I've no objection to consolidating the two > debugging-related options, which seems to be a good idea, but in any event > I think that they should probably be easily available for a while to make > error detection and reporting easy. The new dillo code hasn't been > exposed to large number of users yet, and we can expect some problems to > arise. Agreed. > I'm assuming that your Makefile was an outline to show what you think > ought to be done differently, and not necessarily a suggestion for the > finished product, but just to be explicit, it would have needed CONFLICTS, > consideration of wget as a dependency, etc. Of course those are just a suggestions. The king is, who submits first :) Actually, I was going to contact maintainer of www/dillo and ask whether the port should be updated or dillo2 added instead (that's why there's no CONFLICTS), investigate why dillo-i18n was needed and whether the same thing should be done for dillo2, and also why's there wget dependency in old dillo port, so my port was not meant as 100% complete. > I've attached my revised proposal for the port, incorporating > some of your suggestions. Except for incomplete configfile handling, looks good, thanks a lot! I'm also against adding DEBUG to options though (as something that should only be set once for a single build, not for the whole port), but since we consider dillo2 unstable, option would be useful for now. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru
--- On Thu, 10/16/08, Dmitry Marakasov <amdmi3@amdmi3.ru> wrote: > From: Dmitry Marakasov <amdmi3@amdmi3.ru> > Subject: Re: ports/128139: [NEW PORT]www/dillo2 > To: "bf" <bf2006a@yahoo.com> > Cc: bug-followup@FreeBSD.org > Date: Thursday, October 16, 2008, 5:36 PM > * bf (bf2006a@yahoo.com) wrote: > > > > - Automatic config file handling > > For the first installation this is a little bit more > convenient than my > > original suggestion. > That's not only for the first installation. Please note > 4 exec/unexec > lines in my plist. exec's do the same thing as the > port, but for > package installation, and unexec lines remove config files > on > deinstallation if they were not changed. I think it's > the most clean > way to handle configs. Yes, I forgot to modify the pkg-plist. I included these changes in the revised shell archive attached to this message. > > Also I think .default/.dist suffix is more appropriate here > (sorry for > being a nitpick ;) I don't see a compelling reason for favoring one over the other -- both are used, and both have their descriptive advantages. I will use ".dist" here. > > > > Also I think your port is overoptionized. > > > COOKIES and WITH_THREADED_DNS should just be > removed (those features > > > are on by default and don't introduce any > extra dependencies/noticeable > > > increase of compile time). > > Yes, but these are not the only considerations. Both > of these options > > introduce important functional changes. Cookies raise > security and > > privacy concerns, and some people prefer to dispense > with them entirely. > > Most other browsers make this possible. If there is a > run-time switch to > > disable them, then we can remove the option. > Otherwise, I strongly advise > > that we keep it. > Agreed. > > > The re-entrant DNS had been reported to cause problems > with some *BSD, and > > the dillo developers had suggested using a > single-threaded resolver on > > some of these systems, so I included it. Some people > may experience > > problems, and have to fall back to it, and it would be > best to make this > > as easy as possible. > Seems reasonable as well. Althrough it would be better to > know what > exactly the problems are, so maybe add OSVERSION/ARCH > condititional. > But option is good enough for now. Yes, it would be good to determine if this still causes problems, and, if so, how. I guess we'll see as more people use it, or if someone takes the time to analyze it. > > > > PROFILE is only needed for developers, who will > much more likely > > > work with dillo sourcecode from VCS, do I > don't see the need for > > > it in the port; same for RTFL, but I guess rtfl > feature may be > > > enabled if the port is compiled WITH_DEBUG > (without adding an option > > > for DEBUG of course) so if the port is rebuilt > WITH_DEBUG both debug > > > symbols and verbose logging will be available. > > My version was based on the one I was using with the > code in dillo CVS, as > > you can probably tell. I've no objection to > consolidating the two > > debugging-related options, which seems to be a good > idea, but in any event > > I think that they should probably be easily available > for a while to make > > error detection and reporting easy. The new dillo > code hasn't been > > exposed to large number of users yet, and we can > expect some problems to > > arise. > Agreed. > > > I'm assuming that your Makefile was an outline to > show what you think > > ought to be done differently, and not necessarily a > suggestion for the > > finished product, but just to be explicit, it would > have needed CONFLICTS, > > consideration of wget as a dependency, etc. > Of course those are just a suggestions. The king is, who > submits first :) > Actually, I was going to contact maintainer of www/dillo > and ask > whether the port should be updated or dillo2 added instead > (that's > why there's no CONFLICTS), investigate why dillo-i18n > was needed > and whether the same thing should be done for dillo2, and > also why's > there wget dependency in old dillo port, so my port was not > meant > as 100% complete. I didn't really look closely at dillo-i18n, but it seemed to me that there was a lot of redundancy, and that that port could be streamlined as a slave port of www/dillo, or even consolidated with the latter. If the other maintainer isn't interested in continuing to maintain the original dillo ports, then I think we can eventually get rid of them, but I suggest we leave them around for a time. It looks like dillo2 will continue to use wget for ftp and https for a while. Regards, b.
* bf (bf2006a@yahoo.com) wrote: > # This is a shell archive. Save it in a file, remove anything before > # this line, and then unpack it by entering "sh file". Note, it may > # create directories; files and directories will be owned by you and > # have default permissions. > # > # This archive contains: > # > # dillo2 > # dillo2/Makefile > # dillo2/pkg-plist > # dillo2/pkg-descr > # dillo2/distinfo > # This looks good for me, I think we can commit it. So, was there any word from dillo port maintainer? -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru
--- On Thu, 10/30/08, Dmitry Marakasov <amdmi3@amdmi3.ru> wrote: > From: Dmitry Marakasov <amdmi3@amdmi3.ru> > Subject: Re: ports/128139: [NEW PORT]www/dillo2 > To: "bf" <bf2006a@yahoo.com> > Cc: bug-followup@FreeBSD.org > Date: Thursday, October 30, 2008, 8:56 AM > * bf (bf2006a@yahoo.com) wrote: > > > # This is a shell archive. Save it in a file, remove > anything before > > # this line, and then unpack it by entering "sh > file". Note, it may > > # create directories; files and directories will be > owned by you and > > # have default permissions. > > # > > # This archive contains: > > # > > # dillo2 > > # dillo2/Makefile > > # dillo2/pkg-plist > > # dillo2/pkg-descr > > # dillo2/distinfo > > # > This looks good for me, I think we can commit it. > So, was there any word from dillo port maintainer? > Not to me, but I saw that he had opened: ports/128390: [Maintainer] Repocopy request: www/dillo -> www/dillo2 I'm not sure whether this was coordinated with one of you, or if he did it independently; and I don't know what his plans are, if any, for www/dillo2. Regards, b. > -- > Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A > 80DD F9D2 F77D > amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru > http://www.amdmi3.ru
* bf (bf2006a@yahoo.com) wrote: > ports/128390: [Maintainer] Repocopy request: www/dillo -> www/dillo2 > > I'm not sure whether this was coordinated with one of you, or if he > did it independently; and I don't know what his plans are, if any, for > www/dillo2. Ok, I guess miwi will handle this as both PR's are assigned to him. Please mail me if there are any problems. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru
Responsible Changed From-To: miwi->amdmi3 Dmitry will deal with both pr's. Thank you very much!
amdmi3 2008-11-24 14:48:38 UTC FreeBSD ports repository Modified files: www Makefile www/dillo2 Makefile distinfo pkg-descr pkg-plist Added files: www/dillo2/files patch-src-cookies.c Removed files: www/dillo2/files enable-ssl.patch patch-configure patch-dpi-https.c Log: - Update dillo2 port to 2.0 (port by [1]), connect to build PR: 128139 [1], 128390 [2] Submitted by: bf <bf2006a at yahoo dot com> [1], Thomas-Martin Seck <tmseck at netcologne dot de> [2] Discussed with: Thomas-Martin Seck <tmseck at netcologne dot de> (www/dillo maintainer) Revision Changes Path 1.2184 +1 -0 ports/www/Makefile 1.42 +63 -56 ports/www/dillo2/Makefile 1.21 +3 -3 ports/www/dillo2/distinfo 1.3 +0 -10 ports/www/dillo2/files/enable-ssl.patch (dead) 1.3 +0 -114 ports/www/dillo2/files/patch-configure (dead) 1.4 +0 -18 ports/www/dillo2/files/patch-dpi-https.c (dead) 1.1 +11 -0 ports/www/dillo2/files/patch-src-cookies.c (new) 1.9 +4 -2 ports/www/dillo2/pkg-descr 1.8 +6 -3 ports/www/dillo2/pkg-plist _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
State Changed From-To: open->closed New port added, with minor changes (also added a patch to fix build with cookies disabled). Thanks!