FYI: `mach python-test` API change

If you never use `mach python-test`, you can stop reading now. At the latest version of mozilla-central, `mach python-test` no longer takes a `--python` command-line argument. If you're used to using it, you have alternatives: * If you're used to doing `./mach python-test --python 3 ...`, you

FYI: mach virtualenv change

If you never use mach, you can stop reading now. Bug 1656993 imposes a new requirement that we run mach commands in a virtualenv, rather than using the system Python as we have been doing up to this point. When this patch hits mozilla-central, you may notice that your normal workflow starts

FYI: Taskcluster Services Migration

*tl;dr:* Taskcluster, the platform supporting Firefox CI, will be moving to a new hosting environment during the tree-closing window at the end of September. This is a major change and upgrade to the platform, but may cause some bumps along the way. Taskcluster is in the midst of a few

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

t On Saturday, March 17, 2018 at 11:51:02 AM UTC+1, Patrick McManus wrote: > Hi All, FYI: > > Soon we'll be launching a nightly based pref-flip shield study to confirm > the feasibility of doing DNS over HTTPs (DoH). If all goes well the study > will launch Monday (and if not, prob

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On 3/21/18 9:04 AM, Axel Hecht wrote: > I have a couple of further questions: > > One is about the legal impact on users. DNS mangling is part of law > enforcement strategies in many parts of the world (incl Germany). Would you mind describing this in more detail? What kind of DNS mangling do

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On 3/21/18 10:53 AM, tom...@gmail.com wrote: On Wednesday, March 21, 2018 at 3:30:48 PM UTC+1, Boris Zbarsky wrote: The point is to gather data on how this behaves in the wild. If the study is opt-in, then you have to try to figure out what part of the effect you're seeing (if any) is just

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

I have a couple of further questions: One is about the legal impact on users. DNS mangling is part of law enforcement strategies in many parts of the world (incl Germany). We should restrict this experiment to regions where Mozilla knows that there's no legal trouble of using DoH and

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On Wednesday, March 21, 2018 at 3:30:48 PM UTC+1, Boris Zbarsky wrote: > The point is to gather data on how this behaves in the wild. If the > study is opt-in, then you have to try to figure out what part of the > effect you're seeing (if any) is just selection effects. >From my understanding

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On 3/21/18 10:02 AM, tom...@gmail.com wrote: I also don't see any arguments why this *needs* to be opt-out? The point is to gather data on how this behaves in the wild. If the study is opt-in, then you have to try to figure out what part of the effect you're seeing (if any) is just

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On Tuesday, March 20, 2018 at 3:35:48 AM UTC+1, Kris Maglione wrote: > >Let me add my voice as a person outside the network team who can understand > >the concerns and _still thinks we should be doing this_. > > I'll second this. > > I think it's reasonable to be concerned about the public

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

+1 (as a Moz fan and privacy expert) On Tue, Mar 20, 2018 at 2:35 AM, Kris Maglione wrote: > On Mon, Mar 19, 2018 at 07:27:39PM -0700, Nicholas Alexander wrote: >> >> Hi all, >> >> On Mon, Mar 19, 2018 at 3:56 PM, Xidorn Quan wrote: >> >>> It's fine to

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

Note, this effort is already being reported in the tech press based on this thread. For example: https://www.theregister.co.uk/AMP/2018/03/20/mozilla_firefox_test_of_privacy_mechanism_prompts_privacy_worries/ A blog post does sound like a good idea. On Mon, Mar 19, 2018, 11:33 PM Dave Townsend

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On Tue, Mar 20, 2018 at 3:02 AM, Henri Sivonen wrote: > I understand that the goal is better privacy. But it's likely that > people get outraged if a browser sends information about what is > browser to an off-path destination without explicit consent regardless > of

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On Tue, Mar 20, 2018 at 11:43:13AM +0100, Frederik Braun wrote: On 20.03.2018 04:33, Dave Townsend wrote: The DoH service we're using is likely more private than anything the user is currently using. This is only true for some parts of the world. I'd like us not to regress for our user base

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On 2018-03-19 11:33 PM, Dave Townsend wrote: As one of the folks who brought up the initial concern let me be clear that at this point my only real concern here is one of optics. The DoH service we're using is likely more private than anything the user is currently using. It isn't explicit

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On 20.03.2018 04:33, Dave Townsend wrote: > The DoH service > we're using is likely more private than anything the user is currently > using. This is only true for some parts of the world. I'd like us not to regress for our user base globally here.

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

As one of the folks who brought up the initial concern let me be clear that at this point my only real concern here is one of optics. The DoH service we're using is likely more private than anything the user is currently using. I just don't want to see random folks on the web "discover" these DoH

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On 3/19/18 8:59 PM, Boris Zbarsky wrote: > On 3/19/18 1:08 PM, Selena Deckelmann wrote: >> There's a lot of thinking that went into the agreement we have with >> Cloudflare to enable this experiment in a way that respects user privacy. > > I would like us to be very clear that there are two

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On 3/19/18 1:08 PM, Selena Deckelmann wrote: There's a lot of thinking that went into the agreement we have with Cloudflare to enable this experiment in a way that respects user privacy. I would like us to be very clear that there are two separate things here: 1) Is this behavior good for

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On Mon, Mar 19, 2018 at 07:27:39PM -0700, Nicholas Alexander wrote: Hi all, On Mon, Mar 19, 2018 at 3:56 PM, Xidorn Quan wrote: It's fine to embed this experiment in the product, and blog about it, but it's definitely not fine to have it enabled by default and send every

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

Hi all, On Mon, Mar 19, 2018 at 3:56 PM, Xidorn Quan wrote: > It's fine to embed this experiment in the product, and blog about it, but > it's definitely not fine to have it enabled by default and send every DNS > request to a third-party. > > I can understand that the intent

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

It's fine to embed this experiment in the product, and blog about it, but it's definitely not fine to have it enabled by default and send every DNS request to a third-party. I can understand that the intent must be good, and for better privacy, but the approach of doing so is not acceptable.

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On Mon, Mar 19, 2018 at 7:08 PM, Selena Deckelmann wrote: > and also in terms of the regulatory environment in the US) allows *all* of > this data to be collected indefinitely and sold to third parties. Some users are in countries where it's illegal for the ISP to sell this

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

Hi! Thanks for all the thoughtful comments about this experiment. The intent of this work is to provide users privacy-respecting DNS. Status quo for DNS does not offer many users reasonable, informed choice about log retention, and doesn't offer encrypted DNS. Users also cannot be reasonably

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On Mon, 19 Mar 2018, Martin Thomson wrote: I don't know if it is possible to know if you have a manually-configured DNS server, but disabling this experiment there if we can determine that would be good - that might not be something to worry about with Nightly, but it seems like it might be

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

> explicit opt in. It think it would be better for Mozilla to > unambiguously promise not to do the kind of thing that's being > proposed here without explicit opt in.) > >> I initiated this thread on dev-platform because imo it is a reasonable >> scope for nightly changes,

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

to do the kind of thing that's being proposed here without explicit opt in.) > I initiated this thread on dev-platform because imo it is a reasonable > scope for nightly changes, especially ephemeral flip pref changes, and > that's why the FYI goes here. Its definitely not a secret. Mess

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

Daniel Le 19 mars 2018 à 17:07, Daniel Stenberg a écrit : > What other precautions or actions can we do to reduce the risk of this being > perceived as problematic? opt-in only. That's the only way. What seems innocuous for someone deep into the topic is not necessary

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On Mon, Mar 19, 2018 at 11:48 AM, Martin Thomson wrote: > Yes, it pays to remember that this is Nightly. Even on Nightly we place pretty severe restrictions on ourselves when it comes to user data, e.g., for telemetry. This definitely goes beyond the kind of data I would expect

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

thread on dev-platform because imo it is a reasonable > scope for nightly changes, especially ephemeral flip pref changes, and > that's why the FYI goes here. Its definitely not a secret. Messaging to a > larger user base than is impacted invites confusion. Future possible > changes impactin

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

a continent)) so that should continue to work the same. I initiated this thread on dev-platform because imo it is a reasonable scope for nightly changes, especially ephemeral flip pref changes, and that's why the FYI goes here. Its definitely not a secret. Messaging to a larger user base than

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On Mon, Mar 19, 2018 at 8:10 AM, Henri Sivonen wrote: > On Mon, Mar 19, 2018 at 3:18 AM, Eric Shepherd (Sheppy) > wrote: >> I definitely see some easy ways this could be problematic from a public >> relations perspective given things going on in the

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On Mon, Mar 19, 2018 at 10:07 AM, Daniel Stenberg wrote: > On Sun, 18 Mar 2018, Eric Shepherd (Sheppy) wrote: > > I don't have such a far-reaching agreement with my ISP and its DNS. 1) Mozilla doesn't choose the ISP on users' behalf. (This is the key reason.) 2) The ISP

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On 19/03/2018 09:07, Daniel Stenberg wrote: > On Sun, 18 Mar 2018, Eric Shepherd (Sheppy) wrote: > > I don't have such a far-reaching agreement with my ISP and its DNS. I > don't have such an agreement at all with 8.8.8.8 or other publicly > provided DNS operators. Yes, you're perfectly right, but

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On Mon, Mar 19, 2018 at 3:18 AM, Eric Shepherd (Sheppy) wrote: > I definitely see some easy ways this could be problematic from a public > relations perspective given things going on in the industry these days and > some of our own mistakes the in the past. It's definitely

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On Sun, 18 Mar 2018, Eric Shepherd (Sheppy) wrote: I don't have such a far-reaching agreement with my ISP and its DNS. I don't have such an agreement at all with 8.8.8.8 or other publicly provided DNS operators. What other precautions or actions can we do to reduce the risk of this being

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

I definitely see some easy ways this could be problematic from a public relations perspective given things going on in the industry these days and some of our own mistakes the in the past. It's definitely worth taking a little while to consider the implications before throwing the switch. On Sun,

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On Sun, Mar 18, 2018 at 5:27 PM Patrick McManus wrote: > Obviously, using a central resolver is the downside to this approach - but > its being explored because we believe that using the right resolver can be > a net win compared to the disastrous state of unsecured local

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

Obviously, using a central resolver is the downside to this approach - but its being explored because we believe that using the right resolver can be a net win compared to the disastrous state of unsecured local DNS and privacy and hijacking problems that go on there. Its just a swamp out there

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On Sat, Mar 17, 2018 at 3:51 AM Patrick McManus wrote: > DoH is an open standard and for this test we'll be using the DoH server > implementation at Cloudflare. As is typical for Mozilla, when we > default-interact with a third party service we have a legal agreement in >

FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

Hi All, FYI: Soon we'll be launching a nightly based pref-flip shield study to confirm the feasibility of doing DNS over HTTPs (DoH). If all goes well the study will launch Monday (and if not, probably the following Monday). It will run <= 1 week. If you're running nightly and you want to

Re: FYI: sccache 0.2.6 released, contains fix for frequent hang in 0.2.5

For macOS users this will hopefully be available from brew shortly: https://github.com/Homebrew/homebrew-core/pull/25164 Alex On Tue, Mar 13, 2018 at 9:21 AM, Ted Mielczarek wrote: > Hello, > > Yesterday I tagged and released sccache 0.2.6: >

FYI: sccache 0.2.6 released, contains fix for frequent hang in 0.2.5

Hello, Yesterday I tagged and released sccache 0.2.6: https://github.com/mozilla/sccache/releases/tag/0.2.6 This contains a fix for a hang that users were encountering with sccache 0.2.5 due to the make jobserver support added in that version. If you are using 0.2.5 you will want to update. If

FYI: Questions about the Gecko Profiler? Drop by the #flow IRC channel.

Just a reminder: if you or engineers on your team have questions about using the Gecko Profiler (https://perf-html.io/), you can ask for help in the #flow IRC channel. ___ dev-platform mailing list dev-platform@lists.mozilla.org

FYI: Visual C++ 2017 build system support landing

I'm about to land some patches[1] that will allow configure to detect a Visual C++ 2017 installation. You should be able to launch a MozillaBuild `start-shell.bat` shell and build without having to have the Visual C++ environment configured. The only thing that will change from the current state

Re: FYI, BSL Broken by Bug 1317697

The issue is now resolved and a new version of the add-on has been submitted to AMO for review. Special thanks to Andy Mackay for the fix. Cheers! On 24 April 2017 at 10:32, Anthony Hughes wrote: > This is a heads up that crash charts provided by Bugzilla Socorro Lens are

FYI, BSL Broken by Bug 1317697

This is a heads up that crash charts provided by Bugzilla Socorro Lens are currently broken in Nightly due to the landing of bug 1317697. Any suggestions for how I can fix this are welcome via https://github.com/ashughes1/bugzilla-socorro-lens/issues/20. Thank you -- Anthony Hughes Senior

FYI: Tree Closing Window (TCW) this Saturday, March 25 0500-0930 PT

This will be a SOFT Tree Closure. As a reminder, that means: - jobs may burn - You are responsible for sheriffing your own jobs [TCW] Tree Closing Maintenance Window Mar 25, 05:00-09:30 PDT Trees will be closed for the duration of this

FYI: git-cinnabar and a "Intermittent IndexError: tuple index out of range" error

If you are seeing this error when you try to do |git mozreview push|, update your version-control-tools. Then you'll see a different error. Work related to that is being looked at in https://bugzilla.mozilla.org/show_bug.cgi?id=1338530 Andrew ___

Re: FYI: We've forked the Breakpad client code

I can review the DWARF related bits in a pinch, too. On Thu, Feb 9, 2017 at 2:04 PM, Mike Hommey wrote: > On Thu, Feb 09, 2017 at 12:41:07PM -0800, Jim Blandy wrote: > > Under the circumstances, I'll volunteer to review, if that's feasible. > > I can too. > > > On Thu, Feb 9,

Re: FYI: We've forked the Breakpad client code

On Thu, Feb 09, 2017 at 12:41:07PM -0800, Jim Blandy wrote: > Under the circumstances, I'll volunteer to review, if that's feasible. I can too. > On Thu, Feb 9, 2017 at 12:37 PM, Ted Mielczarek wrote: > > > On Thu, Feb 9, 2017, at 02:47 PM, Aaron Klotz wrote: > > > This is

Re: FYI: We've forked the Breakpad client code

Under the circumstances, I'll volunteer to review, if that's feasible. On Thu, Feb 9, 2017 at 12:37 PM, Ted Mielczarek wrote: > On Thu, Feb 9, 2017, at 02:47 PM, Aaron Klotz wrote: > > This is great news, Ted! > > > > Are you going to be creating a module for this? Who are

Re: FYI: We've forked the Breakpad client code

On Thu, Feb 9, 2017, at 02:47 PM, Aaron Klotz wrote: > This is great news, Ted! > > Are you going to be creating a module for this? Who are the peers? I don't think a new module is necessary, we've covered the existing integration code (nsExceptionHandler.cpp etc) under the Toolkit module for a

Re: FYI: We've forked the Breakpad client code

This is great news, Ted! Are you going to be creating a module for this? Who are the peers? -Aaron ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

FYI: We've forked the Breakpad client code

FYI, I landed a patch[1] yesterday that forked the Breakpad client code. Everything that was in toolkit/crashreporter/google-breakpad/src/client is now in toolkit/crashreporter/breakpad-client. Google has switched Chromium to using Crashpad (their new crash reporting library) on Windows, OS X

FYI: SOFT tree close for TCW Scheduled Tree Closing Maintenance Window 2016-11-19 07:00a PST 5 hours

The tree closing this weekend will be a SOFT CLOSE -- there will be period of time where new commits to hg.mozilla.org will be disabled, but the rest of the automation infrastructure will be operational. Some minor work might cause an unlucky job to burn - devs will need to retrigger those jobs.

fyi, ./mach hangs on terminal-notifier? brew update to 1.7.1

Hi, as an fyi, I almost filed a bug on mach hanging on terminal-notifier after the end of a build or packaging step. Seems that was a bug in terminal-notifier 1.7.0, another brew update/upgrade updated that to 1.7.1 and fixed it. Just in case you've been in that boat. Axel

FYI: Emergency TCW this Saturday, February 20, 0600-1000 PT

tl;dr: this will be a "Soft Close" to deal with glibc updates As most of you know, upgrading glibc requires a reboot of each Linux host. With so many hosts needing to be rebooted, there will be impacts on the build and test machinery. We fully expect the system to self-recover, but jobs in

FYI - Autophone down for maintenance

Autophone is going down this afternoon for several hours while the devices are being switched to new hosts. bc ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: FYI: e10s will be enabled in beta 44/45

On Sunday, December 13, 2015 at 9:12:59 PM UTC-6, Daniel Veditz wrote: > On Mon, Dec 7, 2015 at 4:36 AM, Kurt Roeckx wrote: > > > On 2015-12-04 19:43, jmath...@mozilla.com wrote: > > > >> Not an issue since initial rollout to beta and release will be to users > >> who do not have

Re: FYI: e10s will be enabled in beta 44/45

On Mon, Dec 7, 2015 at 4:36 AM, Kurt Roeckx wrote: > On 2015-12-04 19:43, jmath...@mozilla.com wrote: > >> Not an issue since initial rollout to beta and release will be to users >> who do not have addons installed. >> > > Is it even possible to have no addons installed? Firefox

Re: FYI: e10s will be enabled in beta 44/45

On 12/4/15 10:43 AM, jmath...@mozilla.com wrote: On Friday, December 4, 2015 at 11:08:08 AM UTC-6, Armen Zambrano G. wrote: LastPass bring the browser to a crawl making it almost impossible to use. If we have users using LastPass on the beta population using e10s we're going to have a lot of

Re: FYI: e10s will be enabled in beta 44/45

On 2015-12-04 19:43, jmath...@mozilla.com wrote: On Friday, December 4, 2015 at 11:08:08 AM UTC-6, Armen Zambrano G. wrote: LastPass bring the browser to a crawl making it almost impossible to use. If we have users using LastPass on the beta population using e10s we're going to have a lot of

Re: FYI: e10s will be enabled in beta 44/45

On 2015-12-04 9:02 AM, jmath...@mozilla.com wrote: Hey all, FYI e10s will be enabled in beta/44 in a limited way for a short period time through an experiment. [1] The purpose of this experiment is to collect e10s related performance measurements specific to beta. The current plan

FYI: e10s will be enabled in beta 44/45

Hey all, FYI e10s will be enabled in beta/44 in a limited way for a short period time through an experiment. [1] The purpose of this experiment is to collect e10s related performance measurements specific to beta. The current plan is to then enabled e10s in beta/45 for a respectable chunk

Re: FYI: e10s will be enabled in beta 44/45

4 9:02 AM, jmath...@mozilla.com wrote: >> Hey all, >> >> FYI e10s will be enabled in beta/44 in a limited way for a short >> period time through an experiment. [1] The purpose of this experiment >> is to collect e10s related performance measurements specifi

Re: FYI: e10s will be enabled in beta 44/45

On Friday, December 4, 2015 at 9:44:36 AM UTC-6, Ehsan Akhgari wrote: > On 2015-12-04 9:02 AM, jmath...@mozilla.com wrote: > > Hey all, > > > > FYI e10s will be enabled in beta/44 in a limited way for a short period > > time through an experiment. [1] The

Re: FYI: e10s will be enabled in beta 44/45

On Friday, December 4, 2015 at 11:08:08 AM UTC-6, Armen Zambrano G. wrote: > LastPass bring the browser to a crawl making it almost impossible to > use. If we have users using LastPass on the beta population using e10s > we're going to have a lot of people upset. Not an issue since initial

Re: FYI: updating yasm on build machines

Chris Peterson wrote: mozilla-build tools already use 1.3 When did it get upgraded? (My mozilla-build only has yasm 1.1) -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: FYI: updating yasm on build machines

On 11/20/15 5:09 AM, Neil wrote: Chris Peterson wrote: mozilla-build tools already use 1.3 When did it get upgraded? (My mozilla-build only has yasm 1.1) Last year according to bug 1113450: https://bugzilla.mozilla.org/show_bug.cgi?id=1113450

FYI: updating yasm on build machines

mozilla-build uses yasm 1.3, but the build machines still use yasm 1.1, which is at least three years out of date. Bug 1224408 will update the build machines to use yasm 1.3. There are no expected problems because local builds using mozilla-build tools already use 1.3. mozilla-central has

Re: PSA/FYI: Changes to the Core::Video/Audio Bugzilla component

One change of note: the MSG/cubeb subcomponent is now called MSG/cubeb/GMP. This is to help folks find out where to file GMP bugs. NOTE: If a particular GMP bug can only affect Playback, we may move that bug under Playback when we triage it. If you're not sure where a new GMP bug should be

Re: PSA/FYI: Changes to the Core::Video/Audio Bugzilla component

On Mon, Jul 27, 2015 at 9:27 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On Mon, Jul 27, 2015 at 2:42 PM, Maire Reavy mre...@mozilla.com wrote: 1. Video/Audio: Playback 2. Video/Audio: MSG/cubeb 3. Video/Audio: Recording 4. WebRTC 5. Web Audio The first three seem to

PSA/FYI: Changes to the Core::Video/Audio Bugzilla component

Hi all, There are a few Bugzilla updates to the Core::Video/Audio bugs that I and the other media folks wanted everyone working on the project to know about. The Core::Video/Audio component has been renamed and reorganized a bit. Core::Video/Audio is now called Core::Audio/Video, and it has

Re: PSA/FYI: Changes to the Core::Video/Audio Bugzilla component

On Mon, Jul 27, 2015 at 2:42 PM, Maire Reavy mre...@mozilla.com wrote: 1. Video/Audio: Playback 2. Video/Audio: MSG/cubeb 3. Video/Audio: Recording 4. WebRTC 5. Web Audio The first three seem to start with Audio/Video:. ___

FYI: Change in crash signature naming in crash-stats

There has been a change in how Socorro records crash signatures. All signature pieces between and are now collapsed into T. That means that some crashes look like they stopped on June 12, when they really have not. Please be on the lookout for this as you interpret crash-stats. Here's the

Re: FYI: Serious windows bug affecting WebRTC when mem use is over 2GB

I guess we can add a command line option to our executable that calls the function and prints the results and exits and then invoke ourselves to do this in a new process and parse the output. What a silly bug. Thanks, Andreas Sent from Mobile. On Mar 26, 2015, at 07:03, Daniel Stenberg

Re: FYI: Serious windows bug affecting WebRTC when mem use is over 2GB

On 3/26/2015 3:00 AM, Randell Jesup wrote: Force a buffer in 2GB memory and always copy into/out of that buffer? That may work, other than it's inconvenient to force a buffer into 2GB space at the time when you need it, and thus we'd have to perma-allocate a large enough buffer for this.

Re: FYI: Serious windows bug affecting WebRTC when mem use is over 2GB

On Thu, 26 Mar 2015, Benjamin Smedberg wrote: What is the largest buffer that we can expect to need? Since VM allocation happens in 64k boundaries, is it sufficient to just use a 64k buffer for this? As per a recent comment in the bug however, it doesn't work to just reserve some memory in

Re: FYI: Serious windows bug affecting WebRTC when mem use is over 2GB

On Fri, Mar 27, 2015 at 5:05 AM, Andreas Gal andreas@gmail.com wrote: I guess we can add a command line option to our executable that calls the function and prints the results and exits and then invoke ourselves to do this in a new process and parse the output. What a silly bug. Surely

FYI: Serious windows bug affecting WebRTC when mem use is over 2GB

Thanks to detective work by a subscriber to dev.media (Tor-Einar Jarnbjo), we've found the cause of unexplained ICE (NAT-traversal) failures in WebRTC on Windows (bug 1107702). This may also affect the code in netwerk that tracks the network link status. It turns out that 32bit Windows programs

Re: FYI: Serious windows bug affecting WebRTC when mem use is over 2GB

Force a buffer in 2GB memory and always copy into/out of that buffer? That may work, other than it's inconvenient to force a buffer into 2GB space at the time when you need it, and thus we'd have to perma-allocate a large enough buffer for this. (Note GetAdapters*() is typically used with a

fyi, temporary degraded performance in syncing to gecko-dev.git

Status: gecko-dev.git updating normally at present. tl;dr: there were some significant conversion delays Friday morning PT (approx 0500-1040PT). Service has been restored. One additional (much shorter) delay will be needed for final

FYI - gitmirror.m.o duplicate repositories will be removed Feb 16

tl;dr: if you reference git://gitmirror.mozilla.org/mozilla-b2g/gaia, please change to git://git.mozilla.org/releases/gaia.git gitmirror.mozilla.org gets overloaded from time to time. To reduce load, we will be removing dead repositories and repositories already mirrored to git.mozilla.org.

Completed FYI: Re: Current recovery plan for gecko-dev and git (Was: Re: gecko-dev and Git replication will be broken for a little while)

All work was completed on Monday and services fully restored. If you are experiencing any issues, please contact #vcs. NOTE: if you use the remote git.mozilla.org/integration/gecko-dev.git please keep reading. If you use this particular remote, and pulled during the problem window (roughly

FYI:

tl;dr: trees and buildfarm will be bumpy this Saturday, November 15, from 0300-1400 PT (1100-2200 UTC) devs will need to monitor their builds, and trigger rebuilds via self serve as needed. There may be several short time frames when

Re: FYI: developer services components moving in Bugzilla Oct 1

...@mozilla.com, dev-platform@lists.mozilla.org, Dylan Hardison dhardi...@mozilla.com Enviados: Miércoles, 1 de Octubre 2014 0:05:35 Asunto: FYI: developer services components moving in Bugzilla Oct 1 These changes (below) will be made on Oct 1 around 2100 PT The complete set of changes are listed

FYI: developer services components moving in Bugzilla Oct 1

These changes (below) will be made on Oct 1 around 2100 PT The complete set of changes are listed at: https://bugzilla.mozilla.org/show_bug.cgi?id=1071332#user_story_header On 2014-09-26 16:35 , Hal Wine wrote: tl;dr: Where you file bugs for version control systems, etc. will be changing.

FYI: developer services components moving in Bugzilla next week.

tl;dr: Where you file bugs for version control systems, etc. will be changing. Developer Services (https://wiki.mozilla.org/DeveloperServices) are the folks who support the version control systems, source code indexing, etc. These systems have been handled by various groups in the past, and the

FYI: Emergency try reset in process - https://bugzil.la/1053558

tl;dr: try repo is being reset - read on for ways to access old push data Today we experienced another hg.m.o event that is not recovering similar to past events. After 2-1/2 hours with no signs of recovery, and with the recommendation of the sheriffs, we are resetting the try repo now. While

FYI: [Planned Maintenance Notification] August 9th - Tree Closing Maintenance Window

FYI - some significant network work will be performed during our regular Tree Closing Window (TCW) Saturday, Aug 9, 0900-1200 PT (details below) We are going to not formally close the trees, but there will likely be delays (from auto retry) and some jobs might need to be manually retriggered

FYI: [Planned Maintenance Notification] Tree closing maintenance window, Sat May 17, 0900-1600 PT

Original Message Subject:[Planned Maintenance Notification] Tree closing maintenance window Date: Thu, 15 May 2014 21:28:41 - From: notificati...@mozilla.com To: every...@mozilla.org Short Summary: Mozilla IT will have a tree closing maintenance window

URGENT FYI: git.mozilla.org will be offline at 1000 PT today for approx 1 hr - Tree Closure

As some of you are aware, we've been having some capacity issues with git.mozilla.org of late, which has impacted build times and caused tree closures. While we work on longer term fixes, we're going to take the server down to add addition RAM at 1000PT today. This will require closing all trees

FYI I you have a slave currently borrowed from Releng (Maint 3/28 2200 PT)

NOTE: if RelEng has loaned you a slave, you may be impacted by the VPN work below happening this Friday night Original Message Subject:[Planned Maintenance Notification] Mozilla VPN maintenance Date: Wed, 26 Mar 2014 18:44:23 - From: notificati...@mozilla.com

Re: FYI I you have a slave currently borrowed from Releng (Maint 3/28 2200 PT)

Hi, If I'm currently borrowing a machine I don't know about it or have a particular use for it. Trev On Wed, Mar 26, 2014 at 12:14:02PM -0700, Hal Wine wrote: NOTE: if RelEng has loaned you a slave, you may be impacted by the VPN work below happening this Friday night Original

FYI: Try repo will be reset Thur, Jan 22, 0500 PT

As usual, previous try pushes will be discarded. After the reset, try push times should be improved. Two improvements since last try reset: - tbpl has been enhanced to maintain the links to your recent try pushes that will be lost - going forward, this will be a standard part of the once per

Re: FYI: Nightly 28 uplift in 7 days

- Original Message - This is a friendly reminder that the next channel merge date [1] is only 7 days away! So don't forget to land those last minute bug fixes this week. :) Also, you may want to hold destablizing or less important changes until next week for Nightly 29. As Gavin

FYI: Nightly 28 uplift in 7 days

This is a friendly reminder that the next channel merge date [1] is only 7 days away! So don't forget to land those last minute bug fixes this week. :) Also, you may want to hold destablizing or less important changes until next week for Nightly 29. cpeterson [1]