15:02:09 <richard> #startmeeting Tor Browser Weekly Meeting 2024-06-17
15:02:09 <MeetBot> Meeting started Mon Jun 17 15:02:09 2024 UTC.  The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:09 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:02:23 <jwilde> o/
15:02:26 <boklm> o/
15:02:37 <manuel[m]> o/
15:02:42 <ma1> o/
15:02:45 <richard> just a heads up, i'm intermittently afk today
15:02:53 <richard> our meeting pad -> https://pad.riseup.net/p/tor-tbb-keep
15:02:54 <ruihildt[m]> o/
15:04:32 <richard> only update from me is that I'll be doing a final pass on the changelog after this meeting, and once we're happy i'm planning to tag and kick a build for 13.5 \o/
15:04:42 <clairehurst> o/
15:05:10 <richard> are there any 13.5-related updates or issues I should be aware that need attention?
15:05:11 <richard> blockers/
15:05:11 <richard> ?
15:05:42 <PieroV> I went through QA for Linux + Windows x86_64 and i686
15:05:50 <ruihildt[m]> It will be an alpha build?
15:05:58 <PieroV> But I haven't covered macOS
15:06:11 <ma1> I was planning to do MacOS x86 today
15:07:00 <ma1> (and we've got busted PTs on Linux?)
15:07:29 <PieroV> However, I haven't tested too throughfully security level (I checked whether JS worked and click to play for example, but not all the features we change)
15:07:37 <PieroV> ma1: they might be nightly-only
15:07:48 <PieroV> I should probably spin a VM and test also there
15:08:29 <donuts> richard: I've started a blog branch for the release post
15:08:33 <richard> ruihildt[m]: release build
15:08:33 <donuts> will loop you into the MR
15:08:40 <richard> ooh great
15:08:52 <richard> what's the issues with PTs?
15:09:58 <PieroV> This morning I tested a nightly to do QA there, to avoid rebuilding the fake release to include HEAD of tor-browser.git
15:10:09 <PieroV> (my fake-release is at current HEAD^)
15:10:15 <richard> nice
15:10:16 <PieroV> And PTs didn't work
15:10:43 <PieroV> I know that we build some PTs from their branch instead of a tag/commit
15:10:51 <richard> but just on Linux?
15:11:01 <PieroV> Yes, I moved to the fake-release for the rest
15:11:15 <PieroV> So I didn't test nightlies on other platforms
15:11:31 <ruihildt[m]> richard: thx, so when can I expect a signed build to test?
15:11:39 <PieroV> The logs included some messages about PTs diying with status code 13
15:11:57 <boklm> we build lyrebird from the `main` branch in nightly
15:12:02 <richard> ruihildt: no sooner than tomorrow afternoon your time
15:12:12 <ruihildt[m]> ack
15:12:28 <PieroV> boklm: Snowflake was also busted
15:12:54 <boklm> snowflake should be the same in alpha and nightly
15:16:09 <dan_b> if i want to do anrdoid QA especially testing the updater, should i wait till the 13.5 stable build and test 13.0.16 bride settings to 13.5 rc ?
15:17:42 <boklm> do we have an updater in android?
15:18:00 <richard> just manual build-to-build
15:18:02 <dan_b> i'd just start with a 12.0.16 apk and the install the new one on top
15:18:09 <dan_b> ok
15:18:19 <PieroV> boklm: no, we don't, we can just reinstall
15:18:22 <richard> but yeah iirc clairehurst did a similar test with alpha to alpha
15:18:36 <PieroV> I also did with 13.0.16 to my fake release
15:18:59 <dan_b> yes i saw so feeling good, but wanted to make sure the user provided bridges got well tested
15:19:09 <dan_b> but it's looking solid
15:20:12 <clairehurst> richard: yep!
15:20:33 <clairehurst> Basically a smoke test
15:24:10 <manuel[m]> so, the content signing certificate (addons, gmp) rotated for 115 and 128. Not sure how affected tor browser is.
15:24:24 <henry-x> richard what is the status on tor-browser!1039 ? Do we need the offline state fixed for the stable release?
15:25:25 * richard reading
15:26:41 <manuel[m]> (just to make you aware of it, one small warning is that Android 115 wasn't tested by QA in Firefox. The version Tor Browser Android is based on. I've put the infos into the discussion section of the meeting-notes doc)
15:26:59 <ruihildt[m]> ()
15:27:26 <ruihildt[m]> sorry meant: (I have a point to raise, is the etiquette to wait for the current discussion to complete?)
15:27:47 <PieroV> ruihildt[m]: we have a list of discussions in the pad
15:28:10 <richard> henry-x: ok i don't think this is a blocker for 13.5
15:28:34 <richard> but seems like we should revisit for 14.0
15:28:47 <henry-x> ok
15:29:10 <richard> <richard> henry-x: ok i don't think this is a blocker for 13.5
15:29:12 <richard> <richard> but seems like we should revisit for 14.0
15:29:36 <richard> manuel: do you mean Firefox ESR 115 for Android isn't tested by QA?
15:29:40 <ruihildt[m]> PieroV: Ok added to the pad.
15:30:35 <manuel[m]> Yes, the cert replacement wasn't tested by QA, probably due to esr version not being shipped there.
15:30:50 <richard> ah ok
15:30:58 <richard> more fun
15:31:45 <richard> manuel: is there a firefox-android patch we would need to backport, or is this all handled in geckoview?
15:32:52 * manuel[m] looking through docs now
15:33:19 <richard> ok in the meantie, did you have something rui?
15:33:22 <richard> meantime*
15:33:38 <ruihildt[m]> Yes thanks:
15:33:38 <ruihildt[m]> Do you think it would be good to make the MB alpha build more public on Mullvad website? (now that the alpha/beta naming question is settled)
15:34:20 <richard> my first instinct is 'yes definitely'
15:34:43 <richard> unless anyone has a good reason not to do so, i only see upside
15:35:34 <ma1> we often complain about lack of alpha testers, so +1
15:35:39 <ruihildt[m]> Ok, then I'll look if I can have that "shipped" with 13.5
15:36:02 <richard> there will be some lag time before 14.0a1 is ready
15:36:08 <ruihildt[m]> The only question remaining for me is conceptually how should we add this to the repositories.
15:36:32 <ruihildt[m]> Mullvad has a stable and a beta channel.
15:36:56 <ruihildt[m]> We could add it to either or to both.
15:37:30 <richard> package repos you mean?
15:37:37 <ruihildt[m]> But the Mullvad VPN app only allows one of the channels, since the package name is the same.
15:37:50 <richard> right
15:37:51 <ruihildt[m]> Yes.
15:38:14 <ruihildt[m]> I'm not sure if it's a question for you or for us tbh.
15:40:30 <richard> yeah i don't know what makes sense
15:40:49 <richard> given there's no name collision you can probably just put them both in the same apt repo
15:42:16 <richard> PieroV: what's this about windows-gnullvm?
15:42:41 <ruihildt[m]> Ok, I'll go with that idea and discuss with our repositories maintainers if they have stronger opinions. :D
15:42:42 <PieroV> So, I've worked on updating tor-browser-build for 128
15:43:24 <boklm> it makes sense to put both in the stable repo if you want to increase the number of alpha users
15:43:25 <PieroV> And the good news is that I got desktop to build (except MB on Windows, we'll have to investigate on some mingw problems with windows.graphics.h, and some D3D interfaces)
15:44:14 <PieroV> However, I got a problem with Windows also for Tor Browser: it isn't reproducible because of Rust (and maybe because of the GCC-based mingw toolchain)
15:45:42 <richard> webrtc related stuff for MB?
15:45:58 <PieroV> (I guess the Rust toolchain is usually pretty deterministic, but it might include some parts of mingw-w64, which has a lot of different artifacts; std is the only different thing between the build done in my computer and in tb-build-03)
15:46:20 <PieroV> Yes, the problem is in WebRTC. Tor Browser builds because it doesn't have WebRTC
15:46:25 <richard> righto
15:46:25 <PieroV> In particular video capturing
15:47:29 <PieroV> So, since we've had for a long time an issue about building Rust with mingw built only with LLVM stuff, I tried to check if this is enough to solve the reproducibility problem (and finally get rid of the GCC-based mingw)
15:47:40 <PieroV> The good news is that it is
15:48:16 <richard> is there bad news?
15:48:20 <PieroV> The other good news is that a LLVM-based (esp. libunwind) Rust is an official thing and it's been promoted from tier 3 to tier 2
15:48:32 <richard> ooh nice
15:48:39 <PieroV> The bad news is that it's considered a different target
15:49:01 <PieroV> {i686,x86_64,aarch64}-pc-windows-gnullvm instead of ...-pc-windows-gnu
15:49:42 <PieroV> Firefox can use only ...-pc-windows-gnu, because it doesn't recognize gnullvm as a valid thing. I have a patch to solve also this problem, but I see a couple of problems:
15:50:10 <manuel[m]> richard: The cert-update will be in esr 115.13 released alongside 128 (https://whattrainisitnow.com/release/?version=128). Not sure how your normal procedure is, but if you rebase it should be included (however untested).
15:50:11 <PieroV> 1. the gnullvm toolchain isn't validated upstream (even though I assume the biggest difference is libunwind+compiler-rt vs libgcc)
15:50:43 <PieroV> 2. modifying Firefox's build system to accept both gnu and gnullvm isn't trivial
15:50:55 <manuel[m]> richard: couldn't quickly find where the change is done in android or how QA tested it. Will follow up when I find the relevant infos.
15:51:01 <richard> manuel: thx we'll keep an eye out on extension installation for TBA next release
15:51:02 <thorin> /o just arrived .. did I miss anything
15:51:19 <richard> oooh
15:51:29 <richard> so that's where the difficulty lies
15:51:44 <PieroV> rustc supports both, so --print supported-targtets lists both gnu and gnullvm
15:51:54 <PieroV> And the build system can't decide which one to use... So it gives up
15:52:10 <PieroV> Instead of trying both and check if you have at least std for one of the two
15:52:11 <richard> thorin: just the usual :)
15:52:35 <richard> hmm ok
15:52:44 <richard> so the supportd version works but isn't reproducible
15:52:56 <PieroV> * rustc --print target-list
15:53:13 <PieroV> Yes, the supported version works, but we have an issue to move to LLVM anyway
15:53:16 <richard> and the unsupported one is reproducible but we need to fix firefox's build system to use it?
15:53:19 <PieroV> And I opened an upstream Bug
15:53:30 <PieroV> But I haven't received any answer yet
15:53:59 <richard> this may be a try both and go with whichever works first type of situation
15:54:10 <PieroV> Yes, the unsupported is reproducible and we have to fix the build system... Also, the supported is distributed with rustup
15:54:17 <PieroV> The unsupported isn't
15:55:09 <richard> ooh
15:55:12 <PieroV> So, you'd have to build std for gnullvm on your own/extract it from tor-browser-build, or use x86_64-pc-windows-gnu locally and remove the patch to use gnullvm (unless we keep the patch in tor-browser-build)
15:55:30 <richard> so this would make windows on windows builds a pain?
15:55:48 <richard> well, any windows dev builds windows or no
15:55:50 <PieroV> I think Windows on Windows uses x86_64-pc-windows-msvc
15:56:07 <PieroV> jwilde: what do you think about this?
15:56:40 <PieroV> (also, we don't have much time left, so we might have to continue elsewhere)
15:57:06 <richard> yeah happy to move over to tor-browser-dev after
15:57:55 <richard> ok, let's signoff for now and migrate over to #tor-browser-dev for the remainder of Rust+Windows chat
15:58:18 <richard> as always have a good week folks o/
15:58:20 <richard> #endmeeting