Re: Correct way to build style bindings on GNU/Linux ARMv7?

[Ralph Giles]

If you can install a new-enough (4.0.1 worked last I checked, but 5.0.1 is
better) clang and llvm development system packages, those should let the
build complete.

If your distro doesn't provide a new-enough toolchain you'll have to
compile one. Set LLVM_CONFIG in the environment to point to your
llvm-config executable if it's not in path.

We don't build a clang package in automation for arm hosts, so there isn't
one to download. If this is to be a regular thing, It should be
straightforward to add one.

HTH,
 -r

On Wed, Feb 7, 2018 at 9:04 AM, Henri Sivonen  wrote:

> mach bootstrap doesn't appear to download a bindgen-compatible clang
> on an ARMv7 GNU/Linux host.
>
> mach build then complains about not being able to generate the stylo
> bindings.
>
> As I understand it, --disable-stylo-build-bindgen should be OK if one
> isn't modifying stylo, but building with that flag fails:
> 12:02.52 error[E0609]: no field `mBoolFlags` on type `&'ln
> gecko_bindings::structs::root::nsINode`
> 12:02.53-->
> /var/host/media/removable/gecko/gecko/mozilla-central-
> ea00596eb02e/servo/components/style/gecko/wrapper.rs:200:18
> 12:02.53 |
> 12:02.53 200 | (self.0).mBoolFlags
> 12:02.53 |  ^^
>
> What's the correct way to build m-c, the stylo bindings in particular,
> on ARMv7+NEON GNU/Linux?
>
> (My goal is to run XPCOM string gtest microbenchmarks in the hope that
> they are representative of Android ARMv7+NEON.)
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> 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: Faster gecko builds with IceCC on Mac and Linux

[Ralph Giles]

On Wed, Jan 17, 2018 at 10:27 AM, Steve Fink  wrote:


> Would it be possible that when I do an hg pull of mozilla-central or
> mozilla-inbound, I can also choose to download the object files from the
> most recent ancestor that had an automation build?


You mention 'artifact builds' so I assume you know about `ac_add_options
--enable-artifact-builds` which does this for the final libXUL target,
greatly speeding up the first people for people working on the parts of
Firefox outside Gecko.

In the build team we've been discussing for a while if there's a way to
make this more granular. The most concrete plan is to use sccache again.
This tool already supports multi-level (local and remote) caches, so it
could certainly pull the latest object files from a CI build; it already
does this when running in automation. There are still some 'reproducible
build' issues which block general use of this: source directory prefixes
not matching, __FILE__ and __DATE__, different build flags between
automation and the default developer builds, that sort of thing. These
prevent cache hits when compiling the same code. There aren't too many
left; help would be welcome working out the last few if you're interested.

We've also discussed having sccache race local build and remote cache fetch
as you suggest, but not the kind of global scheduling you talk about.
Something simple with the jobserver logic might work here, but I think we
want to complete the long-term project of getting a complete dependency
graph available before looking at that kind of optimization.

FWIW,
 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Faster gecko builds with IceCC on Mac and Linux

[Ralph Giles]

On Tue, Jan 16, 2018 at 11:19 AM, Jean-Yves Avenard 
wrote:

12 minutes sounds rather long, it’s about what the macpro is currently
> doing. I typically get compilation times similar to mac...
>

Yes, I'd like to see 7 minute build times again too! The E5-2643 has a
higher clock speed than the Xeon W in the iMac Pro (3.4 vs 3.0 GHz) but a
much lower peak frequency (3.7 vs 4.5 GHz) so maybe the iMac catches up
during the single-process bottlenecks. Or it could be memory bandwidth.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Faster gecko builds with IceCC on Mac and Linux

[Ralph Giles]

On Tue, Jan 16, 2018 at 7:51 AM, Jean-Yves Avenard 
wrote:

But I would be interested in knowing how long that same Lenovo P710 takes
> to compile *today*….
>

On my Lenovo P710 (2x2x6 core Xeon E5-2643 v4), Fedora 27 Linux

debug -Og build with gcc: 12:34
debug -Og build with clang: 12:55
opt build with clang: 11:51

Interestingly, I can almost no longer get any benefits when using icecream,
> with 36 cores it saves 11s, with 52 cores it saves 50s only…
>

Are you staturating all 52 cores during the buidls? Most of the increase in
build time is new Rust code, and icecream doesn't distribute Rust. So in
addition to some long compile times for final crates limiting the minimum
build time, icecream doesn't help much in the run-up either. This is why
I'm excited about the distributed build feature we're adding to sccache.

I'd still expect some improvement from the C++ compilation though.


> It’s a very sweet machine indeed
>

Glad you finally got one! :)

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Firefox build issues with Rust and the new VS2017 15.5 update

[Ralph Giles]

On Tue, Dec 5, 2017 at 9:16 AM, Emilio Cobos Álvarez 
wrote:


> That looks like bindgen, but the error is a C++ one, that is, it's clang
> who is choking to parse type_traits. Which version of libclang is this
> using?
>

The libclang version supplied to bindgen is set by
https://searchfox.org/mozilla-central/source/build/build-clang/clang-win32.json

That's a patched svn r311608 which is somewhere around 4.0.1.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Status of support for Android on ARMv7 without NEON

[Ralph Giles]

On Tue, Oct 10, 2017 at 5:43 AM,  wrote:


> Is it now impossible to build APKs which run on this platform?
>

Some patching would be required.


> Where can I find an APK of previous versions?
>

Historic versions of Firefox for Android can be found at
https://archive.mozilla.org/pub/mobile/releases/ Please not that these will
have unpatched security vulnerabilities, so I don't recommend them for
daily use.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

New minimum Rust version policy for Firefox

[Ralph Giles]

We've formalized a new plan for when we update the minimum-required Rust
version for building Firefox. Starting later this week we'll require the
latest stable Rust two weeks after it is released.

This means we'll start requiring Rust 1.19.0 August 3rd. If you compile
mozilla-central and haven't run './mach bootstrap' recently, I suggest
doing so now to update.

I've posted a full schedule
<https://wiki.mozilla.org/Oxidation#Supported_Rust_versions_for_Firefox_builds>
of when the minimum version will change for m-c, and what version of Rust
will be required to build each Firefox release. These are expectations to
aid in planning; we may delay particular bumps if there are issues or a
code freeze, but the expectation is that we'll need to update our
development environments by those dates.

We expect ESR releases will stay on the Rust version of the corresponding
stable release.

This change is based on several meetings and discussions with contributors
over the last two months. Rust is evolving quickly, and those working on
Rust code need to know what release to target. Previously we updated the
target version every few releases, whenever someone argued there was a
sufficiently compelling feature. Negotiating that every time was
distracting. Having a planned schedule lets everyone coordinate their work.
Updating Rust regularly helps us iterate and improve the language,
participating in the incredible momentum of the Rust developer community.

Waiting two weeks gives contributors some time to update their
environments. This is especially relevant to those who don't always have a
fast network connection, or work on tier-3 targets where using upstream
Rust packages isn't possible.

This doesn't affect our policy for official Firefox builds, just developer
builds and downstream packagers. I've written up details of the policy
<https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox>, along with
motivation and considered alternatives. Please read that before responding
if you have concerns. I'll update the page next week in response to any
persuasive arguments and move the minimum-version proposal to the current
policy section.

Thanks for you time, and let me know if you have any questions.

Ralph Giles
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: OS/2 still supported ?

[Ralph Giles]

 Tue, Jul 25, 2017 at 8:25 PM, Steve Wendt  wrote:


> Likewise for libvpx and libffi?
>

libvpx is maintained upstream and updated periodically, so there's no point
making changes if they're not also accepted upstream. I don't know about
libffi; our vendored copy is a minor release behind upstream (3.1 vs 3.2.1
released in 2014).

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Announcing MozillaBuild 3.0 Release

[Ralph Giles]

On Mon, Jul 24, 2017 at 3:51 PM, Botond Ballo  wrote:


> With MozReview [1], you can submit patches from the command line via a
> simple "hg push review".
>

There's a `git mozreview push` command in the same repo but I believe it
requires rebasing on top of a git-cinnabar clone of a mercurial repository.
If you want to do this, install the extension and follow the setup
instructons at
https://github.com/glandium/git-cinnabar/wiki/Mozilla:-A-git-workflow-for-Gecko-development.
With that setup you can also use `./mach try` to submit test builds from
the command line (once you have tier-1 commit access).

There are also a few git extensions which can push and pull patches to
bugzilla, but this isn't the preferred method as it's harder to get test
feedback and loses the history.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: IDL vs ifdef

[Ralph Giles]

On Sat, Jul 22, 2017 at 12:11 PM, Enrico Weigelt, metux IT consult <
enrico.weig...@gr13.net> wrote:


> I'm currently in process of making the media stuff optional.
> (dont need/want it within mail client).
>

I suspect this will be painful to maintain. We used to have a lot of
#ifdefs for media playback support but they weren't tested and were usually
broken, so we removed them.

If you're just concerned about codesize, you can get a significant
reduction by stubbing out the MediaDecoder class and then disabling all the
code it depends on. For recent versions you'll also need to stub out the
webrtc implementation. But in general, bottom-up will be easier than
top-down for the media stuff.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: platform specialities

[Ralph Giles]

On Sun, Jul 23, 2017 at 8:11 PM, Enrico Weigelt, metux IT consult <
enrico.weig...@gr13.net> wrote:


> I'm seeing lots of things like #ifdef XP_WIN etc.
>
> Pretty often for simple things like directory delimiters,
> some missing standard types or functions, etc.
>
> Shouldn't things belong into NSPR ?
>

Or a Path.h class under mfbt. Sounds like an improvement.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Embedding Firefox or Gecko in 2017

[Ralph Giles]

You're right that this isn't currently easy to do.

A more recent project, now also abandoned, was
https://github.com/mozilla/positron You might see if that's a place to
start.

 -r

On Thu, Jul 6, 2017 at 12:47 PM, cnico7  wrote:

> Hi,
>
> I would like to embed gecko or firefox in a native windows application.
> The need is to be able to use gecko's rendering and javascript engines in
> order to display web pages that are not correctly displayed with other
> browsers (mainly for legacy reasons of the intranet web site). Those pages
> are part of a desktop application deployed on windows 7.
>
> So I did some searches around this subject and I discovered it could be a
> complex path to achieve it with recent gecko versions.
>
> Here is what I found :
>  * around 2000, an embedding solution was available through XPCOM as
> described here : https://developer.mozilla.org/en-US/docs/Gecko/Embedding_
> Mozilla
> Unfortunately, this is obsolete and does not work any more from my
> understanding.
>  * this blog post http://chrislord.net/2016/03/08/state-of-embedding-in-
> gecko/ lists some old embedding possibilities.
> Unfortunately, none of them seems to still be available.
>  * the servo project seems interesting but is to be shipped in years from
> now.
>
> So here are my questions :
> If I had the technical capabilities to contribute to a gecko embedding
> solution, from what should I start investigating ?
> Is EmbedLite (aka IPCLite) the good starting point or is there a better
> path to embed gecko ?
> If yes, is there a description of the API to use ?
>
> I had the idea of using firefox with marionette protocol in order to
> interact with the engine and to use a custom plugin in order to hide all
> the design (menus, tab bars,...). This idea has many drawbacks : it is slow
> at launching time, it requires to improve marionette protocol in order to
> intercept browsing events and hiding all ui elements with webextensions is
> no more possible.
> So my idea is clearly not a the good way.
>
> Any help would be appreciated. Even if I have not all the technical
> knowledge of firefox internal, I am ready to work on it but I need the good
> entry points to start.
>
> Thank you for reading me and for your answers,
>
> Regards,
> ___
> 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: switch to macosx cross-compiled builds on taskcluster on trunk

[Ralph Giles]

On Wed, Jun 21, 2017 at 9:47 PM, Randell Jesup 
wrote:


> Does this have affect on our still using the 10.7 Mac SDK?


We are still building against the macOS 10.7 SDK, but we can update to 10.9
once we've confirmed transition away from the 10.7 builders.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Rust 1.17.0 or later now required to build Firefox

[Ralph Giles]

If you're building Firefox from source, please check that your rust
toolchain is up-to-date. You can either:

  rustup update

or

  ./mach bootstrap

We've just queued a patch to bump the minimum required rust version from
1.15.1 to 1.17.0, the version released 8 weeks ago. This is necessary for
merging recent changes to the style system from servo as part of the
Quantum project.

The commands above should update you to at least 1.18.0, which is even
better. See https://bugzilla.mozilla.org/show_bug.cgi?id=1374807 and
adjacent bugs for details.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Status of support for Android on ARMv7 without NEON

[Ralph Giles]

Yes, the store doesn't provide any filtering for non-neon armv7
devices. We were going to write some runtime test+error page, but it
looks like that didn't happen.

Sorry for the hassle,
 -r

On Tue, May 23, 2017 at 1:00 PM,   wrote:
> I was updating from Google Play without any warning on my -indeed very old 
> but good functioning- ASUStransformer tf101. Took even a while to figure out 
> what the problem was and why all of a sudden FF didn't work anymore.
> PtrK
>
> ___
> 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: Have you run 'mach bootstrap' lately?

[Ralph Giles]

The stand-alone bootstrap.py script actually has a --no-interactive
option (which answers 'yes' to everything) but the mach wrapper
doesn't support this.

`mach mercurial-setup` takes an --update-only option. Maybe we
implementing something like that for `mach boostrap` would help. Or
calling it something more descriptive like `mach update-deps`. Like
mercurial-setup, it could still use the bootstrap python module to
install things. While the two use cases are different, it makes sense
to share code between an initial development environment setup script
and one that updates that environment.

 -r

On Mon, May 15, 2017 at 3:39 PM, Ethan Glasser-Camp
 wrote:
> Actually, I think my real question is "What is the intended way for
> developers to keep their development environment up-to-date?" I don't think
> that way should require a developer to answer questions, because the
> answers presumably haven't changed since the last time they answered them.
> If the intended way is `mach bootstrap`, then I think `mach bootstrap`
> should have an option to skip the questions[*]. If `mach bootstrap` is only
> intended to run once when setting up a new development environment, then
> maybe there should be a `mach tune-up` command or something like that.
>
> I'm happy to file bugs for whichever is the case, but I'm not sure which
> one it is.
>
> Ethan
>
> [*] When using `./mach bootstrap --settings ./mozconfig`, I get: `The
> bootstrap command does not accept the arguments: --settings ./mozconfig`.
> When using `./mach --settings ./mozconfig bootstrap`, I get the questions.
>
>
> On Fri, May 12, 2017 at 1:04 PM, Geoffrey Brown  wrote:
>
>> I'm not sure. I always just answer the prompts and am happy with that.
>>
>> There is a --settings option, which sounds like it might be helpful, but I
>> don't have any experience with that.
>>
>>  - Geoff
>>
>> On Fri, May 12, 2017 at 9:00 AM, Ethan Glasser-Camp <
>> eglasserc...@mozilla.com> wrote:
>>
>>> Is there a way to run it without having to reanswer the configuration
>>> questions?
>>>
>>> Ethan
>>>
>>>
>>
> ___
> 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: Rationalising Linux audio backend support

[Ralph Giles]

On Wed, Mar 29, 2017 at 3:40 AM, Henri Sivonen  wrote:

> Arguably, system configuration info belongs under FHR, so it would not
> be optimal if the Pulse check wasn't there but was in opt-in Telemetry
> instead. Where was it?

The check was marked opt-out.

https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/Histograms.json#154
https://bugzilla.mozilla.org/show_bug.cgi?id=1280630

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proper way to return nsresult from Rust before Stylo is mandatory?

[Ralph Giles]

On Fri, Mar 17, 2017 at 4:27 AM, Emilio Cobos Álvarez  wrote:

> Fedora didn't have libclang 3.9 packages IIRC, but that could've
> changed.

clang 3.9.1 in now in the fedora 25 updates repo.
https://koji.fedoraproject.org/koji/packageinfo?packageID=21848

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is there a way to improve partial compilation times?

[Ralph Giles]

I second Jeff's point about building with icecream[1]. If you work in
an office with a build farm, or near a fast desktop machine you can
pass jobs to, this makes laptop builds much more tolerable. Despite
the warnings on the mdn page, I do this over the wan as well. It's a
lot slower than when I'm in the office, but still a lot faster than a
local-only build.

There's also a proposal to pull from the continuous integration build
cache[2]. That doesn't work yet though.

 -r

[1] 
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Using_Icecream
[2] https://github.com/mozilla/sccache/issues/30

On Tue, Mar 7, 2017 at 3:50 PM,   wrote:
> On Tuesday, March 7, 2017 at 3:24:33 PM UTC-8, Mike Hommey wrote:
>> On what OS? I have a XPS 12 from 2013 and a XPS 13 9360, and both do
>> clobber builds in 40 minutes (which is the sad surprise that laptop CPUs
>> performance have not improved in 3 years), on Linux. 70 minutes is way
>> too much.
>
> Arch Linux.
>
> Sometimes I'll get down to 40min, but often it's 60.
>
> I'm going to try to remove ccache for the next rebuild and see how it affects 
> things.
>
> I may also have to request a new laptop although I was really hoping now to 
> have to for at least another year...
>
> zb.
> ___
> 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: Editing vendored crates

[Ralph Giles]

On Mon, Feb 27, 2017 at 4:03 AM, Henri Sivonen  wrote:

> I find this level of difficulty (self-inflicted quasi-Tivoization
> practically) an unreasonable impediment to practicing trivial Software
> Freedom with respect to the vendored crates.

I agree we need to fix the ergonomics here, but I don't think you
should be so hard on cargo. The hash checking is designed to make
builds more reproducible, so that unless we make an explicit diversion
we know we're building with the same source as every other use of that
same package version. This has benefits for security, debugging, and
change control.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Should cheddar-generated headers be checked in?

[Ralph Giles]

I agree with Ted and Jack. For the specific case of the mp4parse
cheddar header, we currently check that in because it wasn't much
hassle, and cheddar pulled in syntex-syntax as a dependency which
added significantly to the build time. Eventually I want to use
runtime binding generation, for the usual reason that having generated
source code under version control is confusing. Porting cheddar to the
new `syn` crate would address the issue with build time.

FWIW,
 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rust required to build Gecko

[Ralph Giles]

On Thu, Nov 24, 2016 at 2:49 PM, Ralph Giles <gi...@mozilla.com> wrote:

> You'll still be able to build without a rust compiler by adding:
>
>   ac_add_options --disable-rust

Just a heads up that I've removed this configure option in bug
1284816, so this will stop working on mozilla-central with the next
autoland merge. If you have this in your mozconfig, you'll need to
remove it and add a recent rust toolchain to your build environment.
You can do this by running `./mach bootstrap` and restarting your
shell, or running the install from https://rust-lang.org/

If you're maintaining Firefox on a tier-3 platform which doesn't have
good rust support, please be aware that Firefox 53 will be the last
upstream release where rust is optional.

Cheers,
 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: GCC 4.9 now required to build on Linux/Android

[Ralph Giles]

On Tue, Jan 3, 2017 at 7:05 AM, Ben Kelly  wrote:

> FWIW, it seems ./mach bootstrap does not install gcc 4.9 on ubuntu 14.04.

It looks like it's not packaged for 14.04; so we'd have to add a ppa
to do this prior to 16.04.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Ralph Giles]

On Fri, Dec 16, 2016 at 12:25 PM, Jason Duell  wrote:

> So a switch that toggles the "network is expensive" bit, plus turns off
> browser updates, phishing list fetches, etc?

Windows 10 has such a switch, although I suspect it's up to
applications to opt-in. An API to query 'metered connection' status
for each interface has been available since Windows 8. See
https://msdn.microsoft.com/en-us/library/windows/desktop/hh437593(v=vs.85).aspx

FWIW,
 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rust required to build Gecko

[Ralph Giles]

Anyway, thanks for the suggestion, Simon. I filed
https://bugzil.la/1324040 with this fix.

In the meantime, the curl command line from https://rustup.rs/ should
work equivalently.

 -r

On Fri, Dec 16, 2016 at 9:40 AM, Ralph Giles <gi...@mozilla.com> wrote:
> On Fri, Dec 16, 2016 at 9:19 AM, Simon Sapin <simon.sa...@exyr.org> wrote:
>
>> RUSTUP_URL_BASE = 'https://static-rust-lang-org.s3.amazonaws.com/rustup'
>>
>> If that fixes the issue for you, it’s likely that your Python version does
>> not support SSL SNI.
>
> I can reproduce with python urlib2.urlopen() on an ubuntu 14.04 docker
> container. I thought using the in-tree requests module to work around
> that issue?
>
>  -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rust required to build Gecko

[Ralph Giles]

On Fri, Dec 16, 2016 at 9:19 AM, Simon Sapin  wrote:

> RUSTUP_URL_BASE = 'https://static-rust-lang-org.s3.amazonaws.com/rustup'
>
> If that fixes the issue for you, it’s likely that your Python version does
> not support SSL SNI.

I can reproduce with python urlib2.urlopen() on an ubuntu 14.04 docker
container. I thought using the in-tree requests module to work around
that issue?

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rust required to build Gecko

[Ralph Giles]

Today we've pushed the change to enable rust language code by default
in Firefox builds. The changes are on the autoland branch right now,
so this will affect your builds from mozilla-central or gecko-dev
starting tomorrow. This brings our default developer build in line
with what we've been doing with official builds. Thanks to everyone
who helped make this happen.

As a reminder, you'll now need `rustc` and `cargo` in the PATH of your
build environment, just like with python and the C/C++ compiler. You
can install rust with `./mach bootstrap`. After that you can stay on
the latest stable release by running `rustup update` every 6 weeks or
so. If you want more control I recommend manually running the
installer and update tool from https://rustup.rs/

More information about using Rust code in Firefox can be found at
https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code

Cheers,
 -r


On Thu, Nov 24, 2016 at 2:49 PM, Ralph Giles <gi...@mozilla.com> wrote:
> tl;dr This is a heads-up that all gecko developers should install rust.
>
> Next week I plan to switch our default build config to require Rust
> when building Firefox.[1] If you compile Firefox from the C++ source,
> please install the Rust language environment now.
>
> You can install Rust by running `./mach bootstrap` which will download
> and run the rustup installer for you.[2]
>
> We recommend the installer at https://rustup.rs/ (despite being beta)
> because it makes staying up to date and cross-compilation easy. If you
> want more control, or to experiment with rust, you can install
> directly from that website.
>
> The main thing is to have up-to-date versions of the `rustc` and
> `cargo` executables in the path of your build shell. Rust releases
> every six weeks, just like Firefox, and we generally require the
> latest stable release to compile mozilla-central. You can stay current
> by running `rustup update`.
>
> You'll still be able to build without a rust compiler by adding:
>
>   ac_add_options --disable-rust
>
> to your mozconfig. This is a temporary work-around; we expect to
> remove that option and require Rust unconditionally early next year as
> non-optional features start to depend on it.
>
> Rust language in Gecko is an important part of Project Quantum. I'm
> excited to be taking this next step toward that future. We first
> shipped Rust code to users in Firefox 48, so it's long past time this
> aspect of our default builds matched what we release.[3]
>
> Thanks for your attention,
>  -r
>
> [1] Enabling rust is https://bugzil.la/1283898
> [2] bootstrap support landed Tuesday in https://bugzil.la/1286799
> [3] If you have issues with the installer or build, please file issues
> blocking our tracking bug at https://bugzil.la/oxidation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rust required to build Gecko

[Ralph Giles]

I wasn't able to enable Rust by default this week. While it's working
for most developers, there are some automation jobs which aren't ready
for the change. We'll address those and continue to improve the
`./mach boostrap` installer behaviour before flipping the switch.

Thanks to everyone for your support and testing feedback!

 -r

On Thu, Nov 24, 2016 at 2:49 PM, Ralph Giles <gi...@mozilla.com> wrote:
> tl;dr This is a heads-up that all gecko developers should install rust.
>
> Next week I plan to switch our default build config to require Rust
> when building Firefox.[1] If you compile Firefox from the C++ source,
> please install the Rust language environment now.
>
> You can install Rust by running `./mach bootstrap` which will download
> and run the rustup installer for you.[2]
>
> We recommend the installer at https://rustup.rs/ (despite being beta)
> because it makes staying up to date and cross-compilation easy. If you
> want more control, or to experiment with rust, you can install
> directly from that website.
>
> The main thing is to have up-to-date versions of the `rustc` and
> `cargo` executables in the path of your build shell. Rust releases
> every six weeks, just like Firefox, and we generally require the
> latest stable release to compile mozilla-central. You can stay current
> by running `rustup update`.
>
> You'll still be able to build without a rust compiler by adding:
>
>   ac_add_options --disable-rust
>
> to your mozconfig. This is a temporary work-around; we expect to
> remove that option and require Rust unconditionally early next year as
> non-optional features start to depend on it.
>
> Rust language in Gecko is an important part of Project Quantum. I'm
> excited to be taking this next step toward that future. We first
> shipped Rust code to users in Firefox 48, so it's long past time this
> aspect of our default builds matched what we release.[3]
>
> Thanks for your attention,
>  -r
>
> [1] Enabling rust is https://bugzil.la/1283898
> [2] bootstrap support landed Tuesday in https://bugzil.la/1286799
> [3] If you have issues with the installer or build, please file issues
> blocking our tracking bug at https://bugzil.la/oxidation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rust required to build Gecko

[Ralph Giles]

On Mon, Nov 28, 2016 at 9:28 AM, Michael Froman  wrote:

> Any thoughts?  Further info:
> mfroman-23602:moz-central mfroman$ which rustc
> /Users/mfroman/.cargo/bin/rustc
> mfroman-23602:moz-central mfroman$ rustc --version
> error: no default toolchain configured

Very mysterious. This error message usually means rustup's redirect to
the actual toolchain (in /Users/mfroman/.multirust/toolchains) is
confused. I've seen it when the executable filename has a prefix, for
example.

Make sure there's a toolchain installed under ~/.multirust, then maybe
try `rustup update` and see what that says.

If that doesn't work, try `rustup default stable`.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rust required to build Gecko

[Ralph Giles]

On Sun, Nov 27, 2016 at 2:46 PM, Gerald Squelart  wrote:

> Following your instructions, rustc and friends are in ~/.cargo/bin, and I've 
> added that path in my $PATH.
>
> But now, `./mach build` gives me:
>   force-cargo-build
>   env: /usr/local/bin/cargo: No such file or directory
> [...]
> Sym-linking rustc from /usr/local/bin worked, but it feels wrong!

That does seem wrong. So you have rustc and cargo in ~/.cargo/bin, but
it was looking in /usr/local/bin instead? Was there a
/usr/local/bin/rustc previously? What does `which cargo` print?

> After that, building works, but shows some scary bold text:
>   note: link against the following native artifacts when linking against this 
> static library
>   note: the order and any duplication can be significant on some platforms, 
> and so may need to be preserved
>   note: library: System
>   note: library: c
>   note: library: m
>
> What's with that?

The rust compiler prints this out whenever it generates a static
library, to remind you to link the dependencies into the final target.
We do that (XUL has the same dependencies) but I agree the `note`
output is distracting. I wrote a patch to suppress this by writing it
to a file instead, but didn't get it to an acceptable state to land.
If someone wants to un-bitrot it and add tests, I think that would be
the best way to resolve this.
https://github.com/rust-lang/rust/issues/31471

Thanks for sharing your results,
 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rust required to build Gecko

[Ralph Giles]

On Fri, Nov 25, 2016 at 7:48 AM, Andrew Halberstadt
 wrote:

> For anyone confused by this, the binaries are downloaded to ~/.cargo/bin
> and adding this directory to your $PATH should fix the issue. The
> bootstrapper explains this if you run it a second time, but makes no
> mention of it the first time through for some reason.

Thanks. I've tried to address this in
https://bugzilla.mozilla.org/show_bug.cgi?id=1319860

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Rust required to build Gecko

[Ralph Giles]

tl;dr This is a heads-up that all gecko developers should install rust.

Next week I plan to switch our default build config to require Rust
when building Firefox.[1] If you compile Firefox from the C++ source,
please install the Rust language environment now.

You can install Rust by running `./mach bootstrap` which will download
and run the rustup installer for you.[2]

We recommend the installer at https://rustup.rs/ (despite being beta)
because it makes staying up to date and cross-compilation easy. If you
want more control, or to experiment with rust, you can install
directly from that website.

The main thing is to have up-to-date versions of the `rustc` and
`cargo` executables in the path of your build shell. Rust releases
every six weeks, just like Firefox, and we generally require the
latest stable release to compile mozilla-central. You can stay current
by running `rustup update`.

You'll still be able to build without a rust compiler by adding:

  ac_add_options --disable-rust

to your mozconfig. This is a temporary work-around; we expect to
remove that option and require Rust unconditionally early next year as
non-optional features start to depend on it.

Rust language in Gecko is an important part of Project Quantum. I'm
excited to be taking this next step toward that future. We first
shipped Rust code to users in Firefox 48, so it's long past time this
aspect of our default builds matched what we release.[3]

Thanks for your attention,
 -r

[1] Enabling rust is https://bugzil.la/1283898
[2] bootstrap support landed Tuesday in https://bugzil.la/1286799
[3] If you have issues with the installer or build, please file issues
blocking our tracking bug at https://bugzil.la/oxidation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using Firefox to test the Visual C++ compiler

[Ralph Giles]

On Wed, Nov 16, 2016 at 12:27 AM,   wrote:

> I'm a developer on the Microsoft Visual C++ compiler (code optimizer) and I'm 
> looking into extending our test suite with popular open-source projects. This 
> helps  us to find bugs earlier, ensuring that these projects are not broken 
> by frontend or backend changes. It also helps the projects themselves, by 
> making upgrades to the never compiler easier - ideally without any problems.

Hi. Exciting that you're trying out our code!

> 1. What is the latest version of Visual Studio that should be used? I tried 
> first VS2015 Update 3 and there seems to be a C++ error about "constexpr". 
> Next I tried Update 2 and that one finishes the build.

The current release source builds with VS2015 update 2. We're building
the development tree with VS2015 update 3. We have a 12-week
stabilization period for each release branch, but the main development
tree should always compile, although there may be occasional test
failures. You might consider using that for easier communication with
our developers and quicker testing of new C++ features. That code is
available form

https://github.com/mozilla/gecko-dev or
https://hg.mozilla.org/mozilla-central

> 2. What are the tests that should be run to test correctness? The idea here 
> is to ensure that new optimizations don't introduce new bugs, which should be 
> exposed by new test failures in Firefox. I looked over the QA Automated 
> testing page and there seem to be a lot of different test suites - running 
> all is probably not feasible. Is there a subset that is run when a checkin is 
> done, for example?

Tests expected to fail should be marked so in the tree, so as long as
you use the mach test harness, that should be fine. There are
intermittents and some environment/driver-dependent issues though. I'm
not an expert on our testing, especially on Windows, but I'd start
with gtest, check-spidermonkey, mochitest and crashtest. reftests can
be brittle.

You can see the currently passing tests at
https://treeherder.mozilla.org/#/jobs?repo=mozilla-release or
https://treeherder.mozilla.org/#/jobs?repo=mozilla-central for the
current development tree.

> 3. What Windows OS do you use for testing? Window 10, Windows 8, etc? Any 
> other configuration work needed, such as disabling the antivirus/firewall?

We build on Windows 8, Windows XP (possibly actually NT 2008?) and
Windows 2012 aws images. Look for `B` jobs on the treeherder site
linked above. Once you have a copy of the source and the build
environment, no network access should be necessary.

Hope that helps, and thanks for your interest in Firefox!

Cheers,
 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Adding Rust code to Gecko, now documented

[Ralph Giles]

On Wed, Nov 9, 2016 at 8:41 AM, Kartikaya Gupta  wrote:

> If I edit the third_party/rust/cmake/src/lib.rs
> in-place, the build fails because of a hash mismatch.

Interesting! This is supposed to happen as a check against corruption
and/or non-reproducible builds, but I can't reproduce by modifying
third_party/rust/byteorder/src/lib.rs. Is this the full gecko `mach
build` or a local `cargo build` of the crate you're working on?

> However if I do that the force-cargo-build step in the
> build fails saying the lock file needs updating but --locked was
> passed.

Try running 'cargo update' in toolkit/library/rust

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: hg.mozilla.org certificate fingerprint changed?

[Ralph Giles]

On Fri, Sep 30, 2016 at 12:33 PM, Gregory Szorc  wrote:
> `mach mercurial-setup` does an `hg pull` from hg.mozilla.org to obtain the
> version-control-tools repository, which is where most of the logic for `mach
> mercurial-setup` lives (because we have a nice testing harness in
> version-control-tools). `mach mercurial-setup` doesn't pin the hash when
> invoking `hg pull` because to do so would require vendoring the hash in the

> ... that means if you ran `mach mercurial-setup` on an old revision,
> the pinned hash would be guaranteed to be incorrect and the connection would
> always fail.

Hmm. We should be able to use the fact that keys aren't reused. What
if mercurial-setup had a vendored list of keys it knows have been
rotated out in the past and another list which will be rotated in in
the future of that particular revision? It could safely remove the
former if it finds them in .hgrc because if you were able to pull a
revision with that key marked expired, that should still be true when
it's invoked later. Since mercurial 3.8 and later support multiple
fingerprints, it would be safe to add any expected-to-be-used keys, as
long as they aren't later compromised. Setting some kind of time
window beyond which mercurial-setup doesn't attempt to install new
keys would limit the potential damage. No worse that trusting a
particular TLS config?

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: hg.mozilla.org certificate fingerprint changed?

[Ralph Giles]

The change was announced here and on firefox-dev a few weeks ago. See
for example 
https://groups.google.com/d/msg/mozilla.dev.platform/LOC83qKUPfk/cZtmaEbOAwAJ

It might be nice if `mach mercurial-setup` did this kind of update?

 -r

On Fri, Sep 30, 2016 at 12:18 PM, ISHIKAWA,chiaki  wrote:
> In the last few days, hg.mozilla.org certificate fingerprint seems to have
> changed.
> I noticed this because the trial to update local copy of mozilla-central
> repository within C-C repository failed due to
>
> m-central/mozilla', 'https://hg.mozilla.org/mozilla-central/']
> pulling from https://hg.mozilla.org/mozilla-central/
> abort: certificate for hg.mozilla.org has unexpected fingerprint
> 73:7f:ef:ab:68:0f:49:3f:88:91:f0:b7:06:69:fd:8f:f2:55:c9:56
> (check hostfingerprint configuration)
>
> But I did not see any announcement of this change.
> (It is possible that I missed it during a hectic schedule during a trip).
>
> However, it is great to see a posting of such major infra change in advace,
> especially security-related one.
>
> Finally, I bit the bullet and changed it, but checked bugzilla
> just in case, and found
> https://bugzilla.mozilla.org/show_bug.cgi?id=1305909
> which seems to be related.
>
> Automation is nice, but I still would like to see an announcement of server
> certificate change in advance.
>
> TIA
>
>
> ___
> 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: netwerk and media experts; feedback requests for background upload/download WebAPI video download use-case

[Ralph Giles]

On Wed, Sep 21, 2016 at 3:19 PM, Ehsan Akhgari  wrote:

> Good point, which brings us to this question: is media playback the only
> use case for using the in-progress downloads?

This in-progress issue is mostly about the download size, so I can
imagine the same thing happening with other large files. I guess
that's usually zip files of whatnot, software packages, maybe large
scanned documents. Wanting serial access is most common with media but
it could apply to those cases as well. Whether they're worth the work
of supporting, I don't know.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rationalising Linux audio backend support

[Ralph Giles]

On Fri, Jul 15, 2016 at 3:34 AM, Kurt Roeckx  wrote:

> I also wonder how this fallback thing works.  Things are linked to the
> pulseaudio library, but if the pulseaudio binary isn't installed things fall
> back to something else like alsa as far as I know.  Is this something the
> pulseaudio library does, or do you need to write the fallback yourself?

Currently, we try to dlopen the pulseaudio interface library and fall
back to alsa if that fails. So it's a build-time dependency (for the
headers) but not a run-time dependency. Except on gonk, where we
assume it's available and link to it directly. See
https://github.com/mozilla/gecko-dev/blob/378278ea830e7b01fb280d5274adccdfb2baab28/media/libcubeb/src/cubeb_pulse.c#L503

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Faster gecko builds with IceCC on Mac and Linux

[Ralph Giles]

On Tue, Jul 5, 2016 at 3:36 PM, Gregory Szorc  wrote:

> * `mach build binaries` (touch network/dns/DNS.cpp): 14.1s

24s here. So faster link times and significantly faster clobber times. I'm sold!

Any motherboard recommendations? If we want developers to use machines
like this, maintaining a current config in ServiceNow would probably
help.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Faster gecko builds with IceCC on Mac and Linux

[Ralph Giles]

On Tue, Jul 5, 2016 at 12:12 PM, Gregory Szorc  wrote:

>  I recommend 2x Xeon E5-2637v4 or E5-2643v4.

For comparison's sake, what kind of routine and clobber build times do
you see on a system like this? How much does the extra cache on Xeon
help vs something like a 4 GHz i7?

My desktop machine is five years old, but it's still faster than my
MacBook Pro, so I've never bothered upgrading beyond newer SSDs. If
there's a substantial improvement available in build times it would be
easier to justify new hardware.

A nop build on my desktop is 22s currently. Touching a cpp file (so
re-linking xul) is 46s. A clobber build is something like 17 minutes.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Faster gecko builds with IceCC on Mac and Linux

[Ralph Giles]

On Mon, Jul 4, 2016 at 1:39 PM, Gijs Kruitbosch
 wrote:

> What about people not lucky enough to (regularly) work in an office,
> including but not limited to our large number of volunteers? Do we intend to
> set up something public for people to use?

By all accounts, the available distributed compilers aren't very good
at hiding latency. The build server needs to be on the local lan to
help much.

More generally, we have artifact builds for developers who don't need
the change C++ code, and there's some experiments happening to see if
the build can pull smaller pieces from the s3 build cache for those
who do.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Ralph Giles]

A few of these are in MediaFormatReader.

On Mon, May 30, 2016 at 11:22 PM, Nicholas Nethercote
 wrote:

> 11 MOZ_RELEASE_ASSERT(!mSkipRequest.Exists()) (called mid-skipping)
> 222 0.02 %

Fixed in bug 1068151.

> 16 MOZ_RELEASE_ASSERT(!mAudio.HasPromise()) (No duplicate sample
> requests) 110 0.01 %

We think this is fixed in bug 1276495, but it's too soon to confirm.

> 39 MOZ_RELEASE_ASSERT(!mVideo.mDecodingRequested) (Reset must have
> been called)17  0.00 %

Fixed in bug 1272964.


And in GraphDriver,

> 31 MOZ_CRASH(Could not start cubeb stream for MSG.)27  0.00 %

it looks like this could propagate an error instead. I filed bug 1277037.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Ralph Giles]

Yes, that's fine assuming it builds on try. Official builds will be
happening on 10.7 for a while yet.

 -r

On Sun, May 29, 2016 at 3:59 PM, Chris Pearce <cpea...@mozilla.com> wrote:
> So, given that users won't be able to install Firefox on unsupported
> versions of MacOSX, and unsupported users won't be upgraded, can we proceed
> to remove all the nsCocoaFeatures::On[Mountain]LionOrLater() calls in
> Firefox 49 and just assume everywhere that MacOSX specific Gecko code is
> running on 10.9 or later?
>
>
>
> On Fri, May 27, 2016 at 4:59 PM, Ralph Giles <gi...@mozilla.com> wrote:
>>
>> On Thu, May 26, 2016 at 3:37 PM, L. David Baron <dba...@dbaron.org> wrote:
>>
>> > There's a screenshot in:
>> > https://bugzilla.mozilla.org/show_bug.cgi?id=1255588#c8 (and #c9)
>> > (which is the bug that made the necessary changes for the Mac OS X
>> > support change in Firefox 49).
>>
>> Ah, that's great. Thanks!
>>
>>  -r
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Ralph Giles]

On Thu, May 26, 2016 at 3:37 PM, L. David Baron  wrote:

> There's a screenshot in:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1255588#c8 (and #c9)
> (which is the bug that made the necessary changes for the Mac OS X
> support change in Firefox 49).

Ah, that's great. Thanks!

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Ralph Giles]

By design, dmg's don't do anything. There's no installer, just a
container with the executable ready to run. Nils reported in the other
thread that we just crash at launch time on 10.6, which is
unfortunate. I'd hoped Apple would show a 'not supported on this
version' dialog. We could including a warning background graphic, but
that's a poor experience for unaffected users.

 -r

On Thu, May 26, 2016 at 2:50 PM, Robert Strong  wrote:
> Users won't get updated to an unsupported version and they will be notified
> that their system is no longer supported. The notification includes an url
> to a page for additional information.
>
> I'm not familiar with the Mac installer but since it is just a dmg I don't
> know if there is much that can be done. It would be a good thing if someone
> that knows about dmg's could confirm or make our dmg do the right thing.
>
> Robert
>
> On Thu, May 26, 2016 at 2:33 PM, Chris Pearce  wrote:
>
>> What will the behaviour be for users on unsupported MacOSX versions?
>>
>> It sounds like existing users won't get updated to a non-supported version.
>>
>> What about users to try to install Firefox on an unsupported MacOS
>> version? Will the installer show some sort of notification/dialog box
>> saying that their OS is unsupported? Or will Firefox just fail to start or
>> crash mysteriously?
>>
>>
>> cpearce.
>>
>>
>>
>> On Friday, March 11, 2016 at 7:04:03 AM UTC+13, Benjamin Smedberg wrote:
>> > This is notice of an intent to deprecate support within Firefox for the
>> > following old versions of MacOS: 10.6, 10.7, and 10.8
>> >
>> > The motivation for this change is that we have continued failures that
>> > are specific to these old operating systems and don't have the resources
>> > on engineering teams to prioritize these bugs. Especially with the
>> > deployment of e10s we're seeing intermittent and permanently failures on
>> > MacOS 10.6 that we are not seeing elsewhere. We get very little testing
>> > of old MacOS versions from our prerelease testers and cannot dedicate
>> > much paid staff testing support to these platforms. We also have an
>> > increasingly fragile set of old hardware that supports automated tests
>> > on 10.6 and do not intend to replace this.
>> >
>> > This will affect approximately 1.2% of our current release population.
>> > Here are the specific breakdowns by OS version:
>> >
>> > 10.6
>> >   0.66%
>> > 10.7
>> >   0.38%
>> > 10.8
>> >   0.18%
>> >
>> > The final timeframe for this deprecation has not been finalized, but the
>> > current proposal is to remove support in Firefox 46. We will try and
>> > update existing users on old MacOS versions to the Firefox 45 ESR
>> > release stream, so that they stay with security update support through
>> > the end of 2016.
>> >
>> > Because of the ESR update window, I would like to finalize this decision
>> > by Monday. If you have questions or concerns about this plan, please
>> > reply to the firefox-dev mailing list immediately. Jeff Griffiths will
>> > be working with our communications team to coordinate more public
>> > communications such as post to the Future of Firefox blog.
>> >
>> > --BDS
>>
>> ___
>> 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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

MOZ_LOG_MODULES is now just MOZ_LOG

[Ralph Giles]

Bug 1275439 just landed on inbound, which renames the logging
specifier environment variable from MOZ_LOG_MODULES to just MOZ_LOG,
which is a lot less typing.

MOZ_LOG_FILE for directing logging output to a file remains the same.

Both MOZ_LOG_MODULES and NSPR_LOG_MODULES are still accepted, but
using either prints a warning to help track down the remaining
locations where scripts need to be updated.

Cheers,
 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Requiring SSE2 on all 32-bit x86 OSs (was: Re: Reverting to VS2013 on central and aurora)

[Ralph Giles]

On Wed, May 18, 2016 at 11:10:30AM +0300, Henri Sivonen wrote:

>> So we now require SSE2 on [...]
>>  * 32-bit x86 Mac, which means just the plugin-container now that we
>> no longer support 10.6, which was the last OS X version that ran on
>> 32-bit hardware.

Actually, all of Apple's intel hardware supports SSE2, regardless of
64-bit support.


On Wed, May 18, 2016 at 3:54 AM, Mike Hommey  wrote:

> Now, with my Debian hat on, I can tell you with 100% certainty that
> angry Debian users *will* come with patches and will return even
> angrier if patches are not even welcome.

There are two parts here. I believe Henri was describing patches for
run-time selection of non-SSE2 code in rust not being welcome. That's
separate from being able to build with compile-time selection, through
code generation options and conditional inline assembly.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Reverting to VS2013 on central and aurora

[Ralph Giles]

On Mon, May 16, 2016 at 10:53 AM, Benjamin Smedberg
 wrote:

> IIRC the Mozilla builds of Firefox for Linux already require SSE2 by virtue
> of their -i686 build targeting, so the real question here is whether we
> want to support distros that don't require SSE2? I'm ok with that, but I
> don't whether there are distros who want to disagree or how I'd communicate
> this more effectively.

It's also not clear how many of the distros which technically target
i[345]86 actually function on non-SSE2 hardware. It's easy for
non-compliant binaries to slip in if there's no active testing for
this.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: invalid values behave like "metadata", not "subtitles"

[Ralph Giles]

Sounds good. Thanks for the heads-up.

 -r

On Wed, May 4, 2016 at 6:46 AM, Aryeh Gregor  wrote:
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1269712
>
> Relevant change in standards:
> https://github.com/whatwg/html/issues/293, also maybe
> https://www.w3.org/2015/10/28-htmlcue-minutes.html
>
> Bugs filed against other UAs:
> https://bugs.chromium.org/p/chromium/issues/detail?id=608772
> https://bugs.webkit.org/show_bug.cgi?id=157311
> https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/7426340/
>
> Invalid values for  are currently treated as "subtitles"
> by all UAs, pursuant to old specs.  This means that if we want to add
> any new values in the future, old UAs will treat them as subtitles,
> which might result in undesired behavior.  As such, several months
> ago, the spec was changed to treat invalid values as "metadata", so
> UAs will ignore unrecognized values.  No UA has yet implemented the
> new spec.
>
> The risk in implementing this is that sites might be inadvertently
> using invalid values right now and relying on the fact that they get
> treated as "subtitles".  I haven't done any telemetry or other
> analysis at this point to gauge if this will be a problem in real
> life.
>
> If there are no objections, I intend to land this change on Sunday.
> ___
> 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: Intent to deprecate: MacOS 10.6-10.8 support

[Ralph Giles]

On Mon, May 2, 2016 at 4:10 PM, Gregory Szorc  wrote:

> So this presumably means we can turn off automation running on 10.6-10.8 on
> mozilla-central? I believe that will drastically increase our OS X
> automation capacity...

Yes, please. We can't take advantage of any of the engineering
benefits until we stop gating builds on tests passing on 10.6.

> So where does that leave us on Universal OS X builds? IIRC our blocker is
> the need to support 32-bit Silverlight in the plugin container so various
> streaming services using it don't break. Where are we on that front?

Mac has EME-based support for DMCA-protected video starting in Firefox
47[1], so there's an alternative to Silverlight for those sites. There
are other uses of course, but we have previously announced an end to
native NPAPI plugins at the end of 2016[2] so I think that's the
timeframe for dropping 32-bit mac support. If we want to make progress
in the meantime we should start doing separate 64-bit only builds, and
use the update process to transition users on Mac > 10.6 who don't
have 32-bit plugins to the new 64-bit builds.

[1] 
https://blog.mozilla.org/futurereleases/2016/04/08/mozilla-to-test-widevine-cdm-in-firefox-nightly/
[2] https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Ralph Giles]

On Fri, Apr 29, 2016 at 9:52 PM, Lawrence Mandel  wrote:

> I had planned to update the thread after the post went live so that I had
> the link. Thank you for posting it.

The blog post just says "August 2016". Firefox 48 is scheduled for
release August 2. Can you confirm that means we can start removing
10.6-10.8 support in mozilla-central now, which will be Firefox 49?

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: multiple Rust crates are now supported

[Ralph Giles]

Thanks, Nathan. This is really great to see!

 -r

On Thu, Apr 21, 2016 at 7:57 AM, Nathan Froyd  wrote:
> Bug 1163224 has landed on inbound, which means that Gecko builds with
> --enable-rust now support multiple Rust crates.  This change is
> intended to make the lives of people developing Rust components
> easier, and it comes with several caveats:
>
> 1) There is zero support for interdependencies between crates, so you
> have to structure your crate as one big crate that includes any
> dependencies, rather than several separate crates, as is the norm.
> This is clearly suboptimal, and it will be fixed.  I think it's an
> open question exactly how we're going to integrate multiple crates and
> external projects anyway, so feel free to experiment!
>
> 2) We do not have Rust support on all of our Tier 1 platforms (Android
> is still being worked on), so actually depending on Rust code
> everywhere is still not possible.
>
> 3) Due to bug 1178897, Rust code uses a completely different memory
> allocator than the rest of Gecko.  We therefore don't have any
> visibility into Rust's memory allocations through things like
> about:memory, using Rust code worsens fragmentation issues, and there
> are also edge cases with allocating in C++ and freeing in Rust (or
> vice versa).  This is obviously something we're going to fix, ideally
> soon.
>
> We --enable-rust on all of our Tier 1 desktop platforms, but given 2)
> and 3) above, it seems best to limit the amount of Rust code we
> actually ship.  So if you want to land Rust components in-tree right
> now, I'd recommend gating your component behind an --enable-shiny
> configure option.  Ideally 2) and 3) will be fixed in short order, 1)
> will be ironed out, and then the real fun can begin!
>
> Thanks,
> -Nathan
> ___
> 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: Proposed W3C Charter: Timed Text Working Group

[Ralph Giles]

I'm not sure there's much to say here. I think we should remain
uninterested in the TTML efforts. Work to define translation from
CEA608 and CEA708 to WebVTT is worthwhile, and I'd like to see it
supported. Unfortunately our interest in WebVTT has been mostly
theoretical recently, so I don't see us contributing to it.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Hash files, signature and key now missing from release directory

[Ralph Giles]

On Tue, Apr 12, 2016 at 3:51 AM, Neil Harris  wrote:

> for example, http://releases.mozilla.org/pub/firefox/releases/45.0.1/

Also note that the releases.mozilla.org host supports https, which
offers an additional verification path.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MOZ_LOG_FILE and MOZ_LOG_MODULES are now the environment variables for logging

[Ralph Giles]

On Mon, Mar 21, 2016 at 9:13 AM, Honza Bambas  wrote:

> tl;dr: Start migrating to use of MOZ_LOG_* instead of NSPR_LOG_*.  Don't
> worry about backward compatibility tho, when MOZ_LOG_* is not set, we
> fallback to NSPR_LOG_* values.

Could this be an opportunity to shorten NSPR_LOG_MODULES to just MOZ_LOG?

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Ralph Giles]

Discussion seems to have wound down. Is there a decision on this?

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

[Ralph Giles]

On Tue, Mar 22, 2016 at 3:51 PM, Brian Smith  wrote:

> Is the Rust MP4 parser using panics for flow control (like is common in JS
> and Java with exceptions), or only for "should be impossible" situations
> (like MOZ_CRASH in Gecko)?

We're not using panics for flow control. We do have assert!s, and we
started with a bunch of unwrap()s which have all now been converted to
proper Result flow as we've become more confident in the code. But in
the defensive programming sense one generally can't control whether
dependent code is going to panic or not, so unwinding through FFI is
something we need to think about.

> I personally don't expect people to write correctly write unwinding-safe
> code—especially when mixing non-Rust and Rust—any more than I expect people
> to write exception-safe code (i.e. not at all), and so abort-on-panic is
> really the only acceptable configuration to run Rust code in.

In the specific case of the mp4 parser, I catch panics in the major
parsing call because the overhead is acceptable, and it's nice to be
able to return an error instead of taking down a user-facing process.
Obviously there are a lot of situations where the thread-spawn
overhead would be a problem, and we'd have to crash. But in that case
we still want to make sure it crashes cleanly, rather than doing
something undefined (and maybe exploitable?) and that we get
notification so we can address the issue, which I think was Ted's
point.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Linux distro readiness for Rust in Gecko

[Ralph Giles]

On Tue, Mar 22, 2016 at 9:31 AM,   wrote:

> Given that I know very little about rust, and putting aside the activities of 
> Rust upstream's releases in general, what do we expect is going to be needed 
> here in terms of a rust package to build an ESR vs a regular firefox release? 
>  I assume / hope that if firefox-52ESR can be built with say, rust-2.1 , that 
> it can also be built with the rust-2.4 that's needed to build firefox-58 ??

I would expect this to be the case. So far, the rust team has done a
very good job maintaining backward compatibilty for language features
once they reach stable release.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does SSE2 usage still need to be conditional?

[Ralph Giles]

On Fri, Feb 5, 2016 at 10:31 AM, Ralph Giles <gi...@mozilla.com> wrote:

> Would it result in drama if it's just a bug with an easy fix? Distros'
> support policies are different from ours as their upstream. Perhaps we
> should just try it without the `-C target-feature=-sse2` for linux32,
> but pass it for win32?

Turns out we got pretty instant feedback on win32.
https://bugzilla.mozilla.org/show_bug.cgi?id=1252041
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Moving away from autoconf

[Ralph Giles]

Where do new changes go?

 -r

On Wed, Feb 24, 2016 at 2:28 PM, Mike Hommey  wrote:
> Hi,
>
> We are, officially, and starting today with the landing of bug 1250294,
> moving away from autoconf. This is not going to happen overnight, and it
> is going to be painful, but the first step has just been made, and we're
> not turning back.
>
> The autoconf scripts are however still there and are used, but were
> renamed to old-configure.in. If you have pending patches against
> configure.in or js/src/configure.in, your changes will need to be
> applied to old-configure.in or js/src/old-configure.in.
>
> Cheers,
>
> Mike
> ___
> 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: Does SSE2 usage still need to be conditional?

[Ralph Giles]

On Thu, Feb 4, 2016 at 11:45 PM, Henri Sivonen  wrote:

>> We're actually building it for 32-bit MacOS X too, but all x86 macs have 
>> SSE2.
>
> Is there a plan for adding Android builds and 32-bit Windows and Linux builds?

We plan to do so. Nathan Froyd has been working on both of those.
Win32 is blocked on SAFESEH generation and possibly some msvc unwind
changes coming in rust 1.8.

https://bugzilla.mozilla.org/show_bug.cgi?id=1184732 (windows)
https://bugzilla.mozilla.org/show_bug.cgi?id=1220307 (android)

> To be clear, I'm less worried about Linux users having non-SSE2
> hardware (chutten's numbers suggest we don't need to worry about that)
> than I am about violating Linux distros' policies (that may be out of
> date relative to hardware reality). That is, a policy violation might
> result in drama even if the violation didn't affect a notable user
> population in practice.

Would it result in drama if it's just a bug with an easy fix? Distros'
support policies are different from ours as their upstream. Perhaps we
should just try it without the `-C target-feature=-sse2` for linux32,
but pass it for win32?

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does SSE2 usage still need to be conditional?

[Ralph Giles]

On Wed, Feb 3, 2016 at 5:23 AM, Henri Sivonen  wrote:

> My understanding is that the new
> MP4 demuxer that's written in Rust is currently only being built in
> the x86_64 case, so, AFAICT (I'd love to be wrong!), Rust code in
> 32-bit Firefox isn't a solved problem yet.

We're actually building it for 32-bit MacOS X too, but all x86 macs have SSE2.

> As for the consequences of requiring SSE2 unconditionally, I'm
> personally more worried about a conflict with Linux distros that don't
> already require SSE2

Do you know if rust's unwind will catch illegal instructions? The mp4
demuxer code currently runs in an isolation thead so panics don't
affect the firefox process. So I'm wondering if we could enable this
for linux32 with telemetry to get a measurement outside crash reports.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: VP9 video in mp4

[Ralph Giles]

We intend to support the VP9 video codec in mp4 fragments and files.

Netflix recently proposed a specification for encapsulation of
Google's VPx family of video codecs in the ISO Base Media File Format,
more commonly known as mp4. VP9 is a royalty-free video compression
format developed by Google, and offers better quality at the same
bitrate than the h.264 codec normally used in mp4. The mp4 container
itself is the most widely used container for video on the web.

Firefox has supported VP9 for several years in its native webm
container. Support for VP9 in WebRTC landed recently. Adding support
for it in the mp4 container will make it easier for site authors to
improve quality or reduce transfer costs for video--and reduce the
cost of patent licensing--while reusing established code designed
around the mp4 container.

As with Opus-in-mp4, we intend to support this through the mp4 parser
rewrite Matthew Gregan and I are doing in the rust programming
language, so availablity withh be gated by --enable-rust as well as a
pref, likely media.mp4.vp9.enable. Current that would limit official
builds to MacOS X and 64-bit Linux.

We do not have a target release for this yet. The specification is in
a fairly rough state, so I expect we'll need a few rounds of testing
and implementation feedback before we can consider it ready.

Spec at 
https://github.com/Netflix/vp9-dash/blob/master/Downloads/VPCodecISOMediaFileFormatBinding.pdf
Test files at https://github.com/Netflix/vp9-dash/tree/master/DASH-Samples
More about VPx http://www.webmproject.org/

Comments welcome,
 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: Opus audio in mp4

[Ralph Giles]

We intend to support the Opus audio codec in mp4 fragments and files.

Opus is a royalty-free audio compression format developed by Mozilla
(Xiph), Microsoft (Skype), Broadcom and others. It offers better
quality for both voice and music, scaling over a wider range of
network speeds and with lower latency than previous codecs. It's been
in Firefox for several years and on its own is a manditory part of the
WebRTC specification.

MP4 is the most widely used video format on the web today.

Combining the two will give us a way to record and play back
interactive WebRTC streams with Opus audio and h.264 video, which
currently doesn't work because they have different container supports.

We also hope to make it easier for site authors to take advantage of
better compression technology by reducing migration barriers for
established code based on the mp4 container.

The plan is to support this through the mp4 parser rewrite Matthew
Gregan and I are doing in the rust programming language, so
availability will be gated by --enable-rust as well as a pref, likely
media.mp4.opus.enable. Currently that would limit it to official
builds on MacOS X and 64-bit Linux, but I hope there will be more
soon.

We do not have a target release for this yet. Whenever we feel the
specification is sufficiently stable.

More about Opus at https://opus-codec.org/
Draft spec at https://opus-codec.org/docs/opus_in_isobmff.html


Comments welcome,
 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing unused Perl scripts from the tree

[Ralph Giles]

On 2014-10-27 3:18 PM, Nicholas Nethercote wrote:

 ./media/libopus/celt/arm/arm2gnu.pl
 ./media/libvpx/build/make/ads2gas.pl
 ./media/libtheora/lib/arm/arm2gnu.pl

These come from upstream, and are used to convert syntax of assembler
source files so they can work with various toolchains. Upstream is
unlikely to accept python conversions (perl is more widely deployed) so
I don't think it makes sense to remove or replace these.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: WOFF2 webfont format

[Ralph Giles]

On 2014-10-02 4:03 AM, Jonathan Kew wrote:

 The format is primarily based on earlier TrueType compression work
 (MicroType Express) by Monotype, and a new entropy coder (Brotli)
 developed by Google's data compression team in Zurich.

What kind of filesize reductions do you see over ttf and woff1?

 -r

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Documenting uses of Github at Mozilla

[Ralph Giles]

On 2014-10-01 3:13 AM, Ed Morley wrote:

 Perhaps part of the solution is to move at least some of the other
 repositories to the main Mozilla Github org

Stronger hierarchy has costs. To create a repo under the mozilla
organization I must have a relationship with someone with admin rights
to create the group, add people, etc. To make a new umbrella group for
my team, I don't have to interact with anyone but current contributors.

I don't have to ask permission. I don't have to wait for a response.
There's less cognitive overhead dealing with a smaller group of
contributors and repositories.

I suspect this is a significant factor in the proliferation of
mozilla-foo organizations on github. I don't think it's a bad thing.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Documenting uses of Github at Mozilla

[Ralph Giles]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2014-10-01 9:33 AM, Ms2ger wrote:

 Looks like the instructions to add repos are on intranet; why?

Because they contain the auth secret.

 -r
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJULDV5AAoJEEcAD3uxRB3v6QUH/0jEfQz0iGQvYwLpbhyBhpDG
ZV7MqERdwqw6Lf+6led065dHX20HH5PyRlwyNw3hDVAsAB4RVib9Iza8RQByHWja
vDCvqsoZ9cmwHEUSfu6IboJzV+umhchAsnaS7SovZYzfx2ChgyOQ7+BVOpkSiXse
31mfmZOO5SEyzKn/WKdmHzC/SFvgE6ot5tnEt03/YWjC3HHyL4t6XKDbPt3T6gUd
xaVthh9jFPdgG9GF3sYQTqedrAtv3rZwSkfSOpV97hfI57hHtY0zCUV8lQ+k4RqO
gsLBMHwpixbQ8bUVb9BbEpcPZCSRoNjHJ8rT+5U8KXw7jrl4KO8XvPFIwZmIPjI=
=GAWw
-END PGP SIGNATURE-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Documenting uses of Github at Mozilla

[Ralph Giles]

On 2014-10-01 9:49 AM, Mike Hoye wrote:
 I think the author of that intranet page has left us for Stripe a while
 ago. Who owns it now?

Perhaps no one. I've just discovered in adding new repos that it's
broken. The github webhook format has changed, and it's returning 500.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Documenting uses of Github at Mozilla

[Ralph Giles]

Forked and PR submitted.

Jeff, do you still have admin access on gitmirror.mozilla.org? Can you
deploy and confirm the fix?

 -r

On 2014-10-01 10:12 AM, Ralph Giles wrote:
 On 2014-10-01 9:49 AM, Mike Hoye wrote:
 I think the author of that intranet page has left us for Stripe a while
 ago. Who owns it now?
 
 Perhaps no one. I've just discovered in adding new repos that it's
 broken. The github webhook format has changed, and it's returning 500.
 
  -r

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Documenting uses of Github at Mozilla

[Ralph Giles]

https://github.com/mozillayvr/

Upstream libraries we import:

https://github.com/kinetiknz/nestegg/
https://github.com/xiph/opus/
https://github.com/webmproject/libvpx

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Experiment with running debug tests less often on mozilla-inbound the week of August 25

[Ralph Giles]

On 2014-08-19 1:55 PM, Benoit Girard wrote:
 Perhaps we should instead promote checkin-needed (or a similar simple)
 to coalesce simple changes together.

I would prefer to use 'checkin-needed' for more things, but am blocked
by the try-needed requirement. We need some way to bless small changes
for inbound without a try push. Look up the author's commit access maybe?

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Mac OS X 10.7 SDK or later now required for Mac builds

[Ralph Giles]

On 2014-07-31 11:42 AM, Bob Clary wrote:

 Actually I had been building on 10.6 up until this morning. I've
 switched my builders to 10.9 where it appears all is well and I am able
 to run the builds on 10.6+.

Just out of curiousity, are you building against the 10.7 sdk on 10.9,
or against the native libraries, and having it work on 10.6+?

Would be nice to know if 10.9 builds still work on 10.6.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Mac OS X 10.7 SDK or later now required for Mac builds

[Ralph Giles]

On 2014-08-01 9:47 AM, Bob Clary wrote:

 I didn't specify --with-macos-sdk when building on 10.6 previously nor
 when building on 10.9, so native libraries?

I *think* the default isysroot is '/' so not passing --with-macos-sdk
would build against the system's native libraries, headers and frameworks.

 Xcode 5.0.2 is installed on the 10.9 machine with the 10.8 and 10.9
 sdks, but I didn't specifically select either.
 
 These builds do run on 10.6.

Great, thanks for confirming!

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Studying Lossy Image Compression Efficiency, July 2014

[Ralph Giles]

On 2014-07-19 1:14 PM, Caspy7 wrote:

 Would this code be a candidate for use in Firefox OS or does most of that 
 happen in the hardware?

Probably not for Firefox OS, if you mean mozjpeg. Not necessarily
because it uses hardware, but because mozjpeg is about spending more cpu
power to compress images. It's more something you'd use server-side or
in creating apps. The phone uses libjpeg-turbo for image decoding, which
is fast, just not as good an compression.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: navigator.deviceStorage

[Ralph Giles]

On 2014-07-18 2:28 PM, Dave Hylands wrote:

 No reason, other than I'm not familiar with EventListener. What is an 
 EventListener and how would you use it? Maybe just point me at an example? 


  deviceStorage.addEventListener('newarea', function(event) {
// Handle new area being available.
  });

It's a generic pattern implemented by many objects, and multiple
listeners can be registered. You define the event names and the rules
for triggering them in the spec, then code can easily subscribe to the
changes it wants to observe.

http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Registration-interfaces
https://developer.mozilla.org/en-US/docs/Web/API/EventListener

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: WebMIDI

[Ralph Giles]

On 2014-06-14 1:11 PM, Kyle Machulis wrote:

 Preference behind which this will be implemented: dom.webmidi.enabled 

I suggest dom.midi.enabled. 'web' is redundant with dom, and doesn't
appear as a prefix in any of the API points.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [DEPRECATED] Apple OSX QTkit API dependencies

[Ralph Giles]

On 2014-05-21 9:56 AM, Emmanuel Engelhart wrote:

 checker. But it seems the Mozilla codes uses this API for many things
 linked to video stuff:
 https://mxr.mozilla.org/mozilla-central/search?find=%2Fstring=QTKit

This is all video capture code for WebRTC. What API does Apple recommend
instead?

It's also worth reporting this upstream at webrtc.org, since that
codebase *is* used in a number of iOS applications.

 -r

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: OS.File design issue from bug 961080 (making downloads respect umask)

[Ralph Giles]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2014-04-25 11:08 AM, Zack Weinberg wrote:
 Against these (particularly the third) was the claim that this API
 is only useful to the download manager.

Forgive the derail, but why does the download manager need to make
things executable?

 -r
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTWqxQAAoJEEcAD3uxRB3v9QsH/jHxyUepJVJg1FzX1NJTCWPt
Z3VglyooO/IAb4wz2yLoAwGBQohEOwUFHjur0A5gIOC0q4rYW5sJYxc7EQBKNw8X
c+oKfyALy5mwr1kSI0VlZc5xA9lEMYyj5ienmjo7OSaUxbvOE+GzCwAIMteZSnSC
teMzzYEKJk54oDWBdnDKlFwOjD9rEUpHw1uDQBcfRTR8jN8dJE9wCW71Hgt2A/Bq
eqiOjyQYqDxjUVsbrsNdn12md08Y7o3boINOOJE0McPbdtgYBDXjAkJSKiS8Qcsr
qLeHhDf/s+4spEf2jRIIE5/i4oRFelgwr+dfD53E9jN+Clo0tB0T+pI+h8rzLGs=
=4L1t
-END PGP SIGNATURE-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: OS.File design issue from bug 961080 (making downloads respect umask)

[Ralph Giles]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2014-04-25 12:26 PM, Zack Weinberg wrote:
 AIUI, Windows makes no distinction between readable and
 executable in file permissions.  Files are executable if their
 extension is recognized, and not otherwise.

That's consistent with my tests. I can run a .exe (after clicking
through a warning) downloaded on Windows. On Linux I can't, because
http doesn't propagate permissions and nothing sets the executable
bit. On Mac people use .dmg or .zip to get around this issue. I
suppose linux binaries are generally packaged in an archive as well.

Downloading a .so directly over http, or generating and saving one, is
a new use case.

Thanks for clarifying,
 -r
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTWsQiAAoJEEcAD3uxRB3v7bUH/A04tpv+mWJbRp2ZXw4LFi5I
lcPirOmnqxIxKo//nDJPNDfxHRiSp7nKHbQLM/RKcUsE9rJEFhKszE48ERnTcI5Y
wyYXWE7R+SOyRl4AJ3kOD+jyZbERN3v2i86fDYoGWcxjAdaGmvwgmIHGtJ3YO+UC
IixN35U9xoLG+BHf7vve2jZrnlEnsb1emn0cBKPPmvQGGSEWjkM6bV8G+uw/xIo+
TTOZW/RXx280DjX+47dUPIDs5yiyd7vsxo3kccCppLQ1N+RbnQ6ETjVpcFSANcFW
tZD1WPqh3N3scbmexK6+MfMILYvGxWpUnBZ0XtURCdVBeGBeYheVGxZdsDlOeCs=
=W77G
-END PGP SIGNATURE-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Oculus VR support somehwat-non-free code in the tree

[Ralph Giles]

On 2014-04-14 3:41 PM, Vladimir Vukicevic wrote:

 2. Contact Oculus with our concerns about the license, and see if they
would be willing to relicense to something more standard.

We should certainly ask, and explain what the problem is for us.

 The goal would be to remove LibOVR before we ship (or keep it in assuming it 
 gets relicensed, if appropriate), and replace it with a standard Open VR 
 library.

Can you dlopen the sdk, so it doesn't have to be in-tree? That still
leaves the problem of how to get it on a user's system, but perhaps an
add-on can do that part while the interface code in is-tree.

Finally, did you see Gerv's post at
http://blog.gerv.net/2014/03/mozilla-and-proprietary-software/

 -r

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Why are images that are uploaded in Pinterest and Instagram modified in terms of size and pixel colors?

[Ralph Giles]

On 2014-02-28 8:53 AM, Usman Ehtesham wrote:
 When images are uploaded in Pinterest and Instagram, the size of the images 
 get modified and so do the colors (within a ranges of +/- 10 pixels). Are 
 images modified to align the images as a grid as seen in Pinterest and 
 Instagram? If yes, how do they do it done? Also is there a way when the 
 images are downloaded from these websites, we can get the original image with 
 the original colors and size? I also observed that when the alpha value of 
 the image is changed and then the image is uploaded, the images modify the 
 alpha values too once they are uploaded in Pinterest and Instagram. Is there 
 a way around it?

I don't know much about the details, but generally sites like this
reprocess images after upload. They generally optimize for size and
compression efficiency. I suppose they might tweak the colour as well.

I don't use either pinterest or instagram, but looking at their
developer APIs they provide a few encoded sizes, but no link to the
original or Creative Commons licensing tags.

In general they're trying to make the images look nice and load quickly;
these sites are not about backing up work or sharing high-quality
originals for collaborate reprocessing. There are other sites which do
allow access to the originals, like Flickr.com.

Hope that helps,
 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Maybe-uninitialized warning helper template

[Ralph Giles]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2014-02-28 1:52 PM, Zack Weinberg wrote:

 Yeah, I guess you would.  We could maybe just live with that - at 
 least, what *I* personally care about is not having to wade through
 a flood of preexisting maybe used uninitialized warnings to find
 any new warnings due to what I just changed, and I basically never
 do opt builds locally.

Is there a way to make the template generate 'T var = var;' in the
release case when there's no initializer? That's be a useful hack to
silence -Wunused-variable, -Wsometimes-uninitialized, etc. on gcc and
clang.

 -r
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTEQtqAAoJEEcAD3uxRB3vxWYH/09LUamOeafzdXHno7K1Xk4Z
s32arn4w8db/sT4+/BsBueD88hcRIvY2pHmCsSalK3TUDWGfrGlnH49vp3DORfAn
bcCK2HtdAISegAj5BKEOWPgFSreKzmBvOZIt6ZwdhUbaXLamRTKimwZgTDLDYgNL
4U0AqRj1HqIkaYpq5F0e0P18ygdsXfH9tyNwqo/UeoM/440qNz+tuLoaEzmn/19I
a5+lrjvGbWzB/mqLOgV5LTZqSIClxn9E5mQ+k8qcOocR6dMGXylO9bs9HJL94yx1
blFVY/Tm0khJWEJYmisblUbwOq1tCFHCK70airfwYEDc/qyWUhiQtr6LFX/Sjlk=
=AfPI
-END PGP SIGNATURE-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fixing build warnings [was: Re: Always brace your ifs]

[Ralph Giles]

On 2014-02-24 9:21 AM, Daniel Holbert wrote:
 a) We try to avoid directly modifying third-party code in m-c, since
 any such patches would be clobbered on the next library-update. So we
 may not be able to directly fix our in-tree copy of the code, unless
 it's really important.

FWIW in the media subtree we maintain a separate copy of patches we've
applied since the last import. An 'update' script remembers what files
need to be copied from upstream and applies the patches, which helps a
lot if upstream doesn't change much, and helps when checking if specific
issues have been fixed.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Including Adobe CMaps

[Ralph Giles]

On 2014-02-24 2:41 PM, Brendan Dahl wrote:
 There are 168 files with an average size of ~40KB, and all of the files 
 together are roughly:
 6.9M
 2.2M when gzipped

IIRC mupdf was able to save significant space by pre-parsing the files.
Their code for that is GPL (and oriented toward compiling-in the tables
as C code) but it might be worth a look.

  http://git.ghostscript.com/?p=mupdf.git;a=blob;f=scripts/cmapdump.c

4.2Mresources/cmaps/
1008K   build/debug/pdf/pdf-cmap-table.o

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendations: XQuery, XPath, XSLT, EXI, API for Media Resources

[Ralph Giles]

On 2013-10-29 3:01 AM, Henri Sivonen wrote:
   http://www.w3.org/TR/mediaont-api-1.0/
 ...
 I would prefer to abstain or otherwise not endorse this specification

Ok, thanks for reviewing it.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Killing the Moz Audio Data API

[Ralph Giles]

On 2013-10-16 2:26 PM, Anne van Kesteren wrote:
 For obscure DOM methods we do the warnings, then give it a try in
 nightlies and see if anyone screams. So yeah, you want to do that I
 think.

Sounds good to me.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What platform features can we kill?

[Ralph Giles]

On 2013-10-10 12:28 PM, Steve Fink wrote:

 It seems like the optimal efficiency vs surface exposure vs frequency 
 of use tradeoff would be to do everything but the top formats (JPG, 
 PNG, GIF?) in JS.

That's what we do today. We support those three image formats with
native code, and others can be supported by a js implementation, which
anyone can write. Unless you mean we should maintain a js library
supporting other formats?

 Then for the top three, try to do a hybrid implementation where all
 of the core bit-slinging is done with C/SIMD/GPU/quantum entangled
 cesium ions, but all of metadata and other bits are done in JS.

That sounds awkward to me. You're right that we have to be very careful
with native parsers, and we are, but formats popular enough to adopt
into the platform generally have widely-tested native implementations.

Some things, like scaling and colourspace conversion can already be done
with WebGL though, so the platform is making progress in this direction,
which is helpful for minority formats.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Do you consider to port mp3 support on Windows XP

[Ralph Giles]

On 2013-10-03 4:04 PM, lchenneb...@gmail.com wrote:
 Ok so do you confirming me that MP4 will never be supported natively on 
 Firefox for Windows XP? 

We would like to support it, but it's unclear how without a platform
decoder. Suggestions welcome, especially if they come with
proof-of-concept patches.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Do you consider to port mp3 support on Windows XP

[Ralph Giles]

On 13-07-16 11:15 AM, Ludovic Chenneberg wrote:
 I'm working on a html 5 interactive player that 100% compatible with Chrome 
 from XP to Window 8.
 I Saw that the support of mp3 and mp4 has been introduced in firefox on v21 
 for win 7 and v22 for Vista.

Porting mp3 playback support to WinXP is in progress. See
https://bugzilla.mozilla.org/show_bug.cgi?id=861693

 -r

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Shutting off leak tests?

[Ralph Giles]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13-07-15 1:45 PM, Chris AtLee wrote:

 Would anybody be very sad if we shut them off?

I would be happy if you did, for the reasons you state. Please shut
them off.

 -r

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJR5GANAAoJEEcAD3uxRB3vaF8H/0gq4xVs/rOGumSonllWZ50X
xh8HxJkvakk3mytq0Umcgxe/eVHnFQXesfXOcsg0PuvUNuWOFeo5o0iW0EBqoSAU
FXr1CCfJfYB6E2C1holesMd9y6yWc4swaB5u4k/MRwUFUIgnTNjxMbY3/OwzUWyv
Uozo6De42A3FFcpwo993w2eHr3jid0C6Mr45xr3D4G8Tbb0RNonD9cDJZoMXX97P
wiPftPBz6a/Ql1+49lEN19kX3PlqyKW9e+6z/rwjcglnyjg3nGkVn3bQhOT902yi
nylx0URcAO4T9VXEUQZ8AmrQdtVfir7re1eV6yxTEiUoEsVMiDYL0gbtyuhArG0=
=bl35
-END PGP SIGNATURE-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Doxygen For Mozilla-Central Modules

[Ralph Giles]

On 13-05-01 9:21 AM, Benoit Girard wrote:

 I've started to run doxygen on a fresh mozilla-central by cron once a day
 in the hopes of encouraging source code documentation. I run doxygen on sub
 modules only for users that are interested in the output.

Hooray!

 You can see my script and configuration files here:
 https://github.com/bgirard/doxygen-mozilla

FWIW, in my experience doxygen's recommended doxygen -g + edit
workflow is quite brittle as the supported configuration variable change
across versions. You might consider putting only the variables you've
changed in your Doxyfiles, relying on the defaults for everything else.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: WebP support

[Ralph Giles]

On 13-04-08 4:06 AM, Jeff Muizelaar wrote:
 No decision has been made yet. We are still evaluating the format.

I think the concern is that none of that re-evaluation has been on a
public list or bug I've seen. Can you clarify what Andreas meant by,
new data that shows that WebP has valid use cases and advantages in
https://bugzilla.mozilla.org/show_bug.cgi?id=600919#c185 ?

 -r

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: WebP support

[Ralph Giles]

On 13-04-08 10:02 AM, Jeff Muizelaar wrote:

 Sure. Everything.me was seeing large gains when using lossy image compression 
 with an alpha channel compared to png. This isn't a surprise but it's a use 
 case that's not well supported by the current image formats we support.

At least not since we removed jng support? :)

Thanks for clarifying!

 -r

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Linux Firefox extension on ff17 needs gcc 4.5

[Ralph Giles]

On 13-02-08 3:18 AM, kv wrote:

 Can some body help me how can i compile native extension on 32 bit RHEL
 with gcc 4.5.2, if the package is not available for update.

It doesn't look like there's an official package for rhel 5 or 5. You
can compile and install 4.5.2 (or the latest version) and use that to
build your extension.

 =r

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Emacs and vim modelines

[Ralph Giles]

On 13-01-04 1:01 PM, Mike Hommey wrote:

 That being said, in 2013, I'm not convinced limiting to 80 characters on
 one line still has much meaning...

FWIW I still edit in 80 column windows. Helps get more columns on the
screen.

Now, maybe if you were suggesting switching to proportional fonts... :-)

 -r

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Git mirror of mozilla-central down

[Ralph Giles]

On 12-09-13 2:49 PM, Ehsan Akhgari wrote:
 Sad news everyone.  Since Tuesday night I have been trying to fix the
 repository using almost anything that came to my mind, from trying to
 recreate the missing commits manually one by one to updating hg and hg-git,
 trying to reconvert only parts of the IonMonkey merge to narrow down the
 problem, and eliminating all of the possible factors that could have an
 impact on this conversion process, and all of my attempts have failed.  I
 have sort of narrowed down the range of the IonMonkey merge which causes
 the problem, but narrowing it down further is a very time consuming process.
 
 Unfortunately I don't have enough time for now to work on this even more,
 so you should not expect any more updates to the mozilla-central mirror.

That's sad news indeed. Thanks for working on it. I hope we can get it
back up eventually!

 * This repo is created by RelEng by a direct conversion of the mercurial
 repository to git, which means that there is no CVS history for you to use.

You you understand why this repo doesn't have the same problem with the
ionmonkey merge?

 -r

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Minimum Required Python Version

[Ralph Giles]

On 12-09-09 12:54 PM, Gregory Szorc wrote:

 So, 2.6 or 2.7?

2.7. It's fairly widely deployed these days and has some nice features
over 2.6. Upgrading our build slaves won't be any more work for the one
or the other.

I believe MacOS 10.6 ships with 2.6, but not 2.7, if that's a drawback.

 -r

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Updated WebRTC landing plan

[Ralph Giles]

On 12-09-05 6:07 PM, Randell Jesup wrote:
 Overview of plan to land webrtc code from Alder to Mozilla-Central:
 
 3rd tranche: in alder; each can land separately.  Target date: Sept 15.
 ...
 Opus

Which piece of Opus support are you referring to here? The reference
implementation is already in m-c under media/libopus. A version of the
webrtc support patches have landed on alder, although there will be some
changes after upstream completes review.

 -r

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: STR Needed Keyword?

[Ralph Giles]

On 12-08-16 6:01 PM, Anthony Hughes wrote:
 (CCing dev-quality to reach a broader audience -- please direct responses to 
 dev-platform)
 
 It has come to my attention that we lack a keyword in Bugzilla for when 
 steps-to-reproduce are needed (a very common request). However, we do have 
 keywords for when a testcase, regression range, or URLs are wanted. I find it 
 to be extremely useful when someone requesting qawanted pairs it with a 
 keyword indicating what is being requested. It's certainly more efficient 
 then having to parse the comments to interpret the request.
 
 Assuming support for such a keyword here are some proposed names:
  * steps-wanted
  * str-wanted
  * needSTR
  * need-steps
 
 Would people find this keyword useful? If so, I can file a bug to get it 
 added.

I think this would be useful, and improves workflow clarity along the
lines of dbaron's blog post yesterday.

  * steps-wanted

This is the most obvious of the options you gave.

 -r

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform