firefox-41.0-4.fc21 - New upstream 41.0
firefox-41.0-4.fc22 - New upstream 41.0
firefox-41.0-4.fc23 - New upstream 41.0
Updates may require up to 24 hours to propagate to mirrors. If the following command doesn't work, please retry later:
sudo dnf upgrade --refresh --advisory=FEDORA-2015-16455
Please login to add feedback.
0 | 4 | Test Case firefox addons |
0 | 5 | Test Case firefox browse |
0 | 5 | Test Case firefox media |
0 | 0 | Test Case firefox screenshot |
0 | 0 | Test Case User:Sr02mu/Draft/firefox bookmark |
This update has been submitted for testing by stransky.
This build requires sqlite 3.8.11 which isn't even listed on https://bodhi.fedoraproject.org/updates/?packages=sqlite Can't it build against 3.8.10?
sqlite 3.8.11 is available in Koji, but hasn't been added for testing in Bodhi. (http://koji.fedoraproject.org/koji/buildinfo?buildID=686935) I added the necessary packages and am testing this Firefox build now.
(Bah, I updated my packages not "added".)
Works fine here with the sqlite build from koji. (You should add that to the update to make sure they get pushed as a unit).
That aside OMTC seems to work on both radeonsi and intel based hardware even with layers acceleration enabled (before it was crashy even with just basic).
End result is that performance is much improved.
There's going to be a new version of sqlite today so I need to respin Firefox for that. New update is coming.
Unfortunately I can't remove this update....
I downloaded the .src.rpm and build it (using dnf builddep and rpmbuild --rebuild). I did not have a problem with SQLite. Mine is 3.8.10.2-1.fc22 and I was able to compile the srpm into a working rpms, and run that rpm.
I did pass all the tests. And did already about 2 hours of browsing without a single problem. I also did run the usual benchmark (kraken, octane, etc.) just to stress a bit the browser. And also used the html5test.com service to test for HTML5 features (you can compare results to previous FF release). All worked.
karma: +1
@stransky: You don't have to ... submitting a newer build should obsolete it.
Hm, I need to add the missing sqlite package.
According to the bodhi FAQ: https://fedoraproject.org/wiki/Bodhi2#FAQ ... seems like this happens while the update is being pushed. So you'd have to wait until it changes from pending to testing before being able to edit it.
Question: why wait for SQLite 3.8.11 when it can work with SQLite 3.8.10?
I mean FF 41 includes security fix, so the update should not be stuck because of a non critical dependency update.
So I would answer my initial question: ship FF 41 with SQLite 3.8.10 now (as mentioned in a previous comment - that was me the anonymous guy - it works when using the srpms and compiling against 3.8.10). And if SQLite 3.8.11 is such great update, then we could publish a firefox-41.0-5.fc22 when both are ready.
I've been running this for the last day, and the earlier 41.0-3 that was available in Koji before that, and I haven't encountered any regressions vs. 40. (I have found with both 40 and 41 that there's occasional instability when playing HTML5 video content I hadn't tripped over until recently. In one case it brought the browser down and in another it brought my entire Gnome session down -- the only time I've ever experienced data loss with Fedora. But it's not a regression in 41 specifically.)
I'm confused. Are we waiting for a new build or is someone going to fix this one? It's not even on updates-testing, yet.
I strongly agree with huygens, too. I don't understand how Fedora users are still waiting for this security fix.
Adding sqlite to this update wont delay anything. The fact that the update is not in testing yet has nothing to do with it ... it just that the push takes longer for whatever (unrelated) reasons.
Filed request to bodhi admins here: https://github.com/fedora-infra/bodhi/issues/601 as per instruction bellow the page.
Works fine, obviously with sqlite-3.8.11.1.
works fine with sqlite-3.8.11.1, too.
karma: +1
Works fine
karma: +1
Working well for me, including my pile of extensions and a custom media-intensive application.
Updates fine if one pulls in the sqlite update as well and works well so far
This update has been pushed to testing.
This update has been submitted for stable by bodhi.
I think this is an example of how not to push important updates. This build of FF may reach stable before sqlite it requires reaches testing. A recipe for breaking a lot of systems. Shouldn't these two be going together?
Actually, I'm wrong about systems being broken. I see that there is a requires in this package for sqlite >= 3.8.11, so it just won't install for most people (i.e. dnf will refuse to do it).
If you want to have the update now but with SQLite 3.8.10, download the src.rpm and do:
To my knowledge this won't break anything. When FF 41.0-4 is out, you won't get the update even after SQLite 3.8.11 is out. But when either FF 41.0-5 or 41.1-1 is out, then you will get the update as usual. The 3.8.11 update is not critical (see https://www.sqlite.org/releaselog/3_8_11.html) but as a few nice feature and advertised better performanced. So if security is not paramount for you, you might want to wait (I did not!).
Good here.
So, so confusing. Firstly, when will Fedora users be able to get this security update? It's still not even available via updates-testing. (Obviously, I mean a binary rpm on the mirrors, normal update procedure.) Secondly, what is the source of the delay? drago01 says the sqlite requirement is not related at all, but every other post here suggest that is.
This update has been pushed to stable.
Can't dnf update to 41 because broken dependencies :-(
Broken dependency. Solved by upgrading to sqlite version in Testing
Seriously: Depending a securitiy-critical update on an unreleased Sqlite package is madness!
I can not updating my FF to 41 version on Fedora 22 (broken dependency). How can i solve my cause?
Okay, so I think I see what was going on. Maybe FF41 was out there on updates-testing, but, since it requires new sqlite that wasn't available, dnf wouldn't upgrade it. That's just what bojan said, above. But, as soon as the new sqlite was available, dnf found it and would do the upgrade.
Shouldn't be long now before sqlite hits the normal updates repo, but I got a slight jump on it with --enablerepo=updates-testing; that's where dnf found the new sqlite.
So, the answer to my question is, yes, the sqlite dep was a major part of this delay.
The problem is that this update was locked in Bodhi so I could not add the sqlite packages here. Also the sqlite package was locked. See the ticket I filled at issue tracker and the first comments here.