[opensuse-factory] Moving Firefox to a faster 4-week release cycle - can we get a different name for the ESR release, please?
Hi there,
with Mozilla jumping the gun:
https://blog.mozilla.org/futurereleases/2019/09/17/moving-firefox-to-a-faster-4-week-release-cycle/
_I_ really doubt this will be working out well. Trouble is, we cannot decide on a package _name_ basis, which one to install. Currently we have (according to https://download.opensuse.org/repositories/mozilla/openSUSE_Tumbleweed/x86_64/):
- MozillaFirefox-68.1.0-7.1.x86_64.rpm (which is *ESR*) - MozillaFirefox-69.0-6.1.x86_64.rpm (which is *not* _ESR_)
According to rpm's versioning idea, it would up(date,grade) an ESR installation to a _non_ ESR installation. While this might not be a burning issue with Tumbleweed (as there is _no_ ESR for Tumbleweed due to the identical package name topic), and also since there is no official ESR version for Tumbleweed at all, considering Tumbleweed for a distribution aimed to be usable on a daily basis, MozillaFirefox should remain stable - which I honestly doubt for a "4 week release cycle", and this is why I post this e-mail here.
@Wolfgang: what do you think about this upcoming challenge?
TIA, cheers.
l8er manfred
Hi,
Am 18.09.19 um 15:28 schrieb Manfred Hollstein:
with Mozilla jumping the gun:
https://blog.mozilla.org/futurereleases/2019/09/17/moving-firefox-to-a-faster-4-week-release-cycle/
_I_ really doubt this will be working out well. Trouble is, we cannot decide on a package _name_ basis, which one to install. Currently we have (according to https://download.opensuse.org/repositories/mozilla/openSUSE_Tumbleweed/x86_64/):
- MozillaFirefox-68.1.0-7.1.x86_64.rpm (which is *ESR*)
- MozillaFirefox-69.0-6.1.x86_64.rpm (which is *not* _ESR_)
According to rpm's versioning idea, it would up(date,grade) an ESR installation to a _non_ ESR installation. While this might not be a burning issue with Tumbleweed (as there is _no_ ESR for Tumbleweed due to the identical package name topic), and also since there is no official ESR version for Tumbleweed at all, considering Tumbleweed for a distribution aimed to be usable on a daily basis, MozillaFirefox should remain stable - which I honestly doubt for a "4 week release cycle", and this is why I post this e-mail here.
@Wolfgang: what do you think about this upcoming challenge?
So yes this puts additional workload on us I think. There are not so many options though. My very quick opinion is that Tumbleweed should still stay on the regular release also with 4 week cycles. The amount of changes within a cycle will go down so I do not see that much of a bigger risk. There is actually a problem I see upcoming which is support of 2nd-tier platforms for Factory/Tumbleweed. Just now with the 68.1 and 69.0 releases we have put back (aka synced up with SLE patches) to support the platforms supported with SLE. In that pace I fear that at least I won't be able to make sure platform support stays intact.
So what could (and probably should) be discussed is if we need a Factory/TW version of ESR. In that case with a different package name. In the mozilla repo I used to provide a few years ago an alternative package called firefox-esr where it was easy to switch between the different streams. This is an option to do for Factory/Tumbleweed as well. This will give users the choice which variant to run but on the other hand it's again a bit more work. While not that much because I'm preparing both versions anyway in the mozilla repo. It would just be another package name.
So overall I still think it's feasible to achieve but it will cause (at least) a bit more work and I'm curious about opinions if we want to have an official ESR option in Tumbleweed.
Wolfgang
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
<snip>
On Wed, 2019-09-18 at 17:15 +0200, Wolfgang Rosenauer wrote:
I'm curious about opinions if we want to have an official ESR option in Tumbleweed.
/me raises his hand.
The browser has become a critical component of daily work, and while I'm all for the rolling nature of Tumbleweed, it's my observation that enforcing a short release cadence allows more bugs to seep through. (Please put the flames in a separate thread).
In other words, if Firefox is moving to a 4-week release cadence, I'd like to move to ESR.
- -- James Mason Technical Architect, Public Cloud openSUSE Member SUSE jmason@suse.com
Am Mittwoch, 18. September 2019, 17:15:43 CEST schrieb Wolfgang Rosenauer:
So what could (and probably should) be discussed is if we need a Factory/TW version of ESR. In that case with a different package name. In the mozilla repo I used to provide a few years ago an alternative package called firefox-esr where it was easy to switch between the different streams. This is an option to do for Factory/Tumbleweed as well. This will give users the choice which variant to run but on the other hand it's again a bit more work. While not that much because I'm preparing both versions anyway in the mozilla repo. It would just be another package name.
So overall I still think it's feasible to achieve but it will cause (at least) a bit more work and I'm curious about opinions if we want to have an official ESR option in Tumbleweed.
Given, that 69.0 regresses in several ways for me here, a firefox-esr version for Factory is definitely a good idea and worth the hassle.
Firefox 68.1 fixed a 13 years old bug for me. In letters: thirteen!
https://bugzilla.mozilla.org/show_bug.cgi?id=372650
And 69.0 messed it all up again :-(. Neither desktop not window position are remembered correctly across sessions. Given, that my usual setup consists from about 60 windows, it's no fun at all.
And a new one: it cannot access my Fritz!Box 6490 Cable router anymore.
Beim Verbinden mit 172.16.x.y:zzzzz trat ein Fehler auf. Eine Verwendung des Zertifikatschlüssels ist für den versuchten Arbeitsschritt unpassend. Fehlercode: SEC_ERROR_INADEQUATE_KEY_USAGE
There exist 2 ways to access this thing, either per ip address, as above, or with a dyndns address (from selfhost.de). The FB created a certificate for the latter, but since it is a self signed cert, one have to add an exception anyway.
I tried to: * restart the FB * lower the security settings * disable validation on OCSP server (whatever that is) * check about:config security settings * remove any related certs * access a dozen other FB and Lancom routers
It's just this single FB, that is misbehaving out of the blue. 68.1 was fine. Hrmpf.
Needless to say, apart from the usual Google obstacles (it won't remember any passwords for unsave sites), Chromium does work with this FB of course!
I don't see any changelog entry in 69.0.1 of mozilla:Factory, that might address this issue.
Pete
Am Sonntag, 22. September 2019, 15:33:50 CEST schrieb Hans-Peter Jansen:
Am Mittwoch, 18. September 2019, 17:15:43 CEST schrieb Wolfgang Rosenauer:
So what could (and probably should) be discussed is if we need a Factory/TW version of ESR.
Given, that 69.0 regresses in several ways for me here, a firefox-esr version for Factory is definitely a good idea and worth the hassle.
After reverting to MozillaFirefox-68.1.0 and restoring the related profile¹, both mentioned issues disappeared. I was even able to restore the latest session from 69.0 in 68.1.0.
Given these facts, I vote for a more conservative FF upgrade approach for TW generally in the future. I interpret this release cycle change as: let users beta test it. Interestingly, this move correlates with significant changes in the developer guild of FF. Mozilla management should check, if the new head isn't payed from Google already...
Could somebody point me to a forum, where these issues better fit, please.
Cheers, Pete
¹) That's an severe issue for providing both versions. Attempting to use a downgraded FF with the same profile will *force* the user to create a *new* profile. I've learned now, that FF remembers the latest version in compatibility.ini:LastVersion.
On 23/09/2019 15:51, Hans-Peter Jansen wrote:
Am Sonntag, 22. September 2019, 15:33:50 CEST schrieb Hans-Peter Jansen:
Am Mittwoch, 18. September 2019, 17:15:43 CEST schrieb Wolfgang Rosenauer:
So what could (and probably should) be discussed is if we need a Factory/TW version of ESR.
Given, that 69.0 regresses in several ways for me here, a firefox-esr version for Factory is definitely a good idea and worth the hassle.
After reverting to MozillaFirefox-68.1.0 and restoring the related profile¹, both mentioned issues disappeared. I was even able to restore the latest session from 69.0 in 68.1.0.
Given these facts, I vote for a more conservative FF upgrade approach for TW generally in the future. I interpret this release cycle change as: let users beta test it. Interestingly, this move correlates with significant changes in the developer guild of FF. Mozilla management should check, if the new head isn't payed from Google already...
Could somebody point me to a forum, where these issues better fit, please.
Perhaps (in FF): hamburger button -> Help -> Submit feedback?
It says:
If you're looking to provide general feedback to Mozilla then continue below
Cheers, Pete
¹) That's an severe issue for providing both versions. Attempting to use a downgraded FF with the same profile will *force* the user to create a *new* profile. I've learned now, that FF remembers the latest version in compatibility.ini:LastVersion.
Hi,
Am 23.09.19 um 15:51 schrieb Hans-Peter Jansen:
Am Sonntag, 22. September 2019, 15:33:50 CEST schrieb Hans-Peter Jansen:
Am Mittwoch, 18. September 2019, 17:15:43 CEST schrieb Wolfgang Rosenauer:
So what could (and probably should) be discussed is if we need a Factory/TW version of ESR.
Given, that 69.0 regresses in several ways for me here, a firefox-esr version for Factory is definitely a good idea and worth the hassle.
After reverting to MozillaFirefox-68.1.0 and restoring the related profile¹, both mentioned issues disappeared. I was even able to restore the latest session from 69.0 in 68.1.0.
Given these facts, I vote for a more conservative FF upgrade approach for TW generally in the future. I interpret this release cycle change as: let users beta test it. Interestingly, this move correlates with significant changes in the developer guild of FF. Mozilla management should check, if the new head isn't payed from Google already...
Could somebody point me to a forum, where these issues better fit, please.
Cheers, Pete
¹) That's an severe issue for providing both versions. Attempting to use a downgraded FF with the same profile will *force* the user to create a *new* profile. I've learned now, that FF remembers the latest version in compatibility.ini:LastVersion.
as result of this discussion and because I always had these plans but never enough pressure so far I'm currently preparing a firefox-esr package which can be installed in parallel to the regular MozillaFirefox package. With the new profile handling introduced in Firefox 67 this was finally not too hard anymore and I seem to have covered almost everything meanwhile.
If people are interested in testing this there are currently builds running in the mozilla OBS repository. Once finished you will find a new package firefox-esr-68.1.0* there (MozillaFirefox-68.1.0* will disappear) to test also for Leap.
Please note that you most likely need to install firefox-esr-branding-upstream along because there is no firefox-esr-branding-openSUSE available yet. Apart from that and very few modifications missing from the branding package I'm pretty confident that this will already work to a certain extent and I'm looking for your feedback.
I still would like to have the regular release as default in Tumbleweed but this will give people the choice.
Wolfgang
Am Donnerstag, 3. Oktober 2019, 23:12:28 CEST schrieb Wolfgang Rosenauer:
Hi,
Once finished you will find a new package firefox-esr-68.1.0* there (MozillaFirefox-68.1.0* will disappear) to test also for Leap.
I still would like to have the regular release as default in Tumbleweed but this will give people the choice.
Excellent Wolfgang, much appreciated.
With this move, I will be able to get rid of this little annoyance:
2 Problems: Problem: problem with installed package MozillaFirefox-68.1.0-1.3.x86_64 Problem: problem with installed package MozillaFirefox-translations- common-68.1.0-1.3.x86_64
Problem: problem with installed package MozillaFirefox-68.1.0-1.3.x86_64 Solution 1: install MozillaFirefox-69.0.1-1.1.x86_64 (with vendor change) obs://build.opensuse.org/mozilla --> openSUSE Solution 2: keep obsolete MozillaFirefox-68.1.0-1.3.x86_64
Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c/d/?] (c): 2 Applying solution 2
Problem: problem with installed package MozillaFirefox-translations- common-68.1.0-1.3.x86_64 Solution 1: install MozillaFirefox-translations-common-69.0.1-1.1.x86_64 (with vendor change) obs://build.opensuse.org/mozilla --> openSUSE Solution 2: keep obsolete MozillaFirefox-translations- common-68.1.0-1.3.x86_64
Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c/d/?] (c): 2 Applying solution 2
I'm traveling for a week, but will try to test your build tomorrow briefly.
Given the overwhelming popularity of Firefox in our community, this makes perfect sense. Would be interesting, which kind will be more popular, after things settled for a while.
Thanks, you made my day... Pete
Am Freitag, 4. Oktober 2019, 00:57:20 CEST schrieb Hans-Peter Jansen:
Am Donnerstag, 3. Oktober 2019, 23:12:28 CEST schrieb Wolfgang Rosenauer:
Hi,
Once finished you will find a new package firefox-esr-68.1.0* there (MozillaFirefox-68.1.0* will disappear) to test also for Leap.
I still would like to have the regular release as default in Tumbleweed but this will give people the choice.
What about using an update-alternatives group to provide /usr/bin/firefox? Would need a new name for the current master firefox, e.g. /usr/bin/firefox-69 and than:
in firefox-esr: update-alternatives --install /usr/bin/firefox firefox /usr/bin/firefox-esr 25
in MozillaFirefox: update-alternatives --install /usr/bin/firefox firefox /usr/bin/firefox-69 30
That way, any Firefox installation would give a /usr/bin/firefox, and prefers the current one if both are installed. It needs some fiddling in %post to deal with /usr/bin/firefox not being part of an update-alternatives group before.
Cheers, Pete
Am 04.10.19 um 17:19 schrieb Hans-Peter Jansen:
Am Freitag, 4. Oktober 2019, 00:57:20 CEST schrieb Hans-Peter Jansen:
Am Donnerstag, 3. Oktober 2019, 23:12:28 CEST schrieb Wolfgang Rosenauer:
Hi,
Once finished you will find a new package firefox-esr-68.1.0* there (MozillaFirefox-68.1.0* will disappear) to test also for Leap.
I still would like to have the regular release as default in Tumbleweed but this will give people the choice.
What about using an update-alternatives group to provide /usr/bin/firefox? Would need a new name for the current master firefox, e.g. /usr/bin/firefox-69 and than:
in firefox-esr: update-alternatives --install /usr/bin/firefox firefox /usr/bin/firefox-esr 25
in MozillaFirefox: update-alternatives --install /usr/bin/firefox firefox /usr/bin/firefox-69 30
That way, any Firefox installation would give a /usr/bin/firefox, and prefers the current one if both are installed. It needs some fiddling in %post to deal with /usr/bin/firefox not being part of an update-alternatives group before.
I'm not sure how update-alternatives should be a good choice here. I think it's totally fine to have firefox and firefox-esr both having a desktop file and a menu entry. I'm not planning on allowing even more parallel versions anyway but probably I'm missing the advantage here.
Wolfgang
Am Freitag, 4. Oktober 2019, 20:43:43 CEST schrieb Wolfgang Rosenauer:
I'm not sure how update-alternatives should be a good choice here. I think it's totally fine to have firefox and firefox-esr both having a desktop file and a menu entry.
Yes, won't argue against that.
I'm not planning on allowing even more parallel versions anyway but probably I'm missing the advantage here.
The advantage is about choice. There's one /usr/bin/firefox, that's the default, and power users are able to choose the default between the two (or even more: e.g. firefox68, firefox69, firefox70). Hence this scheme would provide real extra value with very little cost.
With the current scheme, firefox-esr is always the second citizen, programs looking for /usr/bin/firefox may fail (if firefox{69} isn't installed), or may even start the wrong one... Since firefox is very picky with the profiles, that isn't always fun (e.g. there's an upgrade, but no downgrade path for existing profiles).
update-alternatives was created to not force the user into a certain decision, that was done deliberately from somebody else (you!).
Playing games with symlinks in /usr/local/bin and $PATH priorities, are so 90ies..
BTW, switching to firefox-esr was fine:
zypper in firefox-esr # will create a new profile zypper rm MozillaFirefox # to keep the last 68 profile, just stop it, and copy it over cd ~/.mozilla/firefox cp -a xxxxxxxx.default-1515499617867/* yyyyyyyyy.default-esr68/
# and I did as root: update-alternatives --install /usr/bin/firefox firefox /usr/bin/firefox-esr 25
All looks good, thanks.
Cheers, Pete
Hi,
On 10/4/19 11:28 PM, Hans-Peter Jansen wrote:
The advantage is about choice. There's one /usr/bin/firefox, that's the default, and power users are able to choose the default between the two (or even more: e.g. firefox68, firefox69, firefox70). Hence this scheme would provide real extra value with very little cost.
At any time, there are exactly two Firefox versions that have all the necessary security updates:
1. current Firefox 2. current Firefox ESR
The additional choice you want really is not an advantage, all you get is more people running an insecure browser.
Literally all Firefox updates have 10 or more security fixes, usually with 2 or more rated "critical" by Mozilla.
Stefan.
-
Hans-Peter Jansen -
James Mason -
Manfred Hollstein -
Oleksii Vilchanskyi -
Stefan Knorr -
Wolfgang Rosenauer