[tbb-bugs] #27539 [Applications/Tor Browser]: Create plan for releasing on F-Droid
Tor Bug Tracker & Wiki
blackhole at torproject.org
Fri Mar 8 11:20:32 UTC 2019
#27539: Create plan for releasing on F-Droid
-------------------------------------------------+-------------------------
Reporter: sysrqb | Owner: tbb-
| team
Type: enhancement | Status: new
Priority: Medium | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: tbb-mobile, TBA-8.5, | Actual Points:
TorBrowserTeam201903, tbb-8.5 |
Parent ID: #26318 | Points:
Reviewer: | Sponsor:
| Sponsor8
-------------------------------------------------+-------------------------
Comment (by eighthave):
The F-Droid community would generally love to support Tor Project, so
don't consider the current setup something to workaround. I think there
can even be special, hard-coded exceptions for `org.torproject.*`
packages. The builder VM has 4-8GB RAM, and could have more if that would
be useful. There is no disk space limitation so far, just timeouts on the
whole process.
I imagine that the large majority of the TBA build time comes from
building Fennec. f-droid.org has been building and shipping Fennec builds
for years, so we know they work. They've always been handled by one
volunteer, so they haven't required tons of work. Per-build timeouts are
specified in the metadata file, the default is 2 hours. f-droid.org
currently has a 36 hour timeout per build cycle, that could be spent all
on a single job. Looking at IceCat's most recent build log, it took 4.5
hours. You can see all the build logs here:
* https://f-droid.org/wiki/page/org.gnu.icecat
* https://f-droid.org/wiki/page/org.mozilla.fennec_fdroid
fdroid has its `srclibs` mechanism for caching reusable library builds,
that might be useful. The F-Droid community is also open to ideas for
improving things, even if specifically for Tor Project. One simple thing
would be to make the buildserver always try `org.torproject.*` builds
first in each build cycle. There is a separate process that queues
updates, so that quirk would only take effect when there is a
`org.torproject.*` update to build.
**CI builds on fdroid infrastructure**
We have a few instances of the complete build infrastructure running for
CI tests. We also have an alpha gitlab-runner of the full buildserver VM.
For TBA, there could be a GitLab repo somewhere where TBA is built on an
fdroid buildserver on every push. Here are two publicly visible
instances:
* https://jenkins.debian.net/job/reproducible_fdroid_build_apps/
* https://verification.f-droid.org/
**Running the repo**
If the fdroid repo was run on https://www.torproject.org/fdroid, then no
new server or system needed. It is just copying static files to an
directory in an existing webserver. Then the direct download links can
just be symlinks or hard links to the files in the fdroid repo, that is
easily scripted. It could be a static link for the latest release, since
he `fdroid update` can generate a symlink to the 'current version'. The
whole fdroidserver tool suite is build/sign/publish automation, since
f-droid.org is only possible with a large amount of automation.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/27539#comment:19>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tbb-bugs
mailing list