From Fedora Project Wiki

(Redirect Package Maintainer wiki links to docs.fp.o)
 
(44 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Fedora Package Process ==
== Fedora Package Process ==
This cheat sheet will demonstrate how to create a RPM package using eclipse Fedora Packager.
=== Create Account ===
=== Create Account ===
If you are a new package maintainer:
If you are a new package maintainer:
* Create a new account on [https://admin.fedoraproject.org/accounts Fedora Account System (FAS)]
* Create a new account on [https://admin.fedoraproject.org/accounts Fedora Account System (FAS)]
** Click on 'New account' and fill in the blanks.
** Click on 'New account' and fill in the blanks.
After you create your account, please be sure to sign the CLA (if you click on the "My Account" link in the top right, you should see CLA: CLA Done).
**After you create your account, please be sure to sign the CLA (if you click on the "My Account" link in the top right, you should see CLA: CLA Done).
Also you need to upload a public RSA SSH key. You need to use the matching private key to access Fedora machines via SSH
**Also you need to upload a public RSA SSH key. You need to use the matching private key to access Fedora machines via SSH.
* Create an account in Red Hat [https://bugzilla.redhat.com/ bugzilla].
*** Here is information on [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keygen creating SSH key].
* Install the client tools
* Create an account in Red Hat [https://bugzilla.redhat.com/createaccount.cgi bugzilla].
: Koji, generate a client side certificate at FAS, install fedora-packager
* Install the client tools  
** To build Packages for the Fedora Collection or [[EPEL|EPEL]], you need [https://docs.fedoraproject.org/en-US/package-maintainers/Using_the_Koji_Build_System/ Koji].
** You'll also need to [https://admin.fedoraproject.org/accounts/user/gencert generate a client side certificate at the Fedora Account System] and save the file in ~/.fedora.cert, where fedpkg will look for it by default.
** You can now use "koji" to try to build your RPM packages on platforms (e.g., PPC) or distributions you don't have. Note that you can test out builds ("scratch" builds) even when your package hasn't been approved and you don't have a sponsor. [https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/#install_the_developer_client_tools Here] is a simple way to do a scratch build using koji on the command line.


=== Make a Package ===
=== Make a Package ===
* Make sure it is a new package.
* Make sure it is a new package. Check this [https://admin.fedoraproject.org/pkgdb/acls/list/ list] of existing packages.
* Create an RPM package:
* Create an RPM package:
: Create a new RPM project, create a spec file, upload source files, export source/binary RPM
** Select "File->New->Other..." from the main menu. Choose "RPM->RPM Project", click "Next".
* Make sure it is a suitable package (Read the packaging guidelines - Read other submissions)
** Input the "Project name". Click "Finish".
Assist at creating FAS account/Red Hat bugzilla account, etc. Maybe create an interactive help page, which walks one through the steps
** Right click on SPECS, select "New->Other...", choose "RPM->Specfile Based on a Template", click "Next".
Create an RPM spec-file project
** Fill out the template or accept the default values and customize it based your package specifications.
Use RPM-stubby to create a spec-file stub
*** You can also use RPM-stubby plug-in to create a spec-file stub.  
Contributor works on spec-file. Tests on local builds. Support mock builds.
** To send your SRPM/Spec-file for review, select "File->Export" from the main munu, choose "RPM->Source/Binary RPM", click "Next".
Export SRPM/spec-file for review (provide space to enter URL of hosted SRPM/.spec or scp to fedorapeople.org) and create review-request bug (using mylyn)
** Based on your requirements, select one or both options, click "Finish".
Create an RPM .spec project
* Make sure it is a suitable package
Contributor works on spec-file. Tests on local builds. Support mock builds.
** Check [[Packaging:Guidelines|Packaging Guidelines]] and [[Packaging:NamingGuidelines|Packaging Naming Guidelines]] to see if it meets the requirements
Export SRPM/spec-file for review (scp to fedorapeople.org) and create review-request bug (using mylyn)
** Read some other package submissions to learn about packaging and gain familiarity with the process and requirements. One way of doing this is to join the package-review@lists.fedoraproject.org mailing list.
 
(provide space to enter URL of hosted SRPM/.spec or scp to fedorapeople.org) and create review-request bug (using mylyn)


=== Submit For Review ===
=== Submit For Review ===
* Join the mailing lists (introduce yourself)  
* Join the mailing lists (--'''Are all these info for mailing list necessary here, or shall we just put a link to them: http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Join_the_important_Mailing_Lists?''')
* Upload your package (e.g. to repos.fedorapeople.org)
** When a new package maintainer joins the Fedora Project, we request that he/she introduces themselves on the devel@lists.fedoraproject.org. To sign up for the list, visit the devel list signup page . The primary purpose of this is to begin the process of building trust by learning about the package maintainer and increase the chances of your review request being processed sooner.
* Create your review request (--set an appropriate flag for package review, inform upstream)
***The purpose of all this is to break anonymity and foster real-world community within the project. You are under no obligation to reveal personal secrets. The objective is to establish a level of trust with yourself and the other members of the project.
***Subject: Self Introduction
***Body: Add any information you believe is applicable including past experience, a link to the review request you have filed and a brief description of yourself. You can also post your GPG key information if you want to.
**You must join the fedora devel-announce@lists.fedoraproject.org mailing list. It is a low traffic announcements only list, where important development information is posted.
**You can join the fedora devel@lists.fedoraproject.org mailing list, where discussions about the development of Fedora are held. This is a high traffic mailing list.
**You can also consider joining the package-announce@lists.fedoraproject.org mailing list -- The commits mailing list gets notifications on all commits in any package in the Fedora repository. This is a very high traffic mailing list. The Fedora package database sends commit mails for packages you (co-)maintain.
**Another mailing list you might consider (at least to view the archives) is packaging@lists.fedoraproject.org. This is the mailing list of the Fedora Packaging Committee, who determine the official packaging guidelines for Fedora projects.
* Upload your package  
** Upload your SRPM and SPEC files onto the Internet somewhere. This can be anywhere accessible by a URL.  
** If you need hosting space, please make a note of it in your ticket submission and someone will take care of you.
** If you have already got a Fedora Account then you can use your storage at <user-name>.fedorapeople.org for this.
* Create your review request  
** Fill out this form at [https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&format=fedora-review bugzilla].
** Before submitting your request, be sure there’s not a previous request for the same package.
** Make sure that you put the name of the package (excluding version and release numbers) in the 'Review Summary' field, along with a very brief summary of what the package is.
** Put a description of your package (usually, this can be the same thing as what you put in the spec %description) in the 'Review Description' field.
** Include the URLs to your SRPM and SPEC files.
** If this is your first package, explain it and say that you need a sponsor.
* Watch the bugzilla report for feedback
* Watch the bugzilla report for feedback
** You should get notifications of changes by email. Fix any blockers that the reviewer(s) point out.


=== Ready to Ship ===
=== Ready to Ship ===
Follow these steps after your package is approved by reviewers.
Follow these steps after your package is approved by reviewers.
* Obtain member sponsorship (to check in and build your package)
* Obtain member sponsorship (to check in and build your package)
** you must separately obtain member sponsorship in order to check in and build your package. Sponsorship is not automatic and may require that you further participate in other ways in order to demonstrate your understanding of the packaging guidelines.
** Key to becoming sponsored is to convince an existing sponsor-level member that you understand and follow the project's guidelines and processes.
** See [https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/ how to get sponsored into the packager group] for more information.
*  Add package to Source Code Management (SCM) system and Set Owner
*  Add package to Source Code Management (SCM) system and Set Owner
When the package is approved by the reviewer, request a git module and branches with the [[Package_SCM_admin_requests|SCM admin requests]].
* Check out the empty module from SCM
* Check out the empty module from SCM
: fedpkg clone <packagename>
** Once you have the git module, checkout your module from git.
 
*** Select "import->Git->Projects from Fedora Git" and click on Next.
* Test your package ?
*** Input the name of the package in the "Package name".
: using Mock or Koji build systems
** It is probably a good idea to make a "git" toplevel directory, then check-out your files inside of that. (--'''Do we need this line?''')


=== Update your SCM ===
=== Update your SCM ===
* Import and commit your SRPM into master branch  
* Import and commit your SRPM into master branch  
** Right click on your rpm file in SRPMS folder on your local RPM project in eclipse, select "Copy".
** Right click on your cloned project from Fedora Git, select "Paste". (--'''We can consider making it simpler by just one click on RPM project''')
** Right click on pasted file, select "Fedora Packager->Upload this File->Add to Existing Sources".
** Do the same steps for your .spec file.
* Build your package
* Build your package
** Select your spec file, right click, select "Fedora Packager->Prepare for local build".
--'''what are the other steps here? -"Build for Local Architecture", then "Local Build using Mock" then "push the build to Koji"?'''
--'''Do we actually need to put all of them here or just refer to "Fedora Packager User Guide" in Eclipse help?'''
* Submit your package as update in Bodhi
* Submit your package as update in Bodhi
**  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.
** For doing this, right click on your project, select "Fedora Packager->Create New Bodhi Update".
* Close the bugzilla account
* Close the bugzilla account
* Add the package to the comp files --if appropriate for the package
** If the package built successfully, you should close it as NEXTRELEASE.
* Add the package to the comp files
** If appropriate for the package, make it available in "comps" files so that it can be selected during installation and included in yum's package group operations. See [[PackageMaintainers/CompsXml|PackageMaintainers/CompsXml]] for more info.
* Enable Upstream Release Monitoring
* Enable Upstream Release Monitoring
** Fedora has infrastructure available for monitoring new upstream releases of the software you are packaging. Refer to [https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring/ Upstream Release Monitoring] for more details.

Latest revision as of 19:35, 2 October 2021

Fedora Package Process

This cheat sheet will demonstrate how to create a RPM package using eclipse Fedora Packager.

Create Account

If you are a new package maintainer:

  • Create a new account on Fedora Account System (FAS)
    • Click on 'New account' and fill in the blanks.
    • After you create your account, please be sure to sign the CLA (if you click on the "My Account" link in the top right, you should see CLA: CLA Done).
    • Also you need to upload a public RSA SSH key. You need to use the matching private key to access Fedora machines via SSH.
  • Create an account in Red Hat bugzilla.
  • Install the client tools
    • To build Packages for the Fedora Collection or EPEL, you need Koji.
    • You'll also need to generate a client side certificate at the Fedora Account System and save the file in ~/.fedora.cert, where fedpkg will look for it by default.
    • You can now use "koji" to try to build your RPM packages on platforms (e.g., PPC) or distributions you don't have. Note that you can test out builds ("scratch" builds) even when your package hasn't been approved and you don't have a sponsor. Here is a simple way to do a scratch build using koji on the command line.

Make a Package

  • Make sure it is a new package. Check this list of existing packages.
  • Create an RPM package:
    • Select "File->New->Other..." from the main menu. Choose "RPM->RPM Project", click "Next".
    • Input the "Project name". Click "Finish".
    • Right click on SPECS, select "New->Other...", choose "RPM->Specfile Based on a Template", click "Next".
    • Fill out the template or accept the default values and customize it based your package specifications.
      • You can also use RPM-stubby plug-in to create a spec-file stub.
    • To send your SRPM/Spec-file for review, select "File->Export" from the main munu, choose "RPM->Source/Binary RPM", click "Next".
    • Based on your requirements, select one or both options, click "Finish".
  • Make sure it is a suitable package
    • Check Packaging Guidelines and Packaging Naming Guidelines to see if it meets the requirements
    • Read some other package submissions to learn about packaging and gain familiarity with the process and requirements. One way of doing this is to join the package-review@lists.fedoraproject.org mailing list.

(provide space to enter URL of hosted SRPM/.spec or scp to fedorapeople.org) and create review-request bug (using mylyn)

Submit For Review

  • Join the mailing lists (--Are all these info for mailing list necessary here, or shall we just put a link to them: http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Join_the_important_Mailing_Lists?)
    • When a new package maintainer joins the Fedora Project, we request that he/she introduces themselves on the devel@lists.fedoraproject.org. To sign up for the list, visit the devel list signup page . The primary purpose of this is to begin the process of building trust by learning about the package maintainer and increase the chances of your review request being processed sooner.
      • The purpose of all this is to break anonymity and foster real-world community within the project. You are under no obligation to reveal personal secrets. The objective is to establish a level of trust with yourself and the other members of the project.
      • Subject: Self Introduction
      • Body: Add any information you believe is applicable including past experience, a link to the review request you have filed and a brief description of yourself. You can also post your GPG key information if you want to.
    • You must join the fedora devel-announce@lists.fedoraproject.org mailing list. It is a low traffic announcements only list, where important development information is posted.
    • You can join the fedora devel@lists.fedoraproject.org mailing list, where discussions about the development of Fedora are held. This is a high traffic mailing list.
    • You can also consider joining the package-announce@lists.fedoraproject.org mailing list -- The commits mailing list gets notifications on all commits in any package in the Fedora repository. This is a very high traffic mailing list. The Fedora package database sends commit mails for packages you (co-)maintain.
    • Another mailing list you might consider (at least to view the archives) is packaging@lists.fedoraproject.org. This is the mailing list of the Fedora Packaging Committee, who determine the official packaging guidelines for Fedora projects.
  • Upload your package
    • Upload your SRPM and SPEC files onto the Internet somewhere. This can be anywhere accessible by a URL.
    • If you need hosting space, please make a note of it in your ticket submission and someone will take care of you.
    • If you have already got a Fedora Account then you can use your storage at <user-name>.fedorapeople.org for this.
  • Create your review request
    • Fill out this form at bugzilla.
    • Before submitting your request, be sure there’s not a previous request for the same package.
    • Make sure that you put the name of the package (excluding version and release numbers) in the 'Review Summary' field, along with a very brief summary of what the package is.
    • Put a description of your package (usually, this can be the same thing as what you put in the spec %description) in the 'Review Description' field.
    • Include the URLs to your SRPM and SPEC files.
    • If this is your first package, explain it and say that you need a sponsor.
  • Watch the bugzilla report for feedback
    • You should get notifications of changes by email. Fix any blockers that the reviewer(s) point out.

Ready to Ship

Follow these steps after your package is approved by reviewers.

  • Obtain member sponsorship (to check in and build your package)
    • you must separately obtain member sponsorship in order to check in and build your package. Sponsorship is not automatic and may require that you further participate in other ways in order to demonstrate your understanding of the packaging guidelines.
    • Key to becoming sponsored is to convince an existing sponsor-level member that you understand and follow the project's guidelines and processes.
    • See how to get sponsored into the packager group for more information.
  • Add package to Source Code Management (SCM) system and Set Owner

When the package is approved by the reviewer, request a git module and branches with the SCM admin requests.

  • Check out the empty module from SCM
    • Once you have the git module, checkout your module from git.
      • Select "import->Git->Projects from Fedora Git" and click on Next.
      • Input the name of the package in the "Package name".
    • It is probably a good idea to make a "git" toplevel directory, then check-out your files inside of that. (--Do we need this line?)

Update your SCM

  • Import and commit your SRPM into master branch
    • Right click on your rpm file in SRPMS folder on your local RPM project in eclipse, select "Copy".
    • Right click on your cloned project from Fedora Git, select "Paste". (--We can consider making it simpler by just one click on RPM project)
    • Right click on pasted file, select "Fedora Packager->Upload this File->Add to Existing Sources".
    • Do the same steps for your .spec file.
  • Build your package
    • Select your spec file, right click, select "Fedora Packager->Prepare for local build".

--what are the other steps here? -"Build for Local Architecture", then "Local Build using Mock" then "push the build to Koji"? --Do we actually need to put all of them here or just refer to "Fedora Packager User Guide" in Eclipse help?

  • Submit your package as update in Bodhi
    • 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.
    • For doing this, right click on your project, select "Fedora Packager->Create New Bodhi Update".
  • Close the bugzilla account
    • If the package built successfully, you should close it as NEXTRELEASE.
  • Add the package to the comp files
    • If appropriate for the package, make it available in "comps" files so that it can be selected during installation and included in yum's package group operations. See PackageMaintainers/CompsXml for more info.
  • Enable Upstream Release Monitoring
    • Fedora has infrastructure available for monitoring new upstream releases of the software you are packaging. Refer to Upstream Release Monitoring for more details.