tor-browser-build issueshttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues2022-10-27T22:48:08Zhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40638Visit our website link after build-to-build upgrade in Nightly channel points...2022-10-27T22:48:08ZrichardVisit our website link after build-to-build upgrade in Nightly channel points to old v2 onionAfter upgrade nightly builds have the following copy on about:tor:
----
### Tor Browser has been updated.
For the most up-to-date information about this release, [visit our website](http://f4amtbsowhix7rrf.onion/).
----
We need to u...After upgrade nightly builds have the following copy on about:tor:
----
### Tor Browser has been updated.
For the most up-to-date information about this release, [visit our website](http://f4amtbsowhix7rrf.onion/).
----
We need to upgrade this to the new v3 onionSponsor 131 - Phase 3 - Major ESR 102 MigrationPier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40631Stop bundling HTTPS Everywhere on Android.2022-10-27T22:46:06Zma1Stop bundling HTTPS Everywhere on Android.`tor-browser-build` part of tor-browser#41160.`tor-browser-build` part of tor-browser#41160.Sponsor 131 - Phase 3 - Major ESR 102 Migrationma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40626Define the replacements for generic families on Linux2022-10-18T12:23:52ZPier Angelo VendrameDefine the replacements for generic families on LinuxFontConfig does not know much about our fonts, and falls back to the font version, when it cannot find any other criterion to decide which font to use (see tor-browser#41043).
So, we want to make sure that at least `sans-serif`, `serif`...FontConfig does not know much about our fonts, and falls back to the font version, when it cannot find any other criterion to decide which font to use (see tor-browser#41043).
So, we want to make sure that at least `sans-serif`, `serif` and `monospace` are the fonts we want (currently, Arimo, Tinos and Cousine).
This is needed for example for tor-browser#41116: we have patched system fonts, but Firefox does not double check their values with the font replacement system, and queries FontConfig for the font to use directly.
I think that patching the `fonts.conf` is the correct solution for this use-case.Sponsor 131 - Phase 3 - Major ESR 102 MigrationPier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40624Change placeholder bridge addresses to make snowflake and meek work with Reac...2023-05-02T02:18:50ZDavid Fifielddcf@torproject.orgChange placeholder bridge addresses to make snowflake and meek work with ReachableAddresses/FascistFirewallChange the addresses in bridge lines to use port 80 so that tor will consider the bridge lines usable.
A torrc Bridge line requires an IP:port address as part of the syntax. The IP:port address is required, even for transports that are ...Change the addresses in bridge lines to use port 80 so that tor will consider the bridge lines usable.
A torrc Bridge line requires an IP:port address as part of the syntax. The IP:port address is required, even for transports that are not based on making a single connection to a single endpoint; for that reason, Snowflake and meek use "placeholder" addresses, currently 192.0.2.3:1 and 192.0.2.2:2 respectively. However, this causes a problem with ReachableAddresses/FascistFirewall (i.e. the "This computer goes through a firewall that only allows connections to certain ports" setting). tor doesn't know that these transports do not actually connect to the placeholder addresses; all it sees is that port 1 and port 2 are not on the permitted list, so it considers the bridge unusable (tpo/core/tor#19487):
```
[NOTICE] Bridge at '192.0.2.2:2' isn't reachable by our firewall policy. Asking bridge authority instead.
```
The anti-censorship team proposes to set the port of placeholder addresses to 80, so that Snowflake and meek will be usable even when ReachableAddresses/FascistFirewall is set.
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40159#note_2834570
> We currently assign placeholder addresses using the format
>
> > 192.0.2.<var>t</var>:<var>n</var>
>
> where <var>t</var> indicates the transport (1=flashproxy, 2=meek, 3=snowflake) and <var>n</var> is a counter if there are multiple bridge lines for single transport (currently that doesn't happen, but in the past we had :1 for meek-google, :2 for meek-amazon, :3 for meek-azure; and tpo/anti-censorship/pluggable-transports/snowflake#28651 will add a second snowflake bridge).
>
> If we switch to a hardcoded port of 80, there will not be separate places to encode <var>t</var> and <var>n</var>. But we could encode them both into one byte, using 4 bits for <var>t</var> and 4 bits for <var>n</var>:
>
> > 192.0.2.(16(<var>n</var>ā1)+<var>t</var>):80
The team discussed this at the 2022-09-08 meeting.
http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-09-08-15.58.log.html#l-66
```
16:26:30 <meskio> "A new format for placeholder addresses in PT bridge lines"
16:26:37 <dcf1> okay, quick note about placeholder addresses
16:27:12 <dcf1> we have been using placeholder addresses with incrementing port numbers :1, :2, :3, etc., because tor requires all PT bridges to have different IP:port, or it gets them confused
16:27:56 <dcf1> this causes a problem when tor is configured with ReachableAddresses or FascistFirewall, because tor thinks the PT is going to try to actually make a TCP connection to those placeholder addresses
16:28:22 <dcf1> and it says "port 1 is not one of the ports permitted by FascistFirewall, therefore I will not attempt this bridge connection"
16:28:35 <dcf1> imo it's a bug in core tor, but it's WONTFIX for years now
16:29:15 <meskio> it might not get fixed until arti
16:29:23 <dcf1> so the proposal is to move this counter into the IP address and always use port 80 for placeholder addresses, to make them more likely to work with ReachableAddresses and FascistFirewall
16:30:49 <dcf1> Way back in flash proxy, which also needed a placeholder address, I tried to make the placeholder look as different from an actual usable IP address as possible, to reduce confusion
16:31:20 <dcf1> since then, the placeholders have been slowly morphing to look more and more like real IP addresses :)
16:31:38 <dcf1> the progression was something like:
16:31:57 <dcf1> 0.0.0.0:0 <- no good, tor uses the all-zero address as a sentinel internally
16:32:09 <dcf1> 0.0.0.1:1 <- no good, 0.0.0.X is used by SOCKS
16:32:35 <dcf1> 0.0.1.0:1 <- we used this for a while, but it ran into problems with 0/8 being considered "internal" by tor
16:32:59 <dcf1> 192.0.2.1:1 <- what we use now, using a special non-routable IP range reserved for documentation
16:33:13 <dcf1> 192.0.2.1:80 <- new proposal
...
16:39:19 <dcf1> okay well I will propose a merge request with the 192.0.2.(16(nā1)+t):80 format, it's good enough for our needs for now
```Sponsor 131 - Phase 3 - Major ESR 102 Migrationrichardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40621Update namecoin patches for linted TorButton2022-09-09T11:31:12ZPier Angelo VendrameUpdate namecoin patches for linted TorButtonWe have recently linted torbutton (torbutton!91), and now namecoin patches fail to apply, and this makes the nightly builds for Linux (and maybe Windows?) fail.
/cc @JeremyRandWe have recently linted torbutton (torbutton!91), and now namecoin patches fail to apply, and this makes the nightly builds for Linux (and maybe Windows?) fail.
/cc @JeremyRandSponsor 131 - Phase 3 - Major ESR 102 Migrationhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40620Review Mozilla 1734331: Upgrade toolchains to macosx-sdk 11.02022-09-02T17:01:53ZrichardReview Mozilla 1734331: Upgrade toolchains to macosx-sdk 11.0## https://bugzilla.mozilla.org/show_bug.cgi?id=1734331
Not a security issue for of an FYI, but it seems like we will also need to upgrade to the 11.0 sdk for macOS arm builds## https://bugzilla.mozilla.org/show_bug.cgi?id=1734331
Not a security issue for of an FYI, but it seems like we will also need to upgrade to the 11.0 sdk for macOS arm buildsSponsor 131 - Phase 3 - Major ESR 102 Migrationboklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40599Windows 32bit installer is missing many languages from the NSIS file2022-10-04T19:01:53ZDavid Fifielddcf@torproject.orgWindows 32bit installer is missing many languages from the NSIS fileThe installer file lists 56 languages,
* https://github.com/MarkCSmith/tbb-windows-installer/blob/00133b8741eb8ca34fc8153d344c7c54a5e3fae9/torbrowser.nsi#L51
but the installer only shows 26.
It looks like these are the 30 languages tha...The installer file lists 56 languages,
* https://github.com/MarkCSmith/tbb-windows-installer/blob/00133b8741eb8ca34fc8153d344c7c54a5e3fae9/torbrowser.nsi#L51
but the installer only shows 26.
It looks like these are the 30 languages that are missing, notably including TBB official languages Arabic, Farsi, Korean, Polish, Russian, Turkish, and Chinese.
```
!insertmacro MUI_LANGUAGE "SimpChinese"
!insertmacro MUI_LANGUAGE "TradChinese"
!insertmacro MUI_LANGUAGE "Japanese"
!insertmacro MUI_LANGUAGE "Korean"
!insertmacro MUI_LANGUAGE "Greek"
!insertmacro MUI_LANGUAGE "Russian"
!insertmacro MUI_LANGUAGE "Polish"
!insertmacro MUI_LANGUAGE "Ukrainian"
!insertmacro MUI_LANGUAGE "Czech"
!insertmacro MUI_LANGUAGE "Slovak"
!insertmacro MUI_LANGUAGE "Croatian"
!insertmacro MUI_LANGUAGE "Bulgarian"
!insertmacro MUI_LANGUAGE "Hungarian"
!insertmacro MUI_LANGUAGE "Thai"
!insertmacro MUI_LANGUAGE "Romanian"
!insertmacro MUI_LANGUAGE "Latvian"
!insertmacro MUI_LANGUAGE "Macedonian"
!insertmacro MUI_LANGUAGE "Estonian"
!insertmacro MUI_LANGUAGE "Turkish"
!insertmacro MUI_LANGUAGE "Lithuanian"
!insertmacro MUI_LANGUAGE "Slovenian"
!insertmacro MUI_LANGUAGE "Serbian"
!insertmacro MUI_LANGUAGE "SerbianLatin"
!insertmacro MUI_LANGUAGE "Arabic"
!insertmacro MUI_LANGUAGE "Farsi"
!insertmacro MUI_LANGUAGE "Hebrew"
!insertmacro MUI_LANGUAGE "Mongolian"
!insertmacro MUI_LANGUAGE "Albanian"
!insertmacro MUI_LANGUAGE "Belarusian"
!insertmacro MUI_LANGUAGE "Bosnian"
```Sponsor 131 - Phase 3 - Major ESR 102 Migrationhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40592Consider re-using our LLVM/Clang to build Rust2022-10-18T12:24:02ZPier Angelo VendrameConsider re-using our LLVM/Clang to build RustRust re-builds LLVM, which takes a long time.
We could simply reuse the LLVM/Clang we build, and reduce the Rust compiling time, by adding `-DLLVM_INSTALL_UTILS=ON` to the options we use to compile Clang.
The only disadvantage is that ...Rust re-builds LLVM, which takes a long time.
We could simply reuse the LLVM/Clang we build, and reduce the Rust compiling time, by adding `-DLLVM_INSTALL_UTILS=ON` to the options we use to compile Clang.
The only disadvantage is that we link everything to the updated libstdc++.
On Rust we currently pass `--enable-llvm-static-stdcpp`. In my test I've removed it and defined `-DLLVM_STATIC_LINK_CXX_STDLIB=ON` on Clang, but it wasn't enough.
As a workaround, we could either create a project that extracts libstdc++ from GCC, and provides it to projects that want to use Rust without a dependency on GCC (currently only cbindgen), or copy libstdc++ also to Rust.Sponsor 131 - Phase 3 - Major ESR 102 MigrationPier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40591Rust 1.60 not working to build 102 on Debian Jessie2022-10-24T07:10:30ZPier Angelo VendrameRust 1.60 not working to build 102 on Debian JessieMozilla uses Rust 1.60 to build Firefox 102.
For some reason our binaries cannot complete a build, but official binaries can.
It seems like we hit a deadlock in the phase
```
Compiling gkrust-shared v0.1.0 (/home/rbm/tor-browser/toolk...Mozilla uses Rust 1.60 to build Firefox 102.
For some reason our binaries cannot complete a build, but official binaries can.
It seems like we hit a deadlock in the phase
```
Compiling gkrust-shared v0.1.0 (/home/rbm/tor-browser/toolkit/library/rust/shared)
```
Only one `rustc` process remains alive, but it uses only 40-50MB of memory, and 0% of CPU, and it never ends.
I have also tried to add a `RUSTC_LOGS="info"`/`RUSTC_LOGS="debug"`, but I don't get any output.
Our binaries seem to work on the current stable of Debian (I have tried to set bullseye as a container in `projects/firefox/config`).
As a workaround we can run `./install.sh --prefix=$distdir` on the downloaded 1.60, to convert the downloaded archive (which is organized by project) to a more standard directory structure (the usual `bin/`, `lib/`, etc...).
Also, I have opened a thread on Rust's forum: https://users.rust-lang.org/t/how-to-reproduce-official-rustc-builds-for-linux/79569.
My idea is that we could start by building a `rustc` in the same environment and with the same configuration as the official binaries, and then make it more and more similar to our builds, to see when it breaks.Sponsor 131 - Phase 3 - Major ESR 102 MigrationPier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40587Migrate tor-browser-build configs from gitolite to gitlab repos2022-10-14T14:38:50ZrichardMigrate tor-browser-build configs from gitolite to gitlab reposGitolite is going away, we should migrate our build configs to using the gitlab code mirrors where appropriate.Gitolite is going away, we should migrate our build configs to using the gitlab code mirrors where appropriate.Sponsor 131 - Phase 3 - Major ESR 102 Migrationrichardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40585Prune the manual more2022-10-12T18:31:41ZPier Angelo VendramePrune the manual moreWe have had an increase in TBB size, and it's partly due to the manual.
We should remove webfonts because they are not even rendered (7.9MB uncompressed), there are not minimized JS and CSS, and we should see if we can remove some image...We have had an increase in TBB size, and it's partly due to the manual.
We should remove webfonts because they are not even rendered (7.9MB uncompressed), there are not minimized JS and CSS, and we should see if we can remove some images.
We can remove what we don't need with the script that packs the manual (it just copies the static files).Sponsor 131 - Phase 3 - Major ESR 102 MigrationPier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40464go 1.18 fails to build on macOS2022-10-20T19:59:31Zrichardgo 1.18 fails to build on macOS@pierov ran into this issue while we were attempting to build alpha 11.5a8:
```
Opening log file: Thu Mar 17 19:08:27 2022
Starting build (script: build): 2022-03-17 19:08:28
# golang.org/x/sys/unix
unix/zsyscall_darwin_amd64.go:28:3: /...@pierov ran into this issue while we were attempting to build alpha 11.5a8:
```
Opening log file: Thu Mar 17 19:08:27 2022
Starting build (script: build): 2022-03-17 19:08:28
# golang.org/x/sys/unix
unix/zsyscall_darwin_amd64.go:28:3: //go:linkname must refer to declared function or variable
unix/zsyscall_darwin_amd64.go:43:3: //go:linkname must refer to declared function or variable
unix/zsyscall_darwin_amd64.go:59:3: //go:linkname must refer to declared function or variable
unix/zsyscall_darwin_amd64.go:75:3: //go:linkname must refer to declared function or variable
unix/zsyscall_darwin_amd64.go:90:3: //go:linkname must refer to declared function or variable
unix/zsyscall_darwin_amd64.go:105:3: //go:linkname must refer to declared function or variable
unix/zsyscall_darwin_amd64.go:121:3: //go:linkname must refer to declared function or variable
unix/zsyscall_darwin_amd64.go:136:3: //go:linkname must refer to declared function or variable
unix/zsyscall_darwin_amd64.go:151:3: //go:linkname must refer to declared function or variable
unix/zsyscall_darwin_amd64.go:166:3: //go:linkname must refer to declared function or variable
unix/zsyscall_darwin_amd64.go:166:3: too many errors
Finishing build (script: build): 2022-03-17 19:08:33
Build time: 0 hours 0 minutes and 5 seconds
```
Some initial googling points us to: https://stackoverflow.com/questions/71507321/go-upgrade-to-1-18-go-build-run-with-error-my-system-is-mac-12
In the meantime I've reverted the go update on the alpha branch until we can investigate/implement a fix.Sponsor 131 - Phase 3 - Major ESR 102 MigrationDan BallardDan Ballardhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40439Create universal x86-64/arm64 mac builds2022-12-04T17:29:14ZboklmCreate universal x86-64/arm64 mac buildsIn #40158 we add support for macOS aarch64 builds. However, to avoid doubling the space used by macOS builds we should create universal x86-64/arm64 dmg files.
The tickets on mozilla side are:
* https://bugzilla.mozilla.org/show_bug.cgi...In #40158 we add support for macOS aarch64 builds. However, to avoid doubling the space used by macOS builds we should create universal x86-64/arm64 dmg files.
The tickets on mozilla side are:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1675740
* https://bugzilla.mozilla.org/show_bug.cgi?id=1675384
I think the scripts from Mozilla we can use for that are:
* taskcluster/scripts/misc/unify.sh
* toolkit/mozapps/installer/unify.pySponsor 131 - Phase 3 - Major ESR 102 Migrationboklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40415GnuPG signing configuration regressed2023-01-19T10:49:16ZGeorg KoppenGnuPG signing configuration regressedLooking at older GnuPG signatures e.g. in the 10.5a10 folder one gets something like
```
-----BEGIN PGP SIGNATURE-----
iQIcBAABCgAGBQJhdvL6AAoJEOt3RJHZ/wbiWuQQAKcZ38SWVPFvBDsu4cJuJjC3
RPJaN/TdGiF2F5YlQQaQkGwJCF1z/O0uQyeJ3/mnb9dIJR41iviI...Looking at older GnuPG signatures e.g. in the 10.5a10 folder one gets something like
```
-----BEGIN PGP SIGNATURE-----
iQIcBAABCgAGBQJhdvL6AAoJEOt3RJHZ/wbiWuQQAKcZ38SWVPFvBDsu4cJuJjC3
RPJaN/TdGiF2F5YlQQaQkGwJCF1z/O0uQyeJ3/mnb9dIJR41iviI9if107QGsqKf
aFtDiOUEpYXWvPeNOrmC+dQUW4zEiMBCkuZshxJqm+5xMkBziAWnlM8J7OVp/XcD
bJVPBK5iuFxEuBBDsj/wOZ7aYXPNuXHKev0mxTDHR8NPmUjqk17VhLo3TOPJr5qt
JqCKWTlyvRXGnQXN2T92wbuyG0nfb/RhsyVfTPM5Ar3UGUnZRnWcL9uFxqDh7O8/
v14F+NlqnfM+AysUE7sL0rxSEwcBv6ZkK1zIVIzRfFE/V/87ECZE38iToBjv8NGF
T+wOm3BKgH4DwVCWa1Jyij5O9BOeVIrUY0kSQc9tI3VLh55Wa2j6Wj3/cpD+PvRL
/E/IDHlHwYaitm8STpDrs1l4bGyfs+b5Kd/HVYZatjQMiE0uuGHdlbKQvIK40xwm
DYxGvmVrvDgfwTTq19L2U3Pw11fdCEsB/wbvj0Jc1ehM4K4C0xAiq+5U5CqWUf2/
wGpUTc0KROw/J92EflQEZkmcaoNEBfge9RxaRlPdtl36p1ZC+m0W5FkXe1UYmlu0
a0CzNR3M4ir4yksjCxxbghWxKnAGbVvd/0QrMItF3R3AA5fjHhYaJuIK3XvwbaOr
r8CPKwHsULDDcSMte3/T
=1mA1
-----END PGP SIGNATURE-----
```
However, lately we start getting detached signatures like
```
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJh2pq5AAoJEOU9mJqeLUe/hUIP/ihKMJRs88To2dNsaRk9PPWm
w7kAHBCgWsQRSvgdqa5KJxxyFKCKz88pb2qV/prKRrIDnqyh8rV+T6uxGwa+c4yW
fkUDeWsJmfENVqZCmr/I3QJXNIW13wi7UH1t6VVBVwqqfDJod/o7ts0iZqvx1Phd
ez8OR5nX4jZFF4JRRMiCXnHE4jx4EVqSG/yp9fkgxzY7TTx3N4buIzYCXjOjzSdH
F1Qv5BQ+9vUZpYhYOn8xdNSDmr73DP8WqaU9FN6VNgbvH8QGV5DQ5MLudTNUxuYU
9lOmrBM205DxbLp8PaGBlSD9r1WcS9MQV9YYsHd9yVQ2bDzMZwCeFbI5IimnEoSS
MZEraXuaFZ3T0zwalzu0/NNno6F50ivEx9dgo9+9c3zive4zAhbx2Va2H1x7q5+x
18Uqc3MOghgacrh8DyCxIFFRuq330QHD8TUQ9MhAo8y8KdR7Du3jhlMryjk6lPtN
To3kfwG/3KRt+XSM0UnzcMEwVPmUpdWZ/3HB3Ro3a1PoQ1yI9y4YdFqngiTtAWXr
GUl/sEwqM6GdZ2kMKlfEp/d3P2YZWOoBQ1VWmDXU8/etoxZGF0NhPSfU2/pIexRG
EedRaKrB0XZoJBFfS5NVIuNm64TbBRUyfT7Yc8AwM+rX7chb+wYOtsktp5zpEsTJ
KWVEa6NcKroOUb79P743
=ILAL
-----END PGP SIGNATURE-----
```
It seems our signing configuration regressed recently, likely when we switched to our new OpnePGP subkey.Sponsor 131 - Phase 3 - Major ESR 102 Migrationboklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40411Update the target SDK to 30 to support Android 11 in all projects2022-12-04T17:29:12ZcypherpunksUpdate the target SDK to 30 to support Android 11 in all projectshttps://bugzilla.mozilla.org/show_bug.cgi?id=1688062#c0https://bugzilla.mozilla.org/show_bug.cgi?id=1688062#c0Sponsor 131 - Phase 3 - Major ESR 102 Migrationhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40409Upgrade NSIS to 3.082022-10-18T12:23:59ZcypherpunksUpgrade NSIS to 3.08And sync with https://bugzilla.mozilla.org/show_bug.cgi?id=1728507And sync with https://bugzilla.mozilla.org/show_bug.cgi?id=1728507Sponsor 131 - Phase 3 - Major ESR 102 MigrationPier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40370Use buildconf/num_procs (RBM_NUM_PROCS) for firebox build2022-10-21T20:19:13ZboklmUse buildconf/num_procs (RBM_NUM_PROCS) for firebox buildWe have an option `buildconf/num_procs` (or the `RBM_NUM_PROCS` env variable) which we use to select the number of parallel jobs for builds. We use it in some components, but we currently don't use it for firefox.
According to https://f...We have an option `buildconf/num_procs` (or the `RBM_NUM_PROCS` env variable) which we use to select the number of parallel jobs for builds. We use it in some components, but we currently don't use it for firefox.
According to https://firefox-source-docs.mozilla.org/setup/configuring_build_options.html we can set this for firefox with a line like `mk_add_options MOZ_PARALLEL_BUILD=4` in the mozconfig file.
While changing this, maybe we can also change the default value of `buildconf/num_procs` (currently 4 if `RBM_NUM_PROCS` is not set) to be the number of cpus that can be seen in `/proc/cpuinfo`.Sponsor 131 - Phase 3 - Major ESR 102 Migrationboklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40158Tor Browser for macOS aarch642022-11-21T02:25:12ZMatthew FinkelTor Browser for macOS aarch64Mozilla Firefox tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1648496
Tor tracking bug: tpo/core/tor#40198Mozilla Firefox tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1648496
Tor tracking bug: tpo/core/tor#40198Sponsor 131 - Phase 3 - Major ESR 102 Migrationboklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/23656Use .mozconfig files in tor-browser repo for rbm builds2022-10-24T07:09:56ZGeorg KoppenUse .mozconfig files in tor-browser repo for rbm buildsRight now, if we need to change .mozconfig files, we need to change them both in the tor-browser repository and in tor-browser-build (see the respective note in `README.HACKING`).
We should find a way to leave the .mozconfig files in th...Right now, if we need to change .mozconfig files, we need to change them both in the tor-browser repository and in tor-browser-build (see the respective note in `README.HACKING`).
We should find a way to leave the .mozconfig files in the tor-browser repository for local builds outside of `rbm` (and only change them there when writing tor-browser patches) but use them nevertheless for `rbm`-based builds (probably with some modifications if needed).Sponsor 131 - Phase 3 - Major ESR 102 MigrationPier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40693Can't build container-image in main2022-12-09T10:33:00ZrichardCan't build container-image in mainlogs:
```
Starting build (script: pre): 2022-11-22 20:44:06
Ign http://deb.debian.org jessie InRelease
Get:1 http://security.debian.org jessie/updates InRelease [44.9 kB]
Get:2 http://deb.debian.org jessie-updates InRelease [16.3 kB]
Ig...logs:
```
Starting build (script: pre): 2022-11-22 20:44:06
Ign http://deb.debian.org jessie InRelease
Get:1 http://security.debian.org jessie/updates InRelease [44.9 kB]
Get:2 http://deb.debian.org jessie-updates InRelease [16.3 kB]
Ign http://deb.debian.org jessie-updates InRelease
Get:3 http://deb.debian.org jessie Release.gpg [1652 B]
Get:4 http://security.debian.org jessie/updates/main amd64 Packages [781 kB]
Get:5 http://deb.debian.org jessie-updates/main Translation-en [14 B]
Get:6 http://security.debian.org jessie/updates/main Translation-en [401 kB]
Get:7 http://deb.debian.org jessie Release [77.3 kB]
Ign http://deb.debian.org jessie Release
Get:8 http://deb.debian.org jessie/main Translation-en [4581 kB]
Get:9 http://deb.debian.org jessie/main amd64 Packages [6818 kB]
Get:10 http://deb.debian.org jessie-updates/main amd64 Packages [20 B]
Fetched 12.7 MB in 1s (7590 kB/s)
Reading package lists...
W: GPG error: http://deb.debian.org jessie-updates InRelease: The following signatures were invalid: KEYEXPIRED 1668891673
W: GPG error: http://deb.debian.org jessie Release: The following signatures were invalid: KEYEXPIRED 1668891673
Ign http://deb.debian.org jessie InRelease
Hit http://security.debian.org jessie/updates InRelease
Get:1 http://deb.debian.org jessie-updates InRelease [16.3 kB]
Ign http://deb.debian.org jessie-updates InRelease
Hit http://security.debian.org jessie/updates/main amd64 Packages
Get:2 http://deb.debian.org jessie Release.gpg [1652 B]
Get:3 http://security.debian.org jessie/updates/main i386 Packages [781 kB]
Ign http://deb.debian.org jessie-updates/main amd64 Packages/DiffIndex
Hit http://deb.debian.org jessie-updates/main Translation-en
Hit http://deb.debian.org jessie Release
Ign http://deb.debian.org jessie Release
Hit http://security.debian.org jessie/updates/main Translation-en
Ign http://deb.debian.org jessie/main amd64 Packages/DiffIndex
Hit http://deb.debian.org jessie/main Translation-en
Get:4 http://deb.debian.org jessie/main i386 Packages [6821 kB]
Get:5 http://deb.debian.org jessie-updates/main i386 Packages [20 B]
Hit http://deb.debian.org jessie/main amd64 Packages
Hit http://deb.debian.org jessie-updates/main amd64 Packages
Fetched 7620 kB in 1s (5732 kB/s)
Reading package lists...
W: GPG error: http://deb.debian.org jessie-updates InRelease: The following signatures were invalid: KEYEXPIRED 1668891673
W: GPG error: http://deb.debian.org jessie Release: The following signatures were invalid: KEYEXPIRED 1668891673
Reading package lists...
Building dependency tree...
Reading state information...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Reading package lists...
Building dependency tree...
Reading state information...
The following extra packages will be installed:
autoconf automake autotools-dev libalgorithm-c3-perl libarchive-extract-perl
libcgi-fast-perl libcgi-pm-perl libclass-c3-perl libclass-c3-xs-perl
libcpan-meta-perl libdata-optlist-perl libdata-section-perl libfcgi-perl
liblog-message-perl liblog-message-simple-perl libmodule-build-perl
libmodule-pluggable-perl libmodule-signature-perl libmro-compat-perl
libpackage-constants-perl libparams-util-perl libpod-latex-perl
libpod-readme-perl libregexp-common-perl libsigsegv2
libsoftware-license-perl libsub-exporter-perl libsub-install-perl
libterm-ui-perl libtext-soundex-perl libtext-template-perl m4 perl
perl-modules rename
Suggested packages:
autoconf-archive gnu-standards autoconf-doc libtool gettext perl-doc
libterm-readline-gnu-perl libterm-readline-perl-perl make libb-lint-perl
libcpanplus-dist-build-perl libcpanplus-perl libfile-checktree-perl
libobject-accessor-perl
Recommended packages:
libarchive-tar-perl
The following NEW packages will be installed:
autoconf autoconf2.13 automake autotools-dev libalgorithm-c3-perl
libarchive-extract-perl libcgi-fast-perl libcgi-pm-perl libclass-c3-perl
libclass-c3-xs-perl libcpan-meta-perl libdata-optlist-perl
libdata-section-perl libfcgi-perl liblog-message-perl
liblog-message-simple-perl libmodule-build-perl libmodule-pluggable-perl
libmodule-signature-perl libmro-compat-perl libpackage-constants-perl
libparams-util-perl libpod-latex-perl libpod-readme-perl
libregexp-common-perl libsigsegv2 libsoftware-license-perl
libsub-exporter-perl libsub-install-perl libterm-ui-perl
libtext-soundex-perl libtext-template-perl m4 perl perl-modules rename
0 upgraded, 36 newly installed, 0 to remove and 0 not upgraded.
Need to get 8272 kB of archives.
After this operation, 43.2 MB of additional disk space will be used.
WARNING: The following packages cannot be authenticated!
libsigsegv2 m4 autoconf autoconf2.13 autotools-dev automake
libalgorithm-c3-perl libarchive-extract-perl libcgi-pm-perl libfcgi-perl
libcgi-fast-perl libclass-c3-perl libclass-c3-xs-perl libcpan-meta-perl
libparams-util-perl libsub-install-perl libdata-optlist-perl
libmro-compat-perl libsub-exporter-perl libdata-section-perl
liblog-message-perl liblog-message-simple-perl libmodule-pluggable-perl
libpackage-constants-perl libpod-latex-perl libregexp-common-perl
libpod-readme-perl libtext-template-perl libsoftware-license-perl
libterm-ui-perl libtext-soundex-perl rename
E: There are problems and -y was used without --force-yes
Finishing build (script: pre): 2022-11-22 20:44:13
Build time: 0 hours 0 minutes and 7 seconds
```Sponsor 131 - Phase 4 - Browser Release Management