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 :-()
> 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
--
http://haqistan.net/~attila | att...@stalphonsos.com | 0xE6CC1EDB
