Closed Bug 1083357 Opened 10 years ago Closed 10 years ago

Bump size limit for signing mar files

Categories

(Release Engineering :: General, defect, P2)

x86_64
macOS

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: piecu, Assigned: nthomas)

References

Details

Attachments

(1 file)

There are no latest pl localization builds for Firefox Nightly for mac on FTP: ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central-l10n/ (they exist only for linux and win32). They are however for other locales (I believe that only pl is missing).
The relevant log is at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-10-15-03-02-02-mozilla-central-l10n/mozilla-central-macosx64-l10n-nightly-pl-bm82-build1-build4538.txt.gz and the error is:

2014-10-15 07:54:09,887 - 55263dfab0ffcd6d6a75950cbde1539f775d59e6: processing /builds/slave/m-cen-osx64-l10n-ntly-00000000/build/mozilla-central/obj-firefox/i386/dist/update//firefox-36.0a1.pl.mac.complete.mar on https://signing4.srv.releng.scl3.mozilla.com:9100
2014-10-15 07:54:09,903 - 55263dfab0ffcd6d6a75950cbde1539f775d59e6: uploading for signing
2014-10-15 07:54:18,345 - 55263dfab0ffcd6d6a75950cbde1539f775d59e6: error uploading file for signing: 400 File too large

From the build machine the file size is 94543024 bytes, and the limit for signing is 94371840 bytes.

We need to increase http://hg.mozilla.org/build/puppet/file/default/modules/signingserver/templates/signing.ini.erb#l29

We seem to be fine on the dmg limit still.
Component: Build Config → Tools
Product: Firefox → Release Engineering
QA Contact: hwine
Summary: No pl builds for latest nightly localization of Firefox for mac → Bump size limit for signing mar files
Version: Trunk → unspecified
Assignee: nobody → nthomas
Priority: -- → P2
The universe keeps expanding, so do our nightlies.
Attachment #8506574 - Flags: review?
Comment on attachment 8506574 [details] [diff] [review]
[puppet] Bump mar limit from 90 to 95MB

it's not a huge increase so I'm not worried and don't want to block. But as I am not the best one to review, it's probably worth following up on what happens if this limit goes *too* high. catlee, why do we set limits here?
Flags: needinfo?(catlee)
Attachment #8506574 - Flags: review? → review+
Will be deployed within an hour.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
(In reply to Jordan Lund (:jlund) from comment #3)
> it's not a huge increase so I'm not worried and don't want to block. But as
> I am not the best one to review, it's probably worth following up on what
> happens if this limit goes *too* high. catlee, why do we set limits here?

We set limits to avoid situations like we had with l10n where due to improper cleanup, we ended up repacking the files from the previous iteration of the repack into the current repack. This compounded the size of the repack quite quickly, especially if it happened more than once in a row.

See https://bugzilla.mozilla.org/show_bug.cgi?id=938075 for an example.

I don't think we've ever seen it on Mac, but it's good to at least have some conception of how much we're forcing our users to download.
Flags: needinfo?(catlee)
Status: RESOLVED → VERIFIED
Depends on: 1169937
We need to bump the size up again, en-US & localised builds are hitting the limit. I'll clone this one rather than reuse it though.
No longer depends on: 1169937
Blocks: 1170361
No longer blocks: 1170361
Bug 1170361 for the new issue.
Component: Tools → General
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: