17:59:59 <GeKo> #startmeeting tor browser
17:59:59 <MeetBot> Meeting started Mon Apr 23 17:59:59 2018 UTC.  The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:59 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:00:04 <GeKo> hi all!
18:00:32 <GeKo> the meeting pad, as usual, is at https://storm.torproject.org/shared/tHoN4Ii7rLSjPE0OP4gydX4cMGadsXmRQNc-6lwru0N
18:00:44 <GeKo> please add your items and read over the other ones
18:00:46 <isabela> !
18:01:49 <mcs> hi
18:02:04 <igt0> hello
18:02:11 <arthuredelstein> hi everyone!
18:03:19 <antonela> hi!
18:03:53 <pospeselr> hello
18:04:47 <boklm> hi!
18:07:16 <GeKo> okay, let's get started
18:07:39 <GeKo> i don't see anything bold so far!
18:07:49 <GeKo> i wonder whether that's good or not :)
18:07:51 <GeKo> anyway
18:08:20 <GeKo> mcs: are we having a plan for the updater in esr60 or is there still stuff to be sorted out?
18:08:57 <GeKo> i wonder about the hash length and whether we should switch to 384bit
18:09:01 <GeKo> too
18:09:08 <mcs> GeKo: We have a plan but Kathy and I need to file some tickets for handing the transition of the MAR file format.
18:09:31 <GeKo> okay, sounds good to me!
18:09:36 <mcs> I think we want SHA384 and lz compression (what Mozilla is using). Should make our life better in the long run.
18:10:18 <GeKo> ok, fine with me
18:11:43 <sysrqb> seems like arthuredelstein has discussion questions?
18:12:15 <GeKo> sysrqb: igt0: so about that fennec bug backporting
18:12:34 <GeKo> i'll be pretty conservative about that for a number of reasons
18:12:54 <GeKo> but so far i think we'll pick at least two additional patches
18:13:27 <GeKo> does anyone of you want to do the backport and i just review that?
18:13:39 <GeKo> or how should we split that work?
18:14:14 <GeKo> we'll want to have that ready for sometime next week when we start building the new tor browser
18:14:20 <GeKo> (based on esr 52.8.0)
18:14:30 <sysrqb> i think we can prepare a branch for it
18:14:49 <GeKo> so i'll be done with the bug triage tomorrow
18:14:59 <GeKo> ok
18:15:15 <sysrqb> igt0: can you do it? i can, but i'd like to concentrate on my two tasks, if possible
18:15:19 <GeKo> i plan to just use #25810 for that making the ticket a bit more general
18:15:33 <sysrqb> igt0: i can do it, if you're too busy
18:15:37 <igt0> GeKo, sysrqb yep I can do it
18:15:43 <sysrqb> great, thanks
18:15:59 <GeKo> great, i'll add the tickets to that bug then and you can take it from there
18:16:37 <GeKo> boklm: so, i am wondering about #16472
18:17:14 <GeKo> i am mainly interested in #12968 which is why we need it
18:17:27 <GeKo> (apart from 2.24 being an ancient binutils version)
18:18:27 <GeKo> boklm: could you focus this week on that ticket please?
18:18:32 <boklm> ok
18:19:09 <boklm> I will get back on this ticket this week. I had the same reproducibility issue using 2.26. I didn't try yet with 2.25 (which require rebasing some of the patches).
18:19:54 <GeKo> i see, could you add that info to the ticket?
18:20:13 <boklm> ok
18:20:56 <GeKo> okay, discussion time it seems:
18:21:03 <GeKo> arthuredelstein: you are up
18:21:44 <arthuredelstein> yup, so I had previously overlooked that we have mar files on cdn.torproject.org
18:21:53 <arthuredelstein> Are these the same mar files as those on dist.torproject.org?
18:22:05 <boklm> yes, they are the same
18:22:32 <arthuredelstein> Do we need to have them in both places, or could we save space by only having them on one of the two servers?
18:23:24 <boklm> I think we could be able to remove them from dist.tpo, although it will make them a little more difficult to find for people who want to reproduce our builds
18:24:17 <GeKo> hm
18:24:24 <arthuredelstein> I see. What's the difference between dist and cdn here?
18:24:32 <GeKo> i think we should leave all the things that we build in one place
18:24:39 <GeKo> for ease of verification
18:26:13 <arthuredelstein> Another naive question: what would argue against removing the files from cdn and re-pointing our updater?
18:26:31 <arthuredelstein> (re-pointing to dist)
18:26:40 <GeKo> we want to use fastyl
18:26:43 <GeKo> fastly
18:26:49 <GeKo> they are our cdn
18:27:03 <boklm> cdn is using fastly. dist is our servers, which don't have as much bandwidth as fastly.
18:27:06 <GeKo> because otherwise our infra would break during tor browser updtes
18:27:12 <GeKo> *updtaes
18:27:21 <GeKo> *updates
18:27:37 <arthuredelstein> So we serve the mar files from cdn but the installer binaries from dist?
18:27:54 <boklm> yes
18:28:17 <arthuredelstein> is that because the bandwidth for new downloads is much less than the bandwth for mar files?
18:28:21 <arthuredelstein> required?
18:28:22 <GeKo> yes
18:28:50 <GeKo> well, not "less"
18:29:01 <mcs> more spread out in time?
18:29:10 <mcs> or “over time"
18:29:14 <GeKo> but if you look at the donwload numbers compares to the update peaks you'll see the issue
18:29:45 <arthuredelstein> I see, you have to handle the traffic spikes on update day.
18:29:45 <GeKo> def more spread out in time
18:29:49 <GeKo> yes
18:30:17 <mcs> Is it really expensive for us to acquire enough disk space in both places?
18:30:32 <GeKo> arthuredelstein: see: https://blog.torproject.org/making-tor-browser-updates-stable-and-reliable-fastly
18:30:45 <GeKo> it has a bunch of numbers
18:30:52 <GeKo> mcs: i don't know
18:31:09 <GeKo> i think first we need to come up with thre requirements
18:31:11 <sysrqb> i guess there's an argument about who has the logs for users who are downloading tor browser vs updating an existing installation
18:31:41 <GeKo> that was one of the reasons for splitting both
18:31:50 <boklm> the mar files are signed and verified by the updater, so it is less an issue if they are on infrastructure we don't control, while only a small percentage of users verify signatures on the installer
18:32:20 <sysrqb> ah, that's another good point
18:32:41 <mcs> Also related to disk space requirements: when we transition to the new mar file format (in the ESR 60 timeframe), we will need to keep some extra mar files.
18:32:50 <GeKo> + the updates are downloaded over tor while the new installations might not
18:33:19 <GeKo> mcs: but that's just for the first watershed release, right?
18:33:33 <mcs> Older browsers won’t be able to handle the new format, so we will need to keep mar files around to get older browsers to 8.0 or whatever version handles the new format.
18:33:46 <mcs> yes, to get older browsers to the watershed release
18:33:51 <GeKo> yep
18:34:11 <arthuredelstein> OK, I will make an estimate for the increased space we will need on cdn and post it on that ticket.
18:34:18 <arthuredelstein> Thanks, everyone!
18:34:21 <GeKo> thanks, sounds good
18:34:44 <GeKo> boklm: alright the disk space issue on sunet
18:35:18 <GeKo> yes, it seems we won't have space for two? people doing alpha and stable on it while not discarding their atifacts
18:35:22 <GeKo> *artifacts
18:35:36 <GeKo> i can ask weasel about that
18:35:42 <boklm> ok
18:36:21 <GeKo> while we are at it: next week we'll start preparing 7.5.4 and 8.0a7
18:36:42 <GeKo> i'll ask next monday about who wants to help building those :)
18:37:07 <GeKo> because my currentl plan is to be not at my keyboard from next thursday on over the weekend
18:37:34 <sysrqb> sounds nice :)
18:37:44 <GeKo> so, we can test under real conditions how this rotating build duty goes :)
18:38:04 <GeKo> my  plan is to tag the builds and be back on monday thereafter to help with stuff
18:38:11 <GeKo> i hope that's just signing :)
18:38:19 <GeKo> if not i'll help with building as well
18:38:54 <GeKo> mozilla is releasing the new versions on wednesday in the week thereafter
18:39:20 <GeKo> so we got one extra day this time, which makes this less problematic
18:39:33 <GeKo> but we can discuss that more next week
18:39:44 <GeKo> this was just the heads-up :)
18:40:51 <GeKo> anything else for today?
18:40:57 <GeKo> or while we are here?
18:41:40 <sukhe> if anyone is interested in helping out with the snowflake windows build, please don't hesitate :)
18:41:47 <GeKo> right
18:41:52 <GeKo> what's the status?
18:42:31 <sukhe> we are still trying to fix the issues, but here is one we are particularly stuck with: https://groups.google.com/d/topic/discuss-webrtc/UbQ602XSB10/discussion
18:42:58 <sukhe> so we decided to ask on the webrtc mailing list and currently waiting for a reply; meanwhile, I am trying on my end
18:43:14 <GeKo> did you get the whole chrome cross-compiled following the google way?
18:43:20 <GeKo> or did you try that?
18:44:04 <GeKo> because i thought webrtc is part of it and if the full thing at least works you could grab the part you want? :)
18:44:19 <sukhe> yeah this is cross-compiling, but still using what we talked about earlier (webrtc -> clang, go-webrtc -> mingw-w64 because of cgo)
18:45:24 <GeKo> i see, so webrtc itself is not the problem?
18:45:30 <GeKo> but go-webrtc?
18:46:03 <sukhe> well, one theory is that if were to compile go-webrtc with clang, the problem *may* go away because it is due to C++ ABI incompatibility
18:46:40 <sukhe> but we can't do that, since cgo doesn't work with clang and assumes mingw-w64. so making it work with clang is more work than trying to fix this linking issue
18:46:59 <GeKo> i see
18:48:18 <GeKo> sukhe: let me think a bit about it
18:48:21 <arthuredelstein> just a random thought -- there are some very helpful folks on the mingw-w64 IRC channel.
18:48:27 <sukhe> GeKo: thank you
18:48:34 <GeKo> that would be one idea i have
18:48:35 <sukhe> arthuredelstein: good idea, I will run it by them as well
18:48:58 <GeKo> the other one is pinging jacek "our" mingw-w64 guru
18:49:09 <GeKo> and mabye there is something else that comes to mind
18:49:35 <sukhe> yeah I am familiar with jacek's work -- worth a try there as well
18:49:47 <GeKo> okay, anything else for today?
18:49:49 <sukhe> thanks for the suggestions
18:50:40 <GeKo> sure
18:50:45 <GeKo> thanks all then!
18:50:50 <GeKo> *baf*
18:50:52 <GeKo> #endmeeting