[oi-dev] FF 43b6 integration

Sat Nov 28 02:24:20 UTC 2015

 Hi!
(only for 1 minute).

>Пятница, 27 ноября 2015, 20:31 +01:00 от Nikola M <minikola at gmail.com>:
>
>On 11/27/15 05:05 PM, ken mays via oi-dev wrote:
>> We agreed that we could move to FF 43.x (now version 43.0b7 today) to resolve many rendering issues and migrate to the next ESR release or provide an additional package of the current 38.4.0 ESR release.
>>
>>
>> Usually, if you need an older browser you can uninstall a current browser and install the old one (or place it in another directory - which I've done for years). The Oracle provided browser releases allows users to go back and do this (or we can support specific FF releases in IPS).
>>
>> So technically, we could push forward with FF 43b7 today and then provide a FF 38.4.0esr package as well for those
>> users that need/want it (as we do something similar with GCC or NVIDIA packaging).

There are exactly zero conflicts.
On the provided bins package  http://opensxce.org/.FF/43.0b3/i386/PKG/firefox-43.0b3___Multilang__gcc4x-built__supports-flash-plugin__opensolaris-snv_130%2b%2b_all_distros-i386.pkg.bz2 for use OpenSolaris-wide I intentionally solved it in a way to avoid namespace collisions on all layers (e.g. names of files/dirs/the icon and pkg name).

/usr/bin/firefox43.0b3 is a symlink to -> /usr/lib/firefox43.0b3/bin/firefox, which means it neither conflicts with /usr/bin/firefox nor /usr/lib/firefox.

cat /usr/lib/firefox43.0b3/bin/firefox
#!/bin/bash
#
#* CDDL HEADER START
#*
#* The contents of this file are subject to the terms of the
#* Common Development and Distribution License, Version 1.0 only
#* (the "License").  You may not use this file except in compliance
#* with the License.
#*
#* You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
#* or http://www.opensolaris.org/os/licensing.
#* See the License for the specific language governing permissions
#* and limitations under the License.
#*
#* When distributing Covered Code, include this CDDL HEADER in each
#* file and include the License file at usr/src/OPENSOLARIS.LICENSE.
#* If applicable, add the following below this CDDL HEADER, with the
#* fields enclosed by brackets "[]" replaced with your own identifying
#* information: Portions Copyright [yyyy] [name of copyright owner]
#*
#* CDDL HEADER END
#*
#*
#* This wrapper has nothing to do with the flash plugin, but simply
#* with as best as possible multi-distro compatibility and gcc/g++ runtime
#* Hence should run on every OpenSolaris/Solaris/Illumos >= snv_130
#* without the need to install any additional gcc/g++ runtime env.
#*
#* Copyright 2015 OpenSXCE.org Martin Bochnig <opensxce at mail.ru>
#* FireFox 20/30/40++ gcc4.x port with Flash support for OpenSolaris++ x86/x64
#*

export LD_LIBRARY_PATH=/usr/lib/firefox43.0b3/lib/firefox-43.0:$LD_LIBRARY_PATH
exec /usr/lib/firefox43.0b3/lib/firefox-43.0/firefox.exe "$@"

... is a simple wrapper ( to make it work out of the box on _any_ distro installation/env, provoding the end-user the convenience not to depend on any external gcc/g++ runtime to be installed, because as described last week I bundled it, this also avoids versionitis problems).

I renamed the original bin "firefox" to .exe  (which is hardlinked to firefox-bin by default, which I didn't change).

>>
>> The other issues like migration issues is something we document to alleviate those issues with developer support teams. This is standard software porting practice.
>>
>> That way, you CAN still have your cake - while just eating some of it too!
>Ok ship it. Let's move along with it.
>
>I am just uneasy with many people with existing FF profiles reporting 
>core dumps on exit.
>It seems like it will be there for some time but at least there will be 
>more people to figure it out.

As said, nobody needs to first uninstall anything in advance. So have your cake and eat it, too (see a few lines above).

More important: On OpenSXCE I don't have this core dump problem, nor on SXCE_130 (with or without existing ~/.mozilla).
Only a very few times I saw that (but other than giving the core dump message and core creation {AFTER SUCCESSFUL day- or weeks-long working sessions only AFTER the normal ***user-initiated*** exit} there were no other constraints or limitations.

My instant guess is that it may be related to above wrapper itself. To test this somebody with an installation that reports these (otherwise meaningless post-exit core dumps, which I don't have because on OpenSXCE it works equally as fine, only not showing that little cosmetic glitch at post-exit time) should verify, if calling /usr/lib/firefox43.0b3/lib/firefox-43.0/firefox.exe directly (bypassing the tiny wrapper) removes the so called """""problem""""".

Now I could really get a crisis again, seeing that somebody wants to withhold it from release only because of that post-exit message, rather than analyzing it with dbx or gdb or mdb, or compile in debug symbols and the research such a lower priority glitch for days.
Reminder: You can now visit sites which demand FF39 as minimum requirement (recently I was confused to find out, that gmx.de now stops you from reading e-Mail if it finds out that you don't have at least FF38). Ok, for that you have Sun ESR FF38. But what if other sites force the user to have at least 39 or 40?

BTW: There is a lot of talking about fully "approved" "certified" blah blah ESR.
Hint: ESR or not ESR has nothing to do with this post-exit core dump.
Also I failed to see any other regressions on non ESR builds (and over 2015 I built and tested at least 7 versions). We are on Solaris, not on Windows.
The port is a compromise anyway. There may still be potential for enhancements, but it is silly to couple this with ESR or not ESR. It is only a name, which you can enable in ./configure for a different branding.

>
>
>If I can transfer remembered passwords, history and bookmarks
>  (I made it bringing passwords from FF24 by selecting 
>signon.importedFromSqlite to default (right click->reset) in 
>about:config) to new profile , but it seems that I need a new FF profile 
>not to have it dump cor eon exit.
>
>I did not yet figure why new empty profile has no problems on exit and 
>old FF profile makes it core.
>
>In meantime, I ruled out that Addons are probably not the primary cause 
>because sometimes it even does not core on exit and sometimes, with same 
>addons , dumps core (starting->closing->core dump)
>
>So I'll forget about updating profile
>if I can easily move History, Bookmarks and Passwords, providing their 
>format is updated.
>*Please, everyone let's figure out how to easy migrate our Firefox 
>profile to empty profile*
>so we can live with new FF.
>
>Actually new FF lives fine with existing FF profile,
>only problem now is dumping core on exit and I don't know yet what in 
>existing profile might trigger it in new FF.
>
>And dumping core on every program exit I could live for short time but 
>not for long.

Same as above.
Who has no problems, invents them  :)

Believe me: I'm jeaulous for _your_ "problems".
(you don't want to be in  my $$ial situation)

BTW:  I didn't want to beg for more donations, I just mentioned them to provide equal rights to all, rather than demanding more.
Now I can't believe it, but  Alexander Pyhalov - creator and main engine/(er) behind Hipster - donated 50 EUR.
Man! He is the one who should _get_ donations, rather than funding me.

Well, that's this world.
If I wouldn't be in the situation I'm in I would never accept such a donation from someone who spent so many 1000's of unpaid hours himself for OpenSolaris. But I'm forced by circumstances to accept it. BIG BIG THANKS, comrade! Will instantly add you to the Readme.

rgds.,
%martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20151128/d245e3e5/attachment-0005.html>