Hello,
You can find at this URL a proposal to refactor the tor browser bundle build process, using an other tool to replace gitian: https://people.torproject.org/~boklm/automation/tor-automation-proposals.htm... (also added as attached file to this email)
I made a prototype to show how it would work: https://github.com/boklm/burps-tor
The main improvements in this prototype from the current build process are:
- all components are built separately, and include in their output file name the commit hash or version, architecture and OS (if architecture dependant). This allows us to keep previous builds if the commit/version/architecture/OS didn't change. So we can rebuild a bundle very quickly when the browser didn't change.
- the gitian replacment has features to download tarballs and verify them with sha256sum or gpg signature, so this can replace the fetch-inputs.sh script.
- we can remove the linux/windows/macosx descriptors duplication, and instead use template directives for the parts that differ between those builds (it's still possible to use separate files if they differ completly).
- we can define variables based on selected OS. This allows for instance to build python 2.7 when building on Ubuntu Lucid, but avoid building it on other distros which already provide python 2.7.
- we can define variables based on "targets" that are set on command line. For instance in the prototype using "--target enable_pt" instructs to include the portable transports (only pyptlib in this prototype) in the bundle.
- we can easily switch from building in a VM to building locally
- build descriptors can depend on the result of another build descriptor. This remove needs for scripts like mkbundle-*.sh.
And I think those improvements should make it easier to rebuild a new bundle automatically when any of the components of the bundle receives a new commit, and then run tests on this bundle.
Nicolas