Closed
Bug 420947
Opened 17 years ago
Closed 17 years ago
patcher creates directories with a pretty version when it should use the short version
Categories
(Release Engineering :: General, defect, P2)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: bhearsum, Assigned: bhearsum)
Details
Attachments
(4 files, 3 obsolete files)
(deleted),
patch
|
nthomas
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
rhelmer
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
nthomas
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
Details | Diff | Splinter Review |
We hit this in Firefox 3 Beta 4, it appears to be fallout from bug 410006. When creating update snippets patcher creates a directory like this:
/opt/aus2/incoming/3/Firefox/3 Beta 3
When it should really be creating:
/opt/aus2/incoming/3/Firefox/3.0b3
Apparently, this only happens when the oldVersion, as the patch in bug 410006 was landed before the Beta 3 release and did not cause problems with it.
Patcher should be fixed to only use the 'version' in a <release> subsection when it needs something pretty. Any other time it should simply use the subsection name.
Here's an example
<app>
<Firefox>
...
...
<release>
<3.0b3>
version 3 Beta 3
</3.0b3>
</release>
...
...
</Firefox>
</app>
In this case, '3 Beta 3' should be used as the pretty string, and '3.0b3' for everything else.
I'm working on a patch for this.
Assignee | ||
Comment 1•17 years ago
|
||
Ugh, stupid Bugzilla.
<app>
<Firefox>
...
...
<release>
<3.0b3>
version 3 Beta 3
</3.0b3>
</release>
...
...
</Firefox>
</app>
Priority: -- → P2
Assignee | ||
Comment 2•17 years ago
|
||
From discussion on IRC:
Nick suggested using a 'prettyVersion' in the patcher config and leaving 'version' for what it was originally intended for. This will require patcher and Bootstrap patches. We should also go through the patcher configs and make sure there are no 'version' properties with a pretty version in them.
Assignee | ||
Comment 3•17 years ago
|
||
For posterity, this bug seems to be caused by these two lines:
http://lxr.mozilla.org/mozilla/source/tools/patcher/patcher2.pl#937
http://lxr.mozilla.org/mozilla/source/tools/patcher/patcher2.pl#981
Assignee | ||
Comment 4•17 years ago
|
||
I've got a fix in testing right now, I'll be posting patches tomorrow.
Assignee | ||
Comment 5•17 years ago
|
||
I looked through the MozAUS* and patcher2.pl code and this seems to be the only place this change is needed. I've run patcher locally and it appears to generate good snippets, I'll be attaching them in a moment. I will also be attaching updated patcher configs.
Attachment #307460 -
Flags: review?(nrthomas)
Assignee | ||
Comment 6•17 years ago
|
||
The <rc> section of this config did not contain 'beta'
Assignee | ||
Comment 7•17 years ago
|
||
betatest _was_ in the <rc> section.
Assignee | ||
Updated•17 years ago
|
Attachment #307461 -
Attachment description: complete.txt generated → complete.txt on beta channel
Assignee | ||
Comment 8•17 years ago
|
||
I'm not 100% sure if this is needed or not, I believe prettyVersion will only be used on the current release, not the old one. But just in case, I added it to the latest releases on the 1.8 and 1.9 patcher configs. After reading MozAUSConfig.pm a bit more I'm quite certain we won't need these on even older releases.
I purposely did not touch major update configs.
Attachment #307463 -
Flags: review?(nrthomas)
Assignee | ||
Comment 9•17 years ago
|
||
This is pretty trivial. The 'version' is set to the be same as the 'extension-version', like before. And 'prettyVersion' has been added. Now that GetVersion() exists we can just use it to extrapolate a pretty version (which I probably should've done when I added that function in the first place).
Attachment #307464 -
Flags: review?(rhelmer)
Updated•17 years ago
|
Attachment #307464 -
Flags: review?(rhelmer) → review+
Assignee | ||
Comment 10•17 years ago
|
||
This patch contains minor changes to MozAUSConfig.pm, which add a 'prettyAppv' to the data structure that patcher2.pl uses to generate updates.
There are larger changes to patcher2.pl that do the following (in a few places): Add a 'prettySnippetToAppVersion' wherever there is a 'snippetToAppVersion'. 'snippetToAppVersion' was previously used to set the appv in the snippet as well as provide progress on the command-line. In this version 'prettySnippetToAppVersion' performs the former, while snippetToAppVersion does the latter.
I was going to simply redefine 'snippetToAppVersion' as 'prettyVersion', but that made the command line output pretty ugly.
Attachment #307460 -
Attachment is obsolete: true
Attachment #307546 -
Flags: review?(nrthomas)
Attachment #307460 -
Flags: review?(nrthomas)
Assignee | ||
Comment 11•17 years ago
|
||
This is a diff of the aus2 and aus2.test directories using both unmodified patcher code, and patcher patched with attachment 307546 [details] [diff] [review]. As far as I can tell, only the appv is changed.
Attachment #307461 -
Attachment is obsolete: true
Attachment #307462 -
Attachment is obsolete: true
Comment 12•17 years ago
|
||
Comment on attachment 307546 [details] [diff] [review]
[checked in] try it in a different way
r+, thanks for making the more involved patch. I did some extra testing with 2.0.0.x, adding prettyVersion's to the 2.0.0.11 and the 2.0.0.12 blocks in the moz18-branch-patcher.cfg. That induces no changes except where it should, obviously a quick inspection rather than a complete one, 15000 files :-(
Attachment #307546 -
Flags: review?(nrthomas) → review+
Updated•17 years ago
|
Attachment #307463 -
Flags: review?(nrthomas) → review+
Assignee | ||
Comment 13•17 years ago
|
||
Comment on attachment 307463 [details] [diff] [review]
[checked in] 1.8 and 1.9 patcher configs, update with prettyVersion
Checking in moz18-branch-patcher2.cfg;
/cvsroot/mozilla/tools/patcher-configs/moz18-branch-patcher2.cfg,v <-- moz18-branch-patcher2.cfg
new revision: 1.9; previous revision: 1.8
done
Checking in moz19-branch-patcher2.cfg;
/cvsroot/mozilla/tools/patcher-configs/moz19-branch-patcher2.cfg,v <-- moz19-branch-patcher2.cfg
new revision: 1.21; previous revision: 1.20
done
Attachment #307463 -
Attachment description: 1.8 and 1.9 patcher configs, update with prettyVersion → [checked in] 1.8 and 1.9 patcher configs, update with prettyVersion
Assignee | ||
Comment 14•17 years ago
|
||
Comment on attachment 307546 [details] [diff] [review]
[checked in] try it in a different way
Checking in MozAUSConfig.pm;
/cvsroot/mozilla/tools/patcher/MozAUSConfig.pm,v <-- MozAUSConfig.pm
new revision: 1.17; previous revision: 1.16
done
Checking in patcher2.pl;
/cvsroot/mozilla/tools/patcher/patcher2.pl,v <-- patcher2.pl
new revision: 1.30; previous revision: 1.29
done
I'm going to retag with UPDATE_PACKAGING_R1_1 and bump the staging machines to that. If that goes well, we can bump the production ones later.
Attachment #307546 -
Attachment description: try it in a different way → [checked in] try it in a different way
Assignee | ||
Comment 15•17 years ago
|
||
Quick correction: will be tagging with UPDATE_PACKAGING_R2
Assignee | ||
Comment 16•17 years ago
|
||
Comment on attachment 307464 [details] [diff] [review]
[checked in] bootstrap changes to support patcher changes
Checking in Bootstrap/Step/PatcherConfig.pm;
/cvsroot/mozilla/tools/release/Bootstrap/Step/PatcherConfig.pm,v <-- PatcherConfig.pm
new revision: 1.19; previous revision: 1.18
done
Checking in configs/fx-moz19-bootstrap.cfg;
/cvsroot/mozilla/tools/release/configs/fx-moz19-bootstrap.cfg,v <-- fx-moz19-bootstrap.cfg
new revision: 1.18; previous revision: 1.17
done
Checking in configs/fx-moz19-staging-bootstrap.cfg;
/cvsroot/mozilla/tools/release/configs/fx-moz19-staging-bootstrap.cfg,v <-- fx-moz19-staging-bootstrap.cfg
new revision: 1.13; previous revision: 1.12
done
Attachment #307464 -
Attachment description: bootstrap changes to support patcher changes → [checked in] bootstrap changes to support patcher changes
Assignee | ||
Comment 17•17 years ago
|
||
Alright, I've created UPDATE_PACKAGING_R2 following the instructions here: https://bugzilla.mozilla.org/show_bug.cgi?id=411235#c10
cvs co -r UPDATE_PACKAGING_R1 mozilla/client.mk
cd mozilla
make -f client.mk MOZ_CO_PROJECT=all checkout
cvs up -A tools/update-packaging
cvs up -AdP tools/release
cvs up -AdP tools/patcher
cvs -q tag UPDATE_PACKAGING_R2 2>&1 | tee ../tag.log
grep -v '^T' ../tag.log
cvs tag -b UPDATE_PACKAGING_R2_minibranch client.mk
cvs up -r UPDATE_PACKAGING_R2_minibranch client.mk
edited client.mk, bumped to UPDATE_PACKAGING_R2
commited client.mk
Checking in client.mk;
/cvsroot/mozilla/client.mk,v <-- client.mk
new revision: 1.314.2.1.2.1.2.1; previous revision: 1.314.2.1.2.1
done
re-tagged
cvs -q tag UPDATE_PACKAGING_R2 client.mk
W client.mk : UPDATE_PACKAGING_R2 already exists on version 1.314.2.1.2.1 : NOT MOVING tag to version 1.314.2.1.2.1.2.1
cvs -q tag -F UPDATE_PACKAGING_R2 client.mk
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
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
•