----- Original Message -----
From: "Paul Frields" <stickster(a)gmail.com>
To: "John J. McDonough" <wb8rcr(a)arrl.net>
Cc: <oglesbyzm(a)gmail.com>; <laubersm(a)fedoraproject.org>; "Eric
Sent: Tuesday, May 12, 2009 8:34 AM
Subject: Re: Updated script
(1) This sort of call for review/help should be on the
fedora-docs-list where more people can help. It's open source!
Point taken. I still need to get used to this. This seemed so grody I
didn't think the larger goup would care, but then again, being selfish, I am
always interested in learning more, and the more eyes, the more chances i
have to learn! My main motivation in sharing this was so that I wasn't the
only person who knew what I was up to, but there is no reason the three of
you have to be the only ones.
On the other hand, this could be a little misleading without some warnings.
The script essentially builds the rpm, and I am the LAST person anyone
should be looking to for advice on building an rpm. In addition, this is a
transition time, and much of what is in there we hope not to deal with for
Fedora 12. Most if this is fedora-docs-utils stuff that we hope will be
Publican, and some of the Publican stuff are things we hope will be dealt
with in Publican, so certainly, nobody should put too much value on this
On the other hand, it is certainly a treasure trove of ungainly hacks.
I made the rpm for RC in two steps, so in the latest version, the Publican
parts are commented out. I have since pushed the I18n.xml that has the
offending paragraph commented out, so I should be able to run the script
from start to finish, but haven't actually done that yet. After we get the
RC done, I intend to do that so that when any zero day issues are swatted,
we can just run the script to make the rpm.
(2) Is help still needed?
The package that went to RC has the offending paragraph commented out. We
still have absolutely no clue what is going on there. We need someone a lot
more knowledgable about Publican (hint, hint) to help sort it out. As I
said, I pushed the version of I18n.xml that has the offending paragraph (and
I mean XML paragraph here, from <para> to </para>, it is actually a table)
commented out. Uncommenting it and generating html in any non-English
language should expose the problem. Because of the need to merge the po's,
it might be easier to do this from the srpm than from git. It will
certainly be quicker as the po merge takes some time.
On Fri, May 8, 2009 at 11:22 AM, John J. McDonough <wb8rcr(a)arrl.net> wrote:
I'm copying this to Paul because if we can get a piece of him
help, and Eric so he know what's going on.
There is a paragraph in I18n.xml that talks about hotkeys. When you build
non-English anything it complains it can't find (long string) in (long
string). Except that the second string has </para> at the end, they look
identical. If I take the string from the po and paste it into the xml,
clean out the quotes, I get the same error. If I delete the section from
the xml it builds.
Attached the same script as before but with a couple of bugs swatted.
the spec file.
It looks like I won't be able to run this cleanly since I need the
workaround until I figure out the problem with I18n.xml, and so far that
doesn't look promising.
The script essentially produces six tars from the git.
The five documents produced with fedora-doc-utils are shoved into the
tarball essentially complete. For whatever reason we haven't actually put
sources in the script in the past. we "should" have the sources in the
but since we have always done the f-d-u docs building outside the rpm, I
haven't felt the need to change that for this go. Next time we will
probably convert those to Publican anyway.
The release-notes tarball has the minimum bits needed to build the docs
publican. It also has the omf files. For the Publican build, build.sh
grabs the doc from git, does the merge of the po's, builds the omf files,
and shoves it all into a tarball.
build.sh builds the other five documents with fedora-docs-utils and makes
tars with the result.
The tar files must be named <document>-<version> and the top directory in
the tar must be <document>-<version>. Whether this is really "must
can't say for sure, but it is how it is always done.
The .spec file is what actually makes the rpm.
The first bit in the spec is pretty much identification.
The section under %build describes the building that happens within the
rpmbuild. When we do
rpmbuild -ba fedora-release-notes.rpm
This section gets run. The srpm basically includes the six tars and the
spec, the rpm includes the result of the build.
The %install section describes where to place the various files on the
target system. the %files section seems to be more or less a check that
the created files that matter were actually installed and no others.
When you install the rpm building tools, you create a directory tree on
~/rpmbuild. All the rpm building stuff happens there. Before doing the
rpmbuild, the tars must be in ~/rpmbuild/SOURCES. The spec file ends up in
~/rpmbuild/SPECS, the rpm in ~/rpmbuild/RPMS and the source rpm in
~/rpmbuild/SRPM. The other subdirectories are used during the build.
I just built fedora-release-notes-11.0.0.tar.gz separate from build.sh to
test. I don't want to hack the git copy just yet, but I want build.sh to
reflect not doing anything hokey. Until we get the I18n.xml thing resolved
the other languages won't build out of git.
The easiest way to test these things is with a LiveUSB or a VM. You can't
really remove the release notes because a million other things update
so the simplest thing to do is make a LiveUSB and keep a copy of
/LiveOS/overlay-xxxx. You can then install the new release-notes on the
LiveUSB and test them. To test another version, just copy your saved
overlay file back to /LiveOS and you have a clean install of Fedora. You
could do a similar thing with a VM, but I suspect it would be a little
It seems to be easiest to use yum to install the release-notes:
yum --nogpgcheck localinstall
I'm going to test my hacked version shortly. We still need to update the
date/version on the f-d-u docs as outlined in the comments to build.sh. I
would like to resolve the I18n issue, but if not we'll go with the hack. I
guess we have until Sunday, but I am out of town most of tomorrow and
is Mother's Day, so probably a lot won't get done then.