15:00:57 <morganava> #startmeeting Tor Browser Weekly Meeting 2024-08-19
15:00:57 <MeetBot> Meeting started Mon Aug 19 15:00:57 2024 UTC.  The chair is morganava. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:57 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:01:07 <boklm> o/
15:01:31 <dan_b> o/
15:01:36 <morganava> the pad as usual: https://pad.riseup.net/p/tor-tbb-keep
15:01:50 <morganava> last week dan_b and I built Tor Browser 14.0a2 \o/
15:01:52 <clairehurst> o/
15:02:06 <morganava> and Android signed scucessfully \o/
15:02:08 <PieroV> But it doesn't match on Android /o\
15:02:10 <ma1> \o/
15:02:10 <morganava> but Android's not reproducible :(
15:02:21 <morganava> and also x86 and x86_64 are too big for the google play store
15:03:01 <clairehurst> oh damn
15:03:16 <morganava> i also didn't get a chance to try to install the aarch64 builds so who knows if it runs vOv
15:03:37 <PieroV> How do we feel about upx for a temporary workaround on the sizes?
15:03:46 <morganava> upx?
15:04:00 <PieroV> A compressor for binaries
15:04:04 <clairehurst> I can work on trying to get them smaller today. There are unused firefox assets for instance
15:04:27 <morganava> so I looked briefly at where our size budget is going over the weekend
15:04:39 <PieroV> I managed to find a way to save 6.6MB
15:04:40 <morganava> and probably unsurprisingly it's ours libs :p
15:04:48 <PieroV> We still need 2.7MB
15:04:49 <morganava> in which case upx sounds like a good start
15:05:12 <morganava> by my estimates we need at most ~12MB i think
15:05:17 <PieroV> If we don't want UPX we can use LZMA or something else and then extract before calling the PTs on the first launch
15:05:21 <morganava> based on the sizes from 13.5a9
15:05:27 <PieroV> Nah, it's less than 19MB
15:05:29 <PieroV> 10MB
15:05:37 <PieroV> ~9338754 bytes
15:06:00 <morganava> i also don't think this is a blocker for 14.0a2 since it's (currently) only affecting the two skus we don't *really* care about
15:06:11 <PieroV> Was aarch64 (110788003 bytes) accepted?
15:06:16 <morganava> sorry to our 5 x86_64 and x86 users
15:06:21 <morganava> yeah both arms are fine
15:06:39 <PieroV> Then I confirm that it's 9.3MB
15:06:48 <morganava> \o/
15:07:11 <PieroV> Also, I discovered we don't pass optimization flags to tor
15:07:16 <morganava> so what are the implications of this UPX thing?
15:07:18 <bellatchau> o/ late aaaaand now here
15:07:22 <PieroV> I don't know if autoconf/automake/whatever does it for us
15:07:47 <PieroV> But we can try to pass -Os as a CC flag (and -O2 to all other platforms if it isn't automatic!)
15:08:10 <PieroV> UPX compress the binaries and adds its own thin decompressor to them
15:08:17 <morganava> sounds smart
15:08:21 <morganava> I don't suppose a similar flag exists for go
15:08:33 <PieroV> Yes, but we already use it
15:09:11 <PieroV> We don't pass the flag to remove the debug symbols, but they're removed with strip. We can try to pass also -w to see if it's better than stripping then
15:09:53 <morganava> libSnowflake.so, libConjure.so, and libObfs4proxy.so (why isn't this lyrebird?) are the big ones at 37mb, and of course libxul.so at 139mb
15:10:06 <PieroV> morganava: are you using IEC units?
15:10:10 <PieroV> You should use SI :P
15:10:26 <morganava> who knows, whatever my linux uses
15:10:44 <morganava> i prefer the power of 2-based ones whichever that is :p
15:10:59 <PieroV> :(
15:11:28 <dan_b> agreed. isnt base 10 ones just a marketing scheme to say things are bigger than they are?
15:11:34 <morganava> how feasible would it be to prioritise the application-services removal for the 14.0 release
15:11:35 <PieroV> Nope
15:11:39 <PieroV> Base 10 is whatever everything else uses
15:11:45 <PieroV> Nothing is enough special to get exceptions
15:12:00 <dan_b> intersting
15:12:24 <PieroV> Anyway, we should check if Android somehow has an xz decompressor so that we can avoid providing one
15:12:33 <PieroV> I'm sure Firefox has it more or less on desktop
15:12:51 <PieroV> As it's used for updates
15:14:21 <PieroV> Otherwise xz itself is less than 100kB... zstd would be 1.4MB D:
15:16:06 <morganava> is this going to require some manual decompression patch in TBA or is this some built-in packaging solution you're suggesting?
15:16:21 <PieroV> Decompression patch alas
15:16:28 <PieroV> whereas UPX would be automatic
15:16:38 <morganava> 😬
15:16:38 <PieroV> But it'll include it in all the binaries
15:17:00 <PieroV> And it'd decompress the payload at each run
15:17:21 <PieroV> Also, upx has a bad reputation for some antimalware because it's used also by many malware
15:17:26 <PieroV> Like NSIS, in a certain sense
15:17:35 <morganava> probably less of an issue for android tho
15:17:44 <morganava> unless the google play store gets pissy with us
15:19:09 * morganava reading
15:19:14 <morganava> alright it's worht a shot
15:19:31 <PieroV> UPX itself saves almost 4MB
15:20:00 <morganava> in total? per so?
15:20:02 <PieroV> Another trick is that we can remove the geoip files since we don't have the circuit display
15:20:23 <PieroV> morganava: in total, compared to deflating our binaries
15:20:40 <PieroV> There's a nice command that is called zipinfo
15:21:15 <PieroV> It's a sort of `ls -l`, which also outputs the compressed size with the appropriate options (`zipinfo -lh`)
15:21:32 <PieroV> So, I compared the binaries compressed with UPX with the already compressed size in the APK
15:21:33 <morganava> alright, if you come up with any more ideas please create issues and link to tor-browser#42669
15:21:51 <PieroV> Assuming UPX binaries will be stored without additional compression
15:23:27 <morganava> er I meant tor-browser#42607
15:23:31 <morganava> :D
15:23:33 <ma1> :)
15:24:24 <morganava> in any event, do we have any leads on the reproducibility issue?
15:24:36 <PieroV> I have a patch, and I'm building
15:25:46 <morganava> ok, is there any objection to releasing 14.0a2 (Desktop) now and 14.0a2 (Android) in a subsequent -build2?
15:25:59 <PieroV> We're very close to it
15:26:16 <dan_b> wfm
15:26:21 <PieroV> Like, if the problem is solved we can start building already
15:27:27 <dan_b> 🤞
15:27:44 <morganava> alright, i'll hold off on pushing the button
15:27:49 <morganava> blog post will take a bit to write regardless
15:28:37 <morganava> ok, any other fun things to go over?
15:28:50 <PieroV> I do
15:29:17 <PieroV> So, we've merged the Android patchset
15:29:45 <morganava> yes!
15:29:53 <PieroV> There are some low hanging fruit for improving the health patchset, but we decided to merge not to delay the builds even more
15:30:18 <PieroV> Low hanging fruit = some files/additions that are added in some legacy commits and removed in the latest developments
15:30:41 <PieroV> So, there are two possible strategies
15:31:15 <PieroV> 1. we fix a few issues like this, to reduce the cognitive load of the actual patchset refactor
15:31:37 <PieroV> 2. we do everything in a single step (but probably not enough time for 14.0, which is scheduled in a month?)
15:32:08 <dan_b> so i vote 1. there is so much patchset health work i think it really makes sense to break it into bits we do along the way
15:32:10 <PieroV> What do people think about this?
15:32:19 <dan_b> otherwise its a biiiig project and we'll prolly never have time for it
15:32:24 <morganava> i think i'm inclined to agree
15:32:25 <PieroV> Yeah, I tend to agree
15:32:52 <ma1> +1
15:35:41 <morganava> I'm happy sneaking in a bit of refactor each week through the 14.0 release cycle
15:35:56 <morganava> and hopefully that will get us to a happy(ier) place in October
15:36:06 <PieroV> I think this one will need a -2 rebase sooner or later
15:36:56 <morganava> yeah for sure
15:37:12 <PieroV> We might add some desktop shuffling as well
15:37:27 <PieroV> I'm not sure on how to do it, but we can somehow arrange
15:38:59 <morganava> I think we should start with re-arranging within the android block
15:39:26 <PieroV> Yeah, but IIRC Henry had some requests for the desktop block as well
15:39:54 <morganava> and then once we're satisfied w/ the base-browser/tor-browser split, only then migrate/distribute the commits to the 'right' place
15:42:04 <morganava> ok, any other discussion points?
15:42:12 <morganava> otherwise we can adjourn :)
15:43:44 <PieroV> Nothing from me
15:44:02 <ma1> have we got any sense of how long we will support esr115 after 14 is released? (re: Windows legacy)
15:44:23 <PieroV> We should ask tjr now that he's back at work
15:44:44 <PieroV> I looked for official news last week
15:44:49 <PieroV> But Moz didn't say anything officially
15:45:03 <morganava> he responded in the meeting pad actually
15:45:04 <PieroV> (I don't know how official can that Reddit answer be considered)
15:45:11 <boklm> "[tjr] Ryan says "We're working on finalizing the decision brief for running 115 6 more months ASAP, technically still not decided""
15:45:35 <PieroV> FWIW, I think beginning of January would be the maximum we should support
15:45:43 <PieroV> It'll be 5 years after Windows 7 EOL
15:46:11 <ma1> and Windows only, if that's the case, right? The sooner we drop Android the better :P
15:46:17 <PieroV> Yes
15:46:22 <morganava> oh yeah Android would be dropped :3
15:46:23 <PieroV> Maybe macOS
15:46:32 <PieroV> But I'd be in favor of supporting Windows only
15:46:32 <morganava> and yes on that^
15:46:46 <PieroV> morganava: macOS also aarch64?
15:46:58 <PieroV> I think all aarch64 can update to 10.15 or later
15:47:23 <morganava> i hadn't actually thought about macOS
15:47:35 <morganava> beyond 'yeah it's a possibility'
15:47:48 <morganava> given that i don't think i've seen anyone asking for it
15:48:13 <morganava> i'm inclined to ignore macOS for a legacy 13.5 channel
15:48:51 <PieroV> Now that I think of it, I think for aarch64 we already had 10.15 as a minimum version in the SDK, but I should check
15:49:31 <morganava> hmm
15:50:04 <morganava> well in any event, we should plan on developing w/e patch we need to split off legacy windows if the upgrade to 14.0 isn't possible
15:50:29 <morganava> and hopefully mozilla gives us some guidance in a timely fashion
15:51:34 <morganava> alright in the meantime
15:51:37 <morganava> have a good week o/
15:51:47 <morganava> #endmeeting