Red Hat Bugzilla – Bug 845432
Revision History sorted wrongly when packaging translated books
Last modified: 2013-07-04 01:23:41 EDT
Description of problem: When Publican packages a translated book, it interleaves the Revision_History.xml file of the translated language with the Revision_History.xml file of the source language. However, revision numbers with more than one digit in the release segment are sorted according to their first digit. For example, revision 0-7 sorts higher than revision 0-51. As a result, packaging fails with: error: %changelog not in descending chronological order Version-Release number of selected component (if applicable): publican-3.0-0.fc17.t213 How reproducible: 100% Steps to Reproduce: 1. Make a book with a revision history that includes revnumbers "0-7" and "0-51" 2. Attempt to package a translation of that book, supplying a valid Revision_History.xml file in the translated language Actual results: Packaging fails because the Revision_History.xml written to tmp/<lang>/xml_tmp has revision 0-7 sorted higher than revision 0-51 Expected results: Revision_History.xml is sorted correctly and packaging succeeds Additional info: It's possible to work around this by adding "0" in front of the single-digit release numbers, so "0-07" instead of "0-7"
To clarify, the en-US/Revision_History.xml file contains (amongst others) revisions 0-7, 0-51, and 1-3 The pt-BR/Revision_History.xml file contains a single entry: 1-3.33 The order of revisions in tmp/<lang>/xml_tmp/Revision_History.xml is then: 1-3.33 1-3 0-7 0-51
Added better sorting rules to XSL. To ssh://git.fedorahosted.org/git/publican.git 621c7b9..5d4cc12 master -> master
Verified that the most usual cases (x.y-a.b) work in build publican-3.0-0.fc17.t223.noarch More complex cases, like x.y.z-a.b still fail however.
*** Bug 860438 has been marked as a duplicate of this bug. ***
Build from upstream source: publican-3.0-0.el6.t226.noarch Tried x.y-a.b and x.y.z-a.b and both worked in en-US, however in ja-JP the behaviour from bug#860438 still occurs. Sample output: grep -o '<revnumber.*' tmp/en-US/xml_tmp/Revision_History.xml <revnumber>1.1-1.1</revnumber> <revnumber>1.0.1-0.2</revnumber> <revnumber>1.0-0.1</revnumber> <revnumber>1.0-0</revnumber> <revnumber>0.1-0.1</revnumber> <revnumber>0.1-0</revnumber> <revnumber>0-12</revnumber> <revnumber>0-11</revnumber> <revnumber>0-10</revnumber> [...] <revnumber>0-2</revnumber> <revnumber>0-1</revnumber> <revnumber>0.0-0</revnumber> grep -o '<revnumber.*' tmp/ja-JP/xml_tmp/Revision_History.xml <revnumber>1.1-1.1</revnumber> <revnumber>1.1-1.1.1</revnumber> <revnumber>1.0.1-0.2</revnumber> <revnumber>1.0-0.1</revnumber> <revnumber>1.0-0</revnumber> <revnumber>0.1-0.1</revnumber> <revnumber>0.1-0</revnumber> <revnumber>0.0-0</revnumber> <revnumber>0-12</revnumber> <revnumber>0-11</revnumber> <revnumber>0-10</revnumber> [...] <revnumber>0-2</revnumber> <revnumber>0-1</revnumber>
IMHO, if the numbering scheme is as inconsistent as it is in that en-US example, the correct solution is for the writer to sanitise the numbering scheme before packaging. I think we can call this bug fixed if both these cases work: 1. author chooses an x.y-z scheme 2. author chooses an x-z scheme I don't think we need to support mixing those. Suggested test cases below. Cheers Rudi 1. en-US revhistory contains x.y-z <revnumber>11.11-11</revnumber> <revnumber>11.11-2</revnumber> <revnumber>11.11-1</revnumber> <revnumber>11.11-0</revnumber> <revnumber>11.2-0</revnumber> <revnumber>11.1-0</revnumber> <revnumber>11.0-0</revnumber> <revnumber>2.0-0</revnumber> <revnumber>1.0-0</revnumber> <revnumber>0.11-11</revnumber> <revnumber>0.11-2</revnumber> <revnumber>0.11-1</revnumber> <revnumber>0.11-0</revnumber> <revnumber>0.2-0</revnumber> <revnumber>0.1-0</revnumber> <revnumber>0.0-11</revnumber> <revnumber>0.0-2</revnumber> <revnumber>0.0-1</revnumber> <revnumber>0.0-0</revnumber> 2. en-US revhistory contains x-z only <revnumber>11-0</revnumber> <revnumber>2-0</revnumber> <revnumber>1-0</revnumber> <revnumber>0-11</revnumber> <revnumber>0-2</revnumber> <revnumber>0-1</revnumber> <revnumber>0-0</revnumber>
Just to help people out: (In reply to comment #5) > grep -o '<revnumber.*' tmp/ja-JP/xml_tmp/Revision_History.xml > <revnumber>1.1-1.1</revnumber> > <revnumber>1.1-1.1.1</revnumber> This is the "broken" entry, the versions should be reversed. 1.1-1.1 is x.y-z.aa making the translation use x.y-z.aa.ab. The XSL doing the sort has a limitation of x.y-z in the source language, formats of greater positioning that this are unsupported and will not function correctly. This limitation needs to be documented in the User Guide.
Verifed to work for x-z and x.y-z on publican-3.0-0.fc17.t223.noarch
Reopening as some versions that should be supported, aren't :(
Hey Rudi, I've committed a fix on a branch, can you give it a test? git checkout bz845432 It should work for a larger range of string sequences, x.y.z-a.b.c etc. Cheers, Jeff.
*** Bug 891804 has been marked as a duplicate of this bug. ***
Tested branch bz845432 against the files attached to Bug 891804 -- still doesn't work. $ rpm -q publican publican-3.0.0-0.fc17.t1.noarch $ rpm -q perl-Sort-Versions perl-Sort-Versions-1.5-18.fc17.noarch
In the case of those specific files, Publican sorts the entries: <revnumber>1-38.1</revnumber> <date>Fri Dec 21 2012</date> ... <revnumber>1-36.2</revnumber> <date>Tue Nov 6 2012</date> ... <revnumber>1-36.1</revnumber> <date>Tue Nov 6 2012</date> ... <revnumber>1-38</revnumber> <date>Thu Dec 20 2012</date> ... <revnumber>1-37</revnumber> <date>Thu Nov 29 2012</date> ... <revnumber>1-36</revnumber> <date>Tue Nov 6 2012</date>
This fix has been committed to the devel branch for inclusion in Publican 3.1.
Yep, fixed now in 3.0.0-1.t1 -- thanks :)
*** Bug 887060 has been marked as a duplicate of this bug. ***