From Fedora Project Wiki

< User:Immanetize

Revision as of 00:37, 14 May 2013 by Immanetize (talk | contribs) (→‎wget the source and perform a mock build)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Spec File

A sample of the spec file that makes this work can be found at .

create release branch

git branch f19

  1. Pull en_US source from master

At first, the release branch should mirror the master branch. Changes are pulled over to the release branch for release milestones - alpha, beta, and GA release. Active work is done in the master branch. We can check out a file from the master branch to apply.

git checkout f19

git checkout master -- file.xml

ensure source builds

publican build -l en-US -f html

You're doing this often anyway, right?

Push POTs, Pull POs

Early in the milestone cycle, push the source to transifex.

publican update_pot

tx push -s

After translation has been performed, check the transifex dashboard and pull *only* completed translations.

tx pull fr

tx pull nl

reusing tx configs

Please commit your tx configuration! initializing tx for a document can be tedious and error prone - we should not have to do it more than once.

test to ensure translations build

Of course, all languages must build. Test that:

publican build -l fr-FR -f html

publican build -l nl-NL -f html

Fix any issue that you can, and push POs back to transifex:

tx push -t

Remove any docs that do not build.

Prep the branch

Add the source and POs to the git repo. git add {en-US,fr-FR,nl-NL}/* Pull over the barebones desktop file and language index git checkout master -- build/{document.desktop,index.html} git commit -a -m 'adding langs'

review the regex

The sample spec file contains regular expressions to extract certain information. These regular expressions should be fine once adapted to a specific document. Initially, they will probably have to be adjusted.

tag the release branch

The end result will be an RPM with a filename of the form %{name}-%{release}-%{version}.rpm and we want our git tag to match. For example, if building a package for f19 for the third time, the tag could be '19-3.fc19'.

git tag -a 19-3 -m 'updated translations for document'

Tags aren't push unless we ask for it, so:

git push --tags

Order Matters

Be sure that all of your changes are committed *and* pushed before tagging.


After reviewing I don't think we need to use the dist tag, as we did before. It seems to add more complication than benefit.

Check the tag!

The spec file should be consulted to get the correct tag information. If in doubt, bump the version in the spec file and run rpmlint on it to see how the variables are substituted. Test the resulting URL with wget - you'll need to wget the sources to add them later, anyway.

Alpha and Beta Versions

Alpha and beta releases should follow the naming guidelines for pre-release packages:

wget the source and perform a mock build

Test with rpmlint again. Sources can take a a while to become available for download, so rpmlint may complain unjustly. wget the tar.bz2 file described in rpmlint's output to verify the release is tagged correctly and the file is available.

Testing is important!

I put in an embarrassing number of commits when working out this procedure. Testing with mock, and koji scratch builds, is imperative. fedpkg mockbuild is your friend!

Follow the packaging docs to complete submission

  • push the tarball to scm
  • branch build in koji
  • push to testing
  • announce availability for testing
  • push to stable