[tor-bugs] #26073 [Applications/Tor Browser]: patch tor-browser-build.git for Firefox 60 ESR
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon May 28 18:32:38 UTC 2018
#26073: patch tor-browser-build.git for Firefox 60 ESR
--------------------------------------------+------------------------------
Reporter: arthuredelstein | Owner: tbb-team
Type: defect | Status: needs_review
Priority: Very High | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: TorBrowserTeam201805, ff60-esr | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
--------------------------------------------+------------------------------
Changes (by sukhbir):
* status: needs_revision => needs_review
Comment:
Replying to [comment:24 gk]:
> Okay, `tor-browser-60.0.1esr-8.0-1` is a thing now. Looking at the
commits in your `bug-26073` a general thing I noticed, please make sure
the commits on `bug-26073` are still needed for the final branch. For
instance there is no reason for us to merge
71f7fd76779cb4b4a96ac17a80a82e5de64d0924 to `master`. It's been a WIP
commit. Moreover, it's not been correct in the sense that it has been
changing much more than just the nightly related branch. You only need to
change the `git_hash` part in
> {{{
> nightly:
> git_hash: 'tor-browser-[% c("var/firefox_version") %]-[%
c("var/torbrowser_branch") %]-1'
> tag_gpg_id: 0
> var:
> torbrowser_update_channel: default
> }}}
> + `firefox_platform_version`.
>
> e7b62d616f4a339257c69f2b895802c015b829eb does not need to get merged
either. Just add a clean commit starting from `master` dealing with the
lang packs. Etc.
Thanks for the feedback; I started on a clean branch (I didn't want to use
`--force` on a public repository.) Let me know if another approach is
preferred.
For review:
https://github.com/azadi/tor-browser-build-1/tree/bug-26073-rev1
{{{
69874135a6550419f95ef39d41a4e3cc5aa5fa02 -- not needed with the idea in
commit 81da10daeaa1c35cb78e22006e63f1f86c68a1a8; however now I see as the
version string:
"tbb-nightly --with-distribution-id=org.torproject --enable-update-
channel=default --enable-bundled-fonts"
I wonder if that's related to this change or to our tor-browser patches...
}}}
Isn't the string expected given the configuration options we pass? Or was
there something else before we switched to this?
{{{
4c42450871b9a61e04fb97a5163d0895e71452f9 -- not okay
You guard the rust inclusion in the build script behind
+[% IF c("var/linux") %]
+[% END -%]
but not in the config file. I think we should just want to have it enabled
unconditionally under the assumption that building ESR60 on the other
platforms is broken anyway until we fix the toolchains.
}}}
I guarded the other related changes as well for now, just to be
consistent. If you prefer that we enable it unconditionally, let me know.
{{{
e41884c0447cc9c39a466cb5b23ea58dfc48c728 -- not okay
Do we have a lib64 dir for 32bit Linux builds? I somehow doubt that.
"$rootdir" is not needed (as seen by the tar command we used for cmake
previously.
}}}
Updated.
{{{
2e0aee0362bfba5c46f2a097aa3383bc468609dd -- not okay
We switched to the informaction.com URL because 5.1.8.5 is not available
on AMO anymore, we should switch back to AMO for the WebExtension version.
}}}
Updated.
{{{
51309b419d6b645fda682665ae2b4091373d590a -- not okay
Please provide a clean commit for dealing with the lang packs, i.e. not a
commit to fix arthur's commit.
}}}
Done.
{{{
d2f372825b0cee09f5087976b1ed53edb38a7aef -- not okay
tor-browser-60.0.1esr-8.0-1 is a thing now.
}}}
Done.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26073#comment:31>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list