Bug 845432

Summary: Revision History sorted wrongly when packaging translated books
Product: [Community] Publican Reporter: Ruediger Landmann <rlandman>
Component: publicanAssignee: Jeff Fearn <jfearn>
Status: CLOSED CURRENTRELEASE QA Contact: tools-bugs <tools-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.0CC: rlandman+disabled, sgordon
Target Milestone: 3.1Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: 3.1.0 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-05 22:40:50 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Ruediger Landmann 2012-08-03 01:34:40 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):

How reproducible:

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"
Comment 1 Ruediger Landmann 2012-08-03 01:52:17 EDT
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:

Comment 2 Jeff Fearn 2012-08-19 22:55:45 EDT
Added better sorting rules to XSL.

To ssh://git.fedorahosted.org/git/publican.git
   621c7b9..5d4cc12  master -> master
Comment 3 Ruediger Landmann 2012-08-19 23:59:19 EDT
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.
Comment 4 Jeff Fearn 2012-09-25 17:46:56 EDT
*** Bug 860438 has been marked as a duplicate of this bug. ***
Comment 5 Andrew Ross 2012-10-03 18:05:42 EDT
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 

grep -o '<revnumber.*' tmp/ja-JP/xml_tmp/Revision_History.xml 
Comment 6 Ruediger Landmann 2012-10-03 19:09:22 EDT
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.


1. en-US revhistory contains x.y-z


2. en-US revhistory contains x-z only

Comment 7 Jeff Fearn 2012-10-04 01:13:51 EDT
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.
Comment 8 Ruediger Landmann 2012-10-30 21:43:56 EDT
Verifed to work for x-z and x.y-z on publican-3.0-0.fc17.t223.noarch
Comment 9 Jeff Fearn 2012-11-27 03:42:01 EST
Reopening as some versions that should be supported, aren't :(
Comment 10 Jeff Fearn 2012-11-27 03:48:29 EST
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.
Comment 11 Ruediger Landmann 2013-01-06 22:50:59 EST
*** Bug 891804 has been marked as a duplicate of this bug. ***
Comment 12 Ruediger Landmann 2013-01-06 23:52:04 EST
Tested branch bz845432 against the files attached to Bug 891804 -- still doesn't work.

$ rpm -q publican
$ rpm -q perl-Sort-Versions
Comment 13 Ruediger Landmann 2013-01-06 23:55:38 EST
In the case of those specific files, Publican sorts the entries:

<date>Fri Dec 21 2012</date>
<date>Tue Nov 6 2012</date>
<date>Tue Nov 6 2012</date>
<date>Thu Dec 20 2012</date>
<date>Thu Nov 29 2012</date>
<date>Tue Nov 6 2012</date>
Comment 14 Jeff Fearn 2013-01-07 17:21:11 EST
This fix has been committed to the devel branch for inclusion in Publican 3.1.
Comment 15 Ruediger Landmann 2013-01-07 18:35:55 EST
Yep, fixed now in 3.0.0-1.t1 -- thanks :)
Comment 16 Jeff Fearn 2013-07-04 01:23:41 EDT
*** Bug 887060 has been marked as a duplicate of this bug. ***