Closed Bug 508963 Opened 15 years ago Closed 14 years ago

Signing Makefile shouldn't rely on xpi's being present

Categories

(Release Engineering :: General, defect, P5)

Product:
Release Engineering
Component:
General
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: catlee, Assigned: bhearsum)

References

Details

(Whiteboard: [oldbugs][signing])

In the 3.6a1 release, the sign-files step failed because it tried to copy some non-existent xpi files from the unsigned directory into the signed directory. This release didn't have any xpi files generated => FAIL.
You could argue that fixing bug 485860 would make this a non-bug, because it would ensure we always had an win32/xpi directory regardless of whether l10n was being built or not.
Component: Release Engineering → Release Engineering: Future
Mass move of bugs from Release Engineering:Future -> Release Engineering. See http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.
Component: Release Engineering: Future → Release Engineering
Priority: -- → P3
Whiteboard: [signing]
Assignee: nobody → bhearsum
Whiteboard: [signing] → [triage][oldbugs]
Whiteboard: [triage][oldbugs] → [triage][oldbugs][signing]
Priority: P3 → P5
Whiteboard: [triage][oldbugs][signing] → [oldbugs][signing]
(In reply to comment #1) > You could argue that fixing bug 485860 would make this a non-bug, because it > would ensure we always had an win32/xpi directory regardless of whether l10n > was being built or not. I agree with this 100%. I don't think it's worth fixing this unless we have a future situation where a release signed with these scripts legitimately doesn't have XPIs. I'll resolve this as WFM when bug 485860 has landed.
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 14 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.