Bug 891804

Summary: Publican does not correctly sort translated revision histories with release numbers that contain more than one digit
Product: [Community] Publican Reporter: Ruediger Landmann <rlandman>
Component: publicanAssignee: Jeff Fearn <jfearn>
Status: CLOSED DUPLICATE QA Contact: tools-bugs <tools-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.0CC: rglasz, rlandman+disabled, thildred, ykatabam
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-01-06 22:50:59 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
English (source) revision history
none
Japanese (translated) revision history none

Description Ruediger Landmann 2013-01-03 22:52:46 EST 
Description of problem:

When the release numbers in a Revision History file contain more than one digit, Publican cannot correctly interleave the Revision Histories of the source language and any translated language.


Version-Release number of selected component (if applicable):
3.0

How reproducible:
100%

Steps to Reproduce:
1. create a revision histories file with entries like 1-21 1-22 1-23
2. run update_pot and update_po
3. add more revisions to the source language like 1-24 1-25
4. run update_po
5. try to package the translated book
  
Actual results:
Packaging fails with "error: %changelog not in descending chronological order"

Expected results:
Packaging succeeds

Additional info:
See attached sample files
Comment 1 Ruediger Landmann 2013-01-03 22:57:10 EST 
Created attachment 672287 [details]
English (source) revision history
Comment 2 Ruediger Landmann 2013-01-03 22:57:57 EST 
Created attachment 672288 [details]
Japanese (translated) revision history
Comment 3 Ruediger Landmann 2013-01-06 22:50:59 EST 

*** This bug has been marked as a duplicate of bug 845432 ***