The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-07-09T18:33:06Zhttps://gitlab.torproject.org/tpo/applications/rbm/-/issues/33289Expand list of targets more efficiently2021-07-09T18:33:06ZboklmExpand list of targets more efficientlydcf has been using a tool called NYTProf to profile rbm:
https://people.torproject.org/~dcf/graphs/nytprof-rbm-20200212-94fce31e/#subs_table
According to this, rbm has been spending a lot of time in the `RBM::get_target` function.
When...dcf has been using a tool called NYTProf to profile rbm:
https://people.torproject.org/~dcf/graphs/nytprof-rbm-20200212-94fce31e/#subs_table
According to this, rbm has been spending a lot of time in the `RBM::get_target` function.
When the rbm configuration contains something like this:
```
targets:
torbrowser-linux-x86_64:
- linux-x86_64
- linux
```
And the list of current targets is `[ 'torbrowser-linux-x86_64' ]`, the `RBM::get_targets` function (which is calling `RBM::get_target`) is responsible for expanding the list of current targets to `[ 'linux-x86_64', 'linux' ]`. It is probably possible to re-implement this in a more efficient way.https://gitlab.torproject.org/tpo/applications/rbm/-/issues/33283Add caching for the exec function in rbm2020-10-28T21:11:07ZboklmAdd caching for the exec function in rbmIn a mail to tbb-dev, dcf mentioned that while building tor-browser, a lot of time is spent in rbm:
https://lists.torproject.org/pipermail/tbb-dev/2020-February/001045.html
I think an easy way to improve this is by caching the result fr...In a mail to tbb-dev, dcf mentioned that while building tor-browser, a lot of time is spent in rbm:
https://lists.torproject.org/pipermail/tbb-dev/2020-February/001045.html
I think an easy way to improve this is by caching the result from the `exec()` template function. We use it for example with the line `version: '[% c("abbrev") %]'` which runs something like `exec("git log -1 --format=%h")`, which then runs a `git checkout` before running the `git log` command. The `version` value is used in filenames, and build_id, which are then used in a lot of places, but with no caching we end up doing a lot of calls the same `git checkout` and `git log` commands. The switch to `pion` which added a lot of go projects each with their git repository probably made this issue more visible.boklmboklmhttps://gitlab.torproject.org/tpo/applications/rbm/-/issues/32527rbm downloads 0B sig file if network drops; rejects sig on next run2021-07-09T18:33:07ZJeremyRandrbm downloads 0B sig file if network drops; rejects sig on next runInstructions to reproduce:
1. Build Tor Browser via `tor-browser-build`.
2. Right before rbm tries to download a `.sig` file, shut off the network connection.
Expected results:
rbm should not write a `.sig` file. Future invocations o...Instructions to reproduce:
1. Build Tor Browser via `tor-browser-build`.
2. Right before rbm tries to download a `.sig` file, shut off the network connection.
Expected results:
rbm should not write a `.sig` file. Future invocations of rbm once network connection is restored should download the `.sig` file.
Observed results:
rbm writes a `.sig` file with size 0B. When the network connection is restored and rbm is run again, rbm does not retry downloading the `.sig` file, and instead says something like `Error: File llvm-8.0.0.src.tar.xz is not signed with a valid key`. Manually deleting the 0B `.sig` file allows rbm to function properly again.boklmboklmhttps://gitlab.torproject.org/tpo/applications/rbm/-/issues/32272Lots of left-over folders in tor-browser-build/tmp folder filling up disk2022-12-08T15:15:28ZrichardLots of left-over folders in tor-browser-build/tmp folder filling up diskFor some reason folders in tor-browser-build/tmp sometimes do not get removed. The data here is not re-used between invocations of make and take up many 10s of gigabytes, so after time your build disk can become full.For some reason folders in tor-browser-build/tmp sometimes do not get removed. The data here is not re-used between invocations of make and take up many 10s of gigabytes, so after time your build disk can become full.https://gitlab.torproject.org/tpo/applications/rbm/-/issues/31904Update project description on https://rbm.torproject.org/2023-06-01T17:24:08ZboklmUpdate project description on https://rbm.torproject.org/The first paragraph on https://rbm.torproject.org/ currently makes it look like it is limited to creating packages for some linux distributions.
We should make it more clean that it can be used to do any kind of build, giving macOS, Win...The first paragraph on https://rbm.torproject.org/ currently makes it look like it is limited to creating packages for some linux distributions.
We should make it more clean that it can be used to do any kind of build, giving macOS, Windows and Android as examples.https://gitlab.torproject.org/tpo/applications/rbm/-/issues/31264tar.gz output files contain nonreproducible timestamps2021-07-09T18:33:06ZJeremyRandtar.gz output files contain nonreproducible timestampsSteps to reproduce:
Run the following command twice:
./rbm/rbm build gocompress --target nightly --target torbrowser-linux-x86_64
Expected results:
The output .tar.gz files should be identical.
Observed results:
The gzip header con...Steps to reproduce:
Run the following command twice:
./rbm/rbm build gocompress --target nightly --target torbrowser-linux-x86_64
Expected results:
The output .tar.gz files should be identical.
Observed results:
The gzip header contains different timestamps per build, based on when the build was done. See the following Diffoscope:
https://try.diffoscope.org/kpqdeyggzdec.html
Text version of Diffoscope output in case the above link expires:
--- a/gocompress-cc9eb1d7ad76-linux-x86_64-4fd18e.tar.gz
+++ b/gocompress-cc9eb1d7ad76-linux-x86_64-4fd18e.tar.gz
├── filetype from file(1)
│ @@ -1 +1 @@
│ -gzip compressed data, last modified: Tue Jul 30 00:09:03 2019, from Unix, original size 20551680
│ +gzip compressed data, last modified: Tue Jul 30 00:11:48 2019, from Unix, original size 20551680
Other notes:
Switching from .tar.gz to .tar.xz fixes the issue and results in reproducible binaries. Given that .xz has much better compression than .gz and (AFAIK) is usually readily available on GNU/Linux and macOS systems just like .gz, my recommendation is to simply switch the .tar.gz to .tar.xz in tor-browser-build, and add a warning to the "tar" entry in rbm's options_misc.asc saying that using .gz compression should not be used because it will break reproducibility.
Since this issue affects both rbm and Tor Browser, I'm not sure which component to select for this ticket. I'm going with rbm, but feel free to change that if you like. Or feel free to split it into 2 tickets if that makes it easier to make sure that both components get a fix.boklmboklmhttps://gitlab.torproject.org/tpo/applications/rbm/-/issues/30480rbm should check that a signed tag object contains the expected tag name2020-06-27T13:42:37Zboklmrbm should check that a signed tag object contains the expected tag nameWhen we use the `tag_gpg_id` option, rbm will check that a tag is gpg signed. However it does not check that the tag object contains the expected tag name, and git does not check that either. As discussed in legacy/trac#30479, this can a...When we use the `tag_gpg_id` option, rbm will check that a tag is gpg signed. However it does not check that the tag object contains the expected tag name, and git does not check that either. As discussed in legacy/trac#30479, this can allow rollback attacks.boklmboklmhttps://gitlab.torproject.org/tpo/applications/rbm/-/issues/30039Add options to be able to prepend or append targets2020-06-27T13:42:37ZboklmAdd options to be able to prepend or append targetsWhen listing an other project in `input_files`, it is possible to specify other targets which will be used to build this project.
In `tor-browser-build` we do this for example in `projects/https-everywhere/config` to use the `common-str...When listing an other project in `input_files`, it is possible to specify other targets which will be used to build this project.
In `tor-browser-build` we do this for example in `projects/https-everywhere/config` to use the `common-stretch` target and avoid building a different python for each platform.
The issue however with setting `target` is that it is replacing any previous target. In many cases however it would be useful to keep the previous targets and only append or prepend some other targets.boklmboklmhttps://gitlab.torproject.org/tpo/applications/rbm/-/issues/29572Fetching latest commits fails when building testbuilds2021-07-09T18:33:07ZGeorg KoppenFetching latest commits fails when building testbuildsTrying to build a test build on one of my build machines surprisingly failed during the fetch step with the following error:
```
./rbm/rbm build release --target testbuild --target torbrowser-windows-i686
fatal: Refusing to fetch into cu...Trying to build a test build on one of my build machines surprisingly failed during the fetch step with the following error:
```
./rbm/rbm build release --target testbuild --target torbrowser-windows-i686
fatal: Refusing to fetch into current branch refs/heads/master of non-bare repository
Error: Error fetching git repository
Makefile:117: recipe for target 'testbuild-windows-i686' failed
```
Instrumenting `rbm` showed me that this happens when `git` is trying to fetch the latest commits for the `tor` repo but there aren't any new ones. I compared the `rbm` config etc. with one of my other build machines where this issue does not show up and the only difference I found so far is the `git` version. On the succeeding machine I have 2.11.0 and on the failing one 2.1.4.
So, I am assuming right now that something between those versions got fixed in `git` that made the error go away. We should (a) figure out whether that theory is correct and, if so, (b) think about whether we want to support the older `git` versions affected by this and, if so, (c) think about a good workaround.https://gitlab.torproject.org/tpo/applications/rbm/-/issues/29194Set DEBIAN_FRONTEND=noninteractive when installing packages2021-07-09T18:33:06ZboklmSet DEBIAN_FRONTEND=noninteractive when installing packagesThe build of the buster container image used for building https-everywhere is getting stuck because a configuration windows for setting up the `tango-common` package is waiting for input.The build of the buster container image used for building https-everywhere is getting stuck because a configuration windows for setting up the `tango-common` package is waiting for input.boklmboklmhttps://gitlab.torproject.org/tpo/applications/rbm/-/issues/28466rbm does not correctly apply git submodule URL changes2021-07-09T18:33:07Zboklmrbm does not correctly apply git submodule URL changesrbm has an option to include git submodules when creating source tarballs for a build.
rbm is initializing and updating the submodules with `git submodule update --init`. However looking at the git-submodule manpage, it seems that the `...rbm has an option to include git submodules when creating source tarballs for a build.
rbm is initializing and updating the submodules with `git submodule update --init`. However looking at the git-submodule manpage, it seems that the `--init` submodule option will only initialize submodules which have not been initialized yet. If a commit is changing a submodule URL, then this change will not be taken into account if the submodule has been initialized before.
To fix this, rbm should also run `git submodule sync`.boklmboklmhttps://gitlab.torproject.org/tpo/applications/rbm/-/issues/28396Temporary gpg signature verification scripts are not removed2021-07-09T18:33:06ZboklmTemporary gpg signature verification scripts are not removedIn order to verify gpg signature of git tags and commits, rbm is creating temporary scripts in the `tmp` directory, but those scripts are not removed.In order to verify gpg signature of git tags and commits, rbm is creating temporary scripts in the `tmp` directory, but those scripts are not removed.boklmboklmhttps://gitlab.torproject.org/tpo/applications/rbm/-/issues/28117Some URLs can't be downloaded with LC_ALL=C2023-06-01T17:24:05ZboklmSome URLs can't be downloaded with LC_ALL=CIt seems that wget can't download some URLs when we set `LC_ALL=C`.
One example is this URL: https://jcenter.bintray.com/org/jetbrains/kotlin/kotlin-annotation-processing/1.1.51/kotlin-annotation-processing-1.1.51.jar
This is what I ge...It seems that wget can't download some URLs when we set `LC_ALL=C`.
One example is this URL: https://jcenter.bintray.com/org/jetbrains/kotlin/kotlin-annotation-processing/1.1.51/kotlin-annotation-processing-1.1.51.jar
This is what I get without setting `LC_ALL=C`:
```
$ locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
$ wget https://jcenter.bintray.com/org/jetbrains/kotlin/kotlin-annotation-processing/1.1.51/kotlin-annotation-processing-1.1.51.jar
--2018-10-19 10:30:14-- https://jcenter.bintray.com/org/jetbrains/kotlin/kotlin-annotation-processing/1.1.51/kotlin-annotation-processing-1.1.51.jar
Resolving jcenter.bintray.com (jcenter.bintray.com)... 159.122.18.156
Connecting to jcenter.bintray.com (jcenter.bintray.com)|159.122.18.156|:443... connected.
HTTP request sent, awaiting response... 302
Location: https://d29vzk4ow07wi7.cloudfront.net/6b8361d8f44649e739343b77c644f1fef1f19d771734ed83785b0dc297198bd1?response-content-disposition=attachment%3Bfilename%3D%22kotlin-annotation-processing-1.1.51.jar%22&Policy=eyJTdGF0ZW1lbnQiOiBbeyJSZXNvdXJjZSI6Imh0dHAqOi8vZDI5dnprNG93MDd3aTcuY2xvdWRmcm9udC5uZXQvNmI4MzYxZDhmNDQ2NDllNzM5MzQzYjc3YzY0NGYxZmVmMWYxOWQ3NzE3MzRlZDgzNzg1YjBkYzI5NzE5OGJkMT9yZXNwb25zZS1jb250ZW50LWRpc3Bvc2l0aW9uPWF0dGFjaG1lbnQlM0JmaWxlbmFtZSUzRCUyMmtvdGxpbi1hbm5vdGF0aW9uLXByb2Nlc3NpbmctMS4xLjUxLmphciUyMiIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTUzOTkzNzk4Nn0sIklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIwLjAuMC4wLzAifX19XX0_&Signature=CzTV-hVDn8bI3nVjlVQNmkEYesUVCAK25TDuKbcvkmp8D1Js3jv3PH2~6MYlKnJDauZr9G-nXXEVG2jfbkYiwHe-K~vB2zo1~agDBY84HIFGykX9R898aTsiPYATLJRLTm5UY5srP~fMCVcp8JpDI5VBPhSSrkYM0-sk5jHFIUaAvcCxUDDQbHfZiRriRve5B7yRQvTUtXVjbFQc6RS9Q90zFNm5VsVc3SwaZF7hg5Zr96RExqThGC5OoHKj4S2qiYGMsSMCMtonwBrAPPBotLci7ZHXELNhzRhut4kRVNq4pZP1k3xls-6LuyJuUHeBvBnM-2xV2ClKqK-EupdysQ__&Key-Pair-Id=APKAIFKFWOMXM2UMTSFA [following]
--2018-10-19 10:30:14-- https://d29vzk4ow07wi7.cloudfront.net/6b8361d8f44649e739343b77c644f1fef1f19d771734ed83785b0dc297198bd1?response-content-disposition=attachment%3Bfilename%3D%22kotlin-annotation-processing-1.1.51.jar%22&Policy=eyJTdGF0ZW1lbnQiOiBbeyJSZXNvdXJjZSI6Imh0dHAqOi8vZDI5dnprNG93MDd3aTcuY2xvdWRmcm9udC5uZXQvNmI4MzYxZDhmNDQ2NDllNzM5MzQzYjc3YzY0NGYxZmVmMWYxOWQ3NzE3MzRlZDgzNzg1YjBkYzI5NzE5OGJkMT9yZXNwb25zZS1jb250ZW50LWRpc3Bvc2l0aW9uPWF0dGFjaG1lbnQlM0JmaWxlbmFtZSUzRCUyMmtvdGxpbi1hbm5vdGF0aW9uLXByb2Nlc3NpbmctMS4xLjUxLmphciUyMiIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTUzOTkzNzk4Nn0sIklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIwLjAuMC4wLzAifX19XX0_&Signature=CzTV-hVDn8bI3nVjlVQNmkEYesUVCAK25TDuKbcvkmp8D1Js3jv3PH2~6MYlKnJDauZr9G-nXXEVG2jfbkYiwHe-K~vB2zo1~agDBY84HIFGykX9R898aTsiPYATLJRLTm5UY5srP~fMCVcp8JpDI5VBPhSSrkYM0-sk5jHFIUaAvcCxUDDQbHfZiRriRve5B7yRQvTUtXVjbFQc6RS9Q90zFNm5VsVc3SwaZF7hg5Zr96RExqThGC5OoHKj4S2qiYGMsSMCMtonwBrAPPBotLci7ZHXELNhzRhut4kRVNq4pZP1k3xls-6LuyJuUHeBvBnM-2xV2ClKqK-EupdysQ__&Key-Pair-Id=APKAIFKFWOMXM2UMTSFA
Resolving d29vzk4ow07wi7.cloudfront.net (d29vzk4ow07wi7.cloudfront.net)... 143.204.222.2
Connecting to d29vzk4ow07wi7.cloudfront.net (d29vzk4ow07wi7.cloudfront.net)|143.204.222.2|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 218055 (213K) [application/content-stream]
Saving to: ‘kotlin-annotation-processing-1.1.51.jar.1’
kotlin-annotation-processing-1.1.51.jar.1 100%[=======================================================================================>] 212.94K 241KB/s in 0.9s
2018-10-19 10:30:16 (241 KB/s) - ‘kotlin-annotation-processing-1.1.51.jar.1’ saved [218055/218055]
```
And when setting `LC_ALL=C`:
```
$ LC_ALL=C wget https://jcenter.bintray.com/org/jetbrains/kotlin/kotlin-annotation-processing/1.1.51/kotlin-annotation-processing-1.1.51.jar
converted 'https://jcenter.bintray.com/org/jetbrains/kotlin/kotlin-annotation-processing/1.1.51/kotlin-annotation-processing-1.1.51.jar' (ANSI_X3.4-1968) -> 'https://jcenter.bintray.com/org/jetbrains/kotlin/kotlin-annotation-processing/1.1.51/kotlin-annotation-processing-1.1.51.jar' (UTF-8)
--2018-10-19 10:31:03-- https://jcenter.bintray.com/org/jetbrains/kotlin/kotlin-annotation-processing/1.1.51/kotlin-annotation-processing-1.1.51.jar
Resolving jcenter.bintray.com (jcenter.bintray.com)... 5.153.35.248
Connecting to jcenter.bintray.com (jcenter.bintray.com)|5.153.35.248|:443... connected.
HTTP request sent, awaiting response... 302
Location: https://d29vzk4ow07wi7.cloudfront.net/6b8361d8f44649e739343b77c644f1fef1f19d771734ed83785b0dc297198bd1?response-content-disposition=attachment%3Bfilename%3D%22kotlin-annotation-processing-1.1.51.jar%22&Policy=eyJTdGF0ZW1lbnQiOiBbeyJSZXNvdXJjZSI6Imh0dHAqOi8vZDI5dnprNG93MDd3aTcuY2xvdWRmcm9udC5uZXQvNmI4MzYxZDhmNDQ2NDllNzM5MzQzYjc3YzY0NGYxZmVmMWYxOWQ3NzE3MzRlZDgzNzg1YjBkYzI5NzE5OGJkMT9yZXNwb25zZS1jb250ZW50LWRpc3Bvc2l0aW9uPWF0dGFjaG1lbnQlM0JmaWxlbmFtZSUzRCUyMmtvdGxpbi1hbm5vdGF0aW9uLXByb2Nlc3NpbmctMS4xLjUxLmphciUyMiIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTUzOTkzODU5MX0sIklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIwLjAuMC4wLzAifX19XX0_&Signature=PriqMimfLqEeyqR3y9bX~HPB83dmXvAIh3Jkl~g2bc~xMgsUpw-UT00yajHiKdaE37yy-t1eD5BEfliSq41MYCxJifgQ0H3ye0P~GZ0j3XIIBaLe70iS-g16DMozSodrLwKG0NIAsTXqdyJeBYcHyRXrfeg0VeBuLqr3qGc577JFKKIpvHdj3~ZLZ92Flk~gy66arYFR0HC2z0HimbJCCL2WiH4kOQH9L0pirJa55W9NPf4rccSJRwWNAVO5-T5dmf7AY4VdM3y6ad11lV~9wIbn5wcveOxPhslMl8EHRCTKRaqFSa5iC~7EiGn3KMW7~lF7Rj6iFhhadvQtVbjJhw__&Key-Pair-Id=APKAIFKFWOMXM2UMTSFA [following]
converted 'https://d29vzk4ow07wi7.cloudfront.net/6b8361d8f44649e739343b77c644f1fef1f19d771734ed83785b0dc297198bd1?response-content-disposition=attachment%3Bfilename%3D%22kotlin-annotation-processing-1.1.51.jar%22&Policy=eyJTdGF0ZW1lbnQiOiBbeyJSZXNvdXJjZSI6Imh0dHAqOi8vZDI5dnprNG93MDd3aTcuY2xvdWRmcm9udC5uZXQvNmI4MzYxZDhmNDQ2NDllNzM5MzQzYjc3YzY0NGYxZmVmMWYxOWQ3NzE3MzRlZDgzNzg1YjBkYzI5NzE5OGJkMT9yZXNwb25zZS1jb250ZW50LWRpc3Bvc2l0aW9uPWF0dGFjaG1lbnQlM0JmaWxlbmFtZSUzRCUyMmtvdGxpbi1hbm5vdGF0aW9uLXByb2Nlc3NpbmctMS4xLjUxLmphciUyMiIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTUzOTkzODU5MX0sIklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIwLjAuMC4wLzAifX19XX0_&Signature=PriqMimfLqEeyqR3y9bX~HPB83dmXvAIh3Jkl~g2bc~xMgsUpw-UT00yajHiKdaE37yy-t1eD5BEfliSq41MYCxJifgQ0H3ye0P~GZ0j3XIIBaLe70iS-g16DMozSodrLwKG0NIAsTXqdyJeBYcHyRXrfeg0VeBuLqr3qGc577JFKKIpvHdj3~ZLZ92Flk~gy66arYFR0HC2z0HimbJCCL2WiH4kOQH9L0pirJa55W9NPf4rccSJRwWNAVO5-T5dmf7AY4VdM3y6ad11lV~9wIbn5wcveOxPhslMl8EHRCTKRaqFSa5iC~7EiGn3KMW7~lF7Rj6iFhhadvQtVbjJhw__&Key-Pair-Id=APKAIFKFWOMXM2UMTSFA' (ANSI_X3.4-1968) -> 'https://d29vzk4ow07wi7.cloudfront.net/6b8361d8f44649e739343b77c644f1fef1f19d771734ed83785b0dc297198bd1?response-content-disposition=attachment;filename="kotlin-annotation-processing-1.1.51.jar"&Policy=eyJTdGF0ZW1lbnQiOiBbeyJSZXNvdXJjZSI6Imh0dHAqOi8vZDI5dnprNG93MDd3aTcuY2xvdWRmcm9udC5uZXQvNmI4MzYxZDhmNDQ2NDllNzM5MzQzYjc3YzY0NGYxZmVmMWYxOWQ3NzE3MzRlZDgzNzg1YjBkYzI5NzE5OGJkMT9yZXNwb25zZS1jb250ZW50LWRpc3Bvc2l0aW9uPWF0dGFjaG1lbnQlM0JmaWxlbmFtZSUzRCUyMmtvdGxpbi1hbm5vdGF0aW9uLXByb2Nlc3NpbmctMS4xLjUxLmphciUyMiIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTUzOTkzODU5MX0sIklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIwLjAuMC4wLzAifX19XX0_&Signature=PriqMimfLqEeyqR3y9bX~HPB83dmXvAIh3Jkl~g2bc~xMgsUpw-UT00yajHiKdaE37yy-t1eD5BEfliSq41MYCxJifgQ0H3ye0P~GZ0j3XIIBaLe70iS-g16DMozSodrLwKG0NIAsTXqdyJeBYcHyRXrfeg0VeBuLqr3qGc577JFKKIpvHdj3~ZLZ92Flk~gy66arYFR0HC2z0HimbJCCL2WiH4kOQH9L0pirJa55W9NPf4rccSJRwWNAVO5-T5dmf7AY4VdM3y6ad11lV~9wIbn5wcveOxPhslMl8EHRCTKRaqFSa5iC~7EiGn3KMW7~lF7Rj6iFhhadvQtVbjJhw__&Key-Pair-Id=APKAIFKFWOMXM2UMTSFA' (UTF-8)
--2018-10-19 10:31:10-- https://d29vzk4ow07wi7.cloudfront.net/6b8361d8f44649e739343b77c644f1fef1f19d771734ed83785b0dc297198bd1?response-content-disposition=attachment;filename=%22kotlin-annotation-processing-1.1.51.jar%22&Policy=eyJTdGF0ZW1lbnQiOiBbeyJSZXNvdXJjZSI6Imh0dHAqOi8vZDI5dnprNG93MDd3aTcuY2xvdWRmcm9udC5uZXQvNmI4MzYxZDhmNDQ2NDllNzM5MzQzYjc3YzY0NGYxZmVmMWYxOWQ3NzE3MzRlZDgzNzg1YjBkYzI5NzE5OGJkMT9yZXNwb25zZS1jb250ZW50LWRpc3Bvc2l0aW9uPWF0dGFjaG1lbnQlM0JmaWxlbmFtZSUzRCUyMmtvdGxpbi1hbm5vdGF0aW9uLXByb2Nlc3NpbmctMS4xLjUxLmphciUyMiIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTUzOTkzODU5MX0sIklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIwLjAuMC4wLzAifX19XX0_&Signature=PriqMimfLqEeyqR3y9bX~HPB83dmXvAIh3Jkl~g2bc~xMgsUpw-UT00yajHiKdaE37yy-t1eD5BEfliSq41MYCxJifgQ0H3ye0P~GZ0j3XIIBaLe70iS-g16DMozSodrLwKG0NIAsTXqdyJeBYcHyRXrfeg0VeBuLqr3qGc577JFKKIpvHdj3~ZLZ92Flk~gy66arYFR0HC2z0HimbJCCL2WiH4kOQH9L0pirJa55W9NPf4rccSJRwWNAVO5-T5dmf7AY4VdM3y6ad11lV~9wIbn5wcveOxPhslMl8EHRCTKRaqFSa5iC~7EiGn3KMW7~lF7Rj6iFhhadvQtVbjJhw__&Key-Pair-Id=APKAIFKFWOMXM2UMTSFA
Resolving d29vzk4ow07wi7.cloudfront.net (d29vzk4ow07wi7.cloudfront.net)... 143.204.222.2
Connecting to d29vzk4ow07wi7.cloudfront.net (d29vzk4ow07wi7.cloudfront.net)|143.204.222.2|:443... connected.
HTTP request sent, awaiting response... 403 Forbidden
2018-10-19 10:31:11 ERROR 403: Forbidden.
--2018-10-19 10:31:11-- https://jcenter.bintray.com/org/jetbrains/kotlin/kotlin-annotation-processing/1.1.51/kotlin-annotation-processing-1.1.51.jar
Connecting to jcenter.bintray.com (jcenter.bintray.com)|5.153.35.248|:443... connected.
HTTP request sent, awaiting response... 302
Location: https://d29vzk4ow07wi7.cloudfront.net/6b8361d8f44649e739343b77c644f1fef1f19d771734ed83785b0dc297198bd1?response-content-disposition=attachment%3Bfilename%3D%22kotlin-annotation-processing-1.1.51.jar%22&Policy=eyJTdGF0ZW1lbnQiOiBbeyJSZXNvdXJjZSI6Imh0dHAqOi8vZDI5dnprNG93MDd3aTcuY2xvdWRmcm9udC5uZXQvNmI4MzYxZDhmNDQ2NDllNzM5MzQzYjc3YzY0NGYxZmVmMWYxOWQ3NzE3MzRlZDgzNzg1YjBkYzI5NzE5OGJkMT9yZXNwb25zZS1jb250ZW50LWRpc3Bvc2l0aW9uPWF0dGFjaG1lbnQlM0JmaWxlbmFtZSUzRCUyMmtvdGxpbi1hbm5vdGF0aW9uLXByb2Nlc3NpbmctMS4xLjUxLmphciUyMiIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTUzOTkzODU5MX0sIklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIwLjAuMC4wLzAifX19XX0_&Signature=PriqMimfLqEeyqR3y9bX~HPB83dmXvAIh3Jkl~g2bc~xMgsUpw-UT00yajHiKdaE37yy-t1eD5BEfliSq41MYCxJifgQ0H3ye0P~GZ0j3XIIBaLe70iS-g16DMozSodrLwKG0NIAsTXqdyJeBYcHyRXrfeg0VeBuLqr3qGc577JFKKIpvHdj3~ZLZ92Flk~gy66arYFR0HC2z0HimbJCCL2WiH4kOQH9L0pirJa55W9NPf4rccSJRwWNAVO5-T5dmf7AY4VdM3y6ad11lV~9wIbn5wcveOxPhslMl8EHRCTKRaqFSa5iC~7EiGn3KMW7~lF7Rj6iFhhadvQtVbjJhw__&Key-Pair-Id=APKAIFKFWOMXM2UMTSFA [following]
converted 'https://d29vzk4ow07wi7.cloudfront.net/6b8361d8f44649e739343b77c644f1fef1f19d771734ed83785b0dc297198bd1?response-content-disposition=attachment%3Bfilename%3D%22kotlin-annotation-processing-1.1.51.jar%22&Policy=eyJTdGF0ZW1lbnQiOiBbeyJSZXNvdXJjZSI6Imh0dHAqOi8vZDI5dnprNG93MDd3aTcuY2xvdWRmcm9udC5uZXQvNmI4MzYxZDhmNDQ2NDllNzM5MzQzYjc3YzY0NGYxZmVmMWYxOWQ3NzE3MzRlZDgzNzg1YjBkYzI5NzE5OGJkMT9yZXNwb25zZS1jb250ZW50LWRpc3Bvc2l0aW9uPWF0dGFjaG1lbnQlM0JmaWxlbmFtZSUzRCUyMmtvdGxpbi1hbm5vdGF0aW9uLXByb2Nlc3NpbmctMS4xLjUxLmphciUyMiIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTUzOTkzODU5MX0sIklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIwLjAuMC4wLzAifX19XX0_&Signature=PriqMimfLqEeyqR3y9bX~HPB83dmXvAIh3Jkl~g2bc~xMgsUpw-UT00yajHiKdaE37yy-t1eD5BEfliSq41MYCxJifgQ0H3ye0P~GZ0j3XIIBaLe70iS-g16DMozSodrLwKG0NIAsTXqdyJeBYcHyRXrfeg0VeBuLqr3qGc577JFKKIpvHdj3~ZLZ92Flk~gy66arYFR0HC2z0HimbJCCL2WiH4kOQH9L0pirJa55W9NPf4rccSJRwWNAVO5-T5dmf7AY4VdM3y6ad11lV~9wIbn5wcveOxPhslMl8EHRCTKRaqFSa5iC~7EiGn3KMW7~lF7Rj6iFhhadvQtVbjJhw__&Key-Pair-Id=APKAIFKFWOMXM2UMTSFA' (ANSI_X3.4-1968) -> 'https://d29vzk4ow07wi7.cloudfront.net/6b8361d8f44649e739343b77c644f1fef1f19d771734ed83785b0dc297198bd1?response-content-disposition=attachment;filename="kotlin-annotation-processing-1.1.51.jar"&Policy=eyJTdGF0ZW1lbnQiOiBbeyJSZXNvdXJjZSI6Imh0dHAqOi8vZDI5dnprNG93MDd3aTcuY2xvdWRmcm9udC5uZXQvNmI4MzYxZDhmNDQ2NDllNzM5MzQzYjc3YzY0NGYxZmVmMWYxOWQ3NzE3MzRlZDgzNzg1YjBkYzI5NzE5OGJkMT9yZXNwb25zZS1jb250ZW50LWRpc3Bvc2l0aW9uPWF0dGFjaG1lbnQlM0JmaWxlbmFtZSUzRCUyMmtvdGxpbi1hbm5vdGF0aW9uLXByb2Nlc3NpbmctMS4xLjUxLmphciUyMiIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTUzOTkzODU5MX0sIklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIwLjAuMC4wLzAifX19XX0_&Signature=PriqMimfLqEeyqR3y9bX~HPB83dmXvAIh3Jkl~g2bc~xMgsUpw-UT00yajHiKdaE37yy-t1eD5BEfliSq41MYCxJifgQ0H3ye0P~GZ0j3XIIBaLe70iS-g16DMozSodrLwKG0NIAsTXqdyJeBYcHyRXrfeg0VeBuLqr3qGc577JFKKIpvHdj3~ZLZ92Flk~gy66arYFR0HC2z0HimbJCCL2WiH4kOQH9L0pirJa55W9NPf4rccSJRwWNAVO5-T5dmf7AY4VdM3y6ad11lV~9wIbn5wcveOxPhslMl8EHRCTKRaqFSa5iC~7EiGn3KMW7~lF7Rj6iFhhadvQtVbjJhw__&Key-Pair-Id=APKAIFKFWOMXM2UMTSFA' (UTF-8)
--2018-10-19 10:31:11-- https://d29vzk4ow07wi7.cloudfront.net/6b8361d8f44649e739343b77c644f1fef1f19d771734ed83785b0dc297198bd1?response-content-disposition=attachment;filename=%22kotlin-annotation-processing-1.1.51.jar%22&Policy=eyJTdGF0ZW1lbnQiOiBbeyJSZXNvdXJjZSI6Imh0dHAqOi8vZDI5dnprNG93MDd3aTcuY2xvdWRmcm9udC5uZXQvNmI4MzYxZDhmNDQ2NDllNzM5MzQzYjc3YzY0NGYxZmVmMWYxOWQ3NzE3MzRlZDgzNzg1YjBkYzI5NzE5OGJkMT9yZXNwb25zZS1jb250ZW50LWRpc3Bvc2l0aW9uPWF0dGFjaG1lbnQlM0JmaWxlbmFtZSUzRCUyMmtvdGxpbi1hbm5vdGF0aW9uLXByb2Nlc3NpbmctMS4xLjUxLmphciUyMiIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTUzOTkzODU5MX0sIklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIwLjAuMC4wLzAifX19XX0_&Signature=PriqMimfLqEeyqR3y9bX~HPB83dmXvAIh3Jkl~g2bc~xMgsUpw-UT00yajHiKdaE37yy-t1eD5BEfliSq41MYCxJifgQ0H3ye0P~GZ0j3XIIBaLe70iS-g16DMozSodrLwKG0NIAsTXqdyJeBYcHyRXrfeg0VeBuLqr3qGc577JFKKIpvHdj3~ZLZ92Flk~gy66arYFR0HC2z0HimbJCCL2WiH4kOQH9L0pirJa55W9NPf4rccSJRwWNAVO5-T5dmf7AY4VdM3y6ad11lV~9wIbn5wcveOxPhslMl8EHRCTKRaqFSa5iC~7EiGn3KMW7~lF7Rj6iFhhadvQtVbjJhw__&Key-Pair-Id=APKAIFKFWOMXM2UMTSFA
Connecting to d29vzk4ow07wi7.cloudfront.net (d29vzk4ow07wi7.cloudfront.net)|143.204.222.2|:443... connected.
HTTP request sent, awaiting response... 403 Forbidden
2018-10-19 10:31:12 ERROR 403: Forbidden.
[...]
--2018-10-19 10:31:32-- https://jcenter.bintray.com/org/jetbrains/kotlin/kotlin-annotation-processing/1.1.51/kotlin-annotation-processing-1.1.51.jar
Connecting to jcenter.bintray.com (jcenter.bintray.com)|5.153.35.248|:443... connected.
HTTP request sent, awaiting response... 302
Location: https://d29vzk4ow07wi7.cloudfront.net/6b8361d8f44649e739343b77c644f1fef1f19d771734ed83785b0dc297198bd1?response-content-disposition=attachment%3Bfilename%3D%22kotlin-annotation-processing-1.1.51.jar%22&Policy=eyJTdGF0ZW1lbnQiOiBbeyJSZXNvdXJjZSI6Imh0dHAqOi8vZDI5dnprNG93MDd3aTcuY2xvdWRmcm9udC5uZXQvNmI4MzYxZDhmNDQ2NDllNzM5MzQzYjc3YzY0NGYxZmVmMWYxOWQ3NzE3MzRlZDgzNzg1YjBkYzI5NzE5OGJkMT9yZXNwb25zZS1jb250ZW50LWRpc3Bvc2l0aW9uPWF0dGFjaG1lbnQlM0JmaWxlbmFtZSUzRCUyMmtvdGxpbi1hbm5vdGF0aW9uLXByb2Nlc3NpbmctMS4xLjUxLmphciUyMiIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTUzOTkzODU5MX0sIklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIwLjAuMC4wLzAifX19XX0_&Signature=PriqMimfLqEeyqR3y9bX~HPB83dmXvAIh3Jkl~g2bc~xMgsUpw-UT00yajHiKdaE37yy-t1eD5BEfliSq41MYCxJifgQ0H3ye0P~GZ0j3XIIBaLe70iS-g16DMozSodrLwKG0NIAsTXqdyJeBYcHyRXrfeg0VeBuLqr3qGc577JFKKIpvHdj3~ZLZ92Flk~gy66arYFR0HC2z0HimbJCCL2WiH4kOQH9L0pirJa55W9NPf4rccSJRwWNAVO5-T5dmf7AY4VdM3y6ad11lV~9wIbn5wcveOxPhslMl8EHRCTKRaqFSa5iC~7EiGn3KMW7~lF7Rj6iFhhadvQtVbjJhw__&Key-Pair-Id=APKAIFKFWOMXM2UMTSFA [following]
converted 'https://d29vzk4ow07wi7.cloudfront.net/6b8361d8f44649e739343b77c644f1fef1f19d771734ed83785b0dc297198bd1?response-content-disposition=attachment%3Bfilename%3D%22kotlin-annotation-processing-1.1.51.jar%22&Policy=eyJTdGF0ZW1lbnQiOiBbeyJSZXNvdXJjZSI6Imh0dHAqOi8vZDI5dnprNG93MDd3aTcuY2xvdWRmcm9udC5uZXQvNmI4MzYxZDhmNDQ2NDllNzM5MzQzYjc3YzY0NGYxZmVmMWYxOWQ3NzE3MzRlZDgzNzg1YjBkYzI5NzE5OGJkMT9yZXNwb25zZS1jb250ZW50LWRpc3Bvc2l0aW9uPWF0dGFjaG1lbnQlM0JmaWxlbmFtZSUzRCUyMmtvdGxpbi1hbm5vdGF0aW9uLXByb2Nlc3NpbmctMS4xLjUxLmphciUyMiIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTUzOTkzODU5MX0sIklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIwLjAuMC4wLzAifX19XX0_&Signature=PriqMimfLqEeyqR3y9bX~HPB83dmXvAIh3Jkl~g2bc~xMgsUpw-UT00yajHiKdaE37yy-t1eD5BEfliSq41MYCxJifgQ0H3ye0P~GZ0j3XIIBaLe70iS-g16DMozSodrLwKG0NIAsTXqdyJeBYcHyRXrfeg0VeBuLqr3qGc577JFKKIpvHdj3~ZLZ92Flk~gy66arYFR0HC2z0HimbJCCL2WiH4kOQH9L0pirJa55W9NPf4rccSJRwWNAVO5-T5dmf7AY4VdM3y6ad11lV~9wIbn5wcveOxPhslMl8EHRCTKRaqFSa5iC~7EiGn3KMW7~lF7Rj6iFhhadvQtVbjJhw__&Key-Pair-Id=APKAIFKFWOMXM2UMTSFA' (ANSI_X3.4-1968) -> 'https://d29vzk4ow07wi7.cloudfront.net/6b8361d8f44649e739343b77c644f1fef1f19d771734ed83785b0dc297198bd1?response-content-disposition=attachment;filename="kotlin-annotation-processing-1.1.51.jar"&Policy=eyJTdGF0ZW1lbnQiOiBbeyJSZXNvdXJjZSI6Imh0dHAqOi8vZDI5dnprNG93MDd3aTcuY2xvdWRmcm9udC5uZXQvNmI4MzYxZDhmNDQ2NDllNzM5MzQzYjc3YzY0NGYxZmVmMWYxOWQ3NzE3MzRlZDgzNzg1YjBkYzI5NzE5OGJkMT9yZXNwb25zZS1jb250ZW50LWRpc3Bvc2l0aW9uPWF0dGFjaG1lbnQlM0JmaWxlbmFtZSUzRCUyMmtvdGxpbi1hbm5vdGF0aW9uLXByb2Nlc3NpbmctMS4xLjUxLmphciUyMiIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTUzOTkzODU5MX0sIklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIwLjAuMC4wLzAifX19XX0_&Signature=PriqMimfLqEeyqR3y9bX~HPB83dmXvAIh3Jkl~g2bc~xMgsUpw-UT00yajHiKdaE37yy-t1eD5BEfliSq41MYCxJifgQ0H3ye0P~GZ0j3XIIBaLe70iS-g16DMozSodrLwKG0NIAsTXqdyJeBYcHyRXrfeg0VeBuLqr3qGc577JFKKIpvHdj3~ZLZ92Flk~gy66arYFR0HC2z0HimbJCCL2WiH4kOQH9L0pirJa55W9NPf4rccSJRwWNAVO5-T5dmf7AY4VdM3y6ad11lV~9wIbn5wcveOxPhslMl8EHRCTKRaqFSa5iC~7EiGn3KMW7~lF7Rj6iFhhadvQtVbjJhw__&Key-Pair-Id=APKAIFKFWOMXM2UMTSFA' (UTF-8)
20 redirections exceeded.
```
Currently when starting, `rbm` is updating all environment variables defined in `ENV`, which in the case of `tor-browser-build` includes `LC_ALL=C`, causing this issue with wget. Maybe a backup of the initial values of environment variables could be kept. We can then use it in the `urlget` macro to reset initial environment variables.https://gitlab.torproject.org/tpo/applications/rbm/-/issues/27265In some cases, rbm will download files in the wrong project directory2021-07-09T18:33:07ZboklmIn some cases, rbm will download files in the wrong project directoryThe patch for legacy/trac#27045 is causing an error when starting the build with an empty `out/` directory:
https://trac.torproject.org/projects/tor/ticket/27045#comment:11
We can see in the logs that binutils is being downloaded in the...The patch for legacy/trac#27045 is causing an error when starting the build with an empty `out/` directory:
https://trac.torproject.org/projects/tor/ticket/27045#comment:11
We can see in the logs that binutils is being downloaded in the `out/firefox` directory instead of `out/binutils`:
```
Saving to: '/media/ssd/Code/Tor/tor-browser-build/out/firefox/binutils-2.26.1.tar.bz2'
```
The reason is that we override `output_dir` when calling `build_pkg` in `input_files`:
```
} elsif ($input_file->{project} && $t->('project')) {
my $p = $t->('project');
print "Building project $p - $name\n";
my $run_save = $config->{run};
$config->{run} = { target => $input_file->{target} };
$config->{run}{target} //= $run_save->{target};
build_pkg($p, {%$options, origin_project => $project, %$input_file,
output_dir => $proj_out_dir});
$config->{run} = $run_save;
print "Finished build of project $p - $name\n";
} else {
```
The reason why we don't see this error in normal builds and only see it with legacy/trac#27045 is that in legacy/trac#27045 we are changing the `tor-browser` filename to remove `c("var/build_id")` from it, removing the need to download dependencies to compute the filename. In normal builds the binutils tarball is already downloaded (in the correct directory) when we start the firefox build, so we are not hitting this issue.boklmboklmhttps://gitlab.torproject.org/tpo/applications/rbm/-/issues/26185rbm should do deep merge of options hashes2023-06-01T17:23:58Zboklmrbm should do deep merge of options hashesIn templates, when using the `c()` or `pc()` functions, it is possible to give as 2nd or 3rd argument an hash table containing variables to be overridden. To do that, we merge this hash table into the main options hash table. However we ...In templates, when using the `c()` or `pc()` functions, it is possible to give as 2nd or 3rd argument an hash table containing variables to be overridden. To do that, we merge this hash table into the main options hash table. However we only merge one level, which means that if the new options hash table contains variables in a second level with something like `var => { option_1 => 'value1' }`, then `var` is replaced instead of merged, and all `var/*` options other than `option_1` are removed.https://gitlab.torproject.org/tpo/applications/rbm/-/issues/25746git_submodule option doesn't work when a submodule is not in the root directory2021-07-09T18:33:07Zboklmgit_submodule option doesn't work when a submodule is not in the root directoryrbm has the `git_submodule` option to include all submodules in the sources tarball. This option works as expected when all the submodules are located in the root directory, however it fails if one of the submodules is in a sub-directory...rbm has the `git_submodule` option to include all submodules in the sources tarball. This option works as expected when all the submodules are located in the root directory, however it fails if one of the submodules is in a sub-directory.
The reason is that we do this to create .tar files for all the submodules:
```
($stdout, $stderr, $success, $exit_code)
= capture_exec('git', 'submodule', 'foreach',
"git archive --prefix=$project-$version/\$path/"
. " --output=$tmpdir/submodule-\$name.tar \$sha1");
```
We use the submodule name in the output filename inside a temporary directory, which fails when the submodule name contains `/` as it wants to create a file in a directory which does not exist.boklmboklmhttps://gitlab.torproject.org/tpo/applications/rbm/-/issues/25719Add option to store last time a file was used in a build2022-11-29T09:04:23ZboklmAdd option to store last time a file was used in a buildIn `tor-browser-build`, we can clean old build files by running `make clean`, which will keep only the files used in the current build.
There are however some problems with that:
- running `make clean` is slow as it needs to compute all...In `tor-browser-build`, we can clean old build files by running `make clean`, which will keep only the files used in the current build.
There are however some problems with that:
- running `make clean` is slow as it needs to compute all the file names used in a build, for all the branches/series we are using.
- when working on different bugs at the same time, running `make clean` will clean build files created by branches that have not been merged yet.
Instead, it would be nice to be able to clean files that have not been used in the last X days. To allow that, rbm should have an option to store somewhere a timestamp of when each input files have been used in a build for the last time.https://gitlab.torproject.org/tpo/applications/rbm/-/issues/25435keyring/binutils.gpg modified by `make alpha`2021-07-09T18:33:07ZDavid Fifielddcf@torproject.orgkeyring/binutils.gpg modified by `make alpha`From commit [4bed9a85478b6fb16e0d654589d8cb8ed3865027](https://gitweb.torproject.org/builders/tor-browser-build.git/commit/?id=4bed9a85478b6fb16e0d654589d8cb8ed3865027), I ran `make alpha`. When it was finished, `git status` showed that ...From commit [4bed9a85478b6fb16e0d654589d8cb8ed3865027](https://gitweb.torproject.org/builders/tor-browser-build.git/commit/?id=4bed9a85478b6fb16e0d654589d8cb8ed3865027), I ran `make alpha`. When it was finished, `git status` showed that the file keyring/binutils.gpg had changed, and left a backup file keyring/binutils.gpg~.
```
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: keyring/binutils.gpg
Untracked files:
(use "git add <file>..." to include in what will be committed)
keyring/binutils.gpg~
```boklmboklmhttps://gitlab.torproject.org/tpo/applications/rbm/-/issues/25422Give more details in "Cannot checkout" errors2020-06-27T13:42:38ZboklmGive more details in "Cannot checkout" errorsOur nightly build sometimes fail with an error such as:
```
Error: Cannot checkout tor-browser-52.6.0esr-8.0-2-build2
```
We should print the stderr output from the git/hg command to give more details about the error.Our nightly build sometimes fail with an error such as:
```
Error: Cannot checkout tor-browser-52.6.0esr-8.0-2-build2
```
We should print the stderr output from the git/hg command to give more details about the error.boklmboklmhttps://gitlab.torproject.org/tpo/applications/rbm/-/issues/25421Add an option to clean repository if checkout fails2023-06-01T17:23:55ZboklmAdd an option to clean repository if checkout failsOur nightly build sometimes fail with an error such as:
```
Error: Cannot checkout tor-browser-52.6.0esr-8.0-2-build2
```
The reason is that the working tree from the git repository is not clean, which prevents checking out an other com...Our nightly build sometimes fail with an error such as:
```
Error: Cannot checkout tor-browser-52.6.0esr-8.0-2-build2
```
The reason is that the working tree from the git repository is not clean, which prevents checking out an other commit.
We should add an option to rbm to do a `git reset --hard` and `git clean` if the checkout fails.