This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 845432 - Revision History sorted wrongly when packaging translated books
Revision History sorted wrongly when packaging translated books
Status: CLOSED CURRENTRELEASE
Product: Publican
Classification: Community
Component: publican (Show other bugs)
3.0
Unspecified Unspecified
unspecified Severity unspecified
: 3.1
: ---
Assigned To: Jeff Fearn
tools-bugs
: Reopened
: 860438 887060 891804 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-03 01:34 EDT by Ruediger Landmann
Modified: 2013-07-04 01:23 EDT (History)
2 users (show)

See Also:
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:


Attachments (Terms of Use)

  None (edit)
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):
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"
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:

1-3.33
1-3
0-7
0-51
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 
<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>
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.

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>
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
publican-3.0.0-0.fc17.t1.noarch
$ rpm -q perl-Sort-Versions
perl-Sort-Versions-1.5-18.fc17.noarch
Comment 13 Ruediger Landmann 2013-01-06 23:55:38 EST
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>
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. ***

Note You need to log in before you can comment on or make changes to this bug.