18:00:32 <mikeperry> #startmeeting tbb
18:00:32 <MeetBot> Meeting started Mon Oct 13 18:00:32 2014 UTC.  The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:32 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:03:21 <mikeperry> ok, so last week I merged everything tha seemed stable into 4.0. I also hacked Torbutton to ensure that our toolbar configuration is stable (#13219). I uploaded builds last night, and GeKo sent them to tor-qa. Mozilla finally tagged 31.2.0esr yesterday, but did not add any new commits other than the version bump since we tagged, so we're in good shape
18:04:02 <mikeperry> I'm pretty happy about the state of 4.0. It will have the menubar disabled as per the default in Firefox now. hopefully that won't cause support issues
18:04:43 <mikeperry> this week I'll be merging all the changelog items into one set of changes since the last stable for the blog post
18:05:30 <mikeperry> we should also merge a few things that are ready (pinning? #13019? anything else?) for the alpha series, and start those builds asap
18:06:20 <arthuredelstein> pinning is almost ready, but there is one tricky patch I am still backporting
18:07:14 <GeKo> mikeperry: #12903
18:07:28 <mikeperry> I am trying to decide if we should call the alpha series 4.5 or 5.0
18:08:02 <GeKo> I have a branch in my repo bug_12903_squashed_v3 which has all we need I think
18:08:03 <mikeperry> I will also be somewhat distracted this week due to a tor planning meeting I am having with Roger
18:08:18 <MarkSmith> It is hard to go back down, so I would say 4.5 or lower (Kathy agrees)
18:08:23 <GeKo> but we need to make a new branch as we did with maint-3.6
18:08:52 <GeKo> 4.5 sounds good
18:09:23 <MarkSmith> mikeperry: Let us know if you need any info for your meeting with Roger.
18:11:21 <mikeperry> ok. one useful thing to know is if anyone has more hours/availability in the future. I think you guys and arthur are not fully booked by us. if you have more time for Tor things, that would be useful. we're going to try to find funding for a mobile port of TBB I think
18:11:45 <mikeperry> my thinking is something simple: a standalone app that doesn't need Orbot, but can use Orbot's Tor if available
18:13:27 <mikeperry> we probably will also hire for that, but I thought I'd check on your status, too. we can take that to email, also
18:13:47 <arthuredelstein> sounds interesting
18:14:27 <MarkSmith> We will discuss availablility among ourselves and send you email.
18:14:34 <MarkSmith> (Kathy and me, that is)
18:15:21 <MarkSmith> Will the official Tor Project mobile port replace Orbot?
18:15:36 <MarkSmith> (long term)?
18:17:53 <mikeperry> well, we're going to be structuring this proposal based on "needs-finding" work, where people go on the ground into various countries and determine people's painpoints as they try to use our software. I suspect that one of the things they will find is that a self-contained Tor Browser will make more sense for most people than having two apps
18:18:20 <MarkSmith> I think I meant "Will it replace Orweb?" actually…  but your response makes sense.
18:18:21 <mikeperry> but it may also be the case that people need a whole-phone approach, either like my blog post, or asa Tails-like ROM that can be booted into, or even a spare phone for Tor stuff
18:19:18 <MarkSmith> I like the "needs-finding" approach
18:19:26 <mikeperry> yes, the Guardian project is doing some initial work to get OrFox to use our patches, but their budget for the project is small, and I think we'll want a dedicated engineer or two on this, with also support from our existing team
18:19:52 <mikeperry> so I am thinking that we'll be taking over the browser dev work for mobile, long term
18:20:23 <mikeperry> assuming we get the funding for it, of course (proposal is still in the works)
18:20:31 <GeKo> makes sense
18:24:21 <mikeperry> ok, lets continue with the normal meeting. and if you're working on anything that we can merge into the alpha in the next day or two, please say so. I have #11955, #13019, and #12903 currently
18:24:54 <mikeperry> but we're also on a bit of a time crunch. we want the alpha channel people to have a 31.2.0-based esr as soon as possible
18:27:39 <mikeperry> who wants to go next?
18:27:55 <Lunar^> mikeperry: I think gmp should be built with '--enable-fat' but you might want to postpone that for the next alpha
18:28:09 <MarkSmith> We can offer the 4.0 (non-alpha) update on the alpha channel and then offer the 4.5 alpha once it is ready.  If we want to.
18:29:19 <GeKo> I'd rather avoid one additional update if we can.
18:29:23 <mikeperry> MarkSmith: do we have to rebuild for that, to avoid switching people off the channel? can we just rebundle, or does that need a firefox rebuild?
18:30:06 <MarkSmith> mikeperry: They will not be switched off the channel.  See: https://lists.torproject.org/pipermail/tbb-dev/2014-October/000141.html
18:30:28 <MarkSmith> (point 2) within that message)
18:30:30 <mikeperry> Lunar^: GeKo added the gmp build. what does --enable-fat do?
18:31:42 <Lunar^> mikeperry: --enable-fat will bundle optimizations for all CPUs. That's why LXC and KVM linux builds are different right now, different CPUs get detected and different optimizations compiled
18:32:17 <mikeperry> MarkSmith: ah, ok. that is tempting then, given that I will be distracted this week
18:32:21 <Lunar^> mikeperry: this hasn't trickled down to support yet because you are shipping the ones built with KVM and they are optimized for pentium2
18:32:31 <Lunar^> mikeperry: --enable-fat failed to build on Mac though
18:34:16 * arthuredelstein can go next
18:34:41 <arthuredelstein> Last week I revised my patch for #13019 (locale fingerprinting)
18:34:44 <mikeperry> Lunar^: hrmm. sounds like it needs a ticket then. we may have to get Ray involved for the mac side
18:36:12 <arthuredelstein> and I worked on backporting certificate pinning (#11955), which is almost ready.
18:36:24 <GeKo> yay
18:36:34 <Lunar^> mikeperry: it's not as a problem on mac because the optimization selected there are always the same (because a host is explicitely given to ./configure)
18:37:01 <arthuredelstein> After I finish pinning, I was thinking I might start doing some work on documenting/refactoring/minimizing torbutton code
18:37:40 <mikeperry> arthuredelstein: are your socks isolation patches updated? has mozilla commented on them?
18:39:19 <arthuredelstein> SOCKS patches are updated for ESR31.1. Mozilla has made a small comment on one of them, but I'm awaiting further comments
18:40:49 <arthuredelstein> The other patch hasn't gotten any comments yet. I'll try and re-ping.
18:43:26 <mikeperry> ok. I would say that, and generally updating all of our bugzilla bug patches (http://bugzil.la/ALL%20whiteboard:%5Btor%5D) are probably higher prio that Torbutton cleanup at the moment, but if either stall, Torbutton seems fine to work on
18:44:34 <arthuredelstein> OK -- makes sense. I'll focus on those instead.
18:44:52 <GeKo> I can go next.
18:46:52 <GeKo> I worked on #13359, #13025, #13364, #13018, #12903 and #13027 last week
18:47:23 <GeKo> the latter (writing the test) is not done yet.
18:47:47 <GeKo> but the failure is interesting: I have a test that works on vanilla Firefox but one of our patches breaks it.
18:48:01 <GeKo> as this makes me nverous I am currently bisecting
18:48:49 <GeKo> I'll continue this and finish the test (hopefully) this week. And I am switching back to the security slider work.
18:49:16 <GeKo> that are the two big things at least I plan to do.
18:49:21 <GeKo> that's it for me.
18:50:03 * MarkSmith Can go next.
18:50:14 <MarkSmith> Last week, Kathy and I fixed #13016.
18:50:23 <MarkSmith> We also spent quite a bit of time testing the updater in various scenarios on various platforms.
18:50:32 <MarkSmith> Out of that, we filed and fixed #13356.  We filed #13359 which gk fixed (thanks!)
18:50:45 <MarkSmith> We also found a problem with incremental MAR file generation (missing symlinks) and added a comment to #13324
18:50:51 <MarkSmith> (sorry we didn't catch this problem sooner, and thanks to bolkm for already addressing it).
18:50:58 <MarkSmith> This week we plan to do some updater testing with the 4.0 candidate builds and help with the 4.0 release in any way we can.
18:51:05 <MarkSmith> Also, Kathy and I will be away from the office the end of this week (Thursday / Friday / Saturday).
18:51:14 <MarkSmith> That's all for now.
18:52:27 * boklm can go next
18:52:50 <boklm> last week I have been working on tor-messenger builds, and added some commits on the update-responses-2 branch for #13324
18:53:16 <boklm> for #13324, I still need to add a commit to update hash-bundles.sh, upload-signature.sh and check-match.sh for the sha256sums.incrementals.txt file
18:53:49 <boklm> This week, I plan to look at #12222
18:54:02 <boklm> that's it for me
18:54:18 <mikeperry> boklm: ok. if you also want to fix the upload directory vs tag name consistency issue, that seems like a good thing to do with #13324
18:54:35 <boklm> ah, yes
18:54:42 <mikeperry> #13015
18:57:32 <mikeperry> to make the resync easier, the output directory of the builds should probably be either based on tag name, or commit hash. we should have some kind of consistency for directory naming I think. since nightlies don't use tags, maybe we want to use commit hash?
18:58:00 <mikeperry> not sure. I guess just choose whatever makes it easiest to run your tests consistently
18:59:45 <boklm> maybe we can use tag name if there is a tag, and commit hash otherwise
19:00:20 <mikeperry> s/resync/rsync (ie upload)
19:01:13 <mikeperry> boklm: ok. feel free to choose what makes the most sense to you
19:01:23 <boklm> ok
19:04:32 <mikeperry> ok. anyone else?
19:05:59 <mikeperry> so I guess we'll decide what to do about the alpha channel depending on how the pinning work goes. arthur, if you can email me in the next day on if you think pinning is going to make it, I think that will govern if we just update the alpha users to 4.0 or 4.5 with new patches
19:07:03 <arthuredelstein> OK, I'll do that
19:08:31 <mikeperry> for the updater response scripts, do we need any updates to them to handle multiple channels?
19:09:09 <boklm> when we are ready to release 4.0, we need to update config.yml to add the stable channel
19:09:09 <mikeperry> it looks like we may need updates to the .htaccess file
19:10:04 <tjr> I don't have anything, but AFAICT the 64 bit Mac patches (using gcc, not clang) are okay to be tested for adoption.  If something there needs to change, I'm not aware of it.
19:10:05 <boklm> yes, we need to update config.yml, run the update_responses script and rsync the htdocs dir
19:11:13 <GeKo> tjr: I tested the things the other day with ESR 31 and it worked fine btw.
19:11:56 <mikeperry> should we warn people in this blog post that 32bit mac support is going away?
19:12:08 <GeKo> yes, I think so.
19:12:22 <MarkSmith> And see if anyone complains ;)
19:15:06 <MarkSmith> On a related note we need to make sure we push the .htaccess and XML files during the release process.
19:16:20 <MarkSmith> I guess the release procedures need updating somewhere (wiki?)
19:17:08 <GeKo> yes, I was wondering whether there is a detailed documentation for the updater related bits somewhere
19:17:46 <boklm> the change to config.yml will be something like this: http://paste.debian.net/125995/
19:19:40 <mikeperry> cool, thanks
19:21:34 <MarkSmith> We do not currently have detailed docs for the updater beyond what Mozilla has.  We can create something.  Certainly boklm's script and how to use it needs docs.
19:21:53 <mikeperry> the release process is documented here: https://gitweb.torproject.org/tor-browser-spec.git/blob/HEAD:/processes/ReleaseProcess
19:21:55 <MarkSmith> boklm: I think you have documented the config.yml format, etc.?
19:22:11 <mikeperry> but that is meant to be a script/cut-and-paste set of steps just for releasing
19:22:36 <mikeperry> more details on the operation probably belongs someplace like https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking
19:22:46 <GeKo> MarkSmith: I meant the latter, the Mozilla docs wrt the updater are good IMO
19:24:06 <GeKo> like: what do I need to do in case I am responsible for a release to get the updater bits right
19:25:03 * boklm has this patch for processes/ReleaseProcess: http://paste.fedoraproject.org/141545/14132282/
19:25:23 <boklm> however I am not sure about the rsync URL
19:27:21 <mikeperry> applied that patch. if it seems wrong, I will fix it
19:27:22 <mikeperry> thanks
19:29:13 <mikeperry> I also applied the config.yml patch
19:29:26 <boklm> ok
19:29:35 <mikeperry> I think that wraps it up then? we seem to be in good shape for the 4.0 release, and we have a plan and a contingency plan for the alpha branch
19:30:41 <MarkSmith> thanks to everyone for their 4.0 contributions!
19:31:25 <mikeperry> yes, I think everyone did a great job getting us ready for 31esr, and otherwise. best tbb ever :)
19:31:44 <boklm> :)
19:32:50 <mikeperry> alright, I will be talking to some of you via email. again may have limited availability. see you all next week though!
19:33:02 <mikeperry> #endmeeting *baf*