Bug 482947 - Mark localized files with %lang, fix minor packaging issues
Mark localized files with %lang, fix minor packaging issues
Product: Fedora Documentation
Classification: Fedora
Component: release-notes (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Release Notes Tracker
Karsten Wade
: Patch
Depends On:
  Show dependency treegraph
Reported: 2009-01-28 17:15 EST by Ville Skyttä
Modified: 2013-01-10 00:02 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-10-29 06:59:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Spec file patch (4.68 KB, patch)
2009-01-28 17:15 EST, Ville Skyttä
no flags Details | Diff
Desktop entry patch (503 bytes, patch)
2009-01-28 17:16 EST, Ville Skyttä
no flags Details | Diff
release notes spec file (10.40 KB, application/octet-stream)
2010-05-01 17:35 EDT, John J. McDonough
no flags Details

  None (edit)
Description Ville Skyttä 2009-01-28 17:15:08 EST
Created attachment 330291 [details]
Spec file patch

As discussed on fedora-devel today, attached is a patch that marks localized files in fedora-release-notes with %lang.

Also contains fixes for two other minor packaging issues I found while doing the %langification.
Comment 1 Ville Skyttä 2009-01-28 17:16:39 EST
Created attachment 330293 [details]
Desktop entry patch

Both patches are against the F-10 branch in CVS which appears to be ahead of the devel branch.
Comment 2 Ville Skyttä 2009-04-19 17:01:59 EDT
Any chance we could see this in F-11?
Comment 3 Bug Zapper 2009-06-09 06:57:02 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
Comment 4 Ville Skyttä 2009-07-20 18:09:23 EDT
Didn't make F-11, what about F-12?
Comment 5 Paul W. Frields 2009-07-20 18:54:54 EDT
There's new process under consideration by Fedora Docs for shipping (or not shipping, but separately offering) Release Notes.  I'm going to reassign this bug to the default owner since I'm not as actively involved in this work now.  Sorry for the delay; I should have done that sooner.
Comment 6 Paul W. Frields 2009-07-20 18:56:29 EDT
Hm, well apparently the default ownership is not changed yet in BZ, but it should be relnotes@fedoraproject.org, which brings the Docs team into the loop.
Comment 7 Bug Zapper 2010-04-27 08:49:30 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 8 Ville Skyttä 2010-04-27 15:09:07 EDT
Seemingly still not done in 12.0.95-4.fc13.  Would you like me to take care of this in CVS?
Comment 9 Paul W. Frields 2010-04-27 19:52:55 EDT
If you can get with John McDonough (jjmcd) and send him a copy of your changes, he can build them into the tool he uses to generate this spec file.  If that doesn't work out, as far as I'm concerned you're welcome to make the change, thank you Ville.  Sorry I've not had time to revisit this bug lately, and I appreciate your diligence.
Comment 10 John J. McDonough 2010-04-27 21:22:13 EDT
I guess I don't quite get what you are trying to accomplish with the html.lang file, and perhaps because I don't understand, your code around:

%find_lang %{name} --with-gnome --all-name

causes the rpmbuild to fail.  I get the impression that you are looking for files like index-something.html, and perhaps it fails because there are none.
Comment 11 Ville Skyttä 2010-05-01 08:09:53 EDT
The package has changed quite a bit after I submitted the original patches so I'm not at all surprised that they don't work any more.

I've uploaded a new series of patches against current fedorahosted git here:

The desktop files appear to come from somewhere else, so the patch for them (desktops.patch) is against the versions in the tarball.  This patch (or similar fixes) needs to be applied before 0008-Validate-desktop-files-during-build.patch or it will cause the build to fail as the unmodified desktop files contain errors.
Comment 12 John J. McDonough 2010-05-01 17:31:50 EDT
The desktop file issues have been corrected in doc-publican-rpm 1.8.0, but I still don't quite get what is going on with writing to html.lang in the specfile.  I'll attach an updated specfile and perhaps you can elaborate on what is supposed to happen.
Comment 13 John J. McDonough 2010-05-01 17:35:51 EDT
Created attachment 410732 [details]
release notes spec file

This spec includes the business about writing to html.lang, but the final bit, which is commented out, causes the build to fail.  Since I don't quite understand what you were trying to accomplish I wasn't very successful trying to debug it.
Comment 14 John J. McDonough 2010-05-25 08:11:21 EDT
Moving this to Fedora Documentation so it doesn't get lost.

As much of the patch as actually works is included in the last couple of releases, but parts of the patch fail, and since we still don't know the point of all this, we are unable to work around.

Comment 15 Ville Skyttä 2010-05-25 17:43:25 EDT
Did you read comment 11?  Was there something unclear about that, or the comments in the patch files?  I don't know what more information you're looking for, but here's a try: localized files should be marked with %lang where it doesn't cause other problems in order to honor people's %_install_langs settings (for example to save some space on space constrained setups such as live CD's), and for the other fixes/patches I don't know what more information I could give besides what's already in the patches' commit messages.

I *did* verify that the package builds with the patches in comment 11 applied, otherwise I wouldn't have caught the one mentioned build error nor could I have posted instructions about how to avoid it.

Just a guess: Have you by chance been working on adapting my original patches attached to this bug?  As mentioned in comment 11, they're obsolete, and they're also marked as obsolete in this bug.  Please take a look at the patch set linked to in comment 11 instead.

But on the other hand, I see git has already moved on and now they'd need to be adapted/rebased manually.  I'm afraid I'll need more information about whether you'd consider applying them this time, and against what you'd prefer them (git or the package structure in packages CVS tree) before spending more time on doing that.
Comment 16 John J. McDonough 2010-05-25 19:17:25 EDT
Sorry, Comment 11 wasn't very helpful.  However, what I was most concerned about was the section in your earlier patch:

%find_lang %{name} --with-gnome --all-name
for F in $RPM_BUILD_ROOT%{_defaultdocdir}/HTML/index-*.html ; do
  L=`echo ${F} | %{__sed} 's/.*\/index-\(.*\)\.html$/\1/'`
  echo "%%lang(${L}) ${F#$RPM_BUILD_ROOT}" >> html.lang

which just didn't make any sense to me.  I see it is gone from your most recent patches.  This is the particular snippet I didn't understand and which caused rpmbuild to fail Reviewing it now it appears that perhaps some other document was organized as index-fr.html, index-en.html, etc.  The release notes aren't like that so I was struggling trying to figure out the point of that code.

I believe the current specfile contains most of your patches, I'll review it to be sure we got them all.  The release notes spec file is actually produced programatically, and the actual spec file might change depending on the writer's needs, but once I get all your suggestions into the script, then all documents will benefit.

Sorry if I'm a little slow on the uptake here.  I'm not trying to be contrary, just trying to understand.  And I do appreciate your help.
Comment 17 Ville Skyttä 2010-05-26 01:33:52 EDT
(In reply to comment #16)

> This is the particular snippet I didn't understand and which caused
> rpmbuild to fail Reviewing it now it appears that perhaps some other document
> was organized as index-fr.html, index-en.html, etc.  The release notes aren't
> like that so I was struggling trying to figure out the point of that code.

Yes, as said in comment 11, that patch was obsolete by the time you tried it, no surprise it didn't work at all if the docs had been reorganized/renamed.  It was made in the F-10 era.  At that time it looked for files named /path/to/index-LANGCODE.html, and generated file lists like "%lang(LANGCODE) /path/to/index-LANGCODE.html" out of them, and FWIW at that time it did work.
Comment 18 John J. McDonough 2010-10-29 06:59:10 EDT
I've kept this open because some of the issues were relevant to doc-publican-rpm.  These have been addressed in recent versions of the release notes, and are included in d-p-r, so I am closing this.

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