There are several issues with the current stable version (31) of www-client/firefox and www-client/firefox-bin: - the official end of life of this Firefox ESR is 2015-08-04, i.e. very soon; - it uses the old Sync system, which will be switched off soon (apparently no date has been fixed yet but definitely no later than by the end of 2015); - the source ebuild can no longer be emerged with USE=system-libvpx on systems also containing a stable version of Chromium (or Chrome I suppose) due to a dependency-version conflict - Firefox wants libvpx-1.3.0, Chromium wants 1.4.0. In light of the above, I would like to suggest stabilising the latest Firefox ESR i.e. 38.1.0, already available as both source and binary ebuilds.
It looks like all the major flaws in the 38.x series have been solved (at least the ones we can solve in ebuilds), so upgrading this bug to the full stablereq for all arches. CC'ing AT's, please stabilize at your earliest convenience.
"AT's" is ambiguous here.
Stable for PPC64.
amd64 stable
firefox 38.1 is stable. But 38.1 create new firefox profile and is set default new developer edition profile. So 31.8 to 38.1 upgrade can be difficult(confusing) to new gentoo users. Solution: We can set default profile[0](31.8 profile- old stable) in profiles.ini. So users can choose profile (old or new profile) begining the first start. Sample: $HOME/.mozilla/firefox/profiles.ini [General] StartWithLastProfile=0 [Profile0] => old-stable profile Name=default IsRelative=1 Path=igoxrf4f.default Default=1 [Profile1] Name=dev-edition-default IsRelative=1 Path=y2s06zsp.dev-edition-default
(In reply to Emre Eryilmaz from comment #5) > firefox 38.1 is stable. But 38.1 create new firefox profile and is set > default new developer edition profile. So 31.8 to 38.1 upgrade can be > difficult(confusing) to new gentoo users. I must say I have not observed this phenomenon. Emerged 38.1.0 about two weeks ago (while it was still unstable on ~amd64) with 31.8.0 present in the system and the new version happily picked up the old profile with all its contents, I haven't seen any mention of a development edition either.
(In reply to Marek Szuba from comment #6) > I must say I have not observed this phenomenon. Emerged 38.1.0 about two > weeks ago (while it was still unstable on ~amd64) with 31.8.0 present in the > system and the new version happily picked up the old profile with all its > contents, I haven't seen any mention of a development edition either. Aurora goes firefox developer edition. If enabled "bindist" use-flag. As in the this gentoo forums links(users experiences): https://forums.gentoo.org/viewtopic-p-7789220.html?sid=3a18aa493dc7dd4ac5563756c8f28a31
(In reply to Emre Eryilmaz from comment #7) > (In reply to Marek Szuba from comment #6) > > I must say I have not observed this phenomenon. Emerged 38.1.0 about two > > weeks ago (while it was still unstable on ~amd64) with 31.8.0 present in the > > system and the new version happily picked up the old profile with all its > > contents, I haven't seen any mention of a development edition either. > > Aurora goes firefox developer edition. If enabled "bindist" use-flag. > As in the this gentoo forums links(users experiences): > https://forums.gentoo.org/viewtopic-p-7789220. > html?sid=3a18aa493dc7dd4ac5563756c8f28a31 The developer edition (Aurora) and the official firefox edition isn't supposed to be 100% compatible, although once the developer edition matures to the 'release' version it essentially is. Upstream has each using a separate profile, and we don't intend to change that by default for users on Gentoo. If users set USE="bindist" in their earlier version, and keep that flag set, then their profile continues to be used; likewise if USE="bindist" isn't set. Switching the flag changes the profile just like what is stated in the useflag description. Unless there's something broken about what I've described above, I'm not seeing a bug here.
(In reply to Ian Stakenvicius from comment #8) > Unless there's something broken about what I've described above, I'm not > seeing a bug here. Already, it's not completely bug. It is only compatible problems if enabled bindist flag. We need to fix up compatibility for this users.
(In reply to Ian Stakenvicius from comment #8) [snip...] > Gentoo. If users set USE="bindist" in their earlier version, and keep that > flag set, then their profile continues to be used; Not according to my observations. With bindist set FF jumps to the new profile and ignores the old. Selecting the old profile in the profile manage and ticking not to ask again at start up is ignored. The new profile is selected next time and if deleted (both the new profile and its files), FF recreates at the next start up. > likewise if USE="bindist" > isn't set. Switching the flag changes the profile just like what is stated > in the useflag description. > > Unless there's something broken about what I've described above, I'm not > seeing a bug here. I think that there is a bug, in the sense that the profile manager selection does not stick. I removed the bindist flag and the problem went away. -- Regards, Mick
Superseded by bug #556942.
