Closed
Bug 528457
Opened 15 years ago
Closed 15 years ago
Always force components.list in partial updates (to reset content)
Categories
(Release Engineering :: General, defect)
Release Engineering
General
Tracking
(status1.9.2 beta4-fixed, status1.9.1 .6-fixed)
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
status1.9.2 | --- | beta4-fixed |
status1.9.1 | --- | .6-fixed |
People
(Reporter: whimboo, Assigned: nthomas)
References
Details
(Keywords: verified1.9.2)
Attachments
(2 files, 1 obsolete file)
2.52 KB,
patch
|
coop
:
review+
nthomas
:
checked-in+
|
Details | Diff | Splinter Review |
1.61 KB,
patch
|
bhearsum
:
review+
nthomas
:
checked-in+
|
Details | Diff | Splinter Review |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091112 Minefield/3.7a1pre (.NET CLR 3.5.30729)
As said on bug 519357 we want to update the components.list file for each update we roll-out to users. This seems not to work at the moment. If you modify or remove that file from the components folder we never revert the content to the original state or recreate that file.
It looks like that the mar files don't include a patch for that file for partial and complete updates.
Flags: blocking1.9.2?
Comment 1•15 years ago
|
||
Is this the application updater or something in the way we're generating files? I believe this might be a build config issue.
Flags: blocking1.9.2? → blocking1.9.2+
Reporter | ||
Comment 2•15 years ago
|
||
I checked the last-update.log and no components.list file has been processed. Looks really like a build config issue.
Component: Application Update → Build Config
Product: Toolkit → Core
QA Contact: application.update → build-config
Comment 3•15 years ago
|
||
This would be handled during mar generation and is similar to Bug 404340
Reporter | ||
Updated•15 years ago
|
Summary: Always include file components/components.list to partial/complete updates → Always include components.list in partial/complete updates (to reset content)
Assignee | ||
Comment 4•15 years ago
|
||
This belongs to RelEng, as we have we have to update the scripts that generate partial updates for nightlies and releases. As components.list is being packaged on mozilla-central it will be in the complete mar already.
I'll get to it next week if no-one beats me to it.
Component: Build Config → Release Engineering
Product: Core → mozilla.org
QA Contact: build-config → release
Summary: Always include components.list in partial/complete updates (to reset content) → Always force components.list in partial updates (to reset content)
Version: Trunk → other
Comment 5•15 years ago
|
||
(In reply to comment #4)
> This belongs to RelEng, as we have we have to update the scripts that generate
> partial updates for nightlies and releases. As components.list is being
> packaged on mozilla-central it will be in the complete mar already.
>
> I'll get to it next week if no-one beats me to it.
It's next week, so I'll toss this to you now :)
Throw it back if you don't want it, though.
Assignee: nobody → nrthomas
Assignee | ||
Comment 6•15 years ago
|
||
Force components/components.list using the patcher config for releases.
Attachment #413237 -
Flags: review?(bhearsum)
Assignee | ||
Comment 7•15 years ago
|
||
For nightlies we unfortunately have to touch the code in make_incremental_update.sh, as it currently only checks whether to force when the file differs. We want to always force the file if it's present in the "to" build.
I've done some testing on staging-nightly-updates and the only differences between partials generated with and without this patch are
* components/components.list is present, or replaces a components.list.patch file
* update.manifest has an |add "components/components.list"| instruction
I had to sort the manifest but I don't think that makes any difference.
This probably has to land in CVS HEAD, m-1.9.2, and m-c to catch all possible users of these scripts.
Attachment #413266 -
Flags: review?(ccooper)
Assignee | ||
Comment 8•15 years ago
|
||
Forgot to take account of mac being "special".
Attachment #413237 -
Attachment is obsolete: true
Attachment #413267 -
Flags: review?(bhearsum)
Attachment #413237 -
Flags: review?(bhearsum)
Updated•15 years ago
|
Attachment #413267 -
Flags: review?(bhearsum) → review+
Assignee | ||
Comment 9•15 years ago
|
||
Comment on attachment 413267 [details] [diff] [review]
Force components.list for 1.9.2 releases (v2)
Checking in moz192-branch-patcher2.cfg;
/cvsroot/mozilla/tools/patcher-configs/moz192-branch-patcher2.cfg,v <-- moz192-branch-patcher2.cfg
new revision: 1.14; previous revision: 1.13
done
Attachment #413267 -
Flags: checked-in+
Updated•15 years ago
|
Attachment #413266 -
Flags: review?(ccooper) → review+
Comment 10•15 years ago
|
||
Fixed?
Assignee | ||
Comment 11•15 years ago
|
||
Comment on attachment 413266 [details] [diff] [review]
Force components.list for nightlies
For the nightly update generator:
Checking in make_incremental_update.sh;
/cvsroot/mozilla/tools/update-packaging/make_incremental_update.sh,v <--
make_incremental_update.sh
new revision: 1.14; previous revision: 1.13
done
And updated
/builds/nightly-partial-generation/mozilla-checkout/\
README
mozilla/tools/update-packaging/make_incremental_update.sh
on prometheus-vm and staging-nightly-updates.
For completeness:
http://hg.mozilla.org/mozilla-central/rev/8265be625bb0
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/457c71bfd4ae
Attachment #413266 -
Flags: checked-in+
Assignee | ||
Updated•15 years ago
|
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Reporter | ||
Updated•15 years ago
|
status1.9.2:
--- → final-fixed
Comment 12•15 years ago
|
||
Also checked in on 1.9.1, because I'll need this for updates-on-slaves (bug 511967):
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/59125e2f683b
Reporter | ||
Comment 13•15 years ago
|
||
Chris, I assume we have to set the .6-fixed flag?
Assignee | ||
Comment 14•15 years ago
|
||
Henrik, did you deliberately set the status1.9.2 flag to "final-fixed" ? beta4-fixed is more appropriate I think.
Reporter | ||
Comment 15•15 years ago
|
||
Huh, I haven't changed that flag. No idea what happened here. Lets reset it and also add the flag for 1.9.1 as it seems to have been fixed there too - at least what comment 12 states.
status1.9.1:
--- → .6-fixed
Reporter | ||
Comment 16•15 years ago
|
||
Verified fixed for partial/complete (nightly/beta) updates on 1.9.2 for builds on OS X and Windows due to the different paths:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b5pre) Gecko/20091126 Namoroka/3.6b5pre (.NET CLR 3.5.30729) ID:20091126051330
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b5pre) Gecko/20091126 Namoroka/3.6b5pre ID:20091126033851
Keywords: verified1.9.2
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•