Development/Tasks/Packaging/Roles/Maintainer
From Mandriva Community Wiki
Contents |
New Maintainer
When your maintainer account has been created, don't forget to :
- Check if your new email address, yourlogin@mandriva.org is correctly forwarded to your real email address
- update your bugzilla email address to your mandriva.org email address, so that the bugs on the packages you maintain are automatically assigned to you
- update your http://my.mandriva.com/ account email address to your mandriva.org email address to be able to login to https://maint.mandriva.com/
- subscribe to the maintainers mailling list by sending an email to sympa@mandrivalinux.org with "subscribe maintainers" in the body.
Bookmarks
The important URLs are :
- http://kenobi.mandriva.com/bs/output.php : build status of uploaded packages
- https://maint.mandriva.com/ : packages maintainers database
- http://svn.mandriva.com/cgi-bin/viewvc.cgi/ : svn web interface. To do a checkout using your account use svn+ssh://login@svn.mandriva.com/svn/something.
- This wiki and the Policies pages.
Process overview
The package releasing process depends on several factors:
- branches (cooker, 2006.0, 10.2, etc...)
- section (main, contrib)
- repository
- architecture
Cooker is the dedicated development branch. All maintainers can freely release new updated packages in the contrib section. The main section is more restricted, only some maintainers can release updated packages, and new packages upon permission only. Usually packages should be uploaded to the /release repository of the appropriate section. The /testing repository is available for testing particularly dangerous changes.
The /release repositories of stable releases are frozen, meaning you can't upload packages there. The /testing and /updates repositories of the main section are used for issuing official security updates according to the Post-Release Support Policy (basically, you upload to /testing and pass the baton to the QA and security teams, who will take care of moving it to /updates). The contrib section is similar except the security and QA teams have no involvement, you will upload to /updates directly. The /backports repositories of both main and contrib are available for non-bugfix or security related updates.
Concerning architectures, the two officialy supported ones are i586 and x86_64. You have to make sure your package builds correctly on all of them. There are also other architectures, either developed internally or by the community. See Ports for details.
Technical details
Configuring your environment
The first thing you have to do is to set up your RPM build environment, following RPM Howto. There is no need to set up a GPG signature, however, as your packages will automatically get resigned with the official MDK keys when they will be uploaded.
Building on an NFS-mounted directory may cause troubles:
- locking problems
- slower read/write access
As a consequence, you'd better always build from the node where your home dir is located. When you don't have the choice, such as for the x86_64 arch, you may redefine the relevant rpm macro:
%_builddir %(if [ "$(hostname -a)" == "deborah" ]; then echo -n "/export/$HOME/rpm/BUILD"; else echo -n "%{_topdir}/BUILD"; fi)
Installing packages
On cooker systems, binary package installation is done through the rurpmi command, via sudo:
- sudo rurpmi foo to install or update foo package
- sudo rurpme foo to remove foo package
On the stable systems, binary package installation is done through standard urpm* commands, via sudo:
- sudo urpmi foo to install or update foo package
- sudo urpme foo to remove foo package
On all systems, source package installation can be done from the /SRPMS directory.
Building packages
You can either use rpm directly to build your package within your rpm build tree, or use iurt to build your package in a clean chroot: see Iurt Howto for details.
Your packages will be rebuilt anyway by iurt after submission, and you will receive a mail if something goes wrong.
For a step by step walkthrough about building a package for cooker and using svn, please see Repository System Quickstart. A quick reference page is also available at Build System Quickref.
Building packages for older distributions
You must use Iurt if you want to compile your packages on older version.
sudo iurt2006 package.src.rpm to build on a 2006.0 sudo iurt2007 package.src.rpm to build on a 2007.0
If you just want a chroot, use sudo iurt<version> --shell
Uploading packages
Please see Repository System Quickstart -- Submitting.
The queue is processed approximately every 5 minutes. All packages undergo some basic checks, such as existence of newer release existence, lack of continuity in history, etc... If any of those checks fails, the upload is canceled, and you get the errors list. Otherwise, the package is either put in a compilation queue, waiting for the build bot to recompile them. If the rebuild failed, you get a warning mail; if it succeeds, the packages are pushed to the upload server. A notification mail is then sent to the changelog mailing list. The changelog mail is only triggered by the source package file.
You have an overview of the compilation queue at http://kenobi.mandriva.com/bs/queue.php
Uploading a package during version freeze
During the freeze period, if you want to upload a package:
- You are not sure of your fix and you want it to be tested
Upload it with:
mdv-youri-submit --define section={main,contrib}/testing cooker <package>
It will appear on the media that are publicly available, and everybody will be able to test it and give you feedback. Once uploaded, you are encouraged to send a mail on cooker asking for tests.
You MUST include a bugzilla bug ID in your changelog. If there is no associated bug, try to explain clearly what was the bug and if possible how to reproduce it.
You must only provide the Source package, it will be recompiled by iurt and uploaded if the build succeeded.
You can see the current queue status from the cluster on http://svn.mandriva.com (this is quite raw but there is nothing better right now).
- You have really tested your fix, and this package is critically needed
Please ask a distrib-admin (mailto:distrib-admin@mandrivalinux.org?&cc=maintainers@mandriva.com?subject=upload request) to upload your package via using on the cluster:
mdv-youri-submit --define section={main,contrib}/release <package>
Orphaning Packages
When Mandriva maintainers do not want or are not able to maintain a package any longer, they can orphan the package.
Maintainers can manage their package maintainership by login into http://maintainers.mandriva.com/
