[Security Update] 2018-12-11 - Firefox 64.0

I have built and pushed Firefox 64.0 to the following branches:

  • stable
  • testing
  • unstable
     
  • x32-stable
  • x32-testing
  • x32-unstable

As is always the case for a short-turnaround update, this package has had only minimal testing.


Release notes: https://www.mozilla.org/en-US/firefox/64.0/releasenotes/
Security advisory: https://www.mozilla.org/en-US/security/advisories/mfsa2018-29/


manjaro32 packages should arrive later today.

34 Likes

FF64 for 64 bit yeah

2 Likes

@jonathon
Where is your PKGBUILD kept so I can keep an eye on it?

I just edit and build the Arch PKGBUILD.

64-bit compiles without changes (except this time it needed to use the bundled nspr and nss), 32-bit needs a variety of tweaks depending on the particular release.

OK, I’ll try compiling firefox-kde-opensuse now.
PS, why the 0 pkgrel?
I’ve never seen anyone do that before, this usually always starts with 1.

2 Likes

It’s a no go, patches are failing on me.

==> Patching for KDE
patching file toolkit/system/unixproxy/nsUnixSystemProxySettings.cpp
patching file modules/libpref/Preferences.cpp
Hunk #1 succeeded at 81 (offset 1 line).
Hunk #2 succeeded at 4909 (offset -24 lines).
Hunk #3 succeeded at 4988 (offset -24 lines).
patching file modules/libpref/moz.build
patching file python/mozbuild/mozpack/chrome/flags.py
patching file python/mozbuild/mozpack/chrome/manifest.py
patching file toolkit/components/downloads/moz.build
patching file toolkit/content/jar.mn
Hunk #1 FAILED at 70.
1 out of 1 hunk FAILED – saving rejects to file toolkit/content/jar.mn.rej
patching file toolkit/content/widgets/dialog-kde.xml
patching file toolkit/mozapps/downloads/nsHelperAppDlg.js
Hunk #1 succeeded at 1031 (offset 1 line).
patching file toolkit/system/unixproxy/nsUnixSystemProxySettings.cpp
patching file toolkit/xre/moz.build
Hunk #1 succeeded at 68 (offset 1 line).
patching file toolkit/xre/nsKDEUtils.cpp
patching file toolkit/xre/nsKDEUtils.h
patching file uriloader/exthandler/HandlerServiceParent.cpp
patching file uriloader/exthandler/moz.build
patching file uriloader/exthandler/unix/nsCommonRegistry.cpp
patching file uriloader/exthandler/unix/nsCommonRegistry.h
patching file uriloader/exthandler/unix/nsKDERegistry.cpp
patching file uriloader/exthandler/unix/nsKDERegistry.h
patching file uriloader/exthandler/unix/nsMIMEInfoUnix.cpp
patching file uriloader/exthandler/unix/nsOSHelperAppService.cpp
Hunk #2 succeeded at 1122 (offset -3 lines).
Hunk #3 succeeded at 1140 (offset -3 lines).
Hunk #4 succeeded at 1237 (offset -3 lines).
Hunk #5 succeeded at 1358 (offset -3 lines).
patching file widget/gtk/moz.build
patching file widget/gtk/nsFilePicker.cpp
Hunk #4 FAILED at 635.
1 out of 4 hunks FAILED – saving rejects to file widget/gtk/nsFilePicker.cpp.rej
patching file widget/gtk/nsFilePicker.h
Hunk #1 FAILED at 69.
1 out of 1 hunk FAILED – saving rejects to file widget/gtk/nsFilePicker.h.rej
patching file xpcom/components/ManifestParser.cpp
Hunk #2 succeeded at 422 (offset 2 lines).
Hunk #3 succeeded at 478 (offset 2 lines).
Hunk #4 succeeded at 607 (offset 2 lines).
Hunk #5 succeeded at 672 (offset 2 lines).
patching file xpcom/components/moz.build
patching file xpcom/io/nsLocalFileUnix.cpp
==> ERROR: A failure occurred in prepare().
   Aborting…

I’ll need to sort this out.
PS. What did you mean by “(except this time it needed to use the bundles nspr and nss)”?

1 Like

The package normally comes from Arch, so the 64.0-1 package will make its way through the branches as normal.

Normally the system libraries as used. In this case, the system libraries are too old for what Firefox wanted to build, so I switched to the bundled libraries instead.

1 Like

Ok then, I’ll remark out those from my mozconfig file and see what happens.

# System libraries
# ac_add_options --with-system-nspr
# ac_add_options --with-system-nss

I also went ahead and updated to the latest patch revision from factory (15 hours ago).
_patchrev=9fec29d2ead2

http://www.rosenauer.org/hg/mozilla

Fingers crossed…

2 Likes

Still no go, still getting the same errors.
Looks like I need to look at the patches that are failing.

@jonathon,
Here are my files:

If you have any idea what could be causing my problem, please let me know.
Any help would be appreciated.

Well, the upstream patches were updated this morning.
I’ve also started refactoring my PKGBUILD to more closely resemble upstream arches build.

@jonathon @philm

Here is firefox-kde-opensuse 64.0-1, must be on Manjaro testing branch to install.
http://arch.netrunner.com/netrunner-testing/x86_64/firefox-kde-opensuse-64.0-1-x86_64.pkg.tar.xz
Should I also build a 64.0-0 for stable like jonathan did?
You know built against the provided versions.
Or is testing getting pushed to stable soon?

3 Likes

I pushed it now to testing and unstable. A next stable update should come on Friday.

4 Likes

Sounds good. Thanks. :wink:

Forgot to upload my firefox-kde build.
It just needed the new revision from Rosenauer plus the latest unity-menubar.patch from Ubuntu.
Builds and runs fine.

Really?
How did you get firefox to compile against the older shared libs on stable?
Or are you not compiling it against the (dynamic) libs in the repo, but using the (static) libs provided in the Firefox source tree?

No, I’m on testing since a few months. Sorry for the misunderstanding.

No problems, I was just wondering. :wink:
PS. what PKGBUILD are you using?
I’m thinking about also hosting mine elsewhere besides the netrunner github repo for better collaboration.

1 Like

I forgot to upload it yesterday, it’s basically the same as the original from thaodan, except that it has

  1. a different mozconfig to disable more useless stuff
  2. ccache also enabled for non-PGO builds (a small change to the if clause IIRC)

I’ll upload it later today to my github.

How long it takes to compile firefox on consumer hardware (8700k, 2700x…) ? Does it automatically use all cpu cores to compile as fast as possible ? How much ram it requires ?

Just landed in Testing for me this morning:

Thanks!

It takes around 20 minutes on my hexacore @ 3.6 GHz, using about 16 GB of RAM in the process (cached). A little less with ccache.
However my build is trimmed down, the official one will take longer.

It should use all CPU cores automatically if they’re set in /etc/makepkg.conf (!makeflags might prevent this), else you might need to add
mk_add_options MOZ_MAKE_FLAGS="-jXX" (XX being the number of threads)
to the mozconfig file.

Forum kindly sponsored by