Experimental build of SeaMonkey

[Dave Yeo]

I've uploaded an experimental build of SeaMonkey 2.42.9ESR, https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.42.9esr.en-US.os2_exp1.zip
Optimized for size instead of performance, should fit into memory a bit better and almost as fast. Also optimized for a Pentium M so needs a CPU with SSE2 support.
You could also install it as if it was an RPM, putting everything in @UNIXROOT/usr/lib/seamonkey-2.42.9esr and a copy of seamonkey.exe in @UNIXROOT/usr/bin so it is on the PATH.
Same codebase as the latest release of Firefox. Once dmik releases another version of Firefox, I'll release the usual i686 build and if I ever get some guidance on building an RPM, I'll try to release them as well.
Needs the latest libcx and libc that are now available on netlabs-release RPM repository (I hope).

Note there also seems to be a regression with highmem support, marking xul.dll to load code and data makes SM unstable here on ArcaOS.

[Rich Walsh]

I've uploaded an experimental build of SeaMonkey 2.42.9ESR, https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.42.9R2esr.en-US.os2_exp1.zip

The link does not point at your new build. It is identical to your build of August 17, 2017.

Also, this is OS/2 where the mozapps were specifically designed to be installed wherever the user chooses. Why would anyone advocate confining them to the bloated and largely pointless @unixroot tree unless absolutely necessary? Group-think? A fondness for arrogant and authoritarian mindset that BWW unfailingly displays?

These types who go on and on and on about their unyielding hostility to any semblance of a unix directory structure certainly are tiresome (in extremis), but they do have a point. Me, I'll say it only once:  ONU !!!!

[Dave Yeo]

I've uploaded an experimental build of SeaMonkey 2.42.9ESR, https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.42.9R2esr.en-US.os2_exp1.zip

The link does not point at your new build. It is identical to your build of August 17, 2017.

You're right, somehow I uploaded the wrong binary, I'll blame the crappy interface on the phone, though I'm to blame for not double checking. I'll delete the binary and re-upload when I get the chance.

Also, this is OS/2 where the mozapps were specifically designed to be installed wherever the user chooses. Why would anyone advocate confining them to the bloated and largely pointless @unixroot tree unless absolutely necessary? Group-think? A fondness for arrogant and authoritarian mindset that BWW unfailingly displays?

There's no reason that this can't be installed anywhere, it just also has the option of being installed in @UNIXROOT, which will be needed as Arca Noae eventually wants a RPM, and with all the dependencies, an RPM does make installation easier.
I don't like where development of Mozilla has gone and I did try to upload statically linked binaries for as long as I could, and did things like put sydney audio back in when Bitwise didn't care enough to support sound.
Unluckily, with the direction that Mozilla has gone with Firefox, the need for fixes to the build tools,things like a Python that correctly does the virtual environment thing and the ever increasing list of dependencies and things like NSPR being forked, it has become easier to just follow along with Bitwise and ArcaOS which has become heavily dependent on RPMs.

These types who go on and on and on about their unyielding hostility to any semblance of a unix directory structure certainly are tiresome (in extremis), but they do have a point. Me, I'll say it only once:  ONU !!!!

[Dave Yeo]

Hopefully the link is fixed.

[Lars]

I've uploaded an experimental build of SeaMonkey 2.42.9ESR, https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.42.9R2esr.en-US.os2_exp1.zip

The link does not point at your new build. It is identical to your build of August 17, 2017.

Also, this is OS/2 where the mozapps were specifically designed to be installed wherever the user chooses. Why would anyone advocate confining them to the bloated and largely pointless @unixroot tree unless absolutely necessary? Group-think? A fondness for arrogant and authoritarian mindset that BWW unfailingly displays?

These types who go on and on and on about their unyielding hostility to any semblance of a unix directory structure certainly are tiresome (in extremis), but they do have a point. Me, I'll say it only once:  ONU !!!!

It's funny that you say that. I thought it was AN's idea to come up with the splendid "sys", "etc" and "usr" directories.
As arrogant and authoritarian BWW might be: if they pull the plug on application development for OS/2 then ArcaOS is dead in 2 years flat.

[Martin Iturbide]

Hi Rich.

...Why would anyone advocate confining them to the bloated and largely pointless @unixroot tree unless absolutely necessary? Group-think? A fondness for arrogant and authoritarian mindset that BWW unfailingly displays?

I had also presented my dislike of "Filesystem Hierarchy Standard" many times in the past. Even some groups of the Unix world dislike it. But on our case (The OS/2 platform) I think that the issue was that we became dependent of many Linux ports libraries and even that everything can be reorganized on a better structure it was very difficult to maintain a different layout only for OS/2 because of the lack of resources we have on this platform.

We had a lot of DLL versioning issues and RPM was a good solution to keep all that updated, but it came with a cost. It was to much of chore to have RPM customized to have a different FHS on OS/2. So for me it was to "suck it up" with FHS or try to find resources that wanted to maintain a customized RPM version only for OS/2 and that verifies that every ported/updated DLL works on that new structure.

Regards 

[xynixme]

...Why would anyone advocate confining them to the bloated and largely pointless @unixroot tree unless absolutely necessary? Group-think? A fondness for arrogant and authoritarian mindset that BWW unfailingly displays?

I had also presented my dislike of "Filesystem Hierarchy Standard" many times in the past. Even some groups of the Unix world dislike it.

RPM was a good solution to keep all that updated, but it came with a cost.

</silence>
If the number of lines of output exceeds 100, then using STDOUT instead of STDERR hardly requires resources. Of course there are more optional ways to OS/2'ify software. Icon, installer, documented data file search strategies not assuming an @Unixroot, deleting useless files, avoided useless requirements of requirements (like a HUNSPEL0.DLL without any installed dictionary), and so on.

I'll try to care less, but does a RPM release actually manage e.g .the lxLite package, including all documentation files, of eCS 2.x?
<silence>

[roberto]

Hopefully the link is fixed.

Well, the link does not work for me. ??
saludos

[Dave Yeo]

What about if you start at https://bitbucket.org/dryeo/dry-comm-esr31/downloads/

[R.M. Klippstein]

Hi Dave , latest link doesn't work here also. The Inet has been really slow and unrelieable her lately -- don't know what gives!

klipp

[Andreas Schnellbacher]

latest link doesn't work here also.

Remove the 'R2' from the filename.

[roberto]

I have not had problems downloading now.
I tell you my tests, they have been executing it for the first time it seemed that I was not doing anything. I executed it again, and a first window appeared, a second, I do not recieve if third and it closed. With seamonkey-2.42.9esr.en-US.os2_exp1
What I have observed is that if I want to run firefox45.9, first I have to run firefox45.5 and close it. Then I can open firefox45.9 without problems. In fact, after I closed firefox45.9, I was able to execute it from a folder that was not in libpath. Although it may be that even if it has booted from a folder that is not in the libpath, it may have loaded the xul.dll that is in libptah. I do not.
The seamonkey generate a trp file if you need.
saludos

[Dave Yeo]

Hi Roberto,
You shouldn't have xul.dll in your LIBPATH. Usually SeaMonkey (and Firefox and Thunderbird) look in their program directory for their DLLs including xul.dll.
Now they also look to see if the executable (seamonkey.exe, firefox.exe) is installed in \usr\bin, in which case they will look in \usr\lib\@MOZ_APP_UA_VERSION where MOZ_APP_UA_VERSION currently equals firefox-45.9.0 or seamonkey-2.42.9esr.
The various xul.dll are not compatible with each other, though they are close enough that they will seem to work until you do something like open their options/settings.
Wouldn't hurt to see your trp file and any popuplog.os2 entries after you fix any LIBPATH issues.

[ak120]

What about if you start at https://bitbucket.org/dryeo/dry-comm-esr31/downloads/

Rendering of this page could be a problem for some OS/2 web browsers. So it needs no jump to the rendering problems that still exist with this build. It's not Dave's fault and shows up in the "latest" Bitwise Firefucks builds. A side effect introduced with switching to different libraries that cannot longer scale gif or jpeg image files correctly? Pictures: the first one shows Seamonkey 2.35 (from Feb 2016) the second the recent build (Nov 2017) - especially for this post with the same bunch of DLL hell. A HUGE diamond improvement in every menu that uses the diamond markers. Best instruction for installation I can give: del README.OS2. The content would fit in one sentence: "Please don't readme, thou shalt praise bitwise coding gods for their rpm/yum fork." Sceptics who cannot follow my command should read this document in reverse order.

[roberto]

My libpath in config.sys:
LIBPATH=.;C:\usr\local\lib;C:\usr\lib;C:\usr\lib\unixroot\usr\lib\firefox-45.9.0;C:\PROGRAMS\NETSCAPE\PROGRAM;C:\SYS\DLL;etc etc but not the folder.
In this libpath I have the xull.dll modify with highmen
but running this other firefox45.9 in a folder, you can see the trp, because after send me previous message hang with this trp.
In popup.os2 i have not any about firefox.
You can see that is run in d:\util2017test\....
Do you want me to include this folder in libpath? and wait for it to crack, and take out the trp?
saludos