Re: Mozillabuild 2.0 ready for testing
Hi Ryan, good news. One thing that's a bit unfortunate from the l10n perspective is the svn drop. SVN is still used quite frequently to host the website localizations, so keeping that in would be helpful. Axel, who should probably give this a test run in reals on his VM. On 3/9/15 2:44 AM, Ryan VanderMeulen wrote: For the past many months, I have been working on some major updates to the Mozillabuild package in order to make it more developer-friendly and easily-maintainable in the future. I am proud to say that at this time, it is ready for more widespread testing. The latest test build can be downloaded from the link below: http://people.mozilla.org/~rvandermeulen/MozillaBuildSetup2.0.0pre4.exe sha1sum: 9edb5c51bdb5f9a5d86baf5046967d8940654353 Release notes are available below. A few general notes: * It is strongly advised that you *NOT* install this over a previous 1.x install. Changes have been made to the directory structure and underlying packages that could result in unexpected results should you choose to do so. * As is always the case when updating Mozillabuild, you should clobber after installing. * Bugs that you come across can be filed in the mozilla.org::MozillaBuild component. My goal is to ship the final release in two weeks, so any feedback you can provide now would be welcome! Thanks, Ryan - SIGNIFICANT CHANGES * Added support for MSVC2015 and dropped support for MSVC 2013, WinSDK 8.1, and MSVC Express Edition. - MSVC Community Edition is now the recommended free compiler option * Added minTTY 1.1.3 and enabled it as the default console. - Windows cmd.exe can be used by default by removing the 1 from |SET USE_MINTTY=1| near the top of start-shell.bat * Overhauls to the start-msvc* batch scripts that improve consistency and simplify maintenance. - To launch a plain terminal with no MSVC path setting, use start-shell.bat (was start-shell-l10n.bat in previous releases) * Updated Mercurial to version 3.3.2 and switched to the native python version. - Allows extensions like bzexport that rely on previously-unavailable python components to work correctly. - Enables faster future updates in the event of serious bugs or security issues. - Enabled extensions: blackbox, color, histedit, mq, pager, progress, purge, rebase, share, transplant - See the Known Issues section for regressions from this change. * Updated python to version 2.7.9. - Included packages: pip 6.0.8, setuptools 14.0, virtualenv 12.0.7 OTHER UPDATES/ADDITIONS/REMOVALS * Removed SVN * Updated 7-zip to version 9.20 * Updated bundled CA certs to those from NSS 3.17.4 * Updated emacs to version 24.4 * Updated MSYS to version 1.0.18 and various components to the latest available for MSYS1 * Updated wget to version 1.16.1 KNOWN ISSUES * Changes in behavior due to using minTTY instead of Windows cmd.exe * Problems with python scripts that can't find an hg executable in the path (bug 1128586, bug 1131048) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Ship: Fetch API
Removed pref on m-c. This will ship in 39 except for cache mode and authentication prompt. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: persistent permissions over HTTP
FWIW I am for the original set of HTTPS only restrictions proposed by Anne. I think doing so sends a strong security minded message, even if some think too strong. Pop-ups: I realize including pop-ups in this is a minority opinion (judging by this thread), however, I have not seen a single concrete example by those defending pop-ups of an HTTP-only site that depends on pop-ups for functionality for which this change would inconvenience the user. I am for including pop-ups in this set, at least up to Aurora to test the hypothesis that others have offered that this would annoy users, because frankly, I don't believe it in practice. Notifications: For notifications, Anne's argument is correct. They're not widely adopted yet, so now is a good time to place this restriction on them, when there is very little of site-breakage risk. If there is real-world author/developer demand for INSECURE access to web notifications, we can re-evaluate accordingly. Blog post: In addition, as part of landing these restrictions, I think a blog post by Anne (e.g. perhaps on hacks.mo) on these changes would show and demonstrate Mozilla's user-security focus and technical leadership. Such a blog post could also explicitly note that we do see a spectrum of differences between things as invasive/creepy as camera access vs. just annoying pop-ups notifications, and that based on user and developer feedback we may adjust our implementation accordingly. Better to secure more things, and then only back-off if/when necessary. Thanks, Tantek On Mon, Mar 9, 2015 at 2:07 AM, Anne van Kesteren ann...@annevk.nl wrote: Thanks everyone for weighing in. It sounds like we don't want to touch popups :-) And yes, negative persistence (never allow) should remain available. The Notifications API is a bit in flux and the most interesting notifications require service workers so are already restricted. I guess I'm okay with leaving them alone for now. On Fri, Mar 6, 2015 at 7:04 PM, Gijs Kruitbosch gijskruitbo...@gmail.com wrote: Can we make an exception for localhost and its IPv4 and IPv6 equivalents to make things easier for web devs? Bonus points if we make a mechanism that detects /etc/host overrides (to localhost) and allow it there, too. I think the exceptions of the powerful features document are localhost, equivalent hostnames (I can't think of any), and file URLs. Developer tools should provide overrides. We need overrides for service workers too. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozillabuild 2.0 ready for testing
Nice, I like the new terminal. When I try to run |./mach mercurial-setup| from m-c tip, it gives me the following error after pressing enter: WindowsError: [Error 193] %1 is not a valid Win32 application File c:\Users\Emanuel\firefox\mozilla-central\tools/mercurial/mach_commands.py, line 42, in mercurial_bootstrap result = wizard.run(map(os.path.expanduser, config_paths)) File c:\Users\Emanuel\firefox\mozilla-central\tools/mercurial\hgsetup\wizard.py, line 205, in run hg_version = get_hg_version(hg) File c:\Users\Emanuel\firefox\mozilla-central\python/mozversioncontrol\mozversioncontrol\__init__.py, line 19, in get_hg_version info = subprocess.check_output([hg, 'version'], env=env) File c:\mozilla-build\python\lib\subprocess.py, line 566, in check_output process = Popen(stdout=PIPE, *popenargs, **kwargs) File c:\mozilla-build\python\lib\subprocess.py, line 710, in __init__ errread, errwrite) File c:\mozilla-build\python\lib\subprocess.py, line 958, in _execute_child startupinfo) I'm on 64-bit Windows 7. I get the same error regardless of whether I use start-shell-msvc2013.bat or start-shell-msvc2013-x64.bat. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: persistent permissions over HTTP
Thanks everyone for weighing in. It sounds like we don't want to touch popups :-) And yes, negative persistence (never allow) should remain available. The Notifications API is a bit in flux and the most interesting notifications require service workers so are already restricted. I guess I'm okay with leaving them alone for now. On Fri, Mar 6, 2015 at 7:04 PM, Gijs Kruitbosch gijskruitbo...@gmail.com wrote: Can we make an exception for localhost and its IPv4 and IPv6 equivalents to make things easier for web devs? Bonus points if we make a mechanism that detects /etc/host overrides (to localhost) and allow it there, too. I think the exceptions of the powerful features document are localhost, equivalent hostnames (I can't think of any), and file URLs. Developer tools should provide overrides. We need overrides for service workers too. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
