Build System Project - Update from the last 2 weeks

[David Burns]

Below is a highlight of all work the build peers have done in the last 2
weeks as part of their work to modernise the build infrastructure.

Since the last report[1] we have seen thousands of lines of configure and
m4 code removed from mozilla-central. We have removed over 30 Makefiles
from mozilla-central. The removal of the Makefiles gives us what we need to
use more performant build backends in the future.

In case you missed it, you can now make Artifact Builds[3] if you are using
git[4]. If you find any issues, please raise bugs against Core :: Build
Config.

Finally, we are seeing huge improvements in build times by switching to
Visual Studio 2015. There are however a few regressions in moving to the
latest version. gps has asked for assistance[5] in helping finalise what we
need to make the move. If you can, help get this over the line!

Regards,

David

[1] https://groups.google.com/forum/#!topic/mozilla.dev.platform/PD7Lmot1H3I

[2]
https://groups.google.com/forum/#!msg/mozilla.dev.builds/0Wo_8Vhgu9Y/XFCCSmKABQAJ

[3] https://developer.mozilla.org/en-US/docs/Artifact_builds

[4] https://groups.google.com/forum/#!topic/mozilla.dev.builds/XtyrGfY48wo

[5]
https://groups.google.com/d/msg/mozilla.dev.platform/2dja0nkKq_w/5iJPJXCaBwAJ
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Linux distro readiness for Rust in Gecko

[Henri Sivonen]

On Sun, Mar 20, 2016 at 9:53 PM, Petr Cerny  wrote:
> I can't speak for Debian, but on SLE the solution we went for last time was
> packaging new-enough GCC for older supported code streams, very much like
> other packages (e.g. GTK) we had already needed way before.

This seems like a reasonable solution. As noted, it appears that
Ubuntu backports GCC, too.

>> The comments on https://bugzilla.mozilla.org/show_bug.cgi?id=1175546
>> suggest that Mozilla deferred relying on GCC bug fixes until after 45
>> ESR in order for Debian not to have to backport a compiler for
>> oldstable. Is that the case? That is, is Debian's policy already
>> hindering Mozilla's ability to avoid C++ compiler bugs that the
>> compiler upstream has fixed?
>
>
> TL;DR version: change whatever you need, but please do announce the intent
> loudly, clearly and early enough.

Great!

> Longer version:
>
> It definitely is not just Debian. With all due respect, Mozilla doesn't rule
> an isolated island - like all others it shares a jungle with other animals
> of varying sizes, shapes and habits.

Yes, but the Linux jungle depends on the outside for the browser
engines (Gecko, Blink and WebKit) that it relies on and the numbers
that Web developers look to assess the relevance of these engines
(which translates into whether sites are made in a way that these
engines work for Linux users) happens outside the Linux jungle. It's
not reasonable for a part of the already small jungle to be entitled
to limit the Gecko development inside and outside the jungle to old
compilers.

I want us to have good Linux support, I want obtaining our product to
be convenient for Linux users and I don't want conflicts with the
distros. I started this thread in order to avoid a situation where
nobody saw it coming that we'd be about to land a patch that broke the
distros' workflow by surprise. But consider: Rust as a technology
works the best on Linux. (IIRC, debugging info works better on Linux
than on Mac and it's pretty clear that Linux and Mac are better
matches for Rust development than Windows.) It's very messed up that
the tech that works the best on Linux is the hardest to ship to users
on Linux.

> I'm quite sure there are problems with
> other compilers/systems than just GCC/Linux, but due to their larger target
> user deployment and distribution model, they are being worked around. I know
> it is different (in *many* aspects), but just imagine you had to solve a
> similar issue with Microsoft or Apple (i.e. them distributing Firefox and
> strongly preferring to build it with what they use for building the rest of
> their systems with).

I don't think a comparison with Microsoft and Apple is in the distros'
favor. Microsoft's undocumented ABI has the practical effect of
locking us to their C++ compiler, but they don't make us use just the
C++ features and compiler bugs that were available when Windows XP
shipped. Apple promotes clang and we are at liberty to use clang from
llvm.org instead of Apple-shipped clang and we have the option to
patch clang if we need to.

As for imagining if Microsoft and Apple imposed requirements that they
don't: The important point is that they don't!

As for iOS, the requirement to use an Apple-designated language or
compiler is gone. The policy problem with Apple is that they ban the
class of product that we'd like to build on iOS. But AFAICT, using a
rustc version of the developer's choice to build other kinds of
products is already permitted on iOS.

> Yet back to the point: you certainly can change whichever tool you need or
> want, but the timing is crucial. Stable distribution maintainers are used to
> these things happening every once in a while, so if you announce it loudly a
> couple of releases ahead, it will be perfectly fine and nobody is going to
> complain

Not even Debian?

> Generally, I think it shouldn't really be perceived as: "Linux distributions
> are hindering our development", rather as being polite and respectful in a:
> "Let's not make much more work for them unless it is really, really
> necessary" manner. Which is exactly what shifting such a change from before
> to after a major ESR release is.

Considering how quickly Rust is progressing, chances are that the
Firefox will pick up new rustc releases faster than on a 10-month
cycle, so it will probably be safe to assume that every time there a
new major release becomes ESR, it'll require a newer rustc than the
previous ESR. But a mindset of "Linux distros can just ship ESR and
deal with rustc at 10-month intervals" isn't a great solution when the
distros have a non-enterprise audience or when the distros ship
Chromium every six weeks; see below.

> I think both sides want to achieve the same in the end: having a stable and
> secure Firefox.

It's not clear that that's the case when it comes to what "stable"
actually means. If "stable" means "doesn't crash", sure. If "stable"
means "out-of-date", the goals may not be aligned. There is a strong
te

[Firefox Desktop] Issues found: March 14th to March 18th

[Andrei Vaida]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA 
team last week, *March 14 - March 18* (week 11).


Additional details on the team's priorities last week, as well as the 
plans for the current week are available at:


   https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus



*RELEASE CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1257844 
Hello icon bottom margin is not properly defined when menu is opened
Hello (Loop)
Client
NO  NOBODY
1257845 
[Windows] User account is very small and bolded, it lacks clarity
Hello (Loop)Client  NO  NOBODY
1257846 
"See how it works" button is in focus when the Hello Panel is opened
Hello (Loop)Client  NO  NOBODY
1257840 
Hello Settings panel is cut off after signing in/up into FxA
Hello (Loop)Client  YES NOBODY
1257834 
	Context is shown in Conversation Window even though guest did not join 
the room

Hello (Loop)
Client  NO  NOBODY
1257854 
	Pointer freezes on wrong position for the recipient (both host and 
guest) if cursor is moved a little faster

Hello (Loop)
Client
NO  NOBODY
1257865 
	After the guest leaves the conversation, conversation window is too 
large on the host side

Hello (Loop)
Client
NO  NOBODY
1257866 
	'Disconnect' button displayed for a second when clicking on Hello 
button quickly after closing the conversation

Hello (Loop)
Client
NO  NOBODY

*
**BETA CHANNEL*
none

*AURORA CHANNEL*
none*

**NIGHTLY CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1256323 
Glitches when scrolling on ulika-rovinj.com
Core
Panning and Zooming
YES NOBODY


*ESR CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1257230 
Incorrect branding for 45.0.1esr build
Firefox
Build Config
NO  Rail Aliiev



Regards,
Andrei
Andrei Vaida| QC Team Lead

SOFTVISION | 57 Republicii Street, 400489 Cluj-Napoca, Romania
Email: andrei.va...@softvision.ro  | 
Web: www.softvision.ro 


The content of this communication is classified as SOFTVISION 
Confidential and Proprietary Information.



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

b2g builds on trunk- perma failing for weeks?

[jmaher]

I have noticed that since March 4th, the b2g builds on m-c are perma failing.  
Doing some basic searching we have about 15 hours of machine time going to 
failed builds on every push (which is ~1350 builds or 20,250 machine hours).

These show up in mozreview as failed jobs when you autoland a push.  I assume 
we plan to get all of these builds green and tests green, otherwise we wouldn't 
keep them running on every push for inbound/fx-team/central.

Do we need to keep these running on inbound and fx-team, or can they only run 
on mozilla-central?  I assume somebody is working on getting the builds to 
green up, could we be made aware of the work done here (maybe a tracking bug) 
so it doesn't seem that we are just letting builds run because we can?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

RE: Intent to switch to Visual Studio 2015

[Yuhong Bao]

> On 2016-03-17 8:35 PM, Yuhong Bao wrote:
>>> On Thu, Mar 17, 2016 at 3:30 PM,
>>> mailto:yuhongbao_...@hotmail.com>> wrote:
>>> What about the depreciation of XP SP2?
>>>
>>> Results from bug 1124017 say XP SP2 still works on binaries built with
>>> VS2015u1. This may not always hold true. So we will need to have the XP
>>> SP2 discussion at some point. I defer to bsmedberg to start that
>>> discussion.
>> I was originally thinking of dropping XP SP2 at the same time as moving to 
>> VS2015 this year.
>
> Yuhong, hello again! :-)
>
> I'm not sure why you keep trying to get Mozilla to drop support for
> Windows XP SP2. I think we have had this discussion numerous times,
> some recent examples include bug 1124017, bug 1236931, bug 1064387, bug
> 1136775, etc (also in other fora such as
> .
>
> In case the previous discussions have not made this clear, we will *not*
> drop support for Windows XP SP2 because one person keeps asking for it.
> There are a lot of reasons why we would consider dropping support for a
> platform, for a very recent example you can see the thread about
> dropping support for OSX 10.6-8 going on in the past couple of weeks, I
> suggest reading previous similar discussion to get a better
> understanding of why making this decision is a lot trickier than it may
> appear at first.

Obviously not, especially not immediately. It takes time for market share for 
older platforms to drop.
That is why I suggested timelines such as dropping support for XP SP2 at the 
same time as moving to VS2015 in 2016.

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

Re: b2g builds on trunk- perma failing for weeks?

[Fabrice Desré]

On 03/21/2016 08:31 AM, jmaher wrote:

I have noticed that since March 4th, the b2g builds on m-c are perma failing.  
Doing some basic searching we have about 15 hours of machine time going to 
failed builds on every push (which is ~1350 builds or 20,250 machine hours).

These show up in mozreview as failed jobs when you autoland a push.  I assume 
we plan to get all of these builds green and tests green, otherwise we wouldn't 
keep them running on every push for inbound/fx-team/central.

Do we need to keep these running on inbound and fx-team, or can they only run 
on mozilla-central?  I assume somebody is working on getting the builds to 
green up, could we be made aware of the work done here (maybe a tracking bug) 
so it doesn't seem that we are just letting builds run because we can?


We need them on inbound, yes. I think 
https://bugzilla.mozilla.org/show_bug.cgi?id=1257127 is tracking the fix.


thanks,
--
Fabrice Desré
Connected Devices
Mozilla Corporation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

RE: Intent to switch to Visual Studio 2015

[Yuhong Bao]

> On 2016-03-18 6:43 PM, Yuhong Bao wrote:
>>
>>> On 2016-03-17 8:35 PM, Yuhong Bao wrote:
> On Thu, Mar 17, 2016 at 3:30 PM,
> mailto:yuhongbao_...@hotmail.com>> wrote:
> What about the depreciation of XP SP2?
>
> Results from bug 1124017 say XP SP2 still works on binaries built with
> VS2015u1. This may not always hold true. So we will need to have the XP
> SP2 discussion at some point. I defer to bsmedberg to start that
> discussion.
 I was originally thinking of dropping XP SP2 at the same time as moving to 
 VS2015 this year.
>>>
>>> Yuhong, hello again! :-)
>>>
>>> I'm not sure why you keep trying to get Mozilla to drop support for
>>> Windows XP SP2. I think we have had this discussion numerous times,
>>> some recent examples include bug 1124017, bug 1236931, bug 1064387, bug
>>> 1136775, etc (also in other fora such as
>>> .
>>>
>>> In case the previous discussions have not made this clear, we will *not*
>>> drop support for Windows XP SP2 because one person keeps asking for it.
>>> There are a lot of reasons why we would consider dropping support for a
>>> platform, for a very recent example you can see the thread about
>>> dropping support for OSX 10.6-8 going on in the past couple of weeks, I
>>> suggest reading previous similar discussion to get a better
>>> understanding of why making this decision is a lot trickier than it may
>>> appear at first.
>>
>> Obviously not, especially not immediately. It takes time for market share 
>> for older platforms to drop.
>
> Agreed.
>
>> That is why I suggested timelines such as dropping support for XP SP2 at the 
>> same time as moving to VS2015 in 2016.
>
> Why do you think that us moving to VS2015 will suddenly cause the users
> on this OS to upgrade to a newer OS, or disappear some other way?

This timeline came from what MS officially supported.
Of course, it later turned out that it was easier to support XP SP2 on VS2015 
than VS2013.

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

MOZ_LOG_FILE and MOZ_LOG_MODULES are now the environment variables for logging

[Honza Bambas]

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.



The longer version:

Since the new logging code sits in XPCOM and has no longer anything to 
do with NSPR and NSPR logging, we want to modernize it and release it 
from the NSPR chains even more.


Two days ago a patch for bug 1248565 [1] has landed.  That patch 
introduces two new environment variables - MOZ_LOG_MODULES and 
MOZ_LOG_FILE.  The values are expected to be the same as for the 
NSPR_LOG_* variables pair.


If you don't specify MOZ_LOG_* vars but NSPR_LOG_* vars are specified, 
we will fallback to their values (i.e. those are then used for the new 
XPCOM logging as it was before the patch).  This preserves compatibility 
and there is no rush to redo all existing systems to use MOZ_LOG_*.


The NSPR_LOG_* pair can be specified along with the MOZ_LOG_* pair.  
Actually, NSPR_LOG_* is still needed for code that haven't migrated to 
the new logging API, see [1] and [3], and also for modules defined in 
NSPR and NSS code.



The rational for this move:

- the new logging has nothing to do with NSPR, it's now in XPCOM

- bug 1248565 [1] -> NSPR logging and XPCOM logging both write to the 
same file



-hb-


[1] 
https://mxr.mozilla.org/mozilla-central/search?string=PR_NewLogModule(%22


[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1248565

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1219461


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

Re: Linux distro readiness for Rust in Gecko

[Petr Cerny]

Chris Peterson wrote:
> On 3/20/16 3:04 AM, Henri Sivonen wrote:
>> On Sat, Mar 19, 2016 at 2:27 PM,   wrote:
>>> > On Thursday, 17 March 2016 12:23:32 UTC, Henri Sivonen  wrote:
 >> (rustc originally bootstrapped with OCaml, but
 >> building the whole history of Rust from the OCaml days to present
 >> every time Fedora builds Firefox seems excessively impractical.)
>>> >
>>> > Out of interest, would that actually involve building every single Linux 
>>> > snapshot from 
>>> > https://github.com/rust-lang/rust/blob/master/src/snapshots.txt in 
>>> > sequence? All 319 of them?
>> Presumably, yes, if you want to bootstrap from OCaml. Maybe you could
>> skip some snapshots, but you don't know which ones in advance.
>> Fortunately, e.g. the Fedora policy doesn't require bootstrapping all
>> the way from OCaml.
> 
> How does Debian bootstrap other compilers like Go that are partially 
> self-hosted? Would a Rust compiler written in C/C++ (e.g. generated by 
> an LLVM back-end that emitted C/C++ code?) avoid the bootstrap policy 
> requirements?

That would definitely help (and not just for Debian), since
bootstrapping as far as possible is a generally preferred direction on
Linux, with the only exception of the basic toolchain (binutils, GCC),
libc and couple more packages that form a basic system (shell, make).
That is: you take a minimal working system, recompile new versions of
the packages with those from older release, then use the new minimal
system to build anything else.

If you can get sources that will allow building current rustc within say
3 build cycles, i.e.:

[C sources]---(C compiler)-->[rustc-intermediate]

[Rust sources]---(rustc-intermediate)-->[rustc-current]

[Rust sources]---(rustc-current)-->[rustc-current]

it will be just fine. Obviously 2 cycles would be nicer, but this even
with one added layer in between is manageable. If the distributed source
package contained both the rust sources and a bootstrapping compiler and
maybe even allowed building the final binary with a single command (a la
`[configure script]; make`) it would behave just like any other package.

Actually, this would be pretty much what GCC does: it bootstraps itself
in three phases, with just one `make` command. And although the scale is
much longer, compiling for example GCC-5.3.0 with GCC

The problem is having to go through some 300 iterations (even if one
would probably do that only once on each distribution release). Which as
far as I understand - and please do correct me if I'm wrong - would be
the case (presumably because rustc's code is progressively using its own
new features).

>From my point of view there are two options that would greatly help:

1) a bootstrapping rust compiler written in C  that would work in a
small number of rounds as has been described above. It could as well be
C++, Python, Perl or whatever can be commonly found in distributions -
the lower the better to keep the dependency tree smaller.

2) a more stable rustc codebase - stable in the sense that a recompile
would only be necessary on the order of magnitude of ESR releases (note:
I'm writing this without any knowledge about current rustc compile
requirements). This would allow distributions to perform the long
iteration chain once and then update rustc only from time to time.

Thanks
Kind regards
Petr
-- 
Petr Cerny
Mozilla/OpenSSH maintainer for SUSE Linux
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Linux distro readiness for Rust in Gecko

[banderson]

On Saturday, March 19, 2016 at 9:18:21 PM UTC-7, Cameron Kaiser wrote:
> On 3/19/16 5:27 AM, cosinusoida...@gmail.com wrote:
> > On Thursday, 17 March 2016 12:23:32 UTC, Henri Sivonen  wrote:
> >> On Thu, Mar 17, 2016 at 1:58 PM, Martin Stransky  
> >> wrote:
> >>> Is it possible to build Rust from sources before Firefox build executes?
> >>
> >> rustc is written in Rust, so if you only have source code and the
> >> compilers that are currently available in Fedora, you can't build
> >> rustc. At minimum, you need a "stage0" compiler, which is an archived
> >> older rustc binary. (rustc originally bootstrapped with OCaml, but
> >> building the whole history of Rust from the OCaml days to present
> >> every time Fedora builds Firefox seems excessively impractical.)
> >
> > Out of interest, would that actually involve building every single Linux 
> > snapshot from 
> > https://github.com/rust-lang/rust/blob/master/src/snapshots.txt in 
> > sequence? All 319 of them?
> 
> And are those the steps you'd actually have to take to bring Rust up 
> from scratch on a new platform?
> 
> Cameron Kaiser
> tier-3s in rain dept.

No, to bootstrap Rust you don't have to rebuild it's entire snapshot history. 
You cross compile from a platform that already has a compiler. The exact 
process is slightly different for every platform.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Linux distro readiness for Rust in Gecko

[banderson]

On Sunday, March 20, 2016 at 3:05:25 AM UTC-7, Henri Sivonen wrote:
> On Fri, Mar 18, 2016 at 6:45 PM, Mike Hommey  wrote:
> > On Fri, Mar 18, 2016 at 05:23:21PM +0200, Henri Sivonen wrote:
> >> You say you don't see #5 happening. Do you see #4 happening? If not,
> >> what do you see happening?
> >
> > At this point, I'm wondering if the best outcome wouldn't be 6) Distros
> > die. I'm almost not joking.
> 
> Non-jokingly, though, what resolution do you see?
> 
> >> Looking at 
> >> https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#browser-security
> >> , it seems that Debian users get a more up-to-date Blink than Gecko.
> >> If that policy is any indication, if ESR didn't exist, Gecko would get
> >> the same deal as Blink... In other words, it looks like Debian
> >> penalizes Gecko relative to Blink because ESR exists. :-(
> >
> > Well, at some point Blink wasn't even in stable. I'm actually surprised
> > that it is now.
> 
> The key thing is that it is now and updating it in a way that's an
> exception to Debian's general policy is now itself stated policy. So
> Debian has explicitly granted our main competitor the sort of policy
> exception that would be the best suited to resolving the problem at
> hand arising from Debian policy.
> 
> How do we get for rustc (as a build dependency of Firefox) the sort of
> policy exception that our main competitor already got?
> 
> > But as a matter of fact, Debian's old stable is not
> > receiving Blink/Chromium updates (it's stuck on 37), while it receives
> > updates for Iceweasel (it has 38.7 as or writing, will receive 38.8, and
> > 45.2 after that)
> 
> It appears that 45 ESR compiles with the GCC version that's in
> oldstable. What would have happened if that wasn't the case? What's
> the plan if during the support cycle of the current stable the next
> ESR doesn't build with the GCC version that shipped in current stable?
> 
> The comments on https://bugzilla.mozilla.org/show_bug.cgi?id=1175546
> suggest that Mozilla deferred relying on GCC bug fixes until after 45
> ESR in order for Debian not to have to backport a compiler for
> oldstable. Is that the case? That is, is Debian's policy already
> hindering Mozilla's ability to avoid C++ compiler bugs that the
> compiler upstream has fixed?
> 
> >> On Fri, Mar 18, 2016 at 1:01 PM, Sylvestre Ledru  
> >> wrote:
> >> > One dirty solution would be to ship rustc+llvm sources into Firefox 
> >> > sources when targeting stable distros.
> >> > But this increases the load on the maintainers by an order of magnitude 
> >> > (maintainers will have to manage rust & llvm)
> >> > and might not work if llvm starts requiring a more recent of gcc to 
> >> > build.
> >>
> >> Surely llvm can be built with clang, so you could include not only the
> >> source of every rustc release since Debian's freeze but the source
> >> code of every llvm and clang release since Debian's freeze... Except
> >> then you'd need a policy exception for the anti-bundling policy. If
> >> you need *some* policy exception no matter what, surely going for the
> >> most sensible exception (letting both the Firefox package and the
> >> rustc package update every six weeks within the LTS cycle) would make
> >> the most sense.
> >
> > A 6GB source tarball, for a build taking 200 hours just for one
> > architecture (I'm making up numbers, but I'm probably in the right
> > ballpark). Times 10 supported architectures. You'd better not have a
> > one-liner patch to apply on top of that.
> 
> Right. That would be an absurd outcome caused by Debian's policy. So
> how do we go about getting a policy exception to avoid absurdity?
> 
> > Note that this is why Blink/Chromium can get away with very frequent updates
> > in stable and not Iceweasel/Firefox:
> >
> > $ grep-dctrl -sPackage -FDepends chromium --and --not -FSource 
> > chromium-browser 
> > /var/lib/apt/lists/ftp.jp.debian.org_debian_dists_jessie_main_binary-amd64_Packages
> > | wc -l
> > 2
> >
> > (one is http://chromium-bsu.sourceforge.net/, the other is mozplugger,
> > which... sounds like a mistake... I think it's an NPAPI plugin)
> >
> >
> > $ grep-dctrl -sPackage -FDepends iceweasel --and --not -FSource iceweasel 
> > /var/lib/apt/lists/ftp.jp.debian.org_debian_dists_jessie_main_binary-amd64_Packages
> > | wc -l
> > 64
> 
> Are the dependent packages Firefox extensions? Now that Debian has
> already accepted upgrading to the next ESR during the lifecycle of
> stable, how are those dependent packages expected to survive that
> upgrade without being themselves updated?
> 
> On Fri, Mar 18, 2016 at 9:05 PM,   wrote:
> > One could similarly make distro packages of rustc specifically for building 
> > firefox (called 'rustc-fx' for example), and put them on the same ESR 
> > upgrade schedule as Firefox.
> 
> This is the approach Ubuntu takes with GCC in order rapid-release
> (non-ESR) Firefox for Ubuntu LTS.
> 
> > As another idea: Rust could maintain an LTS branch designed t

Re: Linux distro readiness for Rust in Gecko

[banderson]

On Monday, March 21, 2016 at 9:43:24 AM UTC-7, Petr Cerny wrote:
> Chris Peterson wrote:
> > On 3/20/16 3:04 AM, Henri Sivonen wrote:
> >> On Sat, Mar 19, 2016 at 2:27 PM,   wrote:
> >>> > On Thursday, 17 March 2016 12:23:32 UTC, Henri Sivonen  wrote:
>  >> (rustc originally bootstrapped with OCaml, but
>  >> building the whole history of Rust from the OCaml days to present
>  >> every time Fedora builds Firefox seems excessively impractical.)
> >>> >
> >>> > Out of interest, would that actually involve building every single 
> >>> > Linux snapshot from 
> >>> > https://github.com/rust-lang/rust/blob/master/src/snapshots.txt in 
> >>> > sequence? All 319 of them?
> >> Presumably, yes, if you want to bootstrap from OCaml. Maybe you could
> >> skip some snapshots, but you don't know which ones in advance.
> >> Fortunately, e.g. the Fedora policy doesn't require bootstrapping all
> >> the way from OCaml.
> > 
> > How does Debian bootstrap other compilers like Go that are partially 
> > self-hosted? Would a Rust compiler written in C/C++ (e.g. generated by 
> > an LLVM back-end that emitted C/C++ code?) avoid the bootstrap policy 
> > requirements?
> 
> That would definitely help (and not just for Debian), since
> bootstrapping as far as possible is a generally preferred direction on
> Linux, with the only exception of the basic toolchain (binutils, GCC),
> libc and couple more packages that form a basic system (shell, make).
> That is: you take a minimal working system, recompile new versions of
> the packages with those from older release, then use the new minimal
> system to build anything else.
> 
> If you can get sources that will allow building current rustc within say
> 3 build cycles, i.e.:
> 
> [C sources]---(C compiler)-->[rustc-intermediate]
> 
> [Rust sources]---(rustc-intermediate)-->[rustc-current]
> 
> [Rust sources]---(rustc-current)-->[rustc-current]
> 
> it will be just fine. Obviously 2 cycles would be nicer, but this even
> with one added layer in between is manageable. If the distributed source
> package contained both the rust sources and a bootstrapping compiler and
> maybe even allowed building the final binary with a single command (a la
> `[configure script]; make`) it would behave just like any other package.
> 
> Actually, this would be pretty much what GCC does: it bootstraps itself
> in three phases, with just one `make` command. And although the scale is
> much longer, compiling for example GCC-5.3.0 with GCC

This is also what rustc does - it bootstraps off of itself. rustc is a 
self-hosting systems compiler comparable to gcc. Asking rustc to bootstrap off 
of yet another compiler is just kicking the can down the road. Eventually Rust 
wants to be in the same position as gcc, where distros have their own binary 
lineage and are bootstrapping their own compiler.

If we were to put the effort into transpiling to C (or flat out writing a rust 
compiler in C) so that it could be recompiled it would just be an intermediate 
step until distros have their own bootstrap working. Bootstrapping off of 
transpiled C is not much different than bootstrapping off a binary blog. The C 
is not going to be readable.

> 
> The problem is having to go through some 300 iterations (even if one
> would probably do that only once on each distribution release). Which as
> far as I understand - and please do correct me if I'm wrong - would be
> the case (presumably because rustc's code is progressively using its own
> new features).

I don't think anybody is expecting this. And in any case it's so impracticable 
that it's impossible. Distros will pick some existing binary snapshot to trust 
and then bootstrap off their own binaries.

> 
> From my point of view there are two options that would greatly help:
> 
> 1) a bootstrapping rust compiler written in C  that would work in a
> small number of rounds as has been described above. It could as well be
> C++, Python, Perl or whatever can be commonly found in distributions -
> the lower the better to keep the dependency tree smaller.

If this tool existed it would definitely help fill in the gaps. It would be a 
great amount of work to maintain.

> 
> 2) a more stable rustc codebase - stable in the sense that a recompile
> would only be necessary on the order of magnitude of ESR releases (note:
> I'm writing this without any knowledge about current rustc compile
> requirements). This would allow distributions to perform the long
> iteration chain once and then update rustc only from time to time.
> 
> Thanks
> Kind regards
>   Petr
> -- 
> Petr Cerny
> Mozilla/OpenSSH maintainer for SUSE Linux

___
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

[Nicholas Alexander]

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

Hi Honza,

Thanks for making the world a better place!  I'm sorry to add to your
burden, but could you drop links to updated MDN documentation?  I know that
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSPR/Reference/NSPR_LOG_MODULES
probably wants to reference your new work, and there are probably
additional places.  Is this in the coding styles document?  (Yet?)

Thanks again!
Nick


>
>
> The longer version:
>
> Since the new logging code sits in XPCOM and has no longer anything to do
> with NSPR and NSPR logging, we want to modernize it and release it from the
> NSPR chains even more.
>
> Two days ago a patch for bug 1248565 [1] has landed.  That patch
> introduces two new environment variables - MOZ_LOG_MODULES and
> MOZ_LOG_FILE.  The values are expected to be the same as for the NSPR_LOG_*
> variables pair.
>
> If you don't specify MOZ_LOG_* vars but NSPR_LOG_* vars are specified, we
> will fallback to their values (i.e. those are then used for the new XPCOM
> logging as it was before the patch).  This preserves compatibility and
> there is no rush to redo all existing systems to use MOZ_LOG_*.
>
> The NSPR_LOG_* pair can be specified along with the MOZ_LOG_* pair.
> Actually, NSPR_LOG_* is still needed for code that haven't migrated to the
> new logging API, see [1] and [3], and also for modules defined in NSPR and
> NSS code.
>
>
> The rational for this move:
>
> - the new logging has nothing to do with NSPR, it's now in XPCOM
>
> - bug 1248565 [1] -> NSPR logging and XPCOM logging both write to the same
> file
>
>
> -hb-
>
>
> [1]
> https://mxr.mozilla.org/mozilla-central/search?string=PR_NewLogModule(%22
>
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1248565
>
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1219461
>
>
> ___
> 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: Linux distro readiness for Rust in Gecko

[Petr Cerny]

bander...@mozilla.com wrote:
>> Actually, this would be pretty much what GCC does: it bootstraps
>> itself in three phases, with just one `make` command. And although
>> the scale is much longer, compiling for example GCC-5.3.0 with GCC
> 
> This is also what rustc does - it bootstraps off of itself. rustc is
> a self-hosting systems compiler comparable to gcc. Asking rustc to
> bootstrap off of yet another compiler is just kicking the can down
> the road. Eventually Rust wants to be in the same position as gcc,
> where distros have their own binary lineage and are bootstrapping
> their own compiler.

Sure, once you are on similar level of stability to GCC, it is not such
a big problem. Note that GCC 5.3.0 (to my best knowledge) can be
compiled by GCC-3.4 (10 years difference). Once rustc is capable of
being compiled by a one or two years older version of itself, the
problem is pretty much solved. Even 9 months would be mostly fine.

> If we were to put the effort into transpiling to C (or flat out
> writing a rust compiler in C) so that it could be recompiled it would
> just be an intermediate step until distros have their own bootstrap
> working. Bootstrapping off of transpiled C is not much different than
> bootstrapping off a binary blog. The C is not going to be readable.

Ok, if we are talking about output from LLVM backend, than it is exactly
same as using a binary blob (more below). A simple Rust compiler that
would shorten the chain from point zero to today by a half wouldn't
change that much. If it cut things down to say 10 iterations, it would
help. It wouldn't need to be fast or efficient, since it's product would
only be used once.

>> The problem is having to go through some 300 iterations (even if
>> one would probably do that only once on each distribution release).
>> Which as far as I understand - and please do correct me if I'm
>> wrong - would be the case (presumably because rustc's code is
>> progressively using its own new features).
> 
> I don't think anybody is expecting this. And in any case it's so
> impracticable that it's impossible. Distros will pick some existing
> binary snapshot to trust and then bootstrap off their own binaries.

I actually tend to think you are wrong on this one.

I personally would go through the 300 iterations (even if just once)
rather than using a random binary blob. Unless it is signed with a
secure key and that person/corporation is going to take (legal)
responsibility for any security problems caused by the blob itself (i.e.
compiling in a back-door).

Now, while it's not up to me to make these decisions, I can assure you
that these matters are not taken lightly for enterprise Linux.

> From my point of view there are two options that would greatly
>> help:
>> 
>> 1) a bootstrapping rust compiler written in C  that would work in
>> a small number of rounds as has been described above. It could as
>> well be C++, Python, Perl or whatever can be commonly found in
>> distributions - the lower the better to keep the dependency tree
>> smaller.
> 
> If this tool existed it would definitely help fill in the gaps. It
> would be a great amount of work to maintain.

If it is too much of a burden, 300 iterations may suddenly seem more
appealing. Once we get to point where 2) below applies it's (almost) a
piece of cake (I actually mentioned that above already).

>> 2) a more stable rustc codebase - stable in the sense that a
>> recompile would only be necessary on the order of magnitude of ESR
>> releases (note: I'm writing this without any knowledge about
>> current rustc compile requirements). This would allow distributions
>> to perform the long iteration chain once and then update rustc only
>> from time to time.

Thanks
Kind regards
Petr
-- 
Petr Cerny
Mozilla/OpenSSH maintainer for SUSE Linux
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Linux distro readiness for Rust in Gecko

[Henri Sivonen]

On Mon, Mar 21, 2016 at 6:49 PM,   wrote:
> I'm surprised to hear that *10.4* is still expected to work. The oldest 
> version I've heard Rust needed to support is 10.6.

10.6 on Intel is the oldest supported by Mozilla. Cameron maintains a
port to 10.4 on PPC: http://www.floodgap.com/software/tenfourfox/

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Linux distro readiness for Rust in Gecko

[Henri Sivonen]

On Mar 21, 2016 7:21 PM, "Petr Cerny"  wrote:
>

> Sure, once you are on similar level of stability to GCC, it is not such
> a big problem. Note that GCC 5.3.0 (to my best knowledge) can be
> compiled by GCC-3.4 (10 years difference). Once rustc is capable of
> being compiled by a one or two years older version of itself, the
> problem is pretty much solved. Even 9 months would be mostly fine.

rustc is already in openSUSE, so evidently, it's past the bootstrap phase.
Can't the enterprise version of SUSE promote a package from openSUSE and
have openSUSE (Tumbleweed at least) go through every rustc release so as
not to break the chain?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Linux distro readiness for Rust in Gecko

[Petr Cerny]

Henri Sivonen wrote:

 > Sure, once you are on similar level of stability to GCC, it is not such
 > a big problem. Note that GCC 5.3.0 (to my best knowledge) can be
 > compiled by GCC-3.4 (10 years difference). Once rustc is capable of
 > being compiled by a one or two years older version of itself, the
 > problem is pretty much solved. Even 9 months would be mostly fine.

rustc is already in openSUSE, so evidently, it's past the bootstrap
phase. Can't the enterprise version of SUSE promote a package from
openSUSE and have openSUSE (Tumbleweed at least) go through every rustc
release so as not to break the chain?


I'll have to check how those packages were built originally and discuss 
that with security team - there are differences between openSUSE and SLE.


Thanks
Kind regards
Petr

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

Re: b2g builds on trunk- perma failing for weeks?

[Juan Gómez]

Yep, I could finally fix this bustage and the patch it's just waiting to be
landed. Once it happens, builds won't be fixed immediately because we still
need to push a prebuilt image to one of our servers so once all the bits
are in place, treeherder will show a beautiful green tree again...
eventually :)

On Mon, Mar 21, 2016 at 5:05 PM, Fabrice Desré  wrote:

> On 03/21/2016 08:31 AM, jmaher wrote:
>
>> I have noticed that since March 4th, the b2g builds on m-c are perma
>> failing.  Doing some basic searching we have about 15 hours of machine time
>> going to failed builds on every push (which is ~1350 builds or 20,250
>> machine hours).
>>
>> These show up in mozreview as failed jobs when you autoland a push.  I
>> assume we plan to get all of these builds green and tests green, otherwise
>> we wouldn't keep them running on every push for inbound/fx-team/central.
>>
>> Do we need to keep these running on inbound and fx-team, or can they only
>> run on mozilla-central?  I assume somebody is working on getting the builds
>> to green up, could we be made aware of the work done here (maybe a tracking
>> bug) so it doesn't seem that we are just letting builds run because we can?
>>
>
> We need them on inbound, yes. I think
> https://bugzilla.mozilla.org/show_bug.cgi?id=1257127 is tracking the fix.
>
> thanks,
> --
> Fabrice Desré
> Connected Devices
> Mozilla Corporation
>
> ___
> 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: Test automation addons and signing

[Martijn]

So the xpinstall.signatures.required=false pref in about:config trick
doesn't work anymore for trunki?

Regards,
Martijn

On Tue, Mar 1, 2016 at 5:48 AM, Philip Chee  wrote:

> On 28/02/2016 09:45, Bobby Holley wrote:
>
> >> We were promised that trunk and aurora builds would not enforce addon
> >> signing when xpinstall.signatures.required=false. I did not see any
> >> discussion about rescinding this commitment.
>
> > We also run automation on release-channel builds to test the bits we
> ship...
>
> Ah right forgot about that.
>
> Phil
>
> --
> Philip Chee , 
> http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
> Guard us from the she-wolf and the wolf, and guard us from the thief,
> oh Night, and so be good for us to pass.
> ___
> 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

Intent to implement: -webkit-background-clip:text

[顧思捷]

Summary:
-webkit-background-clip:text has been available for years in webkit based
browsers and has seen widespread usage on the web. This css property is
currently available in Chrome, Safari and Edge.

Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=759568

Link to standard:
https://compat.spec.whatwg.org/#the-webkit-background-clip-property

Platform coverage:
All platforms.

Estimated or target release:
Firefox 48

Preference behind which this will be implemented:
layout.css.prefixes.webkit

Note:
The way we support this property value is a little bit different with
webkit.
After turning on layout.css.prefixes.webkit,
1. -webkit-background-clip property is supported.
2. In gecko, "text" is a valid value for *both* background-clip and
-webkit-backkground-clip.
3. In webkit, "text" is a valid value for only -webkit-backkground-clip.

If you set "text" into -webkit-background-clip and serialize
background-clip prop by style.getPropertyValue, you will still get "text",
which is problematic. dholbert gave more detail explanation on bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=759568#c40
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: text-combine-upright: all

[Xidorn Quan]

Summary:
According to some people from Japanese ebook companies,
text-combine-upright (a.k.a horizontal-in-vertical, or tate-chu-yoko) is a
must for Japanese vertical layout. Without the proper support of this
feature, a book may not be considered complete, and thus cannot be sold
online. This is also a common pattern for layout of Traditional Chinese.

There are two values for text-combine-upright, one is "all", the other is
"digits ". We are currently going to implement only "all", because
that's much easier to implement and can solve the majority of the problem
people have.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1097499

Link to standard:
https://drafts.csswg.org/css-writing-modes-3/#text-combine-upright

Platform coverage: all

Estimated or target release: Firefox 48 (or 49 if missed the cycle of 48)

Preference behind which this will be implemented:
layout.css.text-combine-upright.enabled

DevTools bug: This doesn't seem to need any additional support from
DevTools.

Do other browser engines implement this?
All other browser engines have had the support of the functionality of
"text-combine-upright: all". Edge and Blink have already been shipping it
unprefixed.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: -webkit-background-clip:text

[Jet Villegas]

I'd like to see this guarded by its own pref && layout.css.prefixes.webkit

Thanks for working on this, CJ!

--Jet

On Tue, Mar 22, 2016 at 1:59 PM, Ku(顧思捷)CJ  wrote:

> Summary:
> -webkit-background-clip:text has been available for years in webkit based
> browsers and has seen widespread usage on the web. This css property is
> currently available in Chrome, Safari and Edge.
>
> Bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=759568
>
> Link to standard:
> https://compat.spec.whatwg.org/#the-webkit-background-clip-property
>
> Platform coverage:
> All platforms.
>
> Estimated or target release:
> Firefox 48
>
> Preference behind which this will be implemented:
> layout.css.prefixes.webkit
>
> Note:
> The way we support this property value is a little bit different with
> webkit.
> After turning on layout.css.prefixes.webkit,
> 1. -webkit-background-clip property is supported.
> 2. In gecko, "text" is a valid value for *both* background-clip and
> -webkit-backkground-clip.
> 3. In webkit, "text" is a valid value for only -webkit-backkground-clip.
>
> If you set "text" into -webkit-background-clip and serialize
> background-clip prop by style.getPropertyValue, you will still get "text",
> which is problematic. dholbert gave more detail explanation on bugzilla:
> https://bugzilla.mozilla.org/show_bug.cgi?id=759568#c40
> ___
> 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