Closed Bug 758064 Opened 12 years ago Closed 12 years ago

win32 repacks fail due to badly formed command line

Categories

(Release Engineering :: Release Automation: Other, defect, P3)

x86
Windows 7
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: hwine, Assigned: rail)

References

Details

Attachments

(1 file, 1 obsolete file)

found in FF 13.0b5:

win32 repack logs fail trying to run command "d;\mozilla-build\python27\python.exe \e\builds\moz2_slave\rel-m-beta-w32-rpk-3\scripts\release\signing\signtool.py --cachedir \e\builds\moz2_slave\rel-m-beta-w32-rpk-3\signing_cache -t \e\builds\moz2_slave\rel-m-beta-w32-rpk-3\token -n \e\builds\moz2_slave\rel-m-beta-w32-rpk-3\nonce -c \e\builds\moz2_slave\rel-m-beta-w32-rpk-3\scripts\release\signing\host.cert -H signing1.build.scl1.mozilla.com;9120 -H signing2.build.scl1.mozilla.com;9120 -f signcode -f gpg "l10ngen/setup.exe"
Attachment #626623 - Flags: review?(nrthomas)
Kind of leaning towards backing out https://bugzilla.mozilla.org/show_bug.cgi?id=743304 now.
Attachment #626623 - Attachment is obsolete: true
Attachment #626623 - Flags: review?(nrthomas)
Attachment #626632 - Flags: review?(nrthomas)
Attachment #626632 - Flags: review?(nrthomas) → review+
Hal: You need to update+reconfig bm13.  Hopefully the rebuild of those repacks will work at that point.
win32 repacks successful on 13.0b5
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
huh, colons are replaced by semicolons... very strange...
I think so.

From that link:

    An argument that doesn't start with -, ", ', or @ and contains a : followed by /, :,
    or .; and a / is considered a POSIX path list. Every :-separated element is converted
    according to these rules, and the : are replaced with ;. Any / are converted to \.

The ports are also converted to ;'s :

    -H signing1.build.scl1.mozilla.com;9120

I thought about changing this to /d/mozilla-build/... but thought backing out would be safer given the importance of getting 13.0b5 out for QA.

We could also consider putting everything in quotes in MOZ_SIGN_CMD, which is currently

MOZ_SIGN_CMD=d:/mozilla-build/python27/python.exe /e/builds/moz2_slave/rel-m-beta-w32-rpk-5/scripts/release/signing/signtool.py --cachedir /e/builds/moz2_slave/rel-m-beta-w32-rpk-5/signing_cache -t /e/builds/moz2_slave/rel-m-beta-w32-rpk-5/token -n /e/builds/moz2_slave/rel-m-beta-w32-rpk-5/nonce -c /e/builds/moz2_slave/rel-m-beta-w32-rpk-5/scripts/release/signing/host.cert -H signing1.build.scl1.mozilla.com:9120 -H signing2.build.scl1.mozilla.com:9120

This will be difficult, since it's re-exported in a bash shell script:
http://hg.mozilla.org/build/tools/file/8792673bce2a/scripts/l10n/release_repacks.sh#l53

I'm tempted to defer to bug 740142 but there's gotta be a way we can fix this.
The good repack doesn't replace the port colons with semi-colons.
So I'd say setting PYTHON26 to /d/mozilla-build/ has a good chance of working here, assuming it doesn't break anything else.
(In reply to Chris AtLee [:catlee] from comment #16)
> maybe msys is doing it? http://www.mingw.org/wiki/Posix_path_conversion

Reopening this and closing bug 743304.
Assignee: nobody → rail
Status: RESOLVED → REOPENED
Priority: -- → P3
Resolution: FIXED → ---
Since we have switched to win64 builders and they use more fresh version of python which doesn't require PYTHON26 env variable, I'm resolving it as WFM
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → WORKSFORME
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: