Kubuntu/Packaging/L10nOperatorGuide: Difference between revisions

From KDE Community Wiki
(kde-l10n-common moved to git)
(→‎Doing a release of kde-l10n-common: fixed debsign build/kde-l10n-*.changes line)
Line 37: Line 37:
* Run debian/build-l10n.sh
* Run debian/build-l10n.sh
** The script will download all sorts of source tars and build appropriate packages from them using the common debian dir and substitution of the generic strings.
** The script will download all sorts of source tars and build appropriate packages from them using the common debian dir and substitution of the generic strings.
* debsign build/kde-10n-*.changes
* debsign build/kde-l10n-*.changes
* Archive: If everything went well and you are happy with the results, you can run debian/upload-l10n.sh to get the packages uploaded to Ubuntu
* Archive: If everything went well and you are happy with the results, you can run debian/upload-l10n.sh to get the packages uploaded to Ubuntu
* PPA's: use dput to upload build/kde-10n-*.changes
* PPA's: use dput to upload build/kde-10n-*.changes

Revision as of 22:41, 16 May 2016

How to operate the kde-l10n magic

The branches

Currently the kde-l10n source is to be found at

And the language-pack meta package source at

Concept

The idea is that the kde-l10n-common branch is like any other packaging-only branch, just in a more generic manner and specific to the needs of kde-l10n.

language-pack-kde-common is a meta package to bring in kde-l10n-xx and calligra-l10n-xx and anything else needed.

The names

Throughout the branch you find names like aaaUBUNTULANGCODEbbb the aaa and bbb are only there to uniquify them and ensure that we can sub them using regex without affecting other strings. They generally describe a represenation of the value that is going to be there, so in the above case the string would be replaced with the Ubuntu language code (e.g. ptbr, whereas the KDE version is pt@br). Never ever use a specific name but these place holders instead!

Architechture

The scripts to build kde-l10n and language-pack-kde are 2 separate scripts, however, they use a common sequence debian/common which is present in the kde-l10n branch. Any modifications to debian/common MUST be pushed before continuing, it is better to push and revert than not push at all!

Each script sources this common file and runs the commonSequence function which is common to both scripts before proceeding any further.

All new code in debian/common must be neatly modularized into it's own sequence.

Doing a release of kde-l10n-common

  • Update changelog in kde-l10n-common
  • Any other changes you need to do
  • Commit
  • PUSH <-- you will not be able to proceed unless you pushed the branch, this is to prevent accidently forgetting to push, it is better to push and revert than not push at all!
  • apt-get install debhelper pkg-kde-tools bzr-buildpackage subversion kdelibs5-dev
  • Run debian/build-l10n.sh
    • The script will download all sorts of source tars and build appropriate packages from them using the common debian dir and substitution of the generic strings.
  • debsign build/kde-l10n-*.changes
  • Archive: If everything went well and you are happy with the results, you can run debian/upload-l10n.sh to get the packages uploaded to Ubuntu
  • PPA's: use dput to upload build/kde-10n-*.changes

Doing a release of language-pack-kde-common

  • If you're doing a new release, update kde-l10n-common first!
  • Update changelog in language-pack-kde-common
  • Any other changes you need to do
  • Commit
  • PUSH <-- you will not be able to proceed unless you pushed the branch, this is to prevent accidently forgetting to push, it is better to push and revert than not push at all!
  • Run debian/build-langpack.sh
  • Grab a $BEVERAGE while the script runs
  • debsign build/*.changes
  • Archive: dput ubuntu build/*.changes
  • PPA's: dput ppa:foo/bar build/*.changes

Branching SRU's and backports

  • Branch kde-l10n-common and push to the new SRU or backport location
  • Do the same for language-pack-kde-common
  • update debian/config-l10n with the new branch locations
  • commit
  • Follow the usual doing a release guide above