Denisarnaud (talk | contribs) mNo edit summary |
No edit summary |
||
Line 35: | Line 35: | ||
* Once you've put the files in, commit them with: <code>git commit -m "Initial import (#nnnnnn)."</code> and push the results with <code>git push</code>. | * Once you've put the files in, commit them with: <code>git commit -m "Initial import (#nnnnnn)."</code> and push the results with <code>git push</code>. | ||
'''Step 11:''' Request builds | '''Step 11:''' Request builds | ||
* For each branch that you'd like to request a build for, switch using fedpkg switch-branch and run: <code>fedpkg build</code> | * For each branch that you'd like to request a build for, switch using fedpkg switch-branch and run: <code>fedpkg build</code> (as usual, you don't need to request builds for the master branch) | ||
* If everything goes well, it should queue up your branch for building, the package will cleanly build, and you're done! | * If everything goes well, it should queue up your branch for building, the package will cleanly build, and you're done! | ||
* If it fails to build, the buildsystem will send you an email to report the failure and link you to the logs. Commit any needed changes to git, bump the spec release number and request a new build. | * If it fails to build, the buildsystem will send you an email to report the failure and link you to the logs. Commit any needed changes to git, bump the spec release number and request a new build. |
Revision as of 01:36, 11 August 2010
This is a short version of the PackageMaintainers/Join document, streamlined to show how existing contributors can make new packages.
Step 1: Read the Packaging Guidelines and Package Naming Guidelines . Really. Be comfortable with them.
Step 2: Make a package.
- You should make sure that it is a new package. A list of existing packages in Fedora Packages is here: https://admin.fedoraproject.org/pkgdb/acls/list/
- Some information on how to create an RPM package is in the Creating Package HOWTO
- Make sure that your package meets the Packaging Guidelines and Package Naming Guidelines
- Be aware of ForbiddenItems and Package Review Guidelines (they will be used during the package review)
Step 3: Upload your SRPM and SPEC files onto the internet somewhere.
- If you have already got a Fedora Account then you can use your storage at http://fedorapeople.org for this.
Step 4: Make sure you have a bugzilla account at bugzilla.redhat.com
Step 5: Fill out this form: https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&format=extras-review
- Make sure you put the name of the package in the Review Summary field, along with a very brief summary of what it is
- Make sure that you put the URL paths for the SPEC file and the SRPM file in the Review Description
- Put a description of your package (usually, this can be the same thing as what you put in the spec %description) in Review Description
- The review process is described in detail here: Package Review Guidelines
Step 6: Watch the bugzilla report for your first package (you created this in step 5). Fix any blockers that the reviewer(s) point out.
Step 7: When the package is approved by the reviewer, request a git module and branches with the SCM admin requests .
Step 8: Checkout the git module (details here )
- Once you have the git module, checkout your module from git. Refer to https://fedoraproject.org/wiki/Using_Fedora_GIT
- It is probably a good idea to make a "git" toplevel directory, then check-out your files inside of that.
- If your package is named foobar, this is done with: fedpkg clone foobar
Step 9: Import your srpm
- Then you can import the approved SRPM into master branch by running
fedpkg import libfoo-x.x.x.src.rpm; git commit -m "Initial import (#nnnnnn)."
(where nnnnnn is your Bugzilla package review bug number). - Obviously, replace nameofmy.src.rpm with the full path to your approved SRPM.
- You should see it upload the sources, and finish successfully. If you didn't set up ssh-agent it will ask often for your ssh-key passphrase. This is normal.
- Now run git push to get the final versions in your master branch.
Step 10: You can now import the package to your branches too
- The quickest way to do this is to use
fedpkg switch-branch BRANCH
to switch the branch (where BRANCH can be "f13" and so on). - Get the sources in. One way is to copy the sources file, .gitignore file, .spec file and any patches from master to each branch. Also check if the Makefile exists and copy it if necessary. After that,
git add
all copied files. Alternatively, usefedpkg import
as above. - Once you've put the files in, commit them with:
git commit -m "Initial import (#nnnnnn)."
and push the results withgit push
.
Step 11: Request builds
- For each branch that you'd like to request a build for, switch using fedpkg switch-branch and run:
fedpkg build
(as usual, you don't need to request builds for the master branch) - If everything goes well, it should queue up your branch for building, the package will cleanly build, and you're done!
- If it fails to build, the buildsystem will send you an email to report the failure and link you to the logs. Commit any needed changes to git, bump the spec release number and request a new build.
Step 12: Close the bugzilla ticket (assuming that the package built successfully)
- You should close it as NEXTRELEASE.
Step 13: If this package will be built for any version of Fedora that is already released please submit it for inclusion in the 'fedora-updates' repository for those versions of Fedora. See submitting your update to bodhi for more details.
Step 14: Add the package to the comps file(s) if appropriate.
We know that this process can be as clear as mud sometimes, we're always trying to make it better. If you run into any problems, or have any questions, please ask on fedora development list.
http://lists.fedoraproject.org/pipermail/devel/
There is a helpful git FAQ which also includes instructions for making new releases.