Description of problem: $publican package --brew --lang=<XX-YY>, creates *.src.rpm first locally at ~/Book_Name/tmp/rpm location; and later is uploaded to the brew server and builds it (a taskID over brew server is created) and respective RPMs are generated. Problem is, %changelog in *.spec (generated at ~/Book_Name/tmp/rpm/ location) doesn't follow packaging Version Release format. Version-Release number of selected component (if applicable): publican-2.2-0.fc13.noarch How reproducible: always Steps to Reproduce: 1. Checkout a book (from upstream repository). 2. Complete the translations (*.po) & commit back translated content. 3. Initiate 'publican package --brew --lang=<XX-YY>' 4. Follow the respective ~taskID created over brew server (till build completes successfully). 5. When build completes successfully (and resultant RPMs created), observe the Changelog for not following packaging Version Release format. Actual results: %changelog doesn't follow packaging Version Release format. Expected results: %changelog should follow packaging Version Release format. Additional info: Workaround for %changelog to follow packaging Version Release format has been tried for book|title =Installation_Guide, productname =Red Hat Enterprise Linux, productnumber =6 & edition =1.0 (with following steps): (1) Update, ~/en-US/Revision_History.xml for <revnumber>...</revnumber> section. Content within <revnumber>...</revnumber> section goes into "%changelog" of Red_Hat_Enterprise_Linux-Installation_Guide-6-web-<XX-YY>.spec. (2) ~/LANG/Book_Info.po --> "Project-Id-Version: 2", as it decides the value for "Release" variable/key in Red_Hat_Enterprise_Linux-Installation_Guide-6-web-<XX-YY>.spec. (3) svn commit -m "Project-Id-Version update" <XX-YY>/Book_Info.po (4) Run $publican package --scratch --lang=<XX-YY>. wherein '--scratch' creates following locally on your machine (doesn't upload to brew server) at ~/Installation_Guide/tmp/rpm/ location: Red_Hat_Enterprise_Linux-Installation_Guide-6-web-<XX-YY>-BookVersion-BookRelease.el5.src.rpm Red_Hat_Enterprise_Linux-Installation_Guide-6-web-<XX-YY>-BookVersion-BookRelease.tgz Red_Hat_Enterprise_Linux-Installation_Guide-6-web-<XX-YY>.spec NOTE: %changelog in Red_Hat_Enterprise_Linux-Installation_Guide-6-web-<XX-YY>.spec should follow Version Release format all the time. (5) Now if satisfied with --scratch build, brew the document by initiating following: $publican package --brew --lang=<XX-YY> Sample build, where %changelog follows Version Release format https://brewweb.devel.redhat.com/buildinfo?buildID=145892 (for example sake only) Sample builds, where %changelog DOESN'T follow Version Release format: https://brewweb.devel.redhat.com/buildinfo?buildID=146046 https://brewweb.devel.redhat.com/buildinfo?buildID=145988 (for example sake only)
Summarizing: When Publican packages translated documents, it takes the release number from LANG/Book_Info.po file, but creates the %changelog in the spec file from Revision_History.xml. The release numbers are therefore unlikely to match, and the package therefore won't pass rpmlint.
IMHO the work around is not worth the risk. This is not an issue that would block releasing packages and it has the potential to cause bigger problems than it solves, particularly given the large number of translators who are not technically competent at maintaining packages. The problem here is maintaining language revision history across multiple source language updates. I propose the following solution: 1: Each language has it own <lang-loc>/Revision_History.xml file. This file would be structured the same as the current source language file, but it would only contain language specific changes. 2: When the PO files for a language are updated Publican would: A: reset the release number in the Book_Info.po file to zero, B: add an entry to the language Revision_History.xml file with the new release number stating that the PO files were updated. (The string for the entry could be translated as part of Publican so as to not require this entry to be translated every time.) 3: When a translator updates the translation, they would bump the revision in Book_Info.po and add a new entry to their language Revision_History.po file with a summary of their changes. 4: When building translated books, Publican would merge the source and translation Revision Histories. This would allow translation history to be properly maintained, including the author or authors responsible for it, and allow full and proper change logs to be generated for packaging and use in the generated content. Comments welcome! Cheers, Jeff.
From Comment 2, Yes, the proposal looks good.
Hi, can I get some feedback on Comment #2 from the translation leadership? It will require some training and ongoing management to make it work usefully. Thanks, Jeff.
From Comment #4, For those CC'ed in this bug: if there are any other alternatives against the proposal suggested by Jeff (in Comment #2), please mention in this bug itself. Your valuable feedback awaited. -Sandeep
Any action/feedback/comment from the translation leadership? Or Is it assumed that Jeff's proposal (see Comment #2) is accepted unanimously (which is really good with respect to maintaining language revision history across multiple source language updates) by the translation leadership.
Hi Sandeep, Thanks for bringing this issue, as I have tried to raise it in the beginning itself when publican was introduced. In my opinion following should be the format of srpms and ChangeLogs. ...FOR_ENGLISH Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1.el5.src.rpm Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-2.el5.src.rpm Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-3.el5.src.rpm ... CHANGELOG... 1.0-1 1.0-2 1.0-3 ...FOR_LOCALIZED_BUILDS Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1-de_DE-1.0.el5.src.rpm Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1-de_DE-1.1.el5.src.rpm Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1-de_DE-1.2.el5.src.rpm ... Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-2-de_DE-1.0.el5.src.rpm Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-2-de_DE-1.1.el5.src.rpm Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-2-de_DE-1.2.el5.src.rpm ... Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-1-de_DE-1.0.el5.src.rpm Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-1-de_DE-1.1.el5.src.rpm Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-1-de_DE-1.2.el5.src.rpm ... Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-2-de_DE-1.0.el5.src.rpm Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-2-de_DE-1.1.el5.src.rpm Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-2-de_DE-1.2.el5.src.rpm ... CHANGELOG... 1.0-1-de_DE-1.0 1.0-1-de_DE-1.1 1.0-1-de_DE-1.2 ... Thanks! Ankit
(In reply to comment #7) <snip/> > .. format of srpms and ChangeLogs <snip/> > > ...FOR_LOCALIZED_BUILDS > Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1-de_DE-1.0.el5.src.rpm > Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1-de_DE-1.1.el5.src.rpm > Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1-de_DE-1.2.el5.src.rpm > ... > Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-2-de_DE-1.0.el5.src.rpm > Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-2-de_DE-1.1.el5.src.rpm > Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-2-de_DE-1.2.el5.src.rpm > ... > Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-1-de_DE-1.0.el5.src.rpm > Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-1-de_DE-1.1.el5.src.rpm > Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-1-de_DE-1.2.el5.src.rpm > ... > Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-2-de_DE-1.0.el5.src.rpm > Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-2-de_DE-1.1.el5.src.rpm > Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-2-de_DE-1.2.el5.src.rpm > ... productname =Red_Hat_Enterprise_Linux, productnumber =6 .. .. Hmn, format of the srpm (hope rpmlint remains silent). Thoughts? > > CHANGELOG... > 1.0-1-de_DE-1.0 > 1.0-1-de_DE-1.1 > 1.0-1-de_DE-1.2 > ... item 4: of the proposal (in Comment #2) seems taking shape. Thoughts? item 4: When building translated books, Publican would merge the source and translation Revision Histories.
(In reply to comment #7) > Hi Sandeep, > > Thanks for bringing this issue, as I have tried to raise it in the beginning > itself when publican was introduced. > > In my opinion following should be the format of srpms and ChangeLogs. > > ...FOR_ENGLISH > Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1.el5.src.rpm > Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-2.el5.src.rpm > Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-3.el5.src.rpm > ... > CHANGELOG... > 1.0-1 > 1.0-2 > 1.0-3 > > ...FOR_LOCALIZED_BUILDS > Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1-de_DE-1.0.el5.src.rpm > Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1-de_DE-1.1.el5.src.rpm > Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1-de_DE-1.2.el5.src.rpm > ... > Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-2-de_DE-1.0.el5.src.rpm > Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-2-de_DE-1.1.el5.src.rpm > Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-2-de_DE-1.2.el5.src.rpm > ... > Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-1-de_DE-1.0.el5.src.rpm > Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-1-de_DE-1.1.el5.src.rpm > Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-1-de_DE-1.2.el5.src.rpm > ... > Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-2-de_DE-1.0.el5.src.rpm > Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-2-de_DE-1.1.el5.src.rpm > Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-2-de_DE-1.2.el5.src.rpm > ... > > CHANGELOG... > 1.0-1-de_DE-1.0 > 1.0-1-de_DE-1.1 > 1.0-1-de_DE-1.2 You haven't defined where the NVR components start and end, so it requires guessing where they are. Guessing NVR for Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-3.el5.src.rpm: N: Red_Hat_Enterprise_Linux-6-Installation_Guide V: 1.0 R: 3.el5 This will work, but doesn't seem to gain us anything. Guessing NVR for Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1-de_DE-1.0.el5.src.rpm: N: Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0 V: 1-de_DE R: 1.0.el5 This is wrong, you can't install multiple languages, but you can install multiple versions of a book in one language for a single product version. Both of these are unacceptable. N: Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1 V: de_DE R: 1.0.el5 This is wrong, you can't install multiple languages, but you can install multiple versions of a book in one language for a single product version. Both of these are unacceptable. N: Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1-de_DE V: 1.0.el5 R: This is wrong. Assuming you fix the V & R issues above, the other flaw persists. If you base the translated package name (N) on the English revision (pubsnumber), then you can have multiple versions of a translated book installed, for a single product version, which is unacceptable. e.g. having both the following packages installed would be a huge bug: Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1-de_DE-1.2.el5.src.rpm Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-2-de_DE-1.0.el5.src.rpm
(In reply to comment #4) > Hi, can I get some feedback on Comment #2 from the translation leadership? It > will require some training and ongoing management to make it work usefully. > > Thanks, Jeff. Hi All, Any suggestions on how this bug should move ahead; probably with the implementation of proposal in Comment #2 ? I mean, if there are no possible flaws with the proposal (in Comment #2), then proposal could be implemented and made available in future(estimated) release of publican. Regards, Sandeep
FYI I have emailed an RFC for a proposed solution to the publican list. https://www.redhat.com/archives/publican-list/2010-December/msg00001.html
Added functionality to allow translations to carry their own Revision_History.xml file, which is merged with source language version when building. Added functionality to update translation Revision_History.xml file when update_po file is run for a language. Removed old behaviour of using Book_Info.po file for translation version. PUG updates required to document new behaviour. Fixed in revision 1696
Is the fix available in publican-2.8-1 release ?
(In reply to comment #15) > Is the fix available in publican-2.8-1 release ? Please, disregard Comment 15; Target Milestone is 3.0.
create book with at least 1 translation, in that language directory create a revision history.xml, build the book in that language, ensure tha thte built revision historty adds the translated revision history to the english revision history.
Verified in publican-3.0-0.fc17.t180.noarch update_po adds a <lang>/Revision_History.xml file; building the book adds this file to the English Revision History. Updating the English Revision History and running update_po again correctly interleaves the translated and untranslated revision histories.
Please note that this regresses publican's ability to render pre-existing documents, for example where the 'publish' facility and its putative naming requirements were never required.