I recently merged the Gitian-based pluggable transports bundle build with tag tbb-3.0rc1-build1, with suprisingly little difficulty. I'd like you to take a look at what the pt branch is doing and help me decide what to do next. Some background: The ticket for building the PT bundles is https://trac.torproject.org/projects/tor/ticket/9444 The pt branch is at https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/shortlog/refs/... To see what's different in the pt branch with respect to master, in an existing tor-browser-bundle.git checkout, do this: git remote add dcf https://git.torproject.org/user/dcf/tor-browser-bundle.git git fetch dcf Then, for example, git diff master...dcf/pt --stat git diff master...dcf/pt gitk master dcf/pt A recent build of 00789049873753d931fec3803c9ccae75a5c5267 is here, also containing the full complement of usual build outputs. https://people.torproject.org/~dcf/pt-bundle/3.0-rc-1-pt20131207-1/ These bundles are up to date and seem to be working well. I would be comfortable shipping them to users. I'd like your advice on how to make the pluggable transports browser part of the usual build. The diff between descriptors gitian-bundle.yml and gitian-ptbundle.yml is small; in fact I can paste it here: --- descriptors/linux/gitian-bundle.yml 2013-12-06 19:38:40.000000000 -0800 +++ descriptors/linux/gitian-ptbundle.yml 2013-12-06 19:38:40.000000000 -0800 @@ -1,3 +1,3 @@ --- -name: "bundle-linux" +name: "ptbundle-linux" suites: @@ -29,2 +29,4 @@ - "tor-linux64-gbuilt.zip" +- "pluggable-transports-linux32-gbuilt.zip" +- "pluggable-transports-linux64-gbuilt.zip" - "relativelink-src.zip" @@ -39,2 +41,4 @@ - "tbb-docs.zip" +- "pttbb-docs.zip" +- "linux-pt-torrc" script: | @@ -98,4 +102,8 @@ unzip ~/build/tor-linux$GBUILD_BITS-gbuilt.zip + unzip ~/build/pluggable-transports-linux$GBUILD_BITS-gbuilt.zip unzip ~/build/linux-skeleton.zip unzip ~/build/tbb-docs.zip + mkdir -p Docs/PluggableTransports + unzip -d Docs/PluggableTransports ~/build/pttbb-docs.zip + cat ~/build/linux-pt-torrc >> Data/Tor/torrc-defaults chmod 700 Data/Browser @@ -122,3 +130,3 @@ #mv tor-browser.exe $OUTDIR/tor-browser-linux${GBUILD_BITS}_en-US.7z-selfextract - ~/build/dtar.sh $OUTDIR/tor-browser-linux${GBUILD_BITS}-${TORBROWSER_VERSION}_en-US.tar.xz tor-browser_en-US + ~/build/dtar.sh $OUTDIR/tor-pluggable-transports-browser-linux${GBUILD_BITS}-${TORBROWSER_VERSION}_en-US.tar.xz tor-browser_en-US rm -rf tor-browser_en-US @@ -149,3 +157,3 @@ #mv tor-browser.exe $OUTDIR/tor-browser-linux${GBUILD_BITS}_$LANG.7z-selfextract - ~/build/dtar.sh $OUTDIR/tor-browser-linux${GBUILD_BITS}-${TORBROWSER_VERSION}_$LANG.tar.xz tor-browser_$LANG + ~/build/dtar.sh $OUTDIR/tor-pluggable-transports-browser-linux${GBUILD_BITS}-${TORBROWSER_VERSION}_$LANG.tar.xz tor-browser_$LANG I see a couple of options for getting rid of gitian-ptbundle.yml: 1. Add a conditional variable, something like the '[ ${TORBROWSER_VERSION::3} != "3.0" ]' in linux/gitian-firefox.yml, that controls whether a vanilla or a PT build is underway. When the variable is set, it would just do the few small changes in the diff above. 2. Build the pluggable transports bundles unconditionally, and just do all the dtars in gitian-bundle.yml twice: once for tor-browser and once for tor-pluggable-transports-browser. Either option, I think, puts us in a good place to step to a unified bundle in the future. What do you think? David Fifield