[Sorry for duplicate email to anyone who got one, my bad -A] Landry Breuil <lan...@openbsd.org> writes:
> On Wed, Nov 02, 2016 at 09:55:17AM -0600, attila wrote: n>> >> Landry Breuil <lan...@openbsd.org> writes: >> >> > On Tue, Oct 18, 2016 at 11:07:22AM -0500, attila wrote: >> >> >> >> attila <att...@stalphonsos.com> writes: >> >> >> >> > attila <att...@stalphonsos.com> writes: >> >> > >> >> >> Hi ports@, >> >> >> >> >> > Feedback, comments, most welcome. >> >> > >> >> > Pax, -A >> >> >> >> Ping. Ports attached for convenience. >> > >> > Fwiw, i've built the git tip of https://github.com/torbsd/openbsd-ports >> > on current, and they build fine. >> >> I just pushed a couple of times to address your concerns; updated >> tarball attached for convenience. > > So, more nits portswise only: Thanks a lot for this feedback. Attached is a tarball that attempts to address both your and danj@'s concerns. > - meta/tbb/pkg/DESCR could use some more wording, as > www/tbb/tor-browser/pkg/DESCR. All of the COMMENTs and pkg/DESCR files have been updated. > - i dont see a README anywhere installed in the pkgs (could go to > meta/tbb/pkg/README, with the added line to the corresponding PLIST) > explaining the end-user how that whole stuff works, without having to > refer to the website... There is now a meta/tor-browser/pkg/README > - www/tbb/Makefile -> that .if !defined(ADDONS_ONLY) block should go away Done. > - no need to cargo-cult BROKEN-sparc64 nor the MODGCC4 stuff for archs > where it wont build (yeah i know, i need to clean firefox Makefile..) Removed. > - the dependency on gettext looks fishy. BUILD_DEPENDS + LIB_DEPENDS + > RUN_DEPENDS ? i dont think so, that also looks like cargoculting. Fixed. > - CONFIGURE_STYLE=autoheader ? I have "autoconf no-autoheader", which I think is correct in this case. However there was an issue with make configure that I'm not sure I solved well. The issue is that the "test -f $$d/configure" in gnu.port.mk fails because Tor Browser does not have a configure at toplevel, only a configure.in. I presume there's a reason why the test is not: -f $$d/configure.in -o -f $$d/configure.ac but I don't understand what it is... ? My hack was to prepend . to MOZILLA_AUTOCONF_DIRS, since you already have a pre-configure hook in mozilla.port.mk (which is where I would've put the "extra" call to autoconf anyway). This has the desired effect. If there's a better, more generic way to deal with autoconf'd projects that don't ship a top-level configure I would like to be enlightened. > - since all extensions are installed *only* for tbb, it should be > stressed in their COMMENT/DESCR, so that ppl dont think that > installing 'https-everywhere' package will magically enabled httpse for > their firefox.. My munging of PKGNAMEs attempts to address this as well as explicit text in */pkg/DESCR and COMMENTs. I put a tb- prefix in the PKGNAMEs for www/tor-browser/{browser,noscript,https-everywhere}, so the full list of PKGNAMEs is: tor-browser # meta package tb-browser # firefox esr fork torbutton tor-launcher tb-noscript tb-https-everywhere > And there are probably other nits... :) I have a question that might turn into a nit: portcheck complains thus in www/tor-browser/browser: stdc++ in WANTLIB when gcc4 is in MODULES; run port-lib-depends-check and if stdc++ is still there, check actual build thoroughly, it's broken port-lib-depends-check says: ... tb-browser-6.0.5(www/tor-browser/browser): Extra: stdc++.57 I built www/firefox-esr to see what port-lib-depends-check says there and it's the same. I take it this is due to the way that Mozilla does dynamic loading and there's nothing to be done about it? This has always been the case for TB but I forgot to ask until now. > Landry Again, thanks a lot for your time. Pax, -A -- http://haqistan.net/~attila | att...@stalphonsos.com | 0x62A729CF
tbb605-bbbbis.tgz
Description: updated tor browser ports
