691752 - [Tracking Bug] Officially provide 64-bit GNU/Linux binaries

Status: RESOLVED FIXED

(SeaMonkey :: Release Engineering, enhancement)

Description

[Tristan Miller]

There are no official 64-bit GNU/Linux binaries of stable releases available from the SeaMonkey Download & Releases page (though there is an unofficial en-US contrib build) and it is not trivial task to build SeaMonkey from the source for typical user.  As 64-bit systems are commonplace nowadays it would be helpful to provide official 64-bit binaries alongside the 32-bit ones in the list of official builds at <http://www.seamonkey-project.org/releases/#official>.

(See also Bug 482143 for the same issue reported for a different operating system.)

Comment 1

[Robert Kaiser]

Well, the "contrib" builds are actually coming from our one single official build machine we have for that platform, so it's actually in between contributed and official - as for making it really official, we'd need to run tests against it, which we just can't do with a single machine. Also, our update process etc. requires it to have all localized versions to run smoothly, and for that we'd need even more machine power.

Thankfully, help in terms of more build machines is on the way, they actually have been bought bot not installed yet.
It's still unsure how to present builds for different architectures on a download page without confusing users, though, and the 32bit versions run at least as good as the 64bit versions on most systems.

Comment 2

[Tristan Miller]

I agree that presenting a list with multiple architectures may be confusing for some users.  However, the download link on the home page at <http://www.seamonkey-project.org/> does a decent job of guessing the appropriate OS, presumably on the basis of the visitor's client's user-agent string.  At least for Mozilla browsers, this encodes the CPU architecture as well.  If an official x86-64 build becomes available, then at least this home page download link script could be updated.

Comment 3

[Tony Mechelynck [:tonymec]]

(In reply to Robert Kaiser (:[e-mail]) from comment #1)
[...]
> It's still unsure how to present builds for different architectures on a
> download page without confusing users, though, and the 32bit versions run at
> least as good as the 64bit versions on most systems.

FWIW, I've been running SeaMonkey x86_64 Linux trunk builds "live" for as long as I've had a 64-bit machine, and I remember I bought it a couple of days before openSUSE Linux 11.4 final came out… let me see… March 10. I don't remember ever experiencing a bug which 32-bit users never saw. I am under the impression that this 64-bit build (or set of builds, every day a new nightly) runs noticeably faster and can handle more tabs than the 32-bit build on my former box, but of course that could quite plausibly be due to just the more powerful CPU (seen by software as two 2.8 GHz cores) and increased RAM.

IOW, AFAICT these 64-bit builds run at least as well as the 32-bit builds I had before.

(In reply to Tristan Miller from comment #2)
> I agree that presenting a list with multiple architectures may be confusing
> for some users.  However, the download link on the home page at
> <http://www.seamonkey-project.org/> does a decent job of guessing the
> appropriate OS, presumably on the basis of the visitor's client's user-agent
> string.  At least for Mozilla browsers, this encodes the CPU architecture as
> well.  If an official x86-64 build becomes available, then at least this
> home page download link script could be updated.

At the bottom of the "Other Systems & Languages" page, under "Contributed builds", there is a link to an x86_64 build. It is an en-US build but since langpacks are architecture-independent you could add to it any langpack for the same version of SeaMonkey.

If and when the present bug gets FIXED, I suppose that the "official" 64-bit binaries "provided" will also be "made discoverable" by linking them from the SeaMonkey homepages (maybe via a followup bug).

Comment 4

[Robert Kaiser]

(In reply to Tony Mechelynck [:tonymec] from comment #3)
> IOW, AFAICT these 64-bit builds run at least as well as the 32-bit builds I
> had before.

That doesn't invalidate the opposite, i.e. that the 32bit build run just as well as the 64bit ones, too. And comparing different machines doesn't make too much sense.

> If and when the present bug gets FIXED, I suppose that the "official" 64-bit
> binaries "provided" will also be "made discoverable" by linking them from
> the SeaMonkey homepages (maybe via a followup bug).

I think that's actually what Tristan wants, but as I explained, we have a few hurdles to overcome, mostly getting new machines installed and running, as well as then turning on tests, localized builds and updates in a staged approach.

Comment 5

[Michael Lueck]

My machine is available to test 64 bit builds of SeaMonkey with. Running Ubuntu 10.04.3 x64 edition presently.

I normally install the official Mozilla builds with the assistance of UbuntuZilla.

Currently it has no 64 bit support.

I hand downloaded the 64 bit version of Firefox, and am running the official 32 bit version of SeaMonkey. Both hand installs running within my home directory structure.

I understand that there is an official Mozilla PPA for 64 bit Firefox, so will look around for that. However SeaMonkey seems behind Firefox in 64 bit readiness.

Comment 6

[Tony Mechelynck [:tonymec]]

(In reply to Michael Lueck from comment #5)
[...]
> I understand that there is an official Mozilla PPA for 64 bit Firefox, so
> will look around for that. However SeaMonkey seems behind Firefox in 64 bit
> readiness.

There's a kind of chicken-and-egg problem here: the SeaMonkey Council (commendably) doesn't want to label SeaMonkey linux64 builds as "official" for lack of adequate testing, and distros won't include them (even if they include linux32 builds of SeaMonkey) as long as they aren't "official".

SeaMonkey linux64 builds can be found at the following locations depending on version:
2.4.1 "current release": http://releases.mozilla.org/pub/mozilla.org/seamonkey/releases/2.4.1/contrib/seamonkey-2.4.1.en-US.linux-x86_64.tar.bz2
2.5 "beta": start at http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/ then the latest 2.5* then the latest build then linux-x86_64/en-US where you download the .tar.bz2
2.6a2 "aurora": http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-comm-aurora/seamonkey-2.6a2.en-US.linux-x86_64.tar.bz2
2.7a1 "bleeding-edge development": http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-comm-central-trunk/seamonkey-2.7a1.en-US.linux-x86_64.tar.bz2

Install (in a root console) with
test -a /usr/local/seamonkey && rm -Rvf /usr/local/seamonkey
tar -jxvC /usr/local -f seamonkey-*.linux-x86_64.tar.bz2
test -L /usr/local/bin/seamonkey || (pushd /usr/local/bin; ln -svf ../seamonkey/seamonkey; popd)

Comment 7

[Michael Lueck]

Thank you very much Tony. I just now pulled down seamonkey-2.4.1.en-US.linux-x86_64.tar.bz2 and am running that build.

I will relay this information along to the UbuntuZilla development team.

Comment 8

[Michael Lueck]

UbuntuZilla now officially supports the Mozilla build of SeaMonkey linux-x86_64.

I was able to smoothly transition back to installing via the UbuntuZilla package and no longer need to manually download / deploy the Mozilla linux-x86_64 archive.

http://ubuntuzilla.sourceforge.net/

Comment 9

[Tristan Miller]

(In reply to Robert Kaiser from comment #4)
> I think that's actually what Tristan wants, but as I explained, we have a
> few hurdles to overcome, mostly getting new machines installed and running,
> as well as then turning on tests, localized builds and updates in a staged
> approach.

Just curious as to whether there's been any progress with getting the new equipment up and running.  Are you now in a position to test 64-bit builds?

Comment 10

[Edmund Wong (:ewong)]

I'm turning this into a tracking bug.  This is on my TODO list after we've released two (tentatively) 2.48 betas.

Comment 12

[Edmund Wong (:ewong)]

Attachment: [configs] add Linux64 debug builds.

first step.  provide debug builds + generate tests. (yes, test infra is busted
but figured I'd just enable all the tests and fix the tests on that
test infrastructure fix bug).

Comment 13

[Edmund Wong (:ewong)]

I am gunning for officially supporting Linux64 builds for 2.54  or at worse, 2.55.

Just realized the ESR bug should be a higher priority than this one.

Comment 14

[Frank-Rainer Grahl (:frg)]

Comment on attachment 8892264 [details] [diff] [review]
[configs] add Linux64 debug builds.

> +++ b/seamonkey/config.py

> +            'update_platform': 'Linux_x86_64-gcc3',
Missing from linux-debug. Are these updateable?

> +                'SYMBOL_SERVER_HOST': 'symbolpush.mozilla.org',
> +                'SYMBOL_SERVER_USER': 'seabld',
> +                'SYMBOL_SERVER_PATH': SYMBOL_SERVER_PATH,
> +                'POST_SYMBOL_UPLOAD_CMD': SYMBOL_SERVER_POST_UPLOAD_CMD,
> +                'SYMBOL_SERVER_SSH_KEY': "/home/seabld/.ssh/seabld_dsa",
> +                'MOZ_SYMBOLS_EXTRA_BUILDID': 'linux64',
No symbols in linux-debug

> +                # LD_LIBRARY_PATH needs to be set to properly run elfhack 
> during build process (Bug 904485)
> +                'LD_LIBRARY_PATH': '/tools/gcc-4.5/lib64',
Missing from linux-debug. I think could maybe be removed from all configs and set to:
> 'LD_LIBRARY_PATH': '%s/mozilla/dist/bin' % OBJDIR,

 
> +            'objdir': 'objdir',
> +            'enable_opt_unittests': True,
Only
>  'enable_unittests': True,
in linux_debug

>    ('/builds/gapi.data', '/builds/geoloc-api.key')]
Wrong keyfilename(s) see bug 903439

f+ for now

Comment 15

[Edmund Wong (:ewong)]

(In reply to Frank-Rainer Grahl (:frg) from comment #14)
> Comment on attachment 8892264 [details] [diff] [review]
> [configs] add Linux64 debug builds.
> 
> > +++ b/seamonkey/config.py
> 
> > +            'update_platform': 'Linux_x86_64-gcc3',
> Missing from linux-debug. Are these updateable?

Will need to do this part on a later bug (possibly the setup-updates bug. So
removing this mention.

> 
> > +                'SYMBOL_SERVER_HOST': 'symbolpush.mozilla.org',
> > +                'SYMBOL_SERVER_USER': 'seabld',
> > +                'SYMBOL_SERVER_PATH': SYMBOL_SERVER_PATH,
> > +                'POST_SYMBOL_UPLOAD_CMD': SYMBOL_SERVER_POST_UPLOAD_CMD,
> > +                'SYMBOL_SERVER_SSH_KEY': "/home/seabld/.ssh/seabld_dsa",
> > +                'MOZ_SYMBOLS_EXTRA_BUILDID': 'linux64',
> No symbols in linux-debug

We don't use this part to upload the symbols (well, at least not the
ssh key or the user, or the path).  I'm even debating if we even
need the POST_SYMBOL_UPLOAD command, but will need to check.


> 
> > +                # LD_LIBRARY_PATH needs to be set to properly run elfhack 
> > during build process (Bug 904485)
> > +                'LD_LIBRARY_PATH': '/tools/gcc-4.5/lib64',
> Missing from linux-debug. I think could maybe be removed from all configs
> and set to:
> > 'LD_LIBRARY_PATH': '%s/mozilla/dist/bin' % OBJDIR,

No, not a good idea.  I'd hazard a guess if this is even needed anymore.

> 
>  
> > +            'objdir': 'objdir',
> > +            'enable_opt_unittests': True,
> Only
> >  'enable_unittests': True,
> in linux_debug
> 
fixed.

> >    ('/builds/gapi.data', '/builds/geoloc-api.key')]
> Wrong keyfilename(s) see bug 903439

fixed.

Comment 16

[Edmund Wong (:ewong)]

Attachment: [config] enable Linux64 debug builds. (v2)

Comment 17

[Edmund Wong (:ewong)]

Attachment: [mozconfigs] add debug mozconfig

Comment 18

[Frank-Rainer Grahl (:frg)]

Comment on attachment 8952281 [details] [diff] [review]
[config] enable Linux64 debug builds. (v2)

Linux debug is not using:

+            'upload_symbols': True,
+            'packageTests': True,

Should these be removed?

Linux debug is using in 'env':
 'XPCOM_DEBUG_BREAK': 'stack-and-abort',
 'MOZ_CRASHREPORTER_NO_REPORT': '1',

Should these be added?

r+ with questions answered and/or fixed.

Comment 19

[Frank-Rainer Grahl (:frg)]

Comment on attachment 8952282 [details] [diff] [review]
[mozconfigs] add debug mozconfig

NIT has CRLF line endings instead of just LF.

r+ with this fixed.

Comment 20

[Edmund Wong (:ewong)]

Attachment: [mozconfigs] add debug linux64 mozconfig (v2)

fixed crlfs

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/c52f5776e940
Add Linux64 debug mozconfig. r=frg

Comment 22

[Edmund Wong (:ewong)]

Attachment: [configs] enable linux64-debug, added env vars to linux64-debug and removed upload_symbols/packagetests

Comment 23

[Edmund Wong (:ewong)]

Attachment: [configs] enable linux64-debug (v3)

removed extra blank line.

Comment 24

[Edmund Wong (:ewong)]

Attachment: [configs] linux64 tests need test_tooltool_manifest file.

bustage fix patch.

Comment 25

[Worcester12345]

Is there currently a bug "Provide 64-bit Seamonkey For All Platforms" which this one can be a blocker on?

Comment 26

[Frank-Rainer Grahl (:frg)]

No that is essentially the tracking bug. There is only Windows x64 left tracked in Bug 482143.

Comment 27

[Frank-Rainer Grahl (:frg)]

SeaMonkey 2.49.5 is now provided as a localized x64 Linux version and the download pages on the website have been adjusted for it.