17:59:07 <GeKo> #startmeeting tor browser july 30 17:59:07 <MeetBot> Meeting started Mon Jul 30 17:59:07 2018 UTC. The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:59:07 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 17:59:12 <GeKo> hi! 17:59:13 <sukhe> hello! 17:59:15 <boklm> hi! 17:59:16 <sysrqb> o/ 17:59:20 <GeKo> let's get started 17:59:31 <pospeselr> hello! 17:59:34 <GeKo> the pad is over at https://storm.torproject.org/shared/tHoN4Ii7rLSjPE0OP4gydX4cMGadsXmRQNc-6lwru0N as usual 17:59:39 <mcs> hi 17:59:52 <GeKo> please meark items bold you want to talk about (after adding ouyr own items) 17:59:54 <sukhe> sorry, I am having issues with sandstorm 17:59:57 <igt0> hello 18:00:00 <sukhe> (is it just me?) 18:00:11 <pospeselr> it's laggy af 18:00:17 <GeKo> wfm 18:00:55 <sukhe> I think we can start since I am anyways at the end of the pad 18:00:56 <sisbell> hello 18:01:22 <sukhe> done 18:02:49 <GeKo> okay, let's look over the items 18:02:57 <GeKo> it seems i am first 18:03:17 <GeKo> releases planning: 18:03:40 <arthuredelstein> hi everyone 18:03:44 <GeKo> for the desktop alpha i was wondering whether we should postpone the release for aug 13/14 18:04:19 <GeKo> i am not really convinced we should push it out until aug 2 (assuming i should be helping with it) 18:04:57 <GeKo> my main reasons for that are the onboarding we might want to have i the next alpha to give it serious testing 18:05:07 <GeKo> and the win64 update issues makes me nervous 18:05:15 <mcs> maybe landing more fixes first makes sense… which would be another benefit (plus you being more available in case things go wrong). 18:05:31 <GeKo> i want to ship a potential fix in the next alpha to give it some testing in a nother alpha if we need it 18:05:33 <mcs> I also agree on the Win64 issue. 18:06:03 <GeKo> + i want to have http/2 enabled 18:06:47 <GeKo> okay, then let's keep working on all of those issues to have them ready/sorted out once i am back 18:06:51 <arthuredelstein> yes, I think postponing to aug 13/14 is a good idea 18:06:58 <GeKo> and then we do a release with what we have 18:07:00 <GeKo> good 18:07:19 <boklm> postponing it to aug 13/14 sounds good to me 18:07:25 <GeKo> then let's looks at the mobile angle 18:07:32 <GeKo> sysrqb: igt0: what do you think? 18:08:15 <sysrqb> in terms of what remains before the alpha is ready? 18:08:22 <GeKo> yes 18:08:45 <GeKo> and whether we should postpone releasing as well 18:08:57 <GeKo> we planned for this week-ish 18:09:38 <sysrqb> I think we have at least 1 week of work, but I think we could finish by the end of this week if we try very hard for it 18:09:52 <GeKo> looking at our blockers: the proxy bypass things and the onboarding are the remeaining ones 18:10:07 <igt0> I am not sure how I feel about http2 on mobile, sysrqb do you know anything about it? 18:10:30 <sukhe> can anyone quickly point to the proxy bypass ticket? 18:10:31 <sysrqb> and deciding how we create the signing key and discuss the updating mechanisms 18:10:48 <sysrqb> https://trac.torproject.org/projects/tor/ticket/21863 18:10:57 <sukhe> ah the android one. thanks 18:11:03 <sysrqb> yeah :) 18:11:13 <sysrqb> i don't think http/2 is a blocker 18:11:22 <sysrqb> but we will want it, of course 18:12:41 <sysrqb> we may be able to push the updating ticket until the next alpha release 18:12:57 <GeKo> yes, i think so 18:13:04 <sysrqb> and only have "re-download and install" as the update mechanism 18:14:01 <sysrqb> #26242 18:14:26 <GeKo> sysrqb: igt0: should we plan for august 13/14 for doing the first tba release as well then? 18:14:26 <sysrqb> but if igt0's patch is working, then we can include 18:14:34 <sysrqb> i haven't tested it yet (#26242) 18:14:45 <sysrqb> GeKo: that sounds good to me 18:14:45 <GeKo> i am not sure where we are with the onboarding exactly 18:15:01 <GeKo> but we might want to use that aadditional time to give it more testing 18:15:17 <sysrqb> yes, plus that gives more time for creating the user manual 18:15:22 <GeKo> or iron out the most pressing issues 18:15:32 <GeKo> igt0: ^ 18:15:36 <igt0> yep! 18:15:54 <GeKo> sysrqb: that's on our list? or is that a thing done by the community team? 18:16:15 <igt0> sysrqb, are you looking in the onboarding, right? 18:16:37 <igt0> GeKo, community team is taking a look, iirc ggus was the responsible for it. 18:17:00 <GeKo> okay, that's been my impression 18:17:07 <sysrqb> i haven't done anythig with the manual 18:17:17 <GeKo> it seems we have a sync on wed, so we can see where we are with it 18:17:24 <sysrqb> yes 18:18:05 <antonela> I updated #25696 last week 18:18:44 <GeKo> sysrqb: igt0: great. so, are we clear on who is working on the onboarding stuff on mobile? 18:19:36 <sysrqb> i was letting igt0 take the lead on that 18:19:49 <igt0> okey, I can take a look this week. 18:20:11 <GeKo> sounds good, given that you are working on the proxy bypass bugs (the other remaining blocker) 18:20:20 <sysrqb> :) (thanks!) 18:21:01 <GeKo> alright, we do bloth releases once i am back in the week from aug 13 18:21:12 <GeKo> let's work towards that with that "deadline" in mind 18:21:59 <GeKo> pospeselr: i think this reimbursement request does not sound unreasonable especially as we need good contacts to rust people etc. 18:22:27 <GeKo> i'd suggest asking travel@tpo about the reimbursement (feel free to cc me) 18:22:29 <pospeselr> excellent thanks! 18:22:54 <sysrqb> pospeselr: did you get a sponsored ticket? 18:23:09 <pospeselr> yeah! 18:23:15 <sysrqb> okay, cool 18:23:31 <GeKo> sukhe: you are up 18:24:16 <sukhe> hi. I have marked things I could use help with 18:24:30 <sukhe> let me summarize 18:25:31 <sukhe> https://trac.torproject.org/projects/tor/ticket/25485#comment:23 is what I am looking for, a small C++ program that _uses the latest CXXABI_ so that we compare and check to see if need to use our version of libstdc++ or not 18:26:21 <sukhe> which means we have to write a program that does that, except I can't figure out how to use "the latest CXXABI". I need someone who is good with C++ to tell me what the program should look like, because a simple program even compiled with -Wabi doesn't work 18:26:49 <Hello71> -W is a warning option 18:26:55 <Hello71> it doesn't affect the output 18:27:10 <sukhe> sorry, I miswrote 18:28:56 <sukhe> (I meant -fabi-version) 18:29:48 <boklm> I can look this week if I see a way to do this 18:30:20 <sukhe> thanks, also I left a comment for you re: #12968. 18:30:43 <sukhe> (fwiw, I tried building with https://github.com/gcc-mirror/gcc/commit/f47fc7ef7f52cd095e636d4f93cca052427f3f0a.patch) 18:31:19 <boklm> ok, I can look at this too this week 18:31:40 <sukhe> I don't need to put more things on your plate so if you can just address that question, I am happy to take care of the builds and testing part :) 18:32:25 <boklm> ok 18:32:43 <sukhe> thanks, that's all from my side 18:32:45 <GeKo> okay, thanks boklm. that's at least a start (i'd need to dig into both things, too, in order to be helpful) 18:33:22 <sukhe> I have updated the progress related to #26476 where tjr and I are comparing the builds from TC 18:33:28 <sukhe> I never expected this would take so much time... 18:33:39 <GeKo> arthuredelstein: didn't you do the vacation thing last week? :p 18:33:58 <sukhe> both of us have put many hours into this, trying to compare if the toolchains differ and what not, but not much success 18:33:59 <GeKo> otherwise i think we are good with the status updates. 18:34:02 <GeKo> anything to add? 18:35:13 <GeKo> sukhe: where is that update? 18:35:40 <sukhe> GeKo: I will put it in the ticket. it is currently in our IRC discussions 18:35:48 <GeKo> ah, okay 18:36:53 <GeKo> sisbell: fwiw: nice work. i did not expect that this went so fast. now i hope there is no deep rabbit hole regarding the reproducibility of the binary 18:37:21 <GeKo> (the latter is the main reason for doing the whole dance with tor-browser-build/rbm in the first place) 18:37:39 <GeKo> okay, let's move on to the discussion part 18:38:11 <GeKo> so, i heard complaints from different sides about storm and it's unresponsiveness 18:38:12 <sisbell> I still need to find out how to verify the reproducibility 18:38:41 <GeKo> sisbell: well, building the .apk twice and comparing the sha256 sums is a good start 18:39:09 <sisbell> ok will do 18:39:15 <GeKo> ideally, building it on different machines 18:39:22 <GeKo> but we can do that later during review 18:39:40 <GeKo> as that's probably easier for more than one person 18:39:59 <GeKo> s/it's/its/ 18:40:15 <GeKo> i think we should make a decision on how to move on in that regard 18:40:39 <sysrqb> sisbell: also checkout diffoscope if you haven't already - it has nice support for identifying which file is causing reproducibility issues 18:40:44 <sukhe> I am not a "Sandstorm" expert but I run it on my server and I have noticed it is a RAM hog. perhaps an easy fix would be to increase the memory on the machine 18:40:53 <sukhe> oh yes, definitely a +1 for diffoscope 18:40:58 <GeKo> are we sufficiently annoyed that we should explore other ways of collecting status updates for the meeting? 18:41:27 <GeKo> i see. 18:41:44 <sysrqb> i'm not sufficiently annoyed, but i may have a high tolerance :) 18:42:07 <GeKo> it's working actually pretty well in my alpha tor browser 18:42:13 <tjr> I have no problems; but wouldn't object to a change. w/e works for people 18:42:15 <GeKo> i had way more issues with an esr52based 18:43:31 * tjr has to go to an appointment 18:43:38 <GeKo> o/ 18:44:05 <GeKo> okay, i try to ask around first to get a potential memory upgrade going 18:44:07 <arthuredelstein> not sure why it doesn't work well for me, but I can paste in my status and manage that way. Just makes editing difficult 18:44:32 <GeKo> at least i'll ask around figuring out where exactly the problem could be 18:44:35 <sysrqb> which browser are you using? 18:44:43 <sysrqb> arthuredelstein: ^ 18:45:05 <arthuredelstein> TBB alpha or Firefox 61 18:45:15 <sukhe> I have the same issue as arthuredelstein with 61.0.1 (64-bit) (not TB) 18:45:17 <sysrqb> hrm, okay. weird 18:45:39 <GeKo> arthuredelstein: and you see the isse with both? 18:45:41 <sukhe> in most cases, it doesn't even load the pad, let alone let me edit 18:45:42 <GeKo> *issue 18:45:51 <GeKo> huh 18:46:09 <arthuredelstein> it's very slow and often disconnects in both 18:46:25 <sysrqb> i use FF 61 and it's not nearly that bad for me 18:46:40 <arthuredelstein> maybe it's my computer :) 18:46:44 <sysrqb> but we can move if this is normal for some of you 18:47:15 <sukhe> do we have an alternative :) 18:47:22 <sysrqb> riseup pad's are better for both of you? 18:47:32 <sukhe> I also like it because self-host it 18:47:34 <sukhe> *we 18:47:37 <sysrqb> *pads 18:47:43 <GeKo> sukhe: +1 18:48:19 <boklm> would removing status updates from previous weeks (decreasing the size of the pad) make it faster to load? 18:48:37 <GeKo> oh, good idea. we could try that 18:48:41 <arthuredelstein> I agree there is value to self-hosting so maybe the answer is I just paste :) 18:48:44 <sysrqb> that's possible, i know the network team deletes previous weeks 18:48:51 <arthuredelstein> I don't want to cause more problems than this solves 18:49:10 <sysrqb> seems worth trying, as long as its arhived on the mailing list 18:49:25 <sukhe> arthuredelstein: yeah 18:49:31 <GeKo> okay, let's try to delete previous updates and figure out whether some memory upgrade could help 18:49:39 <GeKo> and if not let's find something else 18:49:40 <sukhe> deleting the pad should improve the loading of the grain, at least anecdotally 18:49:55 <arthuredelstein> If it's working for other people but not me, it suggests it's not a server issue 18:50:00 <arthuredelstein> at least I would guess 18:50:30 <sysrqb> you're not the only one 18:50:37 <sysrqb> sukhe: said he has similar issues 18:50:43 <GeKo> yes, but maybe we could improve things on different ends 18:50:45 <sysrqb> err s/:// 18:51:25 <GeKo> re the github thing: i wrote an email to isabela's mail to tbb-dev to get the discussion going 18:51:31 <sukhe> yeah, but I can live with it. it's not completely broken so why fix it ;) 18:51:48 <GeKo> please chime in if there is anything to add 18:52:05 <sukhe> sorry if it seemed like I said it was causing a problem 18:52:14 <GeKo> or if i am wrong with the things i wrote 18:52:53 <GeKo> i think we could indeed benefit from some form or github "integration" and i think we could have someone taking this onto their plate 18:52:53 <pospeselr> +1 for keeping git in-house 18:53:02 <pospeselr> don't need msft potentially screwing us in the future 18:53:02 <GeKo> yes 18:53:17 <sysrqb> yep 18:53:47 <arthuredelstein> I guess I'm not sure what problem we want to solve by further github integration 18:54:00 <sukhe> code review I think 18:54:09 <GeKo> that's one 18:54:51 <sukhe> also, GitHub gives more control some ways. (I am not saying we should use --force :) but there are other things, like deleting a remote branch which is not possible on git.tp unless the permissions are set 18:54:59 <GeKo> and then there could be an argument made for getting patches faster as it might expose our code to more devs 18:55:34 <arthuredelstein> It's true that code review is nicer on github but I'm a little hesitant to shard our reviews from trac 18:56:20 <arthuredelstein> Mozilla has a separate review tool but the comments get mirrored back to bugzilla so it's still searchable 18:56:25 <GeKo> bc we could lose them on github? 18:56:39 <GeKo> aha! 18:56:42 <arthuredelstein> Just that they're not searchable or readable in one place 18:57:00 <arthuredelstein> I wonder if there is a trac plugin that could do the same kind of mirroring. 18:57:13 <sukhe> arthuredelstein: at least the way I do it -- and doesn't make it right -- is that I reference a github branch on to trac so that way the comments stay on trac and the code is on github 18:57:57 <arthuredelstein> sukhe: Yeah, I think that's fine. I do the same :) 18:58:06 <GeKo> yes, that's what we currently have 18:58:17 <arthuredelstein> More wondering about the benefits/drawbacks of using github's built-in code review 18:59:49 <GeKo> arthuredelstein: could you voice your concerns in a reply to that tbb-dev thread? 19:00:08 <arthuredelstein> sure, will do 19:00:26 <mcs> Network Team people might have useful input about code review tools since they use them (at least sometimes). 19:00:53 <GeKo> i am happy if we could satisfy the wishes tjr had while taking he concerns with github into account as well 19:01:25 <GeKo> okay, final point: next meeting 19:01:38 <GeKo> i need to be afk next monday (and the whole week) 19:01:51 <catalyst> i'm happy with github's review tools. i think they're not perfect, but the network/community effects and usability outweigh the drawbacks 19:01:52 <GeKo> so, i guess 8/13 would be the next one? 19:02:28 <sysrqb> catalyst: thanks 19:02:34 <GeKo> catalyst: which network/community effects wrt review tools to you have in mind? 19:02:41 <GeKo> *do 19:03:08 <arthuredelstein> catalyst: Are you using github tickets as well? Or just trac tickets? 19:03:22 <catalyst> low barrier to entry for new contributors. automatic CI building of pull requests so you know if someone's patches broke the build before you spend time to read them 19:04:02 <catalyst> we use trac tickets for issue tracking together with github pull requests 19:04:05 <GeKo> ah, you were not speaking of review tools in particular, okay 19:05:02 <GeKo> any objection to next meeting on 8/13? 19:05:14 <catalyst> i was lumping CI running on pull requests in with review tools 19:05:21 <GeKo> k 19:05:27 <boklm> 8/13 sounds good to me 19:05:32 <arthuredelstein> me too 19:05:34 <sysrqb> no objection of 8/13 19:05:36 <mcs> 8/13 sounds fine. 19:05:50 <sisbell> good as well 19:06:04 <igt0> it sounds good to me 19:06:13 <pospeselr> no objections! 19:06:18 <GeKo> okay, great! 19:06:29 <GeKo> anything else for discussion? 19:07:15 <GeKo> then we are done with the meeting for today, thanks all *baf* 19:07:19 <GeKo> #endmeeting