From Fedora Project Wiki

No edit summary
m (grammar)
(13 intermediate revisions by 10 users not shown)
Line 2: Line 2:
{{admon/important|Contributors only!|This document is for existing Contributors only. If you do not already have a Fedora account or if this is your ''first'' Fedora package, you ''must'' follow the process documented in [[Join_the_package_collection_maintainers|Join the package collection maintainers]].}}
{{admon/important|Contributors only!|This document is for existing Contributors only. If you do not already have a Fedora account or if this is your ''first'' Fedora package, you ''must'' follow the process documented in [[Join_the_package_collection_maintainers|Join the package collection maintainers]].}}


{{admon/important | Git config needs| A config problem has been discovered which may make <code>fedpkg push</code> or <code>fedpkg commit -p</code> or even <code>git push</code> not understand your intentions.  As a short term work around, you can run: <code>git config --global --add push.default tracking</code>.  This option tells git that when it gets a push request with no other arguments, see if it's tracking a remote branch.  If it is, push to that remote branch.  This seems like it will usually be safe no matter what git repository you are using.}}
{{admon/important | Git config needs| A config problem has been discovered which may make <code>fedpkg push</code> or <code>fedpkg commit -p</code> or even <code>git push</code> not understand your intentions.  As a short term workaround, you can run: <code>git config --global --add push.default tracking</code>.  This option tells git that when it gets a push request with no other arguments, see if it's tracking a remote branch.  If it is, push to that remote branch.  This seems like it will usually be safe no matter what git repository you are using.}}
 
{{admon/tip | Modularity | If you want to build your package as a module (on an independent life cycle, for multiple Fedora releases out of a single source branch, or in multiple versions for one or more releases), see the [https://docs.fedoraproject.org/en-US/modularity/making-modules/adding-new-modules/ Adding new modules page] in Fedora Docs. }}


This is a short version of the [[PackageMaintainers/Join]] document, streamlined to show how existing contributors can make new packages.
This is a short version of the [[PackageMaintainers/Join]] document, streamlined to show how existing contributors can make new packages.
Line 8: Line 10:
'''Step 1:''' Read the [[Packaging:Guidelines|  Packaging Guidelines]]  and [[Packaging:NamingGuidelines|  Package Naming Guidelines]] . Really. Be comfortable with them. <BR>
'''Step 1:''' Read the [[Packaging:Guidelines|  Packaging Guidelines]]  and [[Packaging:NamingGuidelines|  Package Naming Guidelines]] . Really. Be comfortable with them. <BR>
'''Step 2:''' Make a package.
'''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/packages/
* You should make sure that it is a new package. A list of existing packages in Fedora Packages is here: https://src.fedoraproject.org/projects/rpms/*
* Some information on how to create an RPM package is in the [[PackageMaintainers/CreatingPackageHowTo| Creating Package HOWTO]]
* Some information on how to create an RPM package is in the [[PackageMaintainers/CreatingPackageHowTo| Creating Package HOWTO]]
* Make sure that your package meets the [[Packaging:Guidelines|  Packaging Guidelines]]  and [[Packaging:NamingGuidelines|  Package Naming Guidelines]]  
* Make sure that your package meets the [[Packaging:Guidelines|  Packaging Guidelines]]  and [[Packaging:NamingGuidelines|  Package Naming Guidelines]]  
Line 14: Line 16:
'''Step 3:''' Upload your SRPM and SPEC files onto the internet somewhere. <BR>
'''Step 3:''' Upload your SRPM and SPEC files onto the internet somewhere. <BR>
* If you have already got a Fedora Account then you can use your storage at http://fedorapeople.org for this.
* 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 <BR>
'''Step 4:''' Make sure you have a Bugzilla account at bugzilla.redhat.com <BR>
'''Step 5:''' Fill out this form: https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&format=fedora-review
'''Step 5:''' Fill out this form: https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&format=fedora-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 you put the name of the package in the Review Summary field, along with a very brief summary of what it is
Line 20: Line 22:
* Put a description of your package (usually, this can be the same thing as what you put in the spec %description) in 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: [[Packaging:ReviewGuidelines|  Package Review Guidelines]]  
* The review process is described in detail here: [[Packaging:ReviewGuidelines|  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. <BR>
'''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. <BR>
'''Step 7:''' When the package is approved by the reviewer, request a git module and branches with the [[PackageDB_admin_requests| PackageDB admin requests]] . <BR>
'''Step 7:''' When the package is approved by the reviewer, request a git module <code>fedpkg request-repo PACKAGE-NAME BUGZILLA-TICKET-NUMBER</code> and when the repo is created request branches using <code>fedpkg request-branch --repo PACKAGE-NAME BRANCH</code> (see [https://fedoraproject.org/wiki/Changes/fedrepo-req-to-fedpkg])<BR> You might need to get a pagure-API-token before being able to successfully request the repo.<BR>
 
{{admon/tip | Extra info | If you want to set the description or upstream url on the distgit repo, pass the <code>--description</code> or <code>--upstreamurl</code> flags to <code>fedpkg request-repo</code>.}}
 
{{admon/tip | All branches | If you want to request all active Fedora branches, pass the <code>--all-releases</code> flag to <code>fedpkg request-branch</code>.}}
 
* Please wait until the request is approved.
* Please wait until the request is approved.
'''Step 8:''' Once the request is approved, checkout the git module (details [[Join_the_package_collection_maintainers#Check_out_the_module|here]])
'''Step 8:''' Once the request is approved, checkout the git module <code> fedpkg clone &lt;packagename&gt; </code> (details [[Join_the_package_collection_maintainers#Check_out_the_module|here]])
* Once you have the git module, checkout your module from git.  Refer to the [[Package maintenance guide]]
* Refer to the [[Package maintenance guide]]
* It is probably a good idea to make a "git" toplevel directory, then check-out your files inside of that.
* 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
'''Step 9:''' Import your srpm
* First kinit username@FEDORAPROJECT.ORG
* First <code>kinit username@FEDORAPROJECT.ORG</code>
* Then you can import the approved SRPM into master branch by running <code> fedpkg import libfoo-x.x.x.src.rpm; git commit -m "Initial import (#nnnnnn)."</code> (where nnnnnn is your Bugzilla package review bug number).
* Then you can import the approved SRPM into the master branch by running <code> fedpkg import libfoo-x.x.x.src.rpm; git commit -m "Initial import (#nnnnnn)."</code> (where nnnnnn is your Bugzilla package review bug number).
* Obviously, replace libfoo-x.x.x.src.rpm with the full path to your approved SRPM.
* Obviously, replace libfoo-x.x.x.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.
* 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.
* 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
'''Step 10:''' You can now import the package to your branches (which you has requested in Step 7) too
* The quickest way to do this is to use <code>fedpkg switch-branch BRANCH</code> to switch the branch (where BRANCH can be "f13" and so on).
* The quickest way to do this is to use <code>fedpkg switch-branch BRANCH</code> to switch the branch (where BRANCH can be "f13" and so on).
* Now you can <code>git merge master</code>. This will get .spec file, .gitignore and source file together with any patches and other files from master branch and create identical commit.
* Now you can <code>git merge master</code>. This will get .spec file, .gitignore and source file together with any patches and other files from master branch and create an identical commit.
* Previous step already created commit for you, now you can push the results using <code>fedpkg push</code> or <code>git push</code>.
* Previous step already created commit for you, now you can push the results using <code>fedpkg push</code> or <code>git push</code>.
'''Step 11:''' Request builds
'''Step 11:''' Request builds
Line 41: Line 47:
* 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.
'''Step 12:''' Close the bugzilla ticket (assuming that the package built successfully)
'''Step 12:''' Close the Bugzilla ticket (assuming that the package built successfully)
* You should close it with resolution NEXTRELEASE or RAWHIDE, depending on where you built the package.  The resolution field will appear after you set the status field to CLOSED.
* You should close it with resolution NEXTRELEASE or RAWHIDE, depending on where you built the package.  The resolution field will appear after you set the status field to CLOSED.
'''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 [[Package_update_HOWTO#Later_Branched_and_stable_releases|the update submission guide]] for more details.<BR>
'''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 [[Package_update_HOWTO#Later_Branched_and_stable_releases|the update submission guide]] for more details.<BR>
Line 48: Line 54:
'''Step 15:''' Consider enabling [[Upstream Release Monitoring]] for the package.
'''Step 15:''' Consider enabling [[Upstream Release Monitoring]] for the package.


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. <BR>
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 the fedora development list. <BR>


http://lists.fedoraproject.org/pipermail/devel/
http://lists.fedoraproject.org/pipermail/devel/

Revision as of 06:59, 27 April 2020

Important.png
Contributors only!
This document is for existing Contributors only. If you do not already have a Fedora account or if this is your first Fedora package, you must follow the process documented in Join the package collection maintainers.
Important.png
Git config needs
A config problem has been discovered which may make fedpkg push or fedpkg commit -p or even git push not understand your intentions. As a short term workaround, you can run: git config --global --add push.default tracking. This option tells git that when it gets a push request with no other arguments, see if it's tracking a remote branch. If it is, push to that remote branch. This seems like it will usually be safe no matter what git repository you are using.
Idea.png
Modularity
If you want to build your package as a module (on an independent life cycle, for multiple Fedora releases out of a single source branch, or in multiple versions for one or more releases), see the Adding new modules page in Fedora Docs.

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.

Step 3: Upload your SRPM and SPEC files onto the internet somewhere.

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=fedora-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 fedpkg request-repo PACKAGE-NAME BUGZILLA-TICKET-NUMBER and when the repo is created request branches using fedpkg request-branch --repo PACKAGE-NAME BRANCH (see [1])
You might need to get a pagure-API-token before being able to successfully request the repo.

Idea.png
Extra info
If you want to set the description or upstream url on the distgit repo, pass the --description or --upstreamurl flags to fedpkg request-repo.
Idea.png
All branches
If you want to request all active Fedora branches, pass the --all-releases flag to fedpkg request-branch.
  • Please wait until the request is approved.

Step 8: Once the request is approved, checkout the git module fedpkg clone <packagename> (details here)

  • Refer to the Package maintenance guide
  • It is probably a good idea to make a "git" toplevel directory, then check-out your files inside of that.

Step 9: Import your srpm

  • First kinit username@FEDORAPROJECT.ORG
  • Then you can import the approved SRPM into the 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 libfoo-x.x.x.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 (which you has requested in Step 7) 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).
  • Now you can git merge master. This will get .spec file, .gitignore and source file together with any patches and other files from master branch and create an identical commit.
  • Previous step already created commit for you, now you can push the results using fedpkg push or git 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
  • 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 with resolution NEXTRELEASE or RAWHIDE, depending on where you built the package. The resolution field will appear after you set the status field to CLOSED.

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 the update submission guide for more details.
Step 14: Add the package to the comps file(s) if appropriate.
Step 15: Consider enabling Upstream Release Monitoring for the package.

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 the fedora development list.

http://lists.fedoraproject.org/pipermail/devel/

There is a helpful Package maintenance guide which may also be of use.