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 c

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 fa

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 migrations

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

privacy. Best regards, Martin Millnert 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 st

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 yo

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 sele

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 cloudflar

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 o

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 selection

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 reacti

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 embed this experiment in the product, and b

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 intention, nightliness or pro

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 ri

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 r

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 separa

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 use

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 DNS request to a thir

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 must be good, and f

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. Us

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 information to third p

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 expec

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 ne

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

what's proposed here without > 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

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

biguously 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, especially ephemeral flip pref changes, and > that's why the FYI goes her

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 the same for others. W

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 Mozilla, let alone

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

ted 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 is impacted invites confusion. Future possible > change

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

ions (O(~ 1/2 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 larg

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 industry these days and >> some of our own mist

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 sees the Host header in un

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 worth taking a > little

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 per

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 DNS and > privacy and hi

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 (yo

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 > place to look out for th

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 w

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: > https://github.com/mozilla/sccache/releases/tag/0.2.

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 https://lists.mozilla.o

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 of

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 > currently broken in

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 Qualit

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 ma

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 ___ dev-pla

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, 2017 at 12:37 PM, T

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 great news, Ted! > >

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 the peers? > > I don't

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 l

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 and

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. T

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.

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 progre

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 https://lists.mozilla.org/listinfo/dev-

FYI: Tree Closing Maintenance Window, Sat January 9 2016, 0600-1330 PST 2016-01-09 06:00 PST 450 mins

Tracker bug: https://bugzil.la/1230205 -- Forwarded message -- From: Date: Mon, Jan 4, 2016 at 3:03 PM Subject: [Planned] Scheduled Tree Closing Maintenance Window, Sat January 9 2016, 0600-1330 PST 2016-01-09 06:00 PST 450 mins Issue Status: Upcoming Short Summary: IT will be

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

On Saturday, December 12, 2015 at 4:19:55 PM UTC-6, Cameron Kaiser wrote: > 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

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 addons installed

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 installed a > nu

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 peo

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 peo

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 rollout

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 purpo

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

-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 b

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 is to then

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 of

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 __

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 https://lists.mozilla.org/l

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 yasm

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 file

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

On Mon, Jul 27, 2015 at 9:27 PM, Ehsan Akhgari wrote: > On Mon, Jul 27, 2015 at 2:42 PM, Maire Reavy 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:".

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

On Mon, Jul 27, 2015 at 2:42 PM, Maire Reavy 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:". ___ dev-platform mailin

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 becom

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 . 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 So

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

On Fri, Mar 27, 2015 at 5:05 AM, Andreas Gal 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 we can ship a littl

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 wr

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 t

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

>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

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? Thanks, Andreas > On Mar 25, 2015, at 11:17 PM, Randell Jesup wrote: > > 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 We

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 w

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 fix,

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. (s

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 J

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

.org, "Dylan Hardison" 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 at: https://bugzilla.mozilla.org/show_bug.cgi?id=

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 bu

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 you

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 r

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 o

FYI: intermittent build farm capacity reductions during data center move starts May 19

As you heard in today's project meeting, IT's consolidation of data centers will save us $900K/yr!! Yay! There will be some impact to the build farm as the move actually happens, and this posting outlines them. The impact to engineering will be a slight capacity reduction in the build far for the

FYI: intermittent build farm capacity reductions during data center move starts May 19

As you heard in today's project meeting, IT's consolidation of data centers will save us $900K/yr!! Yay! There will be some impact to the build farm as the move actually happens, and this posting outlines them. The impact to engineering will be a slight capacity reduction in the build far for the

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

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 > > > Origi

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 To:

  1   2   >