Announcing MozillaBuild 3.0 Release

[Ryan VanderMeulen]

I am pleased to announce the final release of MozillaBuild 3.0! Sorry in
advance for the length of this message, but there's a lot of changes in
this release worth calling out.

https://ftp.mozilla.org/pub/mozilla/libraries/win32/MozillaBuildSetup-Latest.exe
<http://ftp.mozilla.org/pub/mozilla/libraries/win32/MozillaBuildSetup-Latest.exe>

Important changes since version 2.2.0:

-

MozillaBuild now requires Windows 7+ 64-bit to install.
-

Removed the start-shell-msvc*.bat files. See below for more information
on this change.
-

Updated Python to version 2.7.13 and switched to the 64-bit version.
-

Added Python 3.6.2.
-

Added nodejs 8.1.4 & npm 5.3.0.
-

ESLint is now a first-class citizen on Windows! Things should Just
Work when using the |./mach eslint| command.
-

Other updates to various included components.
-

Mercurial updated to version 4.2.2.
-

NSIS updated to version 3.01 (and older versions removed).
-

Some MSYS components were updated.
-

Behind the scenes, MozillaBuild packaging was completely overhauled so
that anyone can now generate an installer package simply by running the
packageit.py script from the source checkout. This should in turn make it
much easier for new contributors to test their work.


Full changelog:

https://hg.mozilla.org/mozilla-build/pushloghtml?fromchange=MOZILLABUILD_2_2_0_RELEASE&tochange=MOZILLABUILD_3_0_0_RELEASE
<http://hg.mozilla.org/mozilla-build/pushloghtml?fromchange=MOZILLABUILD_2_2_0_RELEASE&tochange=MOZILLABUILD_3_0_0_RELEASE>

It is strongly advised that you not install this over a previous
installation!

Upgrade instructions:

1.

Pull down and update to a modern revision of any trunk repo
(mozilla-central, inbound, or autoland).
2.

Run |./mach mercurial-setup --update-only| to ensure the
version-control-tools repository is current. Extension bustage after
upgrade is likely if you don’t do this.
3.

Run |./mach clobber| to remove the object directory of any trees you
have. Build errors are pretty much guaranteed to occur otherwise.
4.

Assuming you’ve previously installed Rust via |./mach bootstrap|, backup
msys/etc/profile.d/profile-rustup.sh from your current MozillaBuild
installation.
5.

Remove your current installation. If you can't remove the existing
installation, you probably have a terminal open or ssh-agent running.
Terminate it and try again.
6.

Install MozillaBuild 3.0.
7.

Copy profile-rustup.sh to your new msys/etc/profile.d directory. You can
also just re-run |./mach bootstrap| if you don’t want to deal with copying
files around.
8.

If you previously enabled minTTY, you will need to do so again by
setting USE_MINTTY=1 at the top of start-shell.bat.


Please file any problems you come across in mozilla.org::MozillaBuild.

Where did start-shell-msvc*.bat go?

Since the release of MozillaBuild 2.2.0, much has changed with how we build
Firefox and in how Microsoft distributes their compiler and SDK toolchains.
In order to make things more flexible for both our build automation as well
as people building locally, MSVC and Platform SDK detection was moved into
the build system where it’s now detected when configure runs. Both MSVC
2015 and 2017 detection is supported, as well as Windows SDK 8.1+.

If you have both MSVC 2015 and 2017 installed, 2017 will be chosen by
default. This can be overridden by adding the following line to your
mozconfig
<https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Configuring_Build_Options>
:

ac_add_options --with-visual-studio-version=2015

Windows builds currently default to 32-bit. This can cause problems with a
mismatched Rust toolchain because it’ll try to use the 64-bit one by
default and then error out. To create a 64-bit build instead, add the
following two lines to your mozconfig:

ac_add_options --host=x86_64-pc-mingw32

ac_add_options --target=x86_64-pc-mingw32

Otherwise, you’ll need to manually install the i686 toolchain by running
the |rustup install stable-i686-pc-windows-msvc| command.

If you run into any problems with MSVC or Windows SDK detection, please
file a bug in Core::Build Config.

Thanks for reading and enjoy!

-Ryan

[Ryan VanderMeulen]

Apologies as well for the awful formatting job there. Thanks Gmail.

[Ryan VanderMeulen]

It appears that the formatting of that email was pretty well destroyed when
sent out. Here's a direct link to the release notes in Google Doc form:
https://docs.google.com/document/d/1NDz7ROxTYNB5YnP7VJ5CmJomQDun-7o4HDtSRLkuPaw/edit

-Ryan

[Gregory Szorc]

Thanks for all your work on this, Ryan!

So everyone knows, this is hopefully the last major overhaul of
MozillaBuild.

The plan from build system land is to attempt to go "all in" on Windows
Subsystem for Linux (WSL). That's the feature in Windows 10 (and even in
Server additions now) that implements Linux syscalls inside the Windows
kernel and allows you to run Linux binaries "natively" on Windows. The
performance is pretty good and it is a better Linux-on-Windows approach
than msys ever will be. Assuming we can pull it off, the goal is to ditch
MozillaBuild and support building Firefox from WSL. You'll then be able to
develop on Windows from the comfort of a Linux command line with access to
the full power of your favorite Linux distro. We will likely maintain some
support for building in non-WSL environments for automation, etc. But for
the average developer, we want to focus on WSL because we perceive that to
be the best opportunity for a more pleasant development experience on
Windows.

> _______________________________________________
> firefox-dev mailing list
> firef...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>

[Frank-Rainer Grahl]

Personally I find this a bad idea. Windows 7 and 8.1 are still supported till
2020 and 2023. As long as the compilers are supported too on them these should
also be fully supported as a build environment. Windows 10 is buggy and worse
than 8.1 in many aspects. I usually do not wear a tin head but the data
siphoning Microsoft is doing and which can't be disabled on non enterprise
versions together with the other "features" like forced updates of the OS
every once in a while makes it unsuiteable for my use. I could have smashed
something when after a Windows 10 Pro install 8 GB of useless game demos where
downloaded and presented to me. And that is not the only example. I never
thought I would prefer 8.1 over anything but this is currently the case. Not
sure what I do after 2023 but probably switch to Linux and run anything I need
Windows for in a vm.
FRG

[施賀傑]

Thanks for the new version of mozbuild!

Is it including msys2? Then, it will be easier to include the bash-completion.

-Jerry

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

[Ryan VanderMeulen]

It does not use msys2. Those plans were dropped in favor of WSL.

[Enrico Weigelt, metux IT consult]

On 21.07.2017 22:52, Gregory Szorc wrote:

Hi folks,

> The plan from build system land is to attempt to go "all in" on Windows
> Subsystem for Linux (WSL). That's the feature in Windows 10 (and even in
> Server additions now) that implements Linux syscalls inside the Windows
> kernel and allows you to run Linux binaries "natively" on Windows. The
> performance is pretty good and it is a better Linux-on-Windows approach
> than msys ever will be.

<snip>

Does that mean, all the Windows specific stuff (at least except gui)
can now be dropped ?


--mtx

[Mike Hoye]

On 2017-07-22 3:13 AM, Frank-Rainer Grahl wrote:
> Personally I find this a bad idea. Windows 7 and 8.1 are still
> supported till 2020 and 2023. As long as the compilers are supported
> too on them these should also be fully supported as a build environment.

Unfortunately we have to build _for_ a number of our supported operating
systems without being able to build _on_ those operating systems. That's
been true for some time now; while we still support 32-bit systems, for
example, you can't build Firefox on 32-bit systems at all due to memory
constraints, and the new MozillaBuild system is 64-bit only due to a
variety of dependencies.

This means some people on older hardware or OSes aren't able build
Firefox, that's true, but it doesn't mean they have no way to contribute
to Firefox, and restricting ourselves to only shipping a product that we
can build directly on those older systems means giving every single
person who relies on those systems a crap experience and a substandard
product.

It'd be nice in some abstract sense to be able to bootstrap a Firefox
executable on every system we support, but the tradeoffs we'd need to
accept to do that (support costs, development velocity, actual
as-delivered product quality and a lot more) are _so_ egregiously bad
for everyone involved that there's no reasonable, much less responsible,
way we can invest any time or effort making that happen.



- mhoye

[Enrico Weigelt, metux IT consult]

On 24.07.2017 16:00, Mike Hoye wrote:

Hi,

> Unfortunately we have to build _for_ a number of our supported operating
> systems without being able to build _on_ those operating systems.

Is that a big problem ?

At least within Linux world, it's daily business for me (well, I'm
doing a lot of embedded projects).

Haven't tried on Windows yet. Can we crosscompile it from Linux ?
(if so, is there an howto for that ?)

> That's been true for some time now; while we still support 32-bit systems,
> for example, you can't build Firefox on 32-bit systems at all due to
> memory constraints,

This raises the question: why does it take up so much memory ?

> and the new MozillaBuild system is 64-bit only due to a
> variety of dependencies.

Which constraints (beside memory) ? Also on Linux ?

> This means some people on older hardware or OSes aren't able build
> Firefox, that's true,

Not sure, whether an 4core i7 w/ 8GB RAM already counts as "old", but
it's really slow on my box. I've got the impression there's stil a lot
of room for optimizations. For example, I wonder why lots of .cpp-files
are #include'd into one.

> but it doesn't mean they have no way to contribute to Firefox,

A CI for contributors would be very nice here. For example, I don't
have any Windows systems for decades.

> It'd be nice in some abstract sense to be able to bootstrap a Firefox
> executable on every system we support, but the tradeoffs we'd need to
> accept to do that (support costs, development velocity, actual
> as-delivered product quality and a lot more) are _so_ egregiously bad
> for everyone involved that there's no reasonable, much less responsible,
> way we can invest any time or effort making that happen.

I'm currently trying to package tbird (52esr) for Debian/Devuan.
When I'm done, I can provide scripts for that. (maybe put the whole
build stuff into an dedicated package).


--mtx

[Nathan Froyd]

On Mon, Jul 24, 2017 at 4:25 PM, Enrico Weigelt, metux IT consult
<enrico....@gr13.net> wrote:
> On 24.07.2017 16:00, Mike Hoye wrote:
>> Unfortunately we have to build _for_ a number of our supported operating
>> systems without being able to build _on_ those operating systems.
>
> Is that a big problem ?
>
> At least within Linux world, it's daily business for me (well, I'm
> doing a lot of embedded projects).

Sure, it's daily business for us, too. Mike cited examples in his
response (e.g. we cannot compile natively on 32-bit systems, Android
included, so Firefox for such platforms is cross compiled from a
64-bit platform).

> Haven't tried on Windows yet. Can we crosscompile it from Linux ?

No. There are a few people interested, but there are lots of issues.

>> That's been true for some time now; while we still support 32-bit systems,
>> for example, you can't build Firefox on 32-bit systems at all due to
>> memory constraints,
>
> This raises the question: why does it take up so much memory ?

Because Firefox is a large program, and linking large programs takes
up a large amount of memory, more than is addressable on 32-bit
systems.

>> This means some people on older hardware or OSes aren't able build
>> Firefox, that's true,
>
> Not sure, whether an 4core i7 w/ 8GB RAM already counts as "old", but
> it's really slow on my box. I've got the impression there's stil a lot
> of room for optimizations. For example, I wonder why lots of .cpp-files
> are #include'd into one.

Because doing this actually makes builds faster and the final binary
smaller. See https://blog.mozilla.org/nfroyd/2013/10/05/faster-c-builds/
for details.

If you had more RAM, your builds would likely be much faster. Four
C++ compiles could easily take 1-1.5GB of memory apiece, and you would
probably like to run other programs while you compile.

There are probably many places the build can be optimized; if you have
a suggestion, please file a bug at
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Build%20Config

>> but it doesn't mean they have no way to contribute to Firefox,
>
> A CI for contributors would be very nice here. For example, I don't
> have any Windows systems for decades.

You can request level 1 commit access to our try infrastructure:
https://www.mozilla.org/en-US/about/governance/policies/commit/access-policy/
That will enable you to build Firefox with your patches on all the
major platforms we support.

-Nathan

[Joshua Cranmer 🐧]

On 7/24/2017 3:25 PM, Enrico Weigelt, metux IT consult wrote:
>> That's been true for some time now; while we still support 32-bit
>> systems,
> > for example, you can't build Firefox on 32-bit systems at all due to
> > memory constraints,
>
> This raises the question: why does it take up so much memory ?

Release builds on Windows use LTO, which requires essentially keeping
both the final object file and the entire internal IR in memory at the
same time.

> Not sure, whether an 4core i7 w/ 8GB RAM already counts as "old", but
> it's really slow on my box. I've got the impression there's stil a lot
> of room for optimizations. For example, I wonder why lots of .cpp-files
> are #include'd into one.

In that example, undoing that slows down your build. (Parsing C++ header
files take a lot of time in the aggregate, and you spend less time
linking when there's no duplicates of inlined methods).

--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

[Steve Fink]

Sorry, I know this is a tangent, but I'd like to underscore that final
clause, since it's been so surprising to me.

Unified builds *massively* speed up the final link. I dropped the
unified chunk size (number of .cpp files glued together at a time in
unholy matrimony) for js/src because of a very common use case, which is
to touch one file and rebuild. With the default of 16 source files glued
together, that means recompiling a huge source file. Compiles are
naturally much faster with the new value (6).

Surprisingly, though, the total time to touch a single source file and
get out a working build was pretty much unchanged -- the time saved in
the compilation was spent linking more object files instead.

Overall, it's still a good change, since when you're still working
through compile errors on something, you aren't going to be linking
anyway. It just surprised me that the link could get that much slower.
More recently, I accidentally started using a nonunified build, and
honestly thought the linker was hanging because it took so much longer
than I'm used to (this was with n=1 instead of n=6 or n=16).

My guess is that the compilers/linkers don't really handle heavy C++
template usage very well, and end up generating and then eliminating
massive number of duplicate template instantiations. But that's idle
speculation.

[Enrico Weigelt, metux IT consult]

On 24.07.2017 20:40, Nathan Froyd wrote:

> Sure, it's daily business for us, too. Mike cited examples in his
> response (e.g. we cannot compile natively on 32-bit systems, Android
> included, so Firefox for such platforms is cross compiled from a
> 64-bit platform).

OTOH, we should keep in mind that most distros dont do cross compiling.
Some distros (eg. gentoo or lfs) are also building on the target.

I don't like the idea of kicking away these platforms.

>> Haven't tried on Windows yet. Can we crosscompile it from Linux ?
>
> No. There are a few people interested, but there are lots of issues.

I'd guess it could be helpful for developers not running Windows,
at least for doing some build checks.

>> This raises the question: why does it take up so much memory ?
>

> Because Firefox is a large program, and linking large programs takes
> up a large amount of memory, more than is addressable on 32-bit
> systems.

Well, why is the main program so big that linking takes up so much
memory ? Perhaps a lack of proper modularization ?

One thing we could do about that might be limitig the exported symbols
of shared libraries (only export the really necessary ones).

> There are probably many places the build can be optimized; if you have
> a suggestion, please file a bug at
> https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Build%20Config

I'm currently working on fixing optional features, eg. protocols,
codecs, etc. Let's see whether I'll also find things to clean up
in the build system.

Is there an automatic interface for patch submission (something
similarily easy like git-send-mail) ? Having to click through websites
manually is just very time consuming.

> You can request level 1 commit access to our try infrastructure:
> https://www.mozilla.org/en-US/about/governance/policies/commit/access-policy/
> That will enable you to build Firefox with your patches on all the
> major platforms we support.

Sounds interesting. Is there a way for pushing via git directly ?
I'm currently lacking the resources for coping w/ hg stuff.

A real cool feature would be the CI directly pulling from github,
that would make things a lot easier for people like me.


--mtx

[Botond Ballo]

On Mon, Jul 24, 2017 at 6:21 PM, Enrico Weigelt, metux IT consult
<enrico....@gr13.net> wrote:
> Is there an automatic interface for patch submission (something
> similarily easy like git-send-mail) ? Having to click through websites
> manually is just very time consuming.

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

Cheers,
Botond

[1] https://mozilla-version-control-tools.readthedocs.io/en/latest/mozreview-user.html

[Enrico Weigelt, metux IT consult]

On 24.07.2017 21:13, Joshua Cranmer 🐧 wrote:

> In that example, undoing that slows down your build. (Parsing C++ header
> files take a lot of time in the aggregate, and you spend less time
> linking when there's no duplicates of inlined methods).

That leads me to another question: do the headers need to so huge
at all ? Is there a lack of modularization ?

One problem I'm currently struggling with are the dependencies of
lots of places w/ specific network protocols. This IMHO deserves
a cleanup.


--mtx

[Ralph Giles]

On Mon, Jul 24, 2017 at 3:51 PM, Botond Ballo <bba...@mozilla.com> 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

[Mike Hommey]

On Mon, Jul 24, 2017 at 03:57:24PM -0700, Ralph Giles wrote:
> On Mon, Jul 24, 2017 at 3:51 PM, Botond Ballo <bba...@mozilla.com> 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).

It's also possible to work from gecko-dev:
https://github.com/glandium/git-cinnabar/wiki/Mozilla:-Using-a-git-clone-of-gecko%E2%80%90dev-to-push-to-mercurial

Mike

[Enrico Weigelt, metux IT consult]

On 24.07.2017 21:29, Steve Fink wrote:

> My guess is that the compilers/linkers don't really handle heavy C++
> template usage very well, and end up generating and then eliminating
> massive number of duplicate template instantiations. But that's idle
> speculation.

I doubt there's much that compilers can do better here.

When compiling a C++ source, it needs to compile all that's needed
within that file (header-defined functions, constructors, template-
instantiations, etc). Later, at the linking phase, it can throw out
lots of duplicated code. For statically linked binaries, it's still
quite easy, but w/ shared libraries it gets pretty complex.


--mtx

[Mike Hommey]

On Mon, Jul 24, 2017 at 08:25:18PM +0000, Enrico Weigelt, metux IT consult wrote:
> I'm currently trying to package tbird (52esr) for Debian/Devuan.

It looks like you're doing a lot of work that is completely out of scope
for creating packages for Debian/Devuan, and that is work that sounds
like should be discussed with the thunderbird crowd.

(Also, there's already a thunderbird package in Debian)

Mike

[Nathan Froyd]

On Mon, Jul 24, 2017 at 6:21 PM, Enrico Weigelt, metux IT consult
<enrico....@gr13.net> wrote:
> On 24.07.2017 20:40, Nathan Froyd wrote:
>> Sure, it's daily business for us, too. Mike cited examples in his
>> response (e.g. we cannot compile natively on 32-bit systems, Android
>> included, so Firefox for such platforms is cross compiled from a
>> 64-bit platform).
>
> OTOH, we should keep in mind that most distros dont do cross compiling.
> Some distros (eg. gentoo or lfs) are also building on the target.
>
> I don't like the idea of kicking away these platforms.

We do take into account the needs of Linux distributions when making
changes. So far as I am aware, our compilation requirements for Linux
platforms have not caused huge amounts of headaches.

>>> Haven't tried on Windows yet. Can we crosscompile it from Linux ?
>>
>> No. There are a few people interested, but there are lots of issues.
>
> I'd guess it could be helpful for developers not running Windows,
> at least for doing some build checks.

Developers not running Windows tend to use our try server for
compiling on Windows. There are some good reasons for cross-compiling
to Windows, but none of them have become important enough to seriously
consider making the switch.

>>> This raises the question: why does it take up so much memory ?
>>
>> Because Firefox is a large program, and linking large programs takes
>> up a large amount of memory, more than is addressable on 32-bit
>> systems.
>
> Well, why is the main program so big that linking takes up so much
> memory ? Perhaps a lack of proper modularization ?

Well, libxul (the main shared library in Firefox) is rather large, but
we're not going to split it into smaller libraries. We *did* have
multiple shared libraries in the past, and there was a significant
startup and performance hit for doing that. So we have one large
shared library to link now.

> One thing we could do about that might be limitig the exported symbols
> of shared libraries (only export the really necessary ones).

We already do that. Eyeballing the `readelf -sW` output from my
Firefox nightly on Linux, libxul exports ~1% of all the symbols it
defines.

Other people have mentioned options for pushing patches; my preferred
tool for doing this is git-bz-moz:
https://github.com/mozilla/git-bz-moz

-Nathan

[Steve Fink]

Sure, I get that. But first, I'm a little skeptical that the slowdown is
merely linear in the amount of duplication; it feels worse than that.
And second, even if this is the exact problem at hand, it feels like
C++'s reliance on independent compilation units is outdated. It's great
for modularity and simplicity, but in fact C++ the language does not
work that way, and stripping out redundancies during linking is the
wrong algorithm. Not that I would assert that an alternative would be
straightforward, especially with the preprocessor involved and differing
scope lookup environments etc. But from an algorithmic standpoint,
separate compilation is simply incorrect.

[Enrico Weigelt, metux IT consult]

On 24.07.2017 23:04, Mike Hommey wrote:

> It looks like you're doing a lot of work that is completely out of scope
> for creating packages for Debian/Devuan,

Not quite. Of course, I don't wanna compile-in things that aren't
necessary here (eg. the media stuff). But that lead to lots of problems,
so I'm now getting my hands dirty and try to fix at the root.

> and that is work that sounds
> like should be discussed with the thunderbird crowd.

Nope, they directed me to this list, as these things aren't in tbird's
own tree, but generic mozilla.

> (Also, there's already a thunderbird package in Debian)

An old one. And it still contains lots of dead weight, I'd like to get
rid of.

When I'm done w/ that, I'll start w/ things I've been planning for
quite some time, eg. moving mailbox handling to external upas service,
all credential related stuff to factotum, move contact handling to
external programs, etc, etc.

But before I can start with that, I first need a clean working base.


--mtx

[Mike Hommey]

On Tue, Jul 25, 2017 at 12:20:48AM +0000, Enrico Weigelt, metux IT consult wrote:
> On 24.07.2017 23:04, Mike Hommey wrote:
>
> > It looks like you're doing a lot of work that is completely out of scope
> > for creating packages for Debian/Devuan,
>
> Not quite. Of course, I don't wanna compile-in things that aren't
> necessary here (eg. the media stuff). But that lead to lots of problems,
> so I'm now getting my hands dirty and try to fix at the root.
>
> > and that is work that sounds
> > like should be discussed with the thunderbird crowd.
>
> Nope, they directed me to this list, as these things aren't in tbird's
> own tree, but generic mozilla.
>
> > (Also, there's already a thunderbird package in Debian)
>
> An old one.

Debian has 52esr.

> And it still contains lots of dead weight, I'd like to get rid of.

Which is out of scope for packaging something for Debian.

> When I'm done w/ that, I'll start w/ things I've been planning for
> quite some time, eg. moving mailbox handling to external upas service,
> all credential related stuff to factotum, move contact handling to
> external programs, etc, etc.
>
> But before I can start with that, I first need a clean working base.

So, in fact, you want to fork thunderbird, you should just have said so
from the beginning.

Mike

[Fabrice Desre]

On 07/24/2017 05:20 PM, Enrico Weigelt, metux IT consult wrote:

>
> When I'm done w/ that, I'll start w/ things I've been planning for
> quite some time, eg. moving mailbox handling to external upas service,
> all credential related stuff to factotum, move contact handling to
> external programs, etc, etc.
>
> But before I can start with that, I first need a clean working base.

If you haven't done so yet, you should read the archives at
https://mail.mozilla.org/pipermail/tb-planning/ where the future of
Thunderbird is discussed. It looks quite different from trimming down
gecko.

[Enrico Weigelt, metux IT consult]

On 25.07.2017 00:34, Mike Hommey wrote:

> Debian has 52esr.

Maybe in experimental. But that doesn't help me much for jessie.

>> And it still contains lots of dead weight, I'd like to get rid of.
>
> Which is out of scope for packaging something for Debian.

Maybe for average Debian folks, who also have no problem w/ forcing
people into some special init system that wants to be an own OS.
But certainly not for me - I dont wanna have useless code on my
machines.

> So, in fact, you want to fork thunderbird, you should just have said so
> from the beginning.

Too early to tell whether it will end up in a fork or things can be
integrated into mainline. We'll see later.


--mtx

[Joshua Cranmer 🐧]

On 7/24/2017 7:20 PM, Enrico Weigelt, metux IT consult wrote:
> On 24.07.2017 23:04, Mike Hommey wrote:
>
>> It looks like you're doing a lot of work that is completely out of scope
>> for creating packages for Debian/Devuan,
>
> Not quite. Of course, I don't wanna compile-in things that aren't
> necessary here (eg. the media stuff). But that lead to lots of problems,
> so I'm now getting my hands dirty and try to fix at the root.

Trying to build by disabling lots of flags in general leads to lots of
frustration with broken builds. A decade of experience at Mozilla has
shown that configurations not built on standard automation tend to be
quickly broken. The onus of maintenance will be entirely on you, even if
the changes are upstreamed--and they are unlikely to be accepted
upstream without justification (which "I don't wanna have these" is not).

FWIW, building in odd configurations generally disqualifies you from
being able to use Mozilla trademarks on the resulting product.

>
>> and that is work that sounds
>> like should be discussed with the thunderbird crowd.
>
> Nope, they directed me to this list, as these things aren't in tbird's
> own tree, but generic mozilla.

I directed you to this list because you were asking "how do I modify
media/ to stop doing this stuff?", which is plainly out of scope for mdat.

> When I'm done w/ that, I'll start w/ things I've been planning for
> quite some time, eg. moving mailbox handling to external upas service,
> all credential related stuff to factotum, move contact handling to
> external programs, etc, etc.
>
> But before I can start with that, I first need a clean working base.

If you believe that maintaining your own custom pared-down ersatz build
is a necessary precondition for adding new functionality, you will have
rather little time to implement other functionality.

As Mike Hommey says, you are looking to build a fork of Thunderbird at
this point. It's not entirely clear what you're proposing, but the vague
language suggests very heavily that you're intending to delete our
present code for unknown external libraries, which is likely not in the
vision of Thunderbird's future and therefore is unlikely to be accepted
upstream.

[Mike Hommey]

On Tue, Jul 25, 2017 at 01:07:19AM +0000, Enrico Weigelt, metux IT consult wrote:
> On 25.07.2017 00:34, Mike Hommey wrote:
>
> > Debian has 52esr.
>
> Maybe in experimental. But that doesn't help me much for jessie.

No, it's in testing, and should reach stable at some point, and I guess
the Debian LTS people will pull it for jessie, because it's already in
wheezy.

> > > And it still contains lots of dead weight, I'd like to get rid of.
> >
> > Which is out of scope for packaging something for Debian.
>
> Maybe for average Debian folks, who also have no problem w/ forcing
> people into some special init system that wants to be an own OS.

Oh, so you're also trolling, now.

Mike

[Nicholas Nethercote]

This thread is nominally about a new version of MozillaBuild 3.0, though it
has strayed significantly. I'm going to politely suggest that discussion of
other topics in this thread cease. If anybody wants to start other threads
on other topics, please do so.

But also be aware that this mailing list is read by a lot of people
(hundreds at least, I think) and it isn't really intended as a place for
new contributors to ask questions about anything and everything. In
contrast, the #introduction IRC channel is specifically designed for that.

Nick

[Frank-Rainer Grahl]

> This means some people on older hardware or OSes aren't able build Firefox,

This currently means that about 50% of the current users are not being able to
build in the future. With Win 7 and 8.1 market share together we are not
speaking about Vista here. I am building in a vm anyway so can set up a Win 10
one too but limiting choices to force using an operating system which treats
its users like dirt is not what I would call a good move. So as long as the
compilers are supported on other OS than 10 I strongly disagree with this.
FRG