From Mageia wiki
Jump to: navigation, search

NOT FINALIZED YET, TODO:

  • add more urls

I want to be a mentor, how can I do it?

Mageia aims to develop as much as possible packagers team so that we can extend list of maintained packages for users. Thus mentoring new packagers should be seen as something formal and important for distribution future. Successfull mentoring means quality for distribution.

Being a mentor does not mean you should read the documentation for your trainee :). Check these bases are well known before starting.

IRC chans are available:

  • #mageia-dev for development and packaging
  • #mageia-mentoring dedicated to discuss padawan and mentor issues
  • you may choose what is most appropriate for you (mail, jabber...)

Main steps of mentoring process

Supervise the account creation procedure

  • Your trainee should create an account on http://identity.mageia.org/. This account will be used on the wiki, bugzilla, for mailing list subscribtion, and later for svn access.
  • bugzilla edit rights: standard users can't change other people's bug reports (except add comments to them), so you will probably need to ask to QA team leaders (via the qa-discuss mailing list or IRC) or bugsquad team leaders (via the bugsquad-discuss mailing list or IRC) or sysadmins to add give the editbugs right to them in bugzilla.
  • svn commits right: once you think your trainee can commit in Mageia svn, open a request on the bugzilla. See this page for details.
  • mailing-lists registration: check it, it's not a formal prerequiresite but important to follow main changes, plans and discussion within Mageia team

Ensure the new packager is familiarized with main packaging resources

Ensure the new packager is aware of Mageia packaging policies

Or you will have more work explaining why the build system is rejecting their packages

Ensure the new packager is aware of consequences

Make them aware of how changes they make could affect the distribution (e.g. pushing a new library major) and what the responsibilities are in that regard (e.g. ensuring that all packages using a library are/can be rebuilt with the new library major).

New packagers are not necessarily aware of the impact of their changes, here are some advices you should check it's well understood

  • Do not rush to update any packages that’s available in a newer version. This may have an impact on other packages that are not necessarily compatible with that newer version. This is particularly true for perl or ruby modules which tend to have strong interdependencies on each other
  • Before you upgrade a package look at packages which depend on it with **urpmq --whatrequires foo**
  • If you add the SRPM repository, you’ll be able to see packages which depend on a particular version for building
  • Do not leave a package in a broken state, do not rely on other people to fix your mistakes.
    • Please ask if you don’t know how to fix something. We do not expect people to know everything, but we expect people to be responsible and collaborative.
    • Likewise, please conform to the policies as much as you can. We do not expect people to know policies by heart, but we do expect that you check these policies when you make a change to a related package. We do expect that you ask if you find something confusing in these policies. This way we can be aware of it being confusing, and fix it, or rephrase it in a more understandable way.
  • Announce any changes that could have a strong impact on the mailing lists. people could then be warned about the upgrade, and will eventually help you to rebuild the needed packages. Communication is your best friend.
  • Test your changes locally

Mentoring based on concrete examples

It should be the main way to check new packager skills:

  • commits of pending updates
  • solve bug reports with patch attached
  • solve bug reports considered as trivial

Here are the main steps you could follow until validation:

  1. start with local builds for rpms and check all components - push import/commit for him to start with
  2. give him rights to commit (contact adminsys team) when he is ready and check all commits done
  3. ask for submit rights once you think he is ready to work on his own
  4. keep contact with him in case of he needs specific help

Announcing new packager

Once process is over and apprentice got submit right, send a mail to dev mailing announcing new official packager and welcome him/her

Focus on tools

The purpose is to describe the steps needed to teach trainees how to use the tools needed to build packages for Mageia:

  • make trainees familiar with these tools, and at the same time give tips/best practices
  • formalize a bit more how to use these tools the proper way, so that they can be ready to be full-fledged packagers and, hopefully, mentors as well

During the training, some exercices should also be given to trainees so that they learn how to solve common packaging problems, like string format errors (reminder: import the packaging problems page), or making a package compliant with the various policies we have.

This page assume that trainees have already some knowledge about how rpm works: SPEC file syntax, steps needed to build packages.

ssh

The first step is to teach how to use ssh, because that’s needed to be able to commit to svn, or submit packages to the Build System. The basic steps required are laid out here.

subversion

The first step is to teach how basic operation work on svn

  • svn checkout
  • svn add/svn del
  • svn status
  • svn diff

Then, trainees need to learn how the mageia subversion is organized:

  • one subdirectory per package containing
   * SPECS/ directory where the spec file is
   * SOURCES/ directory where the patches are
  • an additional repository called binrepo where the tarball is located

Commits should be atomic (ie, a change in the spec file that adds a patch should be in the same commit as the one where the patch is added).

Warn people to test the package before they commit. Commit should be the last step to teach.

Don’t forget to teach tips about commits

  • How to use SILENT: for little changes to fix a previous commit
  • How to use CCBUG (is this svn hook implemented yet ?)

mgarepo

When trainees are comfortable with svn, they can learn how to use mgarepo for checkout instead to save some tedious typing URLs. see mgarepo howto

bm

Many people who aren’t familiar with mdv use rpmbuild to build the package. bm is nice in that it does not require files to be in %_topdir and thus people can build packages inplace

patcher

patcher is a simple tool that’s very useful to generate patches to fix broken packages (git is more powerful, but more complex too). Remind trainees that they should send patches upstream, and warn them about the pain of maintaining patches. [[1]]

iurt

To test that a package builds in a clean environment, people can learn how to use iurt to simulate a real build. It also helps in triggering missing BuildRequires. More details may be found th the iurt page.

How to setup iurt on one’s machine

  1. install iurt
  2. modify /etc/sudoers to have administrator rights on /usr/sbin/iurt_root_command
  3. create a source rpm (rpmbuild -bs or bm -s)
  4. run iurt using a remote repository (need good bandwidth) example with abiword-2.8.6-1.mga1.src.rpm and http://ftp-stud.hs-esslingen.de/pub/Mirrors/Mageia/distrib/
iurt --repository http://ftp-stud.hs-esslingen.de/pub/Mirrors/Mageia/distrib/ \
 --chrooted-urpmi http://ftp-stud.hs-esslingen.de/pub/Mirrors/Mageia/distrib/ \
 --rebuild cauldron x86_64 ./SRPMS/abiword-2.8.6-1.mga1.src.rpm 

For 32-bit systems:

 iurt  --repository http://ftp-stud.hs-esslingen.de/pub/Mirrors/Mageia/distrib/ \
  --chrooted-urpmi http://ftp-stud.hs-esslingen.de/pub/Mirrors/Mageia/distrib/ \
  --rebuild cauldron i586 ./SRPMS/abiword-2.8.6-1.mga1.src.rpm

Cross compiling from x86_64 to i586:

linux32 iurt  --repository http://ftp-stud.hs-esslingen.de/pub/Mirrors/Mageia/distrib/ \
  --chrooted-urpmi http://ftp-stud.hs-esslingen.de/pub/Mirrors/Mageia/distrib/ \
  --rebuild cauldron i586 ./SRPMS/abiword-2.8.6-1.mga1.src.rpm

urpmi-proxy speeds up things

To save time and bandwidth you can set up urpmi-proxy and then use your proxy's URL:

iurt --repository http://localhost/mageia/distrib/ \
 --chrooted-urpmi http://localhost/mageia/distrib/ \
  --rebuild cauldron x86_64 ./SRPMS/abiword-2.8.6-1.mga1.src.rpm

For 32-bit systems:

iurt --repository http://localhost/mageia/distrib/ \
 --chrooted-urpmi http://localhost/mageia/distrib/ \
  --rebuild cauldron i586 ./SRPMS/abiword-2.8.6-1.mga1.src.rpm

Cross compiling from x86_64 to i586:

linux32 iurt --repository http://localhost/mageia/distrib/ \
 --chrooted-urpmi http://localhost/mageia/distrib/ \
  --rebuild cauldron i586 ./SRPMS/abiword-2.8.6-1.mga1.src.rpm

rpmlint

once trainees are comfortable with the various tool they need to use, a strong focus on quality should be made. rpmlint can ensure some packaging practices are respected, and policies should be emphasized.


Return to the Packagers portal