Expose x86_64 Linux builds on the download pages

VERIFIED FIXED

Status

enhancement
VERIFIED FIXED
10 years ago
6 years ago

People

(Reporter: blueser, Assigned: kohei)

Tracking

(Blocks 1 bug, {polish, ux-discovery})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [kb=1247618] u=user c=ux p=, )

Attachments

(2 attachments, 7 obsolete attachments)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091105 Fedora/3.5.5-1.fc11 Firefox/3.5.5
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091105 Fedora/3.5.5-1.fc11 Firefox/3.5.5

I have x86_64 Linux (Fedora) installed, and I can never beta test Firefox because only x86 versions are provided -- installing these would require pulling x86 versions of lots of x86_64 libs that are already installed.

Reproducible: Always

Steps to Reproduce:
1. go to beta downloads page
2.
3.
Actual Results:  
Only x86 versions are available.

Expected Results:  
x86_64 versions should be available as well.

If I try to run 3.6b2 binary it can't find libgtk-x11-2.0.so.0 :

/usr/local/firefox-3.6beta/firefox/firefox-bin: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory

Problem is that the x86_64 version is installed:

~ locate libgtk-x11-2.0.so.0
/usr/lib64/libgtk-x11-2.0.so.0
/usr/lib64/libgtk-x11-2.0.so.0.1600.6

The x86 versions can be found on package gtk2.i586 on Fedora. Installing it pulls another 11 libs. Even if I install it, Firefox then starts complaining about other libs:

/usr/local/firefox-3.6beta/firefox/firefox-bin: error while loading shared libraries: libdbus-glib-1.so.2: cannot open shared object file: No such file or directory

And the story goes on... :-( As much as I'd like to help with beta-testing, I won't do it if I have to duplicate dozens of libs. Considering x86_64 is becoming the standard architecture with the broad availability of multi-core machines, I believe it's a mistake to neglect it, specially when it comes to beta-testing.
That's definitely better than nothing. But, since you already build them, why not provide them officially when a version is tagged as beta? Dealing with a beta is already "risky" enough, why complicate things even further by pushing people towards nightly builds?
Sending to releng as a first approximation.
Component: General → Release Engineering
Product: Firefox → mozilla.org
QA Contact: general → release
Version: unspecified → other
They are produced for Fx4.0 beta's too, eg
 http://releases.mozilla.org/pub/mozilla.org/firefox/releases/4.0b8/linux-x86_64/
but not promoted on the website. Over to Websites/mozilla.com, where this will probably get duped against another bug.
Component: Release Engineering → www.mozilla.com
Product: mozilla.org → Websites
QA Contact: release → www-mozilla-com
Duplicate of this bug: 621828
Duplicate of this bug: 597739
Are we planning to 'advertise' the linux64 builds in pages like all.html and in download boxes for Firefox 4.0 ?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Duplicate of this bug: 644261
Summary: Please provide betas for x86_64 Linux → Expose x86_64 Linux builds on the download pages
I stand by my comment in the dupe Bug 644261 that because system plugins don't load with the wrong binary this is more than just a feature request--things won't work for the majority of users on x86-64 who upgrade via a direct download.
I don't understand the resistance to fixing this. I don't know of a Linux distribution that doesn't provide x86_64 builds by default on their x86_64 installs, so it can't be a stability issue. And I expect that the implementation would be trivial. Is there no chance of this being addressed in the near future?
I would think the issue here is, are the 64-bit Linux Firefox 4 builds Official releases or not?

If they are then there need to be links to them from the official downloads site.  If they are not then they should not be included in the releases directory on the FTP site.

I also think that the main downloads page should detect the OS and if it is 64-bit offer both 32-bit and 64-bit downloads either via 2 buttons or a select box.  Of course for a 32-bit OS only the 32-bit version should be offered.
Duplicate of this bug: 654404
My bug got marked as a duplicate, but I guess it actually extends this one. I reported the issue with regards to a proper release (4.0.1) and not a beta / nightly.

Since x86 FF simply doesn't work on my 64b system without hunting down some unrelated third-party libraries in x86 version, I see it as a bug - same as comment #9
Duplicate of this bug: 670518
It's been almost two years since this bug was opened. Has no official position been reached?

Running 32 bit versions of Firefox in Linux x64 systems is quite complicated, and some distros ship very old versions of the browser (e.g. Debian), so their users might resort to downloading Firefox directly (as I do).
In these circumstances, after discovering that the downloaded version does not work, users have to navigate the ftp (if they know it exists) and guess the right version they need, while avoiding automatic redirects to the Aurora/Beta download page (should they be looking for an unreleased version) or similar obstacles.

There are few other ways to keep up with the latest Firefox version, and I'd rather get the right version from Firefox than backport repos I'm not willing to trust.
Take into account that frustrated users might jump ship and get Chrome, which offers 64 binaries right away (deb and rpm).
Duplicate of this bug: 678875
FWIW, there are "official Mozilla" Firefox builds for Linux x86_64; their download page is (IIUC) at http://releases.mozilla.org/pub/mozilla.org/firefox/releases/latest/linux-x86_64/

The problem is just getting there from the Firefox portal.
Keywords: polish, ux-discovery
Re: Comment 17: I'm not sure which angle you're coming at it from, but the fact that there /are/ official builds but they're /not/ published is what makes so emotionally irritating.
Posted patch first shot at a patch (obsolete) — Splinter Review
In reply to comment #18: The angle I'm coming from is that:
- Whining leads nowhere; if anything, it probably *reduces* the probability of seeing the bug fixed someday soon;
- Anyone coming here with the complaint that there are no linux64 builds to be found will (if he reads comment #17) know where to go get them.

In addition, and in the hope of seeing some progress in this bug, I'm proposing a patch for http://www.mozilla.com/en-US/firefox/all.html

This doesn't mean that I'm assigning this bug to myself (I'm not, I don't think I'm fully qualified for that), it's just so that whoever does someday take this bug shall have something to build upon (or, as the case may be, to break down).
Comment on attachment 553085 [details] [diff] [review]
first shot at a patch

That page is dynamically generated. You'll need to edit the code that creates that page. Considering win64 is basically becoming a tier 1 platform as well, should just add support for x86_64 in general and offer Linux and Windows 64-bit versions for users visiting with a 64-bit platform.
Attachment #553085 - Flags: review-
I think that at most Win64 users should be given an option to go to a 64-bit download page for now, rather than being shown one by default. Major plugins, namely Flash, are to the best of my knowledge not yet available for 64-bit Windows.
Win64 isn't a supported platform for releases yet, there are just some machines producing nightly builds for development purposes, so offering even a download option on mozilla.com would be premature. That said, I agree with reed that having 64bit support in general will be useful to have.
(In reply to Reed Loden [:reed] (very busy) from comment #20)
> Comment on attachment 553085 [details] [diff] [review]
> first shot at a patch
> 
> That page is dynamically generated. You'll need to edit the code that
> creates that page. Considering win64 is basically becoming a tier 1 platform
> as well, should just add support for x86_64 in general and offer Linux and
> Windows 64-bit versions for users visiting with a 64-bit platform.

I don't know how or where this page is generated, so someone else will have to do that. The code for W64 could be written at the same time, but maybe commented-out for the time being, until that platform becomes "officially" supported.

(In reply to Nick Thomas [:nthomas] from comment #22)
> Win64 isn't a supported platform for releases yet, there are just some
> machines producing nightly builds for development purposes, so offering even
> a download option on mozilla.com would be premature. That said, I agree with
> reed that having 64bit support in general will be useful to have.

As long as W64 isn't "officially" supported, I suppose a single link somewhere near the bottom (together, maybe, with the "localized versions in testing", or even below them) and pointing to some download page (I couldn't find one on either releases.mozilla.org or ftp.mozilla.org but maybe it's even more confidential) would be OK, possibly with a warning that these are development versions, not as dependable as the "official" versions on the rest of the page.
P.S. Ah, I found some nightlies at least: Nightly nightlies only, no Aurora nightlies yet.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-8.0a1.en-US.win64-x86_64.installer.exe
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-8.0a1.en-US.win64-x86_64.zip
and as the same place as the w32 Nightly nigtlies, so linking them from the "public" Firefox portal for releases is perhaps premature.
The links in comment 24 are exposed here:
https://nightly.mozilla.org/

But when the code that built those versions gets migrated to Aurora it's not official anymore by a reason that is not absolutely clear to me, despite reading the previous comments.
(In reply to Thomas Ahlblom from comment #25)
> But when the code that built those versions gets migrated to Aurora it's not
> official anymore by a reason that is not absolutely clear to me, despite
> reading the previous comments.

See comment 22 - win64 is only for *development* purposes at the moment. We don't even have our full test suite being run on them in a way which all developers will check.
(In reply to Mark Banner (:standard8) from comment #26)
> 
> See comment 22 - win64 is only for *development* purposes at the moment. We
> don't even have our full test suite being run on them in a way which all
> developers will check.

Is the Linux x86_64 build also for development purposes, or is it passing the testsuite?

If it is not passing the test suite then I guess it makes sense to not expose it as a download option. 

If it is passing the test suite, it would be great if this bug could be progressed for Linux users and marked as assigned.

Thanks,
Anand
As has already been stated, Linux x86_64 is a supported platform, with supported Beta, Aurora, and release builds, along with update channels for those builds. It is the version distributed by most distributions on x86_64 architectures.
IMHO it's still confusing to users to provide "multiple variants of the release for the same OS" on a download page. A normal user should never need to know how many bits of memory addresses (etc.) his OS uses. If he needs to, something went wrong in designing computers and software.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #29)
> IMHO it's still confusing to users to provide "multiple variants of the
> release for the same OS" on a download page. A normal user should never need
> to know how many bits of memory addresses (etc.) his OS uses. If he needs
> to, something went wrong in designing computers and software.

As long as (unlike on Mac) we have separate L32 and L64 builds, both official, the "All systems and languages" page should offer both; OTOH the front-page portal (with one big breen button, supposedly for the platform you're already using) should offer the 32-bit build to 32-bit users and the 64-bit build to 64-bit users. If someday we can offer a Linux "universal build" (a concept foreign to most Linux users' and distributors' mindset), it may become a different question.

Similarly, when I use openSUSE YAST for "Online Update", it normally offers any available updates for installed packages in their installed architecture (usually x86_64, or sometimes noarch) and from the same "Vendor" as the installed package; but on the "Versions" tab (for any package, installed or not, e.g. after a Search) I can see all versions available for all architectures (often both i586 and x86_64) on all enabled repositories.
Duplicate of this bug: 717601
(In reply to Tyler Downer [Triage] (away) from comment #1)
Sadly the unexpert user cant find the right link.
I could add my little bit of advice.

When I go on https://www.mozilla.org/en-US/firefox/channel/ (and this is the same for the french version https://www.mozilla.org/fr/firefox/channel/) and I'm already using a x86_64 version of Firefox, I really expect to get offered the x86_64 version.

But the direct link for Aurora is to the i686 versions, and the links to download.mozilla.org redirect also to the i686 versions.

I think that, at least when I'm already using the x86_64 flavor, I should be able to download easily the x86_64 version.
I agree with the above comments. I really need to be directed to x86_64 versions.
I tried here: http://www.mozilla.org/en-US/firefox/new/
and here: https://www.mozilla.org/en-US/firefox/channel/

Default is i686 on 64-bit Linux.
At minimum there neads to be a single link saying 64-bit Linux builds are available here http://releases.mozilla.org/pub/mozilla.org/firefox/releases/10.0/linux-x86_64/
OK, so this all comes down to modifying the web pages offering firefox. The question is: where are those web pages stored? Anyone with knowledge of HTML and javascript should be able to create a patch fixing this issue, to be later integrated in Mozilla's site.

I've run a quick check on Firefox's repository and found nothing related to web pages, so it must be some external repo. Is it publicly available?
I've cced some people from the Web team.

The source code is available at https://svn.mozilla.org/projects/mozilla.com/ and http://svn.mozilla.org/libs/product-details/. product-details is where the logic to know which versions are available lives.

I'm not sure this is fixable for all cases though since the user-agent has to expose the 64-bit information. Looks like Firefox gives it : https://developer.mozilla.org/en/Gecko_user_agent_string_reference#Linux
(In reply to Anthony Ricaud (:rik) from comment #37)
> The source code is available at
> https://svn.mozilla.org/projects/mozilla.com/ and
> http://svn.mozilla.org/libs/product-details/. product-details is where the
> logic to know which versions are available lives.

Thanks for the URLs. I have checked those files and created a patch for firefoxDetails.class.php and productDetails.class.php which would expose 'Linux x86_64' builds in "all.html" (All systems and languages page) and directly provide the corresponding build in the main download page, if JavaScript detects the user agent and reports it as 'Linux x86_64'. So far, I have not touched the Javascript for that.
The changes are pretty minor, mostly consisting of adding a new variable or string, plus adapting a colspan and a couple of HTML elements.

The thing is, how do I go about testing these changes? As far as I can tell, the Try Server is only for Firefox development per se, and there seems to be no web pages Try Server. BugZilla estates quite clearly that no untested patches should be attached to a bug, so if someone with access to a test replica of Mozilla's servers wants to give it a try, I can provide the patch.

Things I've found while making the changes:
 - Firefox and Thunderbird's download pages share quite a lot of the PHP backbone, so this change affects both. This means that Thunderbird will also present a fourth column for Linux x86_64 builds, which will be completely empty until the script generating thunderbirdBuildDetails.class.php is updated to detect and include x64 builds. I'm not sure how the direct download link will behave for Thunderbird if a linux x64 user agent is detected.

- The list of builds in firefoxDetails.class.php must be manually edited to expose these builds for all locales. File sizes seem to be greatly outdated, so it won't be necessary to get them all right. So far I've only added the entries for en-US and en-GB, so we can test how things behave when a locale has no x64 build.

- There are no x86_64 builds for Firefox 3.6, so in the event of detecting a linux x64 user agent, the script should provide the x86 build. A special case needs to be created for this, if downloads of 3.6 are still supported somewhere.
By the way, the changes done to those two files also affect Beta and Aurora builds (as the original post in this bug report requested), so the channels page would probably offer the 64bit versions of Linux to people with a User Agent identified as 'Linux x86_64'.
(In reply to Elideb from comment #38)
> The thing is, how do I go about testing these changes? As far as I can tell,
> the Try Server is only for Firefox development per se, and there seems to be
> no web pages Try Server. BugZilla estates quite clearly that no untested
> patches should be attached to a bug, so if someone with access to a test
> replica of Mozilla's servers wants to give it a try, I can provide the patch.

Please do feel free to attach a patch. I'm happy to test and/or review it.

> Things I've found while making the changes:
>  - Firefox and Thunderbird's download pages share quite a lot of the PHP
> backbone, so this change affects both. This means that Thunderbird will also
> present a fourth column for Linux x86_64 builds, which will be completely
> empty until the script generating thunderbirdBuildDetails.class.php is
> updated to detect and include x64 builds. I'm not sure how the direct
> download link will behave for Thunderbird if a linux x64 user agent is
> detected.

http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/latest/linux-x86_64/ says they do have x86_64 builds, so we just need to expose them as well.

> - The list of builds in firefoxDetails.class.php must be manually edited to
> expose these builds for all locales. File sizes seem to be greatly outdated,
> so it won't be necessary to get them all right. So far I've only added the
> entries for en-US and en-GB, so we can test how things behave when a locale
> has no x64 build.

Yeah, I gave up trying to maintain file sizes a long time ago. I have a script somewhere that can do it, though. Don't concern yourself with that small detail for now.

> - There are no x86_64 builds for Firefox 3.6, so in the event of detecting a
> linux x64 user agent, the script should provide the x86 build. A special
> case needs to be created for this, if downloads of 3.6 are still supported
> somewhere.

That's a good question... I think the new ESR builds will replace 3.6. I will check into that.
Have you asked the Firefox Product managers if they want to advertise those 64 bits builds? Do they have equivalent performance to our 32bits version? Do they have the same level of QA than our 32 bits version? etc.
(In reply to Pascal Chevrel:pascalc from comment #41)
> Have you asked the Firefox Product managers if they want to advertise those
> 64 bits builds?

No, I haven't. Should they be CC'ed so we can have their input in this issue? Or contacted by mail/IRC?

> Do they have equivalent performance to our 32bits version?
> Do they have the same level of QA than our 32 bits version? etc.

As indicated in comment #28 Linux x86_64 builds are officially supported and tested. That's why they reside in the Releases branch in the FTP, unlike Windows x64 builds of Firefox.


(In reply to Reed Loden [:reed] (very busy) from comment #40)
> (In reply to Elideb from comment #38)
> > Things I've found while making the changes:
> >  - Firefox and Thunderbird's download pages share quite a lot of the PHP
> > backbone, so this change affects both. This means that Thunderbird will also
> > present a fourth column for Linux x86_64 builds, which will be completely
> > empty until the script generating thunderbirdBuildDetails.class.php is
> > updated to detect and include x64 builds. I'm not sure how the direct
> > download link will behave for Thunderbird if a linux x64 user agent is
> > detected.
> 
> http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/latest/
> linux-x86_64/ says they do have x86_64 builds, so we just need to expose
> them as well.

The problem is that those builds are not included in the details list for Thunderbird. The file thunderbirdBuildDetails.php, which contains the list of locales and platforms to expose, is generated using the script

http://hg.mozilla.org/users/bugzilla_standard8.plus.com/drivertools/file/default/website/generateThunderbirdDetails.py

which should be updated to manage Linux x64 builds too. I think that should be treated in a different bug, as it resides in a completely different component.
Patch to productDetails.class.php and firefoxDetails.class.php.
To apply, from http://svn.mozilla.org/libs/product-details/ run:
patch -p0 <expose_linux_x86_64.v0.diff

Changes:
Include a new column in all.html, titled 'Linux x86_64', including links to said Firefox builds for all locales with 64bit builds available.
Also create the corresponding Linux 64bit link for the direct download button if the proper user agent is reported (Linux x86_64). User Agent detection has not been updated to do so, so i686 builds will still be provided for 64bit users.
Only en_GB and en_US locales have details for Linux x86_64 builds, so far, for testing purposes.

Concerns:
This changes also affect Thunderbird download pages, since both projects share code. To expose Thunderbird x86_64 builds, please add support for them in
http://hg.mozilla.org/users/bugzilla_standard8.plus.com/drivertools/file/default/website/generateThunderbirdDetails.py
and run the script to update thunderbirdBuildsDetails.php
(In reply to Elideb from comment #42)
[...]
> (In reply to Reed Loden [:reed] (very busy) from comment #40)
> > (In reply to Elideb from comment #38)
> > > Things I've found while making the changes:
> > >  - Firefox and Thunderbird's download pages share quite a lot of the PHP
> > > backbone, so this change affects both. This means that Thunderbird will also
> > > present a fourth column for Linux x86_64 builds, which will be completely
> > > empty until the script generating thunderbirdBuildDetails.class.php is
> > > updated to detect and include x64 builds. I'm not sure how the direct
> > > download link will behave for Thunderbird if a linux x64 user agent is
> > > detected.
> > 
> > http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/latest/
> > linux-x86_64/ says they do have x86_64 builds, so we just need to expose
> > them as well.
> 
> The problem is that those builds are not included in the details list for
> Thunderbird. The file thunderbirdBuildDetails.php, which contains the list
> of locales and platforms to expose, is generated using the script
> 
> http://hg.mozilla.org/users/bugzilla_standard8.plus.com/drivertools/file/
> default/website/generateThunderbirdDetails.py
> 
> which should be updated to manage Linux x64 builds too. I think that should
> be treated in a different bug, as it resides in a completely different
> component.

For Thunderbird, see bug 678877.
There may be a corresponding bug for SeaMonkey but I can't find it back ATM.
For SeaMonkey, see bug 691752.
SeaMonkey is, however, in a little worse shape, since 64bit builds don't seem to be official yet. And I can't tell if SeaMonkey uses the same scripts to generate its download pages.
The same as previous patch 594139, but instead of adding a new column in the Systems and Languages page, if a locale has a 64bit build available an extra download link "Download (64bit)" is shown below the 32bit download link.

This prevents showing lots of "Not yet available" if many locales for Firefox or Thunderbird are 32bit only. Also, it makes easier to add Win x64 builds in the future without making the locales page too wide.

Which version to use is up to the Web Design people.
(In reply to Elideb from comment #45)
> SeaMonkey is, however, in a little worse shape, since 64bit builds don't
> seem to be official yet. And I can't tell if SeaMonkey uses the same scripts
> to generate its download pages.

SeaMonkey is a separate project with a separate team and website and uses separate stuff. Also, due to infrastructure shortage, as you saw, it doesn't even have 64bit up as "official" yet, so don't concern yourself with SeaMonkey here, its own team will when they'll be ready.
(In reply to Pascal Chevrel:pascalc from comment #41)
> Have you asked the Firefox Product managers if they want to advertise those
> 64 bits builds? Do they have equivalent performance to our 32bits version?
> Do they have the same level of QA than our 32 bits version? etc.

Certainly, for a while now, a majority of Linux users are on 64bit distros, because most distros like Ubuntu advertise their 64bit versions as "for most computers" and their 32bit versions as "for old computers". And on 64bit, they do ship 64bit Firefox. That's the case of Ubuntu at least.

Us not supporting 64bit Linux builds officially means we fail to support what is de facto being used on Linux! Dangerous disconnect from reality. If really our 64bit builds have a performance or QA deficit, that would be our problem and we'd need to fix it. But since that's what most people use anyway, we're not making anything worse by officially supporting and advertising these builds.
fedora no longer offers a 32-bit version of Firefox if you are running 64-bit fedora.
In fact, 64bit linux is now officially supported as a tier-1 platform:
https://developer.mozilla.org/en/Supported_build_configurations

so it doesn't make sense to me at all, that we're still not exposing it like the 32bit version.
Component: www.mozilla.org/firefox → www.mozilla.org
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
Posted image Alternatives to fixing the bug (obsolete) —
Visual alternatives for fixes. Refer to each by the specific language.
Posted image Alternative fixes for the bug (obsolete) —
Proposed fix, requiring increment to page width. Arabic is properly displayed for width of >1030 in div doc and >750px for main-content.
I'm looking into fixing this bug, but I'm having trouble finding the current way to generate the whole all.html page for the bedrock platform (it still created from the old PHP scripts, some of which I cannot locate). If anyone can direct me to the script used for that, I'd be really glad.

Meanwhile, I'm attaching images with different alternatives to fixing the bug. Please, give feedback regarding the preferred solution.
My favourites are Acholi and Albanian. Acholi, however, needs one more column per 64 bit platform, so adding Windows 64bit in the future would result in a considerably wider page.
Arabic would be the way to go if the content area could be wider (take some space from the search form, or simply make the page wider.
Well, how many builds will we eventually need to advertise? Mac is already taken care of, since the Mac builds are actually "Universal builds" for Intel-32 and Intel-64 now that PPC isn't supported anymore. There are already Linux-32 and Linux-64 builds being built but the page doesn't yet advertise the L64 ones; for W64 we're farther from the goal but it is the intention to support them someday, see bug 558448. This makes a foreseeable total of 5 different platforms: L32, L64, M-Universal, W32 and someday W64.

What takes up width is the word "Download" repeated all over the place. Wouldn't it be possible to allocate more columns by making them narrower, moving the word "Download" out from all cells of the table and into a caption or something? Maybe (if we go all hog) with column titles like "W32" "W64" "Mac" "L32" "L64" and just an icon for each available build; or for a little more generosity, titles "Windows" (someday 2 columns) "Mac" (1 column) "Linux" (2 columns) and in the table, (W)32 (W)64 (M)Uni (L)32 (L)64 where (W) represents a quartered flag, (M) a smiling head, (L) a penguin respectively. Of course W64 builds wouldn't be advertised before we are ready with them, but we should make it easy to add them once they are released.
Another alternative, featuring a 2 level (fake) header for the builds table.
Each configuration has its very own column, one for Mac (Universal), two for both Windows and Linux (32 and 64bit). Windows would remain 32bit only for the time being.

It is a bit crude and the labels can be certainly improved (is Universal appropriate for Mac, if builds are not supported in PPC computers? any ideas for the "Download" replacement?). But it respects the original table size and includes more information in a more compact form.
On the Mac, a "Universal build" is a build containing more than one binary executable meant for different processors. Originally it was PPC Motorola and Intel-32, now (for Mozilla applications at least) it's Intel-32 and Intel-64. DISCLAIMER: I am not a Mac user.
Elideb, 
It looks like we'll need to address a couple issues/tasks to move forward. Please let me know if I'm missing or misinterpreting anything.

1. Need Fx product to signoff on adding this build to this page (I can follow up on that).

2. Need to tweak the layout/UI to fit this link in.

3. Port the page to bedrock.

I'll add this to the Wed Prod backlog and we can triage this. Also, I'll look into getting someone to assist with your Bedrock issues. It would be great if you could and want to implement these changes.
Whiteboard: u=user c=ux p=
Alexis,
If Product approves of the inclussion soon, I guess all work will be done in 808762. If, however, approval is not received on time, I can take care of the issue once the new scripts/page is up in GitHub. I'll try to help with that bug, anyway.

Another issue is checking if "Linux x86_64" user agents are properly detected by the bedrock site, but that would affect a different bug, which would be something like "Offer Linux x86_64 builds as direct download for the corresponding user agents."
Why does this need Product approval? The decision to make Linux x86_64 a Tier 1 platform was taken during the Firefox 4 development cycle. It’s merely a limitation of the Web site that you can’t actually download the x86_64 via the Web site.
Duplicate of this bug: 728192
See Also: → 809697
As discussed in bug 808762's page, the new version of the Systems & Languages page will roll out without Linux x86_64 support, which will be added later.
Thus this bug is blocked until the Sandstone version is finished. Could someone with the proper permissions update the block information in 808762?
Preliminar version, with mockup art, of the "Systems & Languages" page is available at https://github.com/Elideb/bedrock. Remember to add some Linux64 entries to firefox_primary_builds.json or firefox_beta_builds.json.

Example:
"ach":{"19.0a2":{"Windows":{"filesize":0},"OS X":{"filesize":0},"Linux":{"filesize":0},"Linux64":{"filesize":6.1}},"18.0b7":{"Windows":{"filesize":7.8},"OS X":{"filesize":19},"Linux":{"filesize":9.6},"Linux64":{"filesize":6.1}},"17.0.1":{"Windows":{"filesize":7.8},"OS X":{"filesize":19},"Linux":{"filesize":9.6},"Linux64":{"filesize":6.1}}}

New art is needed for the unavailable icon and, ideally, for the Linux64 icon.
I'd be glad if someone could run additional tests of a running server from diverse platforms (Windows 32 and 64bits, Linux x86_64 and x86...). Due to browser server caching I'm not sure I've tested things all that thoroughly.
Posted image Capture of Linux64 builds in all.html (obsolete) —
Attachment #678508 - Attachment is obsolete: true
Attachment #678510 - Attachment is obsolete: true
Attachment #678904 - Attachment is obsolete: true
How can I try this from a running server ?
Check the guides in http://bedrock.readthedocs.org/en/latest/ to create a local server of bedrock. You'll also need to add Linux64 entries in your local version of lib/product_details_json/firefox_primary_builds.json or firefox_beta_builds.json.
In case of doubt, ask in #webdev in mozilla's IRC.

Be advised that those intructions are mainly intended for Linux and MacOS. I haven't been able to successfully install and run bedrock in Windows (I haven't put much effort into it yet, to be honest).
This bug now has its own branch: https://github.com/Elideb/bedrock/tree/bug-527907-expose-linux-x86_64

It depends on another fix which is in pull request (bug #827133).
This bug should be made dependant on bug 828072, asking to add Linux64 entries to product details once doing so won't break the site.
Duplicate of this bug: 863131
Currently all Linux-ready locales have 64-bit builds. So, as I wrote in Bug 809697, this enhancement can be implemented without having to modify product details. I sent a simple pull request to resolve this on Bedrock.
Assignee: nobody → kohei.yoshino
Attachment #553085 - Attachment is obsolete: true
Attachment #594139 - Attachment is obsolete: true
Attachment #594197 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Whiteboard: u=user c=ux p= → [kb=1247618] u=user c=ux p=
No longer depends on: 828072
Duplicate of this bug: 965536
Commit pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/042094fbfaa9a225e28aa0d93a2bc8484a459dfb
Fix Bug 527907 - Expose x86_64 Linux builds on the download pages
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
(In reply to raymond [:retornam] (needinfo? me) from comment #73)
> fixed on stage https://www.allizom.org/en-US/firefox/all/

Fixed on http://www.mozilla.org/en-US/firefox/all/
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.