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

ASSIGNED
Assigned to

Status

--
enhancement
ASSIGNED
7 years ago
8 months ago

People

(Reporter: psychonaut, Assigned: ewong)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

Trunk
x86_64
Linux
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments, 4 obsolete attachments)

(Reporter)

Description

7 years ago
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

7 years ago
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.
Component: Build Config → Release Engineering
QA Contact: build-config → release
(Reporter)

Comment 2

7 years ago
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.
(In reply to Robert Kaiser (:kairo@mozilla.com) 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

7 years ago
(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

7 years ago
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.
(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

7 years ago
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

7 years ago
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/

Updated

6 years ago
Blocks: 237202
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: SeaMonkey 2.4 Branch → Trunk
Depends on: 892418
(Reporter)

Comment 9

2 years ago
(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?
(Assignee)

Comment 10

2 years ago
I'm turning this into a tracking bug.  This is on my TODO list after we've released two (tentatively) 2.48 betas.
Summary: Provide 64-bit GNU/Linux binaries → [Tracking Bug] Provide 64-bit GNU/Linux binaries
(Assignee)

Updated

a year ago
Duplicate of this bug: 1172926
(Assignee)

Updated

a year ago
Summary: [Tracking Bug] Provide 64-bit GNU/Linux binaries → [Tracking Bug] Officially provide 64-bit GNU/Linux binaries
(Assignee)

Comment 12

a year ago
Created attachment 8892264 [details] [diff] [review]
[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).
Assignee: nobody → ewong
Status: NEW → ASSIGNED
Attachment #8892264 - Flags: review?(frgrahl)
(Assignee)

Comment 13

a year ago
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.
(Assignee)

Updated

a year ago
Blocks: 1107878
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
Attachment #8892264 - Flags: review?(frgrahl) → feedback+
(Assignee)

Comment 15

8 months ago
(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.
(Assignee)

Comment 16

8 months ago
Created attachment 8952281 [details] [diff] [review]
[config] enable Linux64 debug builds. (v2)
Attachment #8892264 - Attachment is obsolete: true
Attachment #8952281 - Flags: review?(frgrahl)
(Assignee)

Comment 17

8 months ago
Created attachment 8952282 [details] [diff] [review]
[mozconfigs] add debug mozconfig
Attachment #8952282 - Flags: review?(frgrahl)
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.
Attachment #8952281 - Flags: review?(frgrahl) → review+
Comment on attachment 8952282 [details] [diff] [review]
[mozconfigs] add debug mozconfig

NIT has CRLF line endings instead of just LF.

r+ with this fixed.
Attachment #8952282 - Flags: review?(frgrahl) → review+
(Assignee)

Comment 20

8 months ago
Created attachment 8952921 [details] [diff] [review]
[mozconfigs] add debug linux64 mozconfig (v2)

fixed crlfs
Attachment #8952282 - Attachment is obsolete: true
Attachment #8952921 - Flags: review+

Comment 21

8 months ago
Pushed by ewong@pw-wspx.org:
https://hg.mozilla.org/comm-central/rev/c52f5776e940
Add Linux64 debug mozconfig. r=frg
Status: ASSIGNED → RESOLVED
Last Resolved: 8 months ago
Resolution: --- → FIXED
(Assignee)

Updated

8 months ago
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 22

8 months ago
Created attachment 8952933 [details] [diff] [review]
[configs] enable linux64-debug, added env vars to linux64-debug and removed upload_symbols/packagetests
Attachment #8952281 - Attachment is obsolete: true
Attachment #8952933 - Flags: review+
(Assignee)

Comment 23

8 months ago
Created attachment 8952934 [details] [diff] [review]
[configs] enable linux64-debug (v3)

removed extra blank line.
Attachment #8952933 - Attachment is obsolete: true
Attachment #8952934 - Flags: review+
(Assignee)

Comment 24

8 months ago
Created attachment 8952938 [details] [diff] [review]
[configs] linux64 tests need test_tooltool_manifest file.

bustage fix patch.
(Assignee)

Updated

8 months ago
Status: REOPENED → ASSIGNED

Comment 25

8 months ago
Is there currently a bug "Provide 64-bit Seamonkey For All Platforms" which this one can be a blocker on?
No that is essentially the tracking bug. There is only Windows x64 left tracked in Bug 482143.
You need to log in before you can comment on or make changes to this bug.