11:00:12 #startmeeting Tor Browser Weekly Meeting 2022-07-05 11:00:12 Meeting started Tue Jul 5 11:00:12 2022 UTC. The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot. 11:00:12 Useful Commands: #action #agreed #help #info #idea #link #topic. 11:00:32 o/ 11:00:46 richard, it's actually late evening here (I have non-24 disorder :) ) but good morning to you too :) 11:00:52 as usual, please ensure your boards are up to date and update the pad here: https://pad.riseup.net/p/tor-tbb-keep 11:09:49 ok folks 11:11:27 surprising nobody, the 11.5 release is not coming out today 11:12:05 lol 11:12:12 * Jeremy_Rand_Talos__ admittedly is not up to speed on the messiness in that area but will take your word for it 11:13:21 given that the latest stable/alphas were published on the 2nd I'm goign to push this back at least a week, unless we run into/have run into any major bugs that need to be fixed 11:13:45 WFM 11:14:07 PieroV: I'm not planning on an 11.0.16 release 11:14:23 We have a pair of S96 things to fix (I think I'll need donuts's last word for them) 11:14:51 And 3-4 other things that weren't included in the current 91.11/11.5 stable MR 11:14:52 are they minor UX type stuffs? 11:15:01 Nope, one is the bridgemoji emoji revision 11:15:07 ahhh right 11:15:16 well at least those are testable in nightly then 11:15:32 With the conversion to SVG (it's ready, and I have 2-3 quick&dirty scripts to update the SVGs, if needed) 11:15:51 i'll focus on MRs this week before anything else then 11:16:09 (because old macOS versions don't display all the emojis we chose for bridgemoji, and the SVGs are needed for having the same look in all platforms) 11:16:32 so we're not having a 91.11 release until next week? 11:16:39 Another one for S96 is a text to improve (Add brdiges manually removes all previous bridges) 11:17:25 And IIRC the final issue for S96 is that Tor status is displayed in `about:preferences` without any fragment (which could be an upstream issue on how the about:preferences page has been made) 11:18:25 boklm: that's right, I'll see about having build tags ready asap 11:18:37 iirc I already have an MR for the rebase ready 11:18:52 barring any last minute fixes 11:18:53 Another blocker for 11.5 is macOS bundled fonts (which we can anticipate, the patch is ready, but I wanted Moz to review it, first) 11:19:24 richard: will that be 11.5 or 11.0.16? 11:21:34 11.5, assuming there aren't any major/difficult to test in nightly patches merged 11:21:48 unless folks think that is unwise of course 11:21:50 ok 11:22:16 how many people routinely run Nightly compared to Alpha? 11:22:30 so we build end of this week, and publish begining of next week? 11:22:40 (I have a machine that runs Nightly routinely, but I don't know if I'm a common user) 11:23:13 relatively few compared to alpha and stable, but the things like svgs for bridge emojiis are failry 'simple' to test 11:23:21 ok 11:23:22 I'm also running nightly, but probably not many people are 11:23:24 boklm: that's right 11:24:37 ironically a bunch of Namecoiners are running Nightly because of its experimental integration, I wonder how much that affected the total Nightly userbase numbers... 11:25:43 and re: Android I'm planning to bump stable up to the current alpha firefox version (99 irc) and then subsequently bump alpha to 102, then keep everyone on the esr 102 train over the next year 11:26:11 richard: sounds okay, but I think we are missing the audits for 97-98-99 11:26:21 it seems we don't have nightly on https://metrics.torproject.org/webstats-tb-channel.html, but maybe that could be added 11:26:52 richard, is there an estimate for when desktop Nightly will switch to ESR102? (Knowing this would help me plan for whatever ARM/POWER rebases I need to do) 11:27:33 so ESR102 migration work will be starting *soon* 11:27:59 it's hard to esimate given we don't yet know what work will be needed to be done to tor-browser-build:master to even get nightlies *building* 11:28:22 Does ESR102 depend on me moving tor-launcher and torbutton? 11:28:25 richard, safe to assume there will be at least a week or two where Nightly's toolchain is horribly broken, and I shouldn't try to rebase against it until resolved? 11:30:16 I think we'll try to avoid merging the toolchain updates until it's not horribly broken 11:30:20 PieroV: no not completley, we can start work on 102 stuff w/o the s131 changes being locked in yet 11:30:34 boklm, ok, cool 11:31:03 i would expect that to all start after 11.5 is out the door 11:31:04 richard: I can start working on them as soon as I finish with the current things (this week, probably) 11:31:16 excellent 11:31:31 oh, okay. Of course, if there's anything more we want to fix before 11.5 goes stable I'll do that 11:31:38 I'm going to be mostly occupied for the next 2 weeks, I'll check in again about ESR102 status after that, and plan rebases accordingly 11:31:46 (there are a few minor things, like the errors in the JS console) 11:33:31 I would like to avoid any more patches for 11.5 than can be avoided 11:34:18 Jeremy_Rand_Talos: so what's the summary on this PPC 11:34:32 PPC patch* 11:35:07 richard, basically, upstream Firefox doesn't have a JIT for ppc64le, so JS performance in Tor Browser looks similar to what x86 looks like with Safer mode on always. 11:35:29 mmhm 11:35:42 richard, there's a patch that implements a JIT, written by a ppc64le community member (who also maintains TenFourFox, so he knows the Firefox codebase well) 11:36:18 he intends to upstream it to Firefox sometime after ESR102, but the patch apparently works fine right now; seems a lot of community members run it in production with no issues 11:37:05 neat 11:37:31 My inclination is to include it in Tor Browser before upstream Firefox merges it; it shouldn't be a maintenance issue for Tor, it's just a patch file you apply to the Firefox source 11:37:42 so I presume this is blocked by enabling ppc builds in tor-browser-build (which iirc is itself blocked on arm?) 11:37:46 But obviously I wanted to run that by you guys 11:38:18 richard, yes, that is correct, though it should be easy for me to enable the JIT patch next time I rebase the ppc64le MR 11:38:32 mmhm 11:38:52 Jeremy_Rand_Talos__: do you mean a patch file to apply at build phase, or to include as a commit in the patch set? 11:39:00 so tbh I would rather wait until it's merged upstream 11:39:04 PieroV, at build phase in tor-browser-build 11:39:18 Would be conditional on the ppc64le target 11:39:39 as by then presumably there will have been reviewed/audited by Mozilla devs 11:39:46 richard, if that is your preference, that's fine for me 11:39:46 is that a big patch? and are we likely to have conflicts with this patch when we update to new 102 releases? 11:40:07 boklm, lemme check the patch size, one sec... 11:40:59 i would expect a new JIT backend/target to be a bit of a hefty :p 11:41:26 boklm, the .patch file is 3441 lines (including lines that surround the changed lines), but apparently Void hasn't needed to change the patch since they introduced it for 91.4.1 11:41:46 So yeah, it's big, but doesn't seem to affect code areas with a lot of churn 11:41:46 but i'm motly concerned because I don't think any of us has necessarily has the expertise to audit/review a ppc code generator 11:41:58 richard, yeah, that's a fair concern. 11:42:13 it sounds like something i'd be willing to backport to 102 once it is upstream 11:42:38 yes, backporting once it is upstream sounds better 11:42:49 alright, sounds good to me 11:42:56 ok 11:43:50 any opinions on the POWER8 vs POWER9 question that's raised in the beginning of that GitLab comment? 11:44:19 what does the current branch do? 11:44:32 I would assume having skimmed we should update the toolchain if firefox depends on POWER9 11:45:11 boklm, the MR I submitted is inconsistent, it uses POWER8 for GCC but POWER9 for Firefox, due to sloppiness on my end. Either of those can be switched. 11:45:34 ah, it seems we're half power8 and power9, so in practice we require power9? 11:45:55 boklm, right. I would like to make it consistent, just would like to come to a consensus on what we should switch it to. 11:46:36 The firmware freedom issue and multiplication issue with POWER8 make it somewhat unattractive to me 11:46:57 I believe some major Linux distros like Ubuntu are now dropping POWER8 support FWIW 11:47:25 i would lean toward newer being better, but really I think it would come down to what the actual users would need at this point 11:47:40 I think it's fine to do the same as major Linux distros 11:48:02 (newer legacy architecture being better in terms of maintenance effort) 11:48:23 richard, yeah, so I don't have any numbers on actual users. The main POWER8 desktop machines in use now are Tyan machines that got dumped on eBay a few years ago by some corporate entity who didn't need them anymore 11:48:47 Whereas POWER9 machines are still easy to buy new 11:48:59 wow really? 11:49:10 I saw powerppc and immediatley thought legacy macs 11:49:30 boklm, to be clear, not all distros are dropping POWER8 yet, I think Ubuntu may be an outlier 11:49:49 or xbox360/ps3 :p 11:49:53 richard, POWER9 machines can be bought new from https://www.raptorcs.com/ 11:49:57 richard: there are modern power cpus, they're very open and very cool 11:50:21 remarkable 11:51:04 richard, POWER9 has fully open firmware, direct from the vendor, so you don't need to reverse-engineer/hack stuff like the old Libreboot machines do 11:51:25 FSF RYF certified, even 11:52:11 well ok anywy 11:52:58 yeah so my inclination is to drop POWER8, but if you guys disagree with that inclination, I'll defer to you 11:53:17 sounds reasonable to me 11:53:28 We can always re-enable POWER8 later with a 2-line patch if users ask for it 11:53:41 cool 11:53:46 is there anything else? 11:53:52 nothing else from me 11:53:54 otherwise i'm going to call it 11:53:59 Nothing from me either 11:54:48 ok then 11:55:01 #endmeeting