[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Wheezy update of firefox-esr?



2016-09-25 1:08 GMT+02:00 Bálint Réczey <balint@balintreczey.hu>:
> Hi,
>
> 2016-09-24 15:34 GMT+02:00 Balint Reczey <balint@balintreczey.hu>:
>> Hi,
>>
>> On 09/24/2016 12:51 AM, Mike Hommey wrote:
>>> On Fri, Sep 23, 2016 at 07:57:45PM +0200, Bálint Réczey wrote:
>>>> Hi,
>>>>
>>>> 2016-09-20 23:43 GMT+02:00 Chris Lamb <lamby@debian.org>:
>>>>> Hello dear maintainer(s),
>>>>>
>>>>> the Debian LTS team would like to fix the security issues which are
>>>>> currently open in the Wheezy version of firefox-esr:
>>>>> https://security-tracker.debian.org/tracker/source-package/firefox-esr
>>>>>
>>>>> Would you like to take care of this yourself?
>>>>>
>>>>> If yes, please follow the workflow we have defined here:
>>>>> https://wiki.debian.org/LTS/Development
>>>>>
>>>>> If that workflow is a burden to you, feel free to just prepare an
>>>>> updated source package and send it to debian-lts@lists.debian.org
>>>>> (via a debdiff, or with an URL pointing to the source package,
>>>>> or even with a pointer to your packaging repository), and the members
>>>>> of the LTS team will take care of the rest. Indicate clearly whether you
>>>>> have tested the updated package or not.
>>>>>
>>>>> If you don't want to take care of this update, it's not a problem, we
>>>>> will do our best with your package. Just let us know whether you would
>>>>> like to review and/or test the updated package before it gets released.
>>>>>
>>>>> You can also opt-out from receiving future similar emails in your
>>>>> answer and then the LTS Team will take care of firefox-esr updates
>>>>> for the LTS releases. (In case we don't get any answer for months,
>>>>> we may also take it as an opt-out, too.)
>>>>
>>>> I think Mike would like the LTS Team to prepare the future updates:
>>>>
>>>> On Thu, Aug 04, 2016 at 06:32:14PM +0900, Mike Hommey wrote:
>>>>> On Thu, Aug 04, 2016 at 11:04:47AM +0200, Markus Koschany wrote:
>>>>>> Hello Mike,
>>>>>>
>>>>>> Thank you for preparing the security update of firefox-esr. I have just
>>>>>> sent a security announcement for your update in Wheezy to the
>>>>>> debian-lts-announce mailing list. If you want to take care of this next
>>>>>> time, please follow our guidelines which we have outlined at [1]. If
>>>>>> this is a burden for you, no problem, we will do our best and take care
>>>>>> of the rest. In this case we would like to ask you to send a short
>>>>>> reminder to debian-lts, so that we can prepare the announcement in a
>>>>>> timely manner.
>>>>>
>>>>> Heh, I hadn't realized that wasn't handled by standard DSAs, sorry about
>>>>> that. That these updates go through the same security-master doesn't
>>>>> help making it obvious they are different.
>>>>>
>>>>> Anyways, I'd rather not have more work to do, so if can send
>>>>> announcements, that works for me. Or you can deal with the backport
>>>>> from back to back.
>>>> ...
>>>>
>>>> I have added firefox-esr to lts-do-not-call and started preparing the update.
>>>
>>> Thanks.
>>
>> I have prepared the update.
>>
>> Please see the diff to jessie-security's version attached.
>>
>> Changes:
>>
>>  firefox-esr (45.4.0esr-1~deb7u1) wheezy-security; urgency=medium
>>  .
>>    [ Mike Hommey ]
>>    * New upstream release.
>>    * Fixes for mfsa2016-86, also known as:
>>      CVE-2016-5270, CVE-2016-5272, CVE-2016-5276, CVE-2016-5274,
>>      CVE-2016-5277, CVE-2016-5278, CVE-2016-5280, CVE-2016-5281,
>>      CVE-2016-5284, CVE-2016-5250, CVE-2016-5261, CVE-2016-5257.
>>  .
>>    * debian/control*, debian/rules: Compile with GCC 5 on testing/unstable
>>      on arm* because of crashes when building with GCC 6. (FTBFS)
>>    * debian/rules: Build with -fno-schedule-insns2 and
>>      -fno-delete-null-pointer-checks with GCC >= 6 because it miscompiles
>>      Firefox. Closes: #836533.
>>  .
>>    * config/gcc-stl-wrapper.template.h, memory/mozalloc/throw_gcc.h:
>>      Don't include mozalloc.h from the cstdlib wrapper. bz#1245076,
>> bz#1259537.
>>      Closes: #822715.
>>    * build/gyp.mozbuild: Disable libyuv assembly on mips64. (FTBFS)
>>
>>
>> The binary packages for amd64 are also available for testing here:
>>
>>  deb https://people.debian.org/~rbalint/ppa/wheezy-lts UNRELEASED/
>>
>> I ran browser benchmarks to stress test the package and also visited a
>> few sites manually.
>>
>> I plan uploading the package around 21:00 UTC.
>
> ARM builds are failing for the package due to looking for gcc-5 . :-(
>
> I'm fixing that shortly.

The fix for the regression is as simple as the following:

--- firefox-esr-45.4.0esr/debian/changelog    2016-09-24
15:24:57.000000000 +0200
+++ firefox-esr-45.4.0esr/debian/changelog    2016-09-25
01:18:27.000000000 +0200
@@ -1,3 +1,10 @@
+firefox-esr (45.4.0esr-1~deb7u2) wheezy-security; urgency=medium
+
+  [ Mike Hommey ]
+  * Only force GCC 5 on arm when building for stretch+
+
+ -- Balint Reczey <balint@balintreczey.hu>  Sun, 25 Sep 2016 01:18:23 +0200
+
 firefox-esr (45.4.0esr-1~deb7u1) wheezy-security; urgency=medium

   [ Mike Hommey ]
diff -Nru firefox-esr-45.4.0esr/debian/control.in
firefox-esr-45.4.0esr/debian/control.in
--- firefox-esr-45.4.0esr/debian/control.in    2016-09-21
00:29:05.000000000 +0200
+++ firefox-esr-45.4.0esr/debian/control.in    2016-09-25
01:19:06.000000000 +0200
@@ -9,7 +9,7 @@
                gcc-4.7,
                g++-4.7,
 %endif
-%if ! BACKPORT
+%if BACKPORT != wheezy && BACKPORT != jessie
                gcc-5 [armel armhf arm64],
                g++-5 [armel armhf arm64],
 %endif
diff -Nru firefox-esr-45.4.0esr/debian/rules firefox-esr-45.4.0esr/debian/rules
--- firefox-esr-45.4.0esr/debian/rules    2016-09-21 00:29:05.000000000 +0200
+++ firefox-esr-45.4.0esr/debian/rules    2016-09-25 01:24:27.000000000 +0200
@@ -28,9 +28,11 @@
 endif
 # Building with GCC 6 leads to crashes on arm*.
 ifneq (,$(filter arm%,$(DEB_BUILD_ARCH)))
+ifeq (,$(filter $(BACKPORT),wheezy jessie))
 CC := gcc-5
 CXX := g++-5
 endif
+endif

 OFFICIAL_BRANDING := browser/branding/official
 MOZILLA_OFFICIAL := 1

I'm waiting for the armhf build to finish (which is slow) and will
send out the DLA and the
regression update in the morning.

Sorry for the inconvenience.

Thanks,
Balint


Reply to: