DRAFT
Mitarbeiten bei rpm.livna.org
So, you've decided to become a contributor to rpm.livna.org? This guide will lead you through your first package submission and teach you howto update your package(s) in the future.
Contents
Werde ein Livna Mitwirkender
Having packaging experience in Fedora is much preferred, but newcomers are welcome too. However if you are a newcomer you must first get sponsored, that is find someone to guide you while you learn the ropes.
Erzeuge ein Bugzilla Konto
In either scenario you should create your first livna package and submit this for review as described below. The review process is handled through bugzilla as will any bugs reported against your packages.
Make sure you have an account in Bugzilla.
The email address that you use for your bugzilla account should be the same email address as you use for all things related to rpm.livna.org.
Trete der Mailing Liste bei
Once this is done join the freeworld mailing list (and, optionally, the freeworld graphics mailing list) and introduce yourself there. Include a link to the review request for your first package in your introduction, and if you're a newcomer also mention that you need someone to sponsor you.
If you have questions about the packaging process, this is the place to ask.
Also join the livna subversion mailing list
The subversion mailing-list is used for commit messages for our Subversion repository. You should subscribe to this list to track the changes to our packages.
Übermittle ein neues Paket
Lesen die Paket-Richtlininen
Livna follows the Fedora packaging guidelines, make sure you've read and understood these:
It is also a good idea to read the items which will be checked during the review of your package and to verify yourself that these are all ok:
Create a package review request
Before your package can become part of livna it must first be reviewed, goto https://bugzilla.livna.org/ and create a new bug:
- choose "Meta" as product
- choose "Package Request" as Component
- set Summary to: "Review request: %{name} - %{summary} Where %{name} and %{summary} come from the specfile
- Put the following in the description:
- full URL's to the specfile and the SRPM for the new package
- a short description for the package (hint use %description from the spec)
- why this package is not eligible as a regular Fedora package
- rpmlint output from running rpmlint on both the SRPM and RPM's build
- + from it. Explain for each rpmlint message why you've chosen to ignore it.
- put "QA" in the keywords field. All Review Requests are tagged with this keyword, this way other contributers can easily check for packages that need reviewing. If you want to help others by doing reviews yourself goto:
Wait for your package to be reviewed
As time permits another livna contributer will review your package, sometimes other people add a few comments, this does not constitute a review. when a real / full review gets done the reviewer will assign the bug to him and post a list with his findings with regards to all the Must Check items from the Fedora Review Guidelines. The reviewer will end the comment with all the checked items with a list of things which must be fixed and optionally a list of things which should be fixed.
You should now create an improved version with all the things, which must be fixed, fixed and then add a comment to the bug with:
- which items you fixed and if relevant how
- full URL's to the specfile and the SRPM for the new version
Your package gets approved
If your improved version is okay the reviewer will approve it, by adding a comment that the package is approved.
Its also possible that your package still needs some improvements in which case the reviewer will add a comment saying so and listing which improvements are needed, after which you should create a new improved version and then add a comment about this new improved version as described above. This may repeat until your package is ok.
Ask for creation of a directory for your package in svn
Once approved the submitter sends a private mail to Dams (anvil@livna.org)* to request the creation of a directory in svn for this package and the creation of an ACL so that he will be able to write to that dir. If this is your first package then Dams will also create an svn account for you.
* ATM, Dams is the only person with the necessary powers to create the needed ACL.
Importieren Sie Ihr Paket
Once the dir has been created in svn, the package must be imported into svn. Livna recently has created an import script, but thats alpha, so you might want todo the import manual.
Konfiguration von SSH
Der svn.livna.org Subversion sshd hört auf dem nich-standardmässigen Port 6868. Um dies zu konfigurieren, fügen Sie etwas in der folgenden Art zu Ihrer ~/.ssh/config hinzu:
Host svn.livna.org
Port 6868
Manueller Import
Before you can begin the import you need to have a directory structure matching that in svn, or a complete checkout of svn. If you already have this you can skip the steps below:
mkdir <some-convenient-path>/livna cd <some-convient-path>/livna svn co svn+ssh://<username>@svn.livna.org/rlo/plague-svn svn co svn+ssh://<username>@svn.livna.org/rlo/common mkdir packages
And then now the actual importing:
cd <some-convenient-path>/livna/packages svn co svn+ssh://<username>@svn.livna.org/rlo/packages/<package-name> cd <package-name> svn mkdir devel svn copy ../../plague-svn/Makefile-in-package-dir ./Makefile svn copy ../../plague-svn/Makefile-in-branch-dir ./devel/Makefile <favorite editor> devel/Makefile -> change NAME to <package-name> cd devel cp <package-name>.spec <package-sources> <package-patches> . sha1sum <files-to-be-imported-in-lookaside-cache> > SHA1SUM svn add <package-name>.spec <package-patches> SHA1SUM cd .. svn commit -m "initial devel libmms import" Makefile devel svn copy devel F-<current> echo FC-<current> > F-<current>/branch; svn add F-<current>/branch svn commit -m "initial F-<current> libmms import" F-<current>
See other packages in svn for correct branch names (FC-6, F-7, devel, ...)
Automatischer Import
If you already have a checkout of the common dir you can skip the steps below:
mkdir <some-convenient-path>/livna cd <some-convient-path>/livna svn co svn+ssh://<username>@svn.livna.org/rlo/common
Next download the ALPHA svn-import.sh script and save it in the common dir, then do:
chmod +x svn-import.sh ./svn-import.sh <path-to>/<package-name>-<version>-<release>.src.rpm
Und lehnen Sie sich zurück und entspannen Sie sich während das Skript (hoffentlich) die Arbeit macht.
Markieren der importierten Quellen
Now you should tag the just imported sources so that the plague buildsys can find them:
cd <some-convenient-path>/livna/packages/<package-name>/devel make tag cd <some-convenient-path>/livna/packages/<package-name>/F-<current> make tag
If make tag fails on this line:
test -z "$(LC_ALL=en_US.UTF-8 svn status $(dirname <package-name>.spec))"
Do a "svn status" in the dir. Any files which are printed with a "?" in front of them should be removed (unless they should be in svn in which case you should do a: "svn add <filename>"). If there are files with a letter in front of them, then the dir contains changes not yet committed to svn, commit them and try again.
Anfordern eines Bau-Vorgang
Add a comment to the review that the import has been done and change the keywords field from QA to PUBLISH
People who have access to build packages monitor the PUBLISH queue and take care of stuff (download package sources to the look aside cache, build, sign and push).
Aktualisierung eines bestehenden Paketes
- Update your local copy and test it
- Remember to keep the SHA1SUM file up to date with sha1sums of all files in the look aside cache (or destined to it). Do this even if you don't have access to upload to the look aside cache, it is a prerequisite for updating it.
- Commit your changes to svn, with a _useful_ changelog message (same command line syntax as cvs, see svn docs)
- After committing your change run "make tag" to tag your files so that the plague buildsystem can find the correct version to build.
- The commit message from step 3 is sent to a mailing list which is being monitored by people who can update the look aside cache (if necessary) and give the build command to the plague buildsys.