Why is Fx 57 in Updates Testing?

Was this on purpose? Fx 57 is BETA, and I was under the impression that
BETA software was for RAWHIDE.

Yes, I understand there is an annotation NOT to push Fx 57 to stable - but
I thought that was the purpose of updates testing... software there is
intended to be tested and pushed to stable.

There are many extensions which aren't yet available for Fx 57 - and we're
effectively moving up the timetable by putting it in updates testing.


Re: Why is Fx 57 in Updates Testing?

By Richard W.M. Jones at 10/12/2017 - 04:08

In practical terms, FF57 disables all extensions.

I had forgotten how unusable the web has become without NoScript ...

Anyway, I wouldn't advise anyone else to update to this version
if you use extensions at all.


Re: Why is Fx 57 in Updates Testing?

By Kevin Fenzi at 10/12/2017 - 12:05

On 10/12/2017 01:08 AM, Richard W.M. Jones wrote:
I think thats a bit overstated. I'm running FF57 here with a bunch of
extensions that work with it.

It's true that a number of older extensions will not work.

One thing to look at is to go to the extensions home page and look at
the very bottom and see if it has a developer channel. Enabling that
will sometimes give you a webextension supported version.

Might give uMatrix a try?

Indeed, but note that you might want to upgrade and check your
extensions and see what your state is before Nov...


Re: Why is Fx 57 in Updates Testing?

By Richard W.M. Jones at 10/12/2017 - 14:54

On Thu, Oct 12, 2017 at 09:05:33AM -0700, Kevin Fenzi wrote:
Well, looking at the most popular extensions:

<a href="" title=""></a>

hardly any of them are parked as "compatible with firefox 57+".
I'm counting 5/20 on the first page linked there, and 4/20
on the first page of the highest rated extensions.

So I stand by my slightly modified claim that installing this update
will disable most of your extensions.


Re: Why is Fx 57 in Updates Testing?

By John Florian at 10/12/2017 - 17:48

On Thu, 2017-10-12 at 19:54 +0100, Richard W.M. Jones wrote:
I think you might be surprised how many *new* WebExtension alternatives
are available, but they are not yet popular when competing against the
*old* standbys. IMHO, Mozilla could have done better with epoch
weighting, displaying the legacy tags far earlier -- those are really
quite recent. I was also annoyed that I couldn't easily limit my
search for non-legacy extensions when using firefox < 57.

I learned about this incompatibility while dealing with an unrelated
issue in VimFx several months ago and was sad to learn that extension
would not be ported given the differences and the amount of time it
would require. I began a panic search for replacements because of how
utterly dependent I am on some. I think many popular extensions are
going to fall into this category if they're not backed by companies or
enthusiasts with lots of time.

So I'm happily testing from u-t now so I can convince myself everything
is going to be alright. I'm not going to judge whether this via u-t
was correct or not; I've heard great arguments while perched atop of
the fence.

Re: Why is Fx 57 in Updates Testing?

By Tom Hughes at 10/12/2017 - 17:57

On 12/10/17 22:48, John Florian wrote:
I have been actively looking for replacements for the various extensions
that I use for the last couple of releases and so far only about 50% or
so have anything even vaguely equivalent with only weeks left to be
before the extensionpocalypse hits.

The biggest issues are NoScript (which is supposedly coming) and Cookie
Monster (which seems to be hopeless) but there are plenty of others.


Re: Why is Fx 57 in Updates Testing?

By Adam Williamson at 10/12/2017 - 18:01

On Thu, 2017-10-12 at 22:57 +0100, Tom Hughes wrote:
As someone else mentioned, uMatrix is an alternative (in many ways
superior) to Noscript, and seems to have a web extension version

Re: Why is Fx 57 in Updates Testing?

By stan at 10/12/2017 - 14:22

On Thu, 12 Oct 2017 09:05:33 -0700

I agree with this. I run nightly in addition to the fedora version of
firefox, and I have found that some of my dearly loved extensions have
new versions. And where not, someone has often written a replacement
for the new interface. I found such extensions by searching in the
add-ons pages at Mozilla. My main lack is that I haven't found a
replacement for antvideodownloader or dwhelper yet (video downloaders).

That said, from reading Mozilla forums, it seems that the new web
extension interface is more restricted than the XUL interface it is
replacing, and certain functionality can't be replaced. Which means
that some current XUL extensions can never be recreated as a web
extension. The reason this was done is to enhance security. So, it is
the old trade-off; security versus ease of use.

I don't understand the losses well enough to know whether some of the
things I like to do in firefox with extensions can be replicated or
not. I've thought about keeping an older version of firefox around
that can use the old extensions for special cases.

Mozilla has been warning about this for over a year in their
development version (nightly), so it shouldn't come as a surprise.

Re: Why is Fx 57 in Updates Testing?

By Adam Williamson at 10/12/2017 - 15:02

On Thu, 2017-10-12 at 11:22 -0700, stan wrote:
For me at least, it is a surprise. I had not heard about this until
this mailing list thread.

I'm sure it's not a surprise for people who are specifically interested
in Mozilla / Firefox news; it does seem to have been discussed there
for a long them. But I'm not. I just use Firefox. I don't run betas, I
don't run nightlies, I don't read Firefox-specific news sites etc. I
doubt I'm particularly unusual among Fedora users.

Re: Why is Fx 57 in Updates Testing?

By Dominik 'Rathan... at 10/12/2017 - 04:48

On Thursday, 12 October 2017 at 10:08, Richard W.M. Jones wrote:
Have you tested with the latest noscript? 5.1.1 claims to support Fx57
and is in updates-testing, too.


Re: Why is Fx 57 in Updates Testing?

By Richard W.M. Jones at 10/12/2017 - 04:56

On Thu, Oct 12, 2017 at 10:48:45AM +0200, Dominik 'Rathann' Mierzejewski wrote:
I didn't even know we shipped extensions in Fedora.

I installed mozilla-noscript-5.1.1-1.fc28.noarch and restarted firefox
but it doesn't make any difference. NoScript still shows up as a
"Legacy" extension and isn't working.

Is there something you're supposed to do to enable it?


Re: Why is Fx 57 in Updates Testing?

By Dominik 'Rathan... at 10/12/2017 - 05:04

On Thursday, 12 October 2017 at 10:56, Richard W.M. Jones wrote:
We do and it's a convenient way to have an extension installed for all
users at once.

The about:config switch doesn't work in beta/release versions, as you
have discovered already. I'll update to 5.1.2 in F27 as soon as it's


Re: Why is Fx 57 in Updates Testing?

By Martin Stransky at 10/12/2017 - 04:53

On 10/12/2017 10:48 AM, Dominik 'Rathann' Mierzejewski wrote:
There's also "extensions.legacy.enabled" pref at about:config which can
be flipped:

<a href="" title=""></a>


Re: Why is Fx 57 in Updates Testing?

By Richard W.M. Jones at 10/12/2017 - 04:57

On Thu, Oct 12, 2017 at 10:53:18AM +0200, Martin Stransky wrote:
It doesn't work in our version of Firefox.

Something to do with whether Firefox is built as a developer
version or a beta version.


Re: Why is Fx 57 in Updates Testing?

By Martin Stransky at 10/11/2017 - 10:38

On 10/11/2017 03:17 PM, Gerald B. Cox wrote:
To be clear here, my intention was to enable early testing of new
Firefox 57 release which also includes the CSD patch [1].

If there's no interest for such package I'll pull that out and you can
expect regular FF57 update when the time comes. Please speak out at #BZ [2].

And no, I'm not going to create COPR builds for that - it does not
contain required NSS/NSPR packages and building from git is broken.


[1] <a href="" title=""></a>
[2] <a href="" title=""></a>

Re: Why is Fx 57 in Updates Testing?

By =?UTF-8?Q?Mat=C... at 10/11/2017 - 17:12

On 2017-10-11, 14:38 GMT, Martin Stransky wrote:
I don’t think I want to get immersed into merit of this
discussion, but let me just note that:

a) there is no problem to build NSS/NSPR packages in COPR as

b) it is possible to build package in COPR from ANY URL of
SRPM, which means it could be as well SRPM in koji.

Just my €0.02.


Re: Why is Fx 57 in Updates Testing?

By Martin Stransky at 10/11/2017 - 09:32

On 10/11/2017 03:17 PM, Gerald B. Cox wrote:
It's going to be stable in one month. Fx 57 release date is 2017-11-14.

I expect the testing repo is used by experienced users who wish to test
software planned for Fedora thus I don't see any problem here.

Do you think it's better when it suddenly appears on stable at
2017-11-14? I do not.


Re: Why is Fx 57 in Updates Testing?

By Gerald B. Cox at 10/11/2017 - 10:47

On Wed, Oct 11, 2017 at 6:32 AM, Martin Stransky < ... at redhat dot com>

And? My point was that Fx 57 isn't stable now, it's BETA.

It is my understanding that is the purpose of RAWHIDE. updates-testing is
for software that is intended to be pushed to stable. It isn't for BETA

Well, if people want to test, they can use Nightly or RAWHIDE. If people
start placing BETA software in updates-testing, why do we need

Re: Why is Fx 57 in Updates Testing?

By Tomasz Torcz at 10/11/2017 - 09:52

On Wed, Oct 11, 2017 at 03:32:07PM +0200, Martin Stransky wrote:
It's *updates*-testing repo and software in it should not be 'planned',
but basically 'ready' for Fedora.
If you want testing repo for experienced users, use COPR.

Re: Why is Fx 57 in Updates Testing?

By Martin Stransky at 10/11/2017 - 10:00

On 10/11/2017 03:52 PM, Tomasz Torcz wrote:
I don't see it that way. Is that your personal statement or is that
written in any Fedora rules? I don't see that at Fedora page [1].

Also, the COPR suffers from some drawbacks - can't easily build from
Fedora or other git repo [2].


[1] <a href="" title=""></a>
[2] I know it's supposed to work but the work flow is somehow
complicated and uneasy and it's broken from time to time (actually right

Re: Why is Fx 57 in Updates Testing?

By Gerald B. Cox at 10/11/2017 - 10:53

On Wed, Oct 11, 2017 at 7:00 AM, Martin Stransky < ... at redhat dot com>

Martin, this is what is stated at the very top of the doc you referenced:
"The *updates-testing* repository
<>, also
referred to as *Test Updates*, contains updates scheduled to be released
for Branched <>
pre-releases (after the Bodhi enabling point
<>) and stable
releases of Fedora. User testing and feedback provided via Bodhi
<>, on the test
<> mailing list and
the relevant Bugzilla <> is vital to ensure that
good updates are released quickly and bad ones kept away from release."

By definition BETA software is never intended to be pushed to stable. Fx
57 is BETA. When the STABLE version is released, then it can go into
updates-testing. Not before. Again, that is the purpose of RAWHIDE.

Re: Why is Fx 57 in Updates Testing?

By Emmanuel Seyman at 10/11/2017 - 13:13

* Gerald B. Cox [11/10/2017 07:53] :
We've sometimes pushed beta versions of software, usually when that version is
more stable than the previous stable release.

I'm all for enforcing rules on what goes to the updates and updates-testing
repos but I'ld be happier if they went through the proper channels (FESCo/FPC)
rather than made up on the fly.


Re: Why is Fx 57 in Updates Testing?

By Heiko Adams at 10/11/2017 - 13:04

Am Mittwoch, den 11.10.2017, 07:53 -0700 schrieb Gerald B. Cox:

Re: Why is Fx 57 in Updates Testing?

By Gerald B. Cox at 10/11/2017 - 13:26

As Adam mentioned apparently this isn't the "Official Policy".

My opinion however is common sense dictates that you don't put anything in
updates-testing unless you intend to push that software to stable. If you
want people to test out experimental software, put it in RAWHIDE. If it's
a git-snapshot and your INTENT is to push it to stable (for example, you're
fixing a bug) then that is OK for updates-testing.

In this instance, there is no intent to push Fx 57 BETA to stable. That's
why it does't belong in update-testing.

Re: Why is Fx 57 in Updates Testing?

By Martin Stransky at 10/11/2017 - 15:08

On 10/11/2017 07:26 PM, Gerald B. Cox wrote:
I think there's a bit misunderstanding here. Some parts of the FF57
update are going to be in stable as is (if the testing goes well). That
includes the CSD patch [1].

The package may not be finished yet but the FF57 is almost done
and 99% of the code is going to be shipped to stable. This is not a
completely different version, it may got some bugfixes but what you see
is what you will almost get as stable update at Nov 14.

I'm sure the package is almost done so I don't take your argument about
"completely different" package.

Due to the radical change in extension handlings and also needs to test
the CSD patch [1] which I'd like to include in stable package I decided
to put the FF57 to testing as early as possible. This is really a
special case.

I believed that the update-testing repository is intended for testing
and it's used by power users who can handle that, exclude the package
from testing if needed, downgrade broken package and so on.

I'm surprised that people use updates-testing for stable/production
machines, have problem with handling the update and act like newbies. If
you can't handle that, don't use that. Fedora is really a bleeding edge
so don't complain you get new software with new features - even as
testing only :)

Also, I think your expectation about dramatic change of new extension
availability for FF57 last month before the final release is false.


[1] <a href="" title=""></a>

Re: Why is Fx 57 in Updates Testing?

By Felix Schwarz at 10/12/2017 - 04:44

Am 11.10.2017 um 21:08 schrieb Martin Stransky:
"dramatic change" seems a bit ... dramatic ;-)
However I know at least one somewhat popular addon (NoScript) which is planned
to have a release just before the Firefox 27 release
(<a href="" title=""></a>). So the push to F26 updates-testing really
hurts some users more than necessary.

Other than that I think Fedora maintainers worked hard to get away from the
perception of "unstable/bleeding edge distro" to a more "provides new software
but still reliable".

I think this is not about "having updates-testing enabled and not being able
to handle breakage" - in the end all the complaints came from users who can
"handle" the breakage. I'd like to echo other's concerns that I treat
"updates-testing" very similar to "updates" just with the additional caveat
that it might be a tad bit less tested.

Please let's keep it that way.


Re: Why is Fx 57 in Updates Testing?

By Dominik 'Rathan... at 10/12/2017 - 04:56

On Thursday, 12 October 2017 at 10:44, Felix Schwarz wrote:
NoScript developers offer this useful tip on the page you linked:

IMPORTANT: if you're using Firefox 57 you'll need to open about:config
and turn the extensions.legacy.enabled preference to true, otherwise
the browser will refuse to install Noscript.
Furthermore, you need a "blueish" Firefox, either Firefox Developer
Edition or Nightly. The preference trick doesn't work in "orange"
Firefox (beta/release). NoScript is currently a Hybrid WebExtension,
and therefore won't install on Firefox 57 pre-releases without this
trick. Before Firefox 57 is released in the stable channel, a pure
WebExtension NoScript will be available an you'll be automatically
migrated to it.

This indeed means the release in Fedora should be coordinated at least
with all Firefox extensions package mainainers. Martin, have you
contacted all the extension maintainers directly to coordinate? If not,
please do so now.


Re: Why is Fx 57 in Updates Testing?

By Gerald B. Cox at 10/11/2017 - 20:13

On Wed, Oct 11, 2017 at 12:08 PM, Martin Stransky < ... at redhat dot com>

i have no doubt when this whole situation is reviewed logical minds will
prevail, but in the meantime you've taken advantage of a loophole.

Re: Why is Fx 57 in Updates Testing?

By Adam Williamson at 10/11/2017 - 20:36

On Wed, 2017-10-11 at 17:13 -0700, Gerald B. Cox wrote:
I think you're getting a bit needlessly confrontational at this point.
The issue's been sufficiently well raised now. Let's try to move
forward productively from here...

Re: Why is Fx 57 in Updates Testing?

By Gerald B. Cox at 10/11/2017 - 20:53

On Wed, Oct 11, 2017 at 5:36 PM, Adam Williamson < ... at fedoraproject dot org

Exactly what is confrontational? I quoted his statement. Yes, the issue
has been raised.
Martin is apparently going to keep it in updates-testing because that's
what he wants to do.
It may or may not be reviewed - and he took advantage of a loophole. Since
when is in confrontational to summarize

Re: Why is Fx 57 in Updates Testing?

By Stephen John Smoogen at 10/11/2017 - 15:42

On 11 October 2017 at 15:08, Martin Stransky < ... at redhat dot com> wrote:
There are several misunderstandings here but they all stem from a core
problem which an old Mozilla quote covers:

Surprise is the opposite of engagement. [1]

It is something we forget a lot.. but is a reason why older
maintainers of XYZ software (Mozilla, X11, gcc, kernel, etc) would
make sure that a heads up email about a major version change goes out.

If you put out a heads up that "tomorrow I will be pushing Firefox
57BETA into updates-testing" you could have given people heads up and
would have also learned from someone that updates-testing is on for
everyone in the post-branch world. While in this case it probably
would not have affected your decision, in other cases it might have
made it clearer that you needed to do so after a different time. It
would have also queued in people to either skip updates or know why
their workflow died.

In either case, people would be better informed.

[1] <a href="" title=""></a>

Re: Why is Fx 57 in Updates Testing?

By Martin Stransky at 10/12/2017 - 02:23


I agree with you here, I should post the head up. I agree I
underestimated that and I'm sorry for it.


Re: Why is Fx 57 in Updates Testing?

By Adam Williamson at 10/11/2017 - 15:52

On Wed, 2017-10-11 at 15:42 -0400, Stephen John Smoogen wrote:
Agreed. It is true that in general people using updates-testing should
more or less know what they're doing, but they're not necessarily
expecting surprises like this. And as smooge says, updates-testing is
enabled by default in Branched releases (so, F27 at present); anyone
running F27 Beta will get this package as soon as it reaches the

I think Harald really has a point that the potentially disruptive
nature of the changes in 57 should mean that, if anything, we go
*slower* in pushing it out to our users, not *faster*. Unless it
includes vital security fixes we can't backport, I don't think there's
necessarily a reason we need to jump all over this and try to get it
out on release day; why not wait a bit while providing a way for early
adopters to try it out if they'd like to?

Note that there is an alternative to both u-t and COPR; you can do
scratch builds in Koji, or do real builds but don't actually submit
them to updates-testing , and either provide a repo with those builds
yourself, or just write a blog post or something explaining which
packages people should pull from Koji if they want to test...

Re: Why is Fx 57 in Updates Testing?

By Zbigniew =?utf-... at 10/11/2017 - 16:58

On Wed, Oct 11, 2017 at 12:52:11PM -0700, Adam Williamson wrote:
OTOH, let's consider two points: one, FF57 is disruptive, and two,
FF57 will be released as an update in Fedora when Mozilla make the
release, as specified by our policy for FF updates. In the light of
this, it seems reasonable to push FF57 to updates-testing right now,
the sooner the better.

I don't get the whole kerfuffle about FF57 being beta: F27 is in beta
now too, and it's the time to test what will be in the relased version,
and using a pre-release of a package seems to be a better way to do
this than using some old version that will be soon replaced.
If we had a different updates policy for Firefox in Fedora, things
would be different, but we don't.


Re: Why is Fx 57 in Updates Testing?

By Till Hofmann at 10/12/2017 - 05:22

On 10/11/2017 10:58 PM, Zbigniew Jędrzejewski-Szmek wrote:
FF57 was also pushed to F26 updates-testing. F26 is not beta but a
stable release. I have updates-testing enabled on my main machine to
find unexpected package breakages and give feedback about them, which is
the whole purpose of updates-testing. If this breaks my main web browser
(which could have been expected), I'll just disable updates-testing
again. This means less testing of updates, which a lot of people
(rightfully) complain about anyway. That's why I think such an update
should not go into a stable release's updates-testing.

Actually, as a regular desktop user, I'd be surprised if I got the FF57
with a regular update without upgrading to the latest Fedora release. I
don't think FF57 should be in F26 at all.


Re: Why is Fx 57 in Updates Testing?

By Pierre-Yves at 10/12/2017 - 05:32

On Thu, Oct 12, 2017 at 11:22:52AM +0200, Till Hofmann wrote:
Looking at the updates in bodhi, F26 was release with firefox-52, so you already
upgraded a few times :)

On my side, I do like having the latest firefox, also on my old F25.


Re: Why is Fx 57 in Updates Testing?

By Till Hofmann at 10/12/2017 - 05:54

On 10/12/2017 11:32 AM, Pierre-Yves Chibon wrote:
Yes, but that wasn't branded as all-new, better-than-ever Firefox (which
it is), that intentionally breaks stuff which is directly visible by the
end-user. An update that breaks the majority of extensions is very hard
to sell for a stable release, as much as I love the new Firefox.

From an admin POV, this will result in lots of users complaining about
their broken browsers, and probably at the wrong time, because not
scheduled by the admin.

Also, as someone else has already mentioned in this thread, this is not
really in line with the updates policy. I'm not saying we shouldn't
receive updates for Firefox, but I think it should get an exception, so
everyone actually knows when and why Firefox gets (or doesn't get) updates.

Me too, but I don't like my boss complaining about his broken web browser.


Re: Why is Fx 57 in Updates Testing?

By Thomas Daede at 10/12/2017 - 13:16

On 10/12/2017 02:54 AM, Till Hofmann wrote:
Special-casing a normal Firefox release would be a bad idea as they
don't receive security backports. Switching Fedora to ESR-only would be
the only safe way to accomplish this.

(this is unrelated to whether it should have been pushed as Beta)

Re: Why is Fx 57 in Updates Testing?

By Adam Williamson at 10/12/2017 - 13:52

On Thu, 2017-10-12 at 10:16 -0700, Thomas Daede wrote:
I think that may not realistically be possible, though, as 56 is not
being made an ESR, AFAICT, and it sounds like downgrading from 56 to 52
(the most recent ESR), aside from the epoch bump it'd require on our
side, is not straightforward (it seems there were profile changes
between 56 and 52).

However, I don't think this means we MUST ship 57. Talking about
'security backports' in the abstract is all well and good, but no-one
even seems to have stated yet that there *are* any important security
fixes in 57. Even if there are, we *can* look at the feasibility of
backporting them ourselves (or in co-ordination with other
distributors, who may well be in the same position as us). It's
something we do for many other packages, after all; it's not

Re: Why is Fx 57 in Updates Testing?

By Peter Oliver at 10/13/2017 - 07:29


Is now a good time to think about how we could try to avoid getting into a similar situation again in the future?

I see that Firefox ESR releases are supported for one year plus twelve weeks (<a href="" title=""></a>). For Fedora 27, would it be safer to include Firefox 57 and 58, but then stick with Firefox 59 ESR from March onwards?

Re: Why is Fx 57 in Updates Testing?

By Adam Williamson at 10/13/2017 - 11:40

On Fri, 2017-10-13 at 12:29 +0100, Peter Oliver wrote:
We've chosen not to ship ESR in the past, AIUI, because we think our
target audiences generally prefer to get the main Firefox release
stream, they don't want the ESR stream. We could change that decision,
of course. I don't personally think a one-off ouch-y event like this
would entirely justify such a change, but it'd be interesting to know
if the Quantum stuff means a series of such ouch-y events might
potentially be coming to the main release stream.

Re: Why is Fx 57 in Updates Testing?

By Michael Cronenworth at 10/13/2017 - 11:47

On 10/13/2017 10:40 AM, Adam Williamson wrote:
Shipping ESR will just lead to fragmentation of the user base. Some will create a
copr with the latest version.

Is everyone being over-dramatic (per usual)?

Does this update break the entire browser?

Could I make plenty more rhetorical questions?

If we're going to suggest shipping ESR we might as well stop shipping the latest
kernel, too.

I can't believe I replied to this thread. :(

Re: Why is Fx 57 in Updates Testing?

By Nicolas Mailhot at 10/13/2017 - 13:11

No, it's more akin to the switch from Gnome 2 to Gnome 3: lots of changes all over the place, old trusted features gone, replacements not totally there and in any case different requiring user adaptation.

Which all means our release planning is too focused on Gnome and not enough thought is put into the roadmap of major non-Gnome desktop apps such as Firefox or Libreoffice. I'd argue that this kind of Firefox change is way more impacting for our users than the latest gnome settings redesign.

Too late to switch to ESR now, the best outcome would be to make FF57 a major feature of F27 (since it will be), ship it (even as prerelease) from day 1 and pretend that was always what our release engineering intended to do.


Re: Why is Fx 57 in Updates Testing?

By Ralf Corsepius at 10/15/2017 - 09:35

Definitely. Fedora in danger to become (or already is) Gnome's and
Firefox's "puppet".

This needs to change. Fedora should be in service of its users not
arbitrary upstreams or their package maintainers.


Re: Why is Fx 57 in Updates Testing?

By Gerald Henriksen at 10/15/2017 - 10:47

Except FF57 is stable (at least no one so far is complaining about it
being otherwise).

For those who use its plugins then there may be an issue (depending on
how many do a last minute update vs. can't/won't be udated) but that
day of reckoning is coming sooner or later unless they choose to never
update Firefox again.

Re: Why is Fx 57 in Updates Testing?

By Gerald B. Cox at 10/15/2017 - 12:23

On Sun, Oct 15, 2017 at 7:47 AM, Gerald Henriksen < ... at gmail dot com>

Completely agree. Fx 57 is an extremely important release for Mozilla and
they've done
and excellent job communicating the changes and getting the release ready.
The main
thing people are going to notice is the improved performance and cleaner

Re: Why is Fx 57 in Updates Testing?

By John Florian at 10/16/2017 - 09:58

On Sun, 2017-10-15 at 09:23 -0700, Gerald B. Cox wrote:
Yes! Because of this thread's original message, I pulled 57 into F26
eager to try it out (on $dayjob workstation). Now I want it at $home
workstation. Is there a COPR or some alternative for early testers in
F26 now that the update has been withdrawn? I'd do more looking on my
own, but our corporate web proxy right now is eating kittens and other
helpless creatures and might as well be unplugged for all the good it's
doing me.

Re: Why is Fx 57 in Updates Testing?

By Bob Mauchin at 10/16/2017 - 10:34

On lundi 16 octobre 2017 15:58:32 CEST John Florian wrote:

If you don't mind living on the edge, I provide weekly builds of Firefox
Nightly (58) here: <a href="" title=""></a>

It contains all the Fedora specific patches, including Martin's CSD patch.
It's stable, at least for me.

Re: Why is Fx 57 in Updates Testing?

By James Hogarth at 10/16/2017 - 10:03

I have a build running in a COPR now, and the article will include details
of that.

Since we *are* on the development list where COPR is normal ... ;)

Up till the point FF57 rejoins updates-testing in F26 sometime in November
I'm going to track commits to the F27/rawhide FF57 packages and build them
for F25 and F26 for early testing.

<a href="" title=""></a>

The builds are completing at present ... once they have completed you'll be
able to pick it up there.

Re: Why is Fx 57 in Updates Testing?

By John Florian at 10/16/2017 - 10:40

On Mon, 2017-10-16 at 15:03 +0100, James Hogarth wrote:
Excellent! Thank you for doing this.

Re: Why is Fx 57 in Updates Testing?

By Gerald B. Cox at 10/15/2017 - 12:59

For those of you who were concerned about LastPass:

<a href="" title=""></a>

The beta version is available now - The final version will be ready when
the browser arrives on November 14th.

As I mentioned earlier, for those who want to use a GPLv3 product, check
out Bitwarden:

<a href="" title=""></a>