#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
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs