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.
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+
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
This would be handled during mar generation and is similar to Bug 404340
Summary: Always include file components/components.list to partial/complete updates → Always include components.list in partial/complete updates (to reset content)
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
(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
Created attachment 413237 [details] [diff] [review] 1.9.2 releases Force components/components.list using the patcher config for releases.
Created attachment 413266 [details] [diff] [review] Force components.list for nightlies 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)
Created attachment 413267 [details] [diff] [review] Force components.list for 1.9.2 releases (v2) Forgot to take account of mac being "special".
Attachment #413267 - Flags: review?(bhearsum) → review+
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+
Attachment #413266 - Flags: review?(ccooper) → review+
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+
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
status1.9.2: --- → final-fixed
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
Chris, I assume we have to set the .6-fixed flag?
status1.9.2: beta4-fixed → final-fixed
Henrik, did you deliberately set the status1.9.2 flag to "final-fixed" ? beta4-fixed is more appropriate I think.
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
status1.9.2: final-fixed → beta4-fixed
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
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.