Bug 845432

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

Description Ruediger Landmann 2012-08-03 05:34:40 UTC

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 05:52:17 UTC

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-20 02:55:45 UTC

Added better sorting rules to XSL.

To ssh://git.fedorahosted.org/git/publican.git
   621c7b9..5d4cc12  master -> master

Comment 3 Ruediger Landmann 2012-08-20 03:59:19 UTC

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 21:46:56 UTC

*** Bug 860438 has been marked as a duplicate of this bug. ***

Comment 5 Andrew Ross 2012-10-03 22:05:42 UTC

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 23:09:22 UTC

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 05:13:51 UTC

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-31 01:43:56 UTC

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 08:42:01 UTC

Reopening as some versions that should be supported, aren't :(

Comment 10 Jeff Fearn 🐞 2012-11-27 08:48:29 UTC

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-07 03:50:59 UTC

*** Bug 891804 has been marked as a duplicate of this bug. ***

Comment 12 Ruediger Landmann 2013-01-07 04:52:04 UTC

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-07 04:55:38 UTC

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 22:21:11 UTC

This fix has been committed to the devel branch for inclusion in Publican 3.1.

Comment 15 Ruediger Landmann 2013-01-07 23:35:55 UTC

Yep, fixed now in 3.0.0-1.t1 -- thanks :)

Comment 16 Jeff Fearn 🐞 2013-07-04 05:23:41 UTC

*** Bug 887060 has been marked as a duplicate of this bug. ***