+++ This bug was initially created as a clone of Bug #22776 +++ RedHat has issued an advisory today (March 15): https://access.redhat.com/errata/RHSA-2018:0527 nspr also needs to be updated to 4.19. No rootcerts update is needed for this update. nspr updates built: libnspr4-4.19-1.mga5 libnspr-devel-4.19-1.mga5 I've also checked a rediffed patch for sqlite3's CVE-2018-8740 (Bug 22792) in to Mageia 5 SVN for the firefox package, as it builds with the bundled sqlite3 (Mageia 6 uses the system sqlite3). Firefox 52.7.3 has been released today (March 26): https://www.mozilla.org/en-US/firefox/52.7.3/releasenotes/ It fixes one additional issue: https://www.mozilla.org/en-US/security/advisories/mfsa2018-10/ It has been checked into SVN.
Assigning to all packagers collectively, since there is no registered maintainer for this package.
CC: (none) => marja11Assignee: bugsquad => pkg-bugs
(In reply to David Walser from comment #0) The current spec for 52.7.3 have this lines 282 %if %mgaver > 5 283 # Using the bundled icu because the mgav5 one is too old. 284 echo "ac_add_options --disable-system-icu" >> .mozconfig 285 %endif Not sure but i think the test in line 282 should be = or >=
That's not the current spec. It says: 276 # Using the bundled icu because the mgav5 one is too old. 277 echo "ac_add_options --disable-system-icu" >> .mozconfig and it's not inside of an %if.
(In reply to David Walser from comment #3) > That's not the current spec. > > It says: > 276 # Using the bundled icu because the mgav5 one is too old. > > 277 echo "ac_add_options --disable-system-icu" >> .mozconfig > > and it's not inside of an %if. I read from this revision http://svnweb.mageia.org/packages/updates/6/firefox/current/SPECS/firefox.spec?revision=1218342&view=markup
This bug is for Mageia 5, not Mageia 6.
(In reply to David Walser from comment #5) > This bug is for Mageia 5, not Mageia 6. Oh sorry i think the specs was the same. BTW. if the goal is to have just one spec the test in the 6 version need rewrite.
The goal is to get it to build, which it currently will not, and I didn't see any differences between the 5 and 6 specs that would change that, even though it built in 6. We're stumped.
Try to set MOZ_SMP_FLAGS (lines 307-314) to a minor value (2 or 4 maybe) If remeber well yesterday when i read the log (http://pkgsubmit.mageia.org/uploads/failure/5/core/updates_testing/20180413142204.luigiwalser.duvel.25073/log/firefox-52.7.3-2.mga5/build.0.20180413142311.log) -right now can't read) the value is set to 8 https://forums.gentoo.org/viewtopic-p-7907754.html?sid=5de1fdc938300c197bf436f902476dcd#7907754
It's already set to 2 on line 321: 318 %ifarch %{ix86} x86_64 ppc ppc64 ppc64le aarch64 319 [ -z "$RPM_BUILD_NCPUS" ] && \ 320 RPM_BUILD_NCPUS="`/usr/bin/getconf _NPROCESSORS_ONLN`" 321 [ "$RPM_BUILD_NCPUS" -ge 2 ] && MOZ_SMP_FLAGS=-j2 322 #[ "$RPM_BUILD_NCPUS" -ge 4 ] && MOZ_SMP_FLAGS=-j4 323 #[ "$RPM_BUILD_NCPUS" -ge 8 ] && MOZ_SMP_FLAGS=-j8 324 %endif
Status comment: (none) => Checked into SVN, won't build with OOM error
Mozilla has released Firefox 52.8.0 on May 9: https://www.mozilla.org/en-US/firefox/52.8.0/releasenotes/ Security fixes are listed here: https://www.mozilla.org/en-US/security/advisories/mfsa2018-12/ This brings also a rootcerts update (and nss rebuild) to 20180411, but it doesn't build in Cauldron (it builds fine in mga5): http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20180512202918.luigiwalser.duvel.46394/log/rootcerts-20180411.00-1.mga7/build.0.20180512203005.log
Summary: Firefox 52.7.3 => Firefox 52.8.0
Source RPM: nspr, firefox => rootcerts, nspr, firefox, firefox-l10n
Attempt to build Firefox beginning now. Aside from that, these are the packages: libnspr4-4.19-1.mga5 libnspr-devel-4.19-1.mga5 rootcerts-20180411.00-1.mga5 rootcerts-java-20180411.00-1.mga5 nss-3.28.6-1.4.mga5 nss-doc-3.28.6-1.4.mga5 libnss3-3.28.6-1.4.mga5 libnss-devel-3.28.6-1.4.mga5 libnss-static-devel-3.28.6-1.4.mga5 rootcerts-20180411.00-1.mga6 rootcerts-java-20180411.00-1.mga6 nss-3.28.6-1.4.mga6 nss-doc-3.28.6-1.4.mga6 libnss3-3.28.6-1.4.mga6 libnss-devel-3.28.6-1.4.mga6 libnss-static-devel-3.28.6-1.4.mga6 from SRPMS: nspr-4.19-1.mga5.src.rpm rootcerts-20180411.00-1.mga5.src.rpm nss-3.28.6-1.4.mga5.src.rpm rootcerts-20180411.00-1.mga6.src.rpm nss-3.28.6-1.4.mga6.src.rpm
Mageia 5 Firefox still fails to build: http://pkgsubmit.mageia.org/uploads/failure/5/core/updates_testing/20180513184935.luigiwalser.duvel.31426/log/firefox-52.8.0-1.mga5/build.0.20180513185009.log Mageia 6 update is in Bug 23031.
Mozilla has released Firefox 52.8.1 on June 6: https://www.mozilla.org/en-US/firefox/52.8.1/releasenotes/ Security fix is listed here: https://www.mozilla.org/en-US/security/advisories/mfsa2018-14/ Mageia 5 Firefox still fails to build: http://pkgsubmit.mageia.org/uploads/failure/5/core/updates_testing/20180608005544.luigiwalser.duvel.32408/log/firefox-52.8.1-1.mga5/build.0.20180608005610.log Mageia 6 update is in Bug 23150.
Summary: Firefox 52.8.0 => Firefox 52.8.1
Mozilla has released Firefox 52.9.0 on June 25: https://www.mozilla.org/en-US/firefox/52.9.0/releasenotes/ Security issues fixed: https://www.mozilla.org/en-US/security/advisories/mfsa2018-17/ Mageia 5 still failed to build; Mageia 6 update was in Bug 23233.
Summary: Firefox 52.8.1 => Firefox 52.9.0
Hi, What prevents from building is this error: "virtual memory exhausted: Operation not permitted". According to google, that error appears when building a software in 32 bits needs more memory than the system can address. A solution may be to decrease the value of _smp_ncpus_max in the SPEC file. I tried to build with _smp_ncpus_max set to 6 (the same value as for thunderbird) but it failed. I committed in SVN the value set to 4 but I cannot launch another build because the build succeeded for 64 bits so there are files in /uploads/done/5/core/updates_testing/. Do we need to ask a sysadmin to remove those files? Best regards, Nico.
CC: (none) => nicolas.salguero
(In reply to Nicolas Salguero from comment #15) > I committed in SVN the value set to 4 but I cannot launch another build > because the build succeeded for 64 bits so there are files in > /uploads/done/5/core/updates_testing/. Do we need to ask a sysadmin to > remove those files? Yes we do. You might need to e-mail their sysadmin mailing list directly as they have been completely unresponsive to these requests on IRC. Thanks!
CC: (none) => sysadmin-bugs
This does not even build with -j1 :/
CC: (none) => tmb
Thanks for trying Thomas. Do you think the differences in which libs we bundle between mga5 and mga6 could contribute to the different result in it building?
Closing as OLD, since Mga5 is really EOL now.
Resolution: (none) => OLDStatus: NEW => RESOLVED