attila <att...@stalphonsos.com> writes: > Landry Breuil <lan...@rhaalovely.net> writes: > >> On Mon, Nov 16, 2015 at 09:07:46AM -0600, attila wrote: >>> >>> attila <att...@stalphonsos.com> writes: >>> >>> > attila <att...@stalphonsos.com> writes: >>> > >>> >> attila <att...@stalphonsos.com> writes: >>> >> >>> >>> attila <att...@stalphonsos.com> writes: >>> >>> >>> >>>> attila <att...@stalphonsos.com> writes: >>> >>>> >>> >>>>> Hi ports@, >>> >>>>> >>> >>>>> I have been informed that my previous email re Tor Browser Bundle was >>> >>>>> malformed: the Content-Type header on the message says text/plain but >>> >>>>> should be multipart/mixed, which causes many (most?) MUAs to throw up >>> >>>>> all over it. I'm not sure where the fault lies yet, and apologize for >>> >>>>> the screwed up attachment. >>> >>>>> >>> >>>>> In the interests of simplicity and efficacy the tarball can be found >>> >>>>> here: http://bits.haqistan.net/~attila/tbb.tgz >>> >>>>> >>> >>>>> Sorry. >>> >>>>> >>> >>>>> Pax, -A >>> >>>> >>> >>>> I've updated http://bits.haqistan.net/~attila/tbb.tgz with the >>> >>>> just-completed update to Tor Browser 4.5.3. Tested on amd64. >>> >>>> >>> >>>> So... update & ping. >>> >>>> >>> >>>> Pax, -A >>> >>> >>> >>> Reupdate & reping: >>> >>> >>> >>> I brought the ports up to the current version, which is now 5.0.3. >>> >>> I've also solved my attachment woes; updated ports attached (URL above >>> >>> has new bits as well). Tested on amd64. There are packages available >>> >>> for testing at: >>> >>> http://mirrors.nycbug.org/pub/snapshots/packages/amd64/ >>> >>> The README file there might be helpful if you want to test. >>> >>> >>> >>> FWIW, the GH repository is: https://github.com/torbsd/openbsd-ports >>> >>> YMMV. >>> >>> >>> >>> Pax, -A >>> >> >>> >> Re-reupdate & re-reping: >>> >> >>> >> Thanks to Daniel Jakots for pointing out that the inter-package >>> >> dependencies were all balled up and led to problems. Updated ports >>> >> attached with better deps, updated packages for testing available at >>> >> the nycbug URL, above. >>> >> >>> >> Pax, -A >>> > >>> > Re*ping. I know some people have been using the packages we put up >>> > for testing purposes. I also know this is potentially sort of a >>> > controversial (set of) port(s) and that everyone is busy but if anyone >>> > could be troubled to take a look and give some feedback that would >>> > be great. >>> > >>> > Attaching the latest version of the ports for completeness. >>> > >>> > Pax, -A >>> >>> Ping. >> >> I had a quick look a while ago at the Makefile. I would *really* prefer >> you to shrink it by reusing www/mozilla MODULE, provided you work out >> the correct changes that would be needed for tbb without breaking the >> other users of the module. Instead of copy-pasting-cargo-culting what's >> in the module... > > Okay, finally, I have done at least this much. The attached update to > the five ports is mostly about switching to the www/mozilla MODULE, > thanks to your patch for bundled nss. It also brings us up to TBB > 5.5. Tested on amd64 with whatever the latest snapshot was on 5 Feb > (don't recall now, don't have amd64 handy ATM :-() >
As per ancient custom, I forgot the frigging tarball... attached here. >> Is the .mozconfig hackery really needed ? > > The @CONFIG_GUESS@ token in .mozconfig does not seem to get s///'ed > correctly by autoconf. I don't have my build machine available right > now but I seem to recall that firefox-esr doesn't ship with a > .mozconfig file, but Tor browser does... could be wrong. When I get > my buildbox back I'll look at this again. I'm guessing that this hack > and the other post-extract sed hack for baseconfig.mk can be sussed > out and turned into patches for upstream instead. > >> The @exec lines in the PLIST should go at the bottom. > > Done. > >> I think you dont need files/firefox.desktop, and do you really need >> files/profiles.ini ? > > This is tor-browser.desktop now. The profiles.ini file is > unfortunately necessary given the way I pre-populate ~/.tor-browser > but if there's a better way... this is just how they do it in the > bundle. > >> Have you tried leaving the .xpi files compressed in their respective >> dirs at runtime (eventually unzipping/patching/rezipping) as you comment >> in Makefile.inc line 68 ? Iirc this should also work and is 'nicer' to >> the filesystem.. > > I finally just grokked in fullness what you were saying here (sorry, a > bit slow). Given that I already have a start-tor-browser shell script > in place to set things up we could instead switch to having .xpi files > in distribution/extensions (or wherever) and unpack them when > ~/.tor-browser is populated. I'm sorry I didn't get to it before now, > maybe the rest of what I've done can be critiqued and I'll make this > change and test it when I get my buildbox back. > >> I'm still not a fan of having this in-tree, but i'd like opinions from >> other porters & tor users (users, not fanboys please) here - especially >> pascal since he's the tor maintainer :) > > I'd really like those opinions, too, if they're out there... > > There are packages for amd64 available for testing: > > http://mirrors.nycbug.org/pub/snapshots/packages/amd64/README-55.txt > >> Landry > > Pax, -A Pax, -A -- http://haqistan.net/~attila | att...@stalphonsos.com | 0xE6CC1EDB
tbb-resub.tgz
Description: tor browser bundle in five easy pieces, updated to 5.5
