Edit Info Other
Login

Diff for "Contributors"

Differences between revisions 3 and 88 (spanning 85 versions)
Revision 3 as of 2007-09-24 11:13:10
Size: 9867
Editor: MarcBradshaw
Comment:
Revision 88 as of 2017-05-06 00:29:55
Size: 16443
Comment: packager
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from OldContributorsPage
## page was renamed from Mozilla Thunderbird @@@@(((1.8.4.4.3.0.7.5.7.0.1 Mozilla Thunderbird Support Number
## page was renamed from Contributors
Line 5: Line 8:
[[TableOfContents(10)]]

== Becoming a RPM Fusion contributer ==

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.
<<TableOfContents(10)>>

== Becoming a RPM Fusion contributor ==

Having packaging experience in Fedora is much preferred, but newcomers are welcome too. However if you are a newcomer (i.e. you're not a Fedora sponsored packager) you must first get sponsored, which means find someone to guide you while you learn the procedures.
Line 13: Line 16:
In either scenario you should create your first RPM Fusion package and submit this for review as described below. The review process is handled through bugzilla as will any bugs reported against your packages. In either scenario you should create your first RPM Fusion package and submit it for review as described below. The review process is handled through Bugzilla, as will be any bugs reported against your packages.
Line 17: Line 20:
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 Fusion. The email address that you use for your Bugzilla account should be the same email address as you use for all other things related to RPM Fusion.
Line 21: Line 24:
Once this is done join the [http://lists.fedoraunity.org/mailman/listinfo/repo-merge-discussion RPM Fusion mailing list] (and, optionally, the [http://livna.org/mailman/listinfo/freeworld-graphics 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. Once this is done, join the [[http://lists.rpmfusion.org/mailman/listinfo/rpmfusion-developers|Developers Mailing Lists]] 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.
Line 25: Line 28:
Also join the RPM Fusion subversion mailing list (missing link). 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. Also join the RPM Fusion [[http://lists.rpmfusion.org/mailman/listinfo/rpmfusion-commits|GIT commits]] mailing list. The GIT commits mailing list is used for commit messages from the GIT repository. You should subscribe to this list to track the changes to all the packages.
Line 33: Line 36:
    * http://fedoraproject.org/wiki/Packaging/NamingGuidelines
    * http://fedoraproject.org/wiki/Packaging/Guidelines 
    * [[http://fedoraproject.org/wiki/Packaging/NamingGuidelines|Naming Guidelines]]
    * [[http://fedoraproject.org/wiki/Packaging/Guidelines|Guidelines]]
Line 38: Line 41:
    * http://fedoraproject.org/wiki/Packaging/ReviewGuidelines     * [[http://fedoraproject.org/wiki/Packaging/ReviewGuidelines|Review Guidelines]]

Please read the Kmod standard if you will be packaging an external kernel module:

    * [[Packaging/KernelModules/Kmods2|Kmods2: Packaging kernel modules]]
Line 44: Line 51:
Before your package can become part of RPM Fusion it must first be reviewed, goto https://bugzilla.rpmfusion.org/ and create a new bug:

    * choose "Infrastructure" as product
    * choose "Review Requests" as Component
    * set Summary to: "Review request: %{name} - %{summary} Where %{name} and %{summary} come from the specfile
    * Put the following in the description:
          * full URLs 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 built from it. Explain for each rpmlint message why you've chosen to ignore it.
          * mention if this is your first RPM Fusion package.
    * The request should also be set to block the tracker bug: RF_NEW (#2). Other contributers can easily check for packages that need reviewing. If you want to help others by doing reviews yourself go to: https://bugzilla.rpmfusion.org/show_bug.cgi?id=2
Before your package can become part of RPM Fusion it must first be reviewed, [[https://bugzilla.rpmfusion.org/enter_bug.cgi?product=Package%20Reviews|create a new bug report as follows]] :

    * Choose "Package Reviews" as Product.
    * Choose "Review Requests" as Component.
    * Set `Summary` to: "`Review request: %{name} - %{summary}`", with %{name} and %{summary} from the package.
    * Put the following in the Description:
          * Full URLs to the spec file and source rpm of the package.
          * A short description for the package (usually, the %description from the spec file).
          * Why this package is not eligible to be included in Fedora.
          * The output `rpmlint` gives on both the source and binary packages. Explain for each message why you've chosen to ignore it.
          * Mention if this is your first RPM Fusion package.
          * Mention that you are seeking a sponsor if you are not a Fedora sponsored packager or an RPM Fusion sponsored packager.
    * The request should also be set to block the tracker bug: `RF_NEW` (bug #2). This way, other contributors can easily check for packages that need reviewing. If you want to help others by doing reviews yourself go to [[https://bugzilla.rpmfusion.org/show_bug.cgi?id=2|bug #2]].
    * If you are seeking a sponsor you must also be set to block the tracker bug: `NEEDSPONSORS` (bug #30). Thus, some potential sponsors will look at the NEEDSPONSORS bug to find packages to review. The only allowed sponsors in RPM Fusion are Fedora sponsors.

Please do not submit more than one package per per Bugzilla entry. It would be very very difficult to follow the review otherwise. If you have related packages, it can be handy to trace all the dependencies using the "Depends On" or "Block" Bugzilla features.
Line 59: Line 70:
As time permits another RPM Fusion 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, remove the blocker on RF_NEW (#2) and set it to block the tracker bug: RF_REVIEW (#3). This indicates that a review is in progress. A review request should only be accepted by a maintainer that has at least one package in the RPM Fusion repository.

The reviewer should follow the [http://fedoraproject.org/wiki/Packaging/ReviewGuidelines Fedora Review Guidelines] as close as possible, obviously taking into account any differences between Fedora and RPM Fusion. As RPM Fusion is more permissive with the content it allows, exceptions to these guidelines are allowed in some circumstances but care and common sense should prevail. The reviewer should ensure that any deviations from the [http://fedoraproject.org/wiki/Packaging/Guidelines Fedora Packaging Guidelines] are sane and justified in the package they are reviewing. If in doubt, please ask on the RPM Fusion mailinglist. The reviewer should inform the contributor of any changes that need to be made to their package, if any. The contributor should update their package as necessary, including bumping the release version and submit the new SPEC file and SRPM URL. The reviewer should verify the changes. This is repeated as many times as necessary until the contributor and reviewer are happy with the final package.
As time permits, a reviewer will review your package. A reviewer is either a Fedora sponsored packager or an RPM Fusion only sponsored packager. If you need a sponsor, the reviewer must be a Fedora sponsors. Sometimes other people add a few comments, this does not constitute a review.

When a proper review gets done the reviewer will assign the bug to him, remove the blocker on `RF_NEW` and set it to block the tracker bug `RF_REVIEW` (bug #3). This indicates that a review is in progress.

The reviewer should follow the [[http://fedoraproject.org/wiki/Packaging/ReviewGuidelines|Fedora Review Guidelines]] as close as possible, obviously taking into account any differences between Fedora and RPM Fusion. As RPM Fusion is more permissive with the content it allows, exceptions to these guidelines are allowed in some circumstances but care and common sense should prevail. The reviewer should ensure that any deviations from the [[http://fedoraproject.org/wiki/Packaging/Guidelines|Fedora Packaging Guidelines]] are sane and justified in the package they are reviewing. If in doubt, please ask on the RPM Fusion mailing list. The reviewer should inform the contributor of any changes that need to be made to their package, if any. The contributor should update their package as necessary, including bumping the release version and submit the new SPEC file and source rpm URL. The reviewer should verify the changes. This is repeated as many times as necessary until the contributor and reviewer are happy with the final package.

=== Get an RPM Fusion Account ===

Create an account in the RPM Fusion Account System

    * Visit the account system home: https://admin.rpmfusion.org/accounts/
    * Click on `New account` and fill in the blanks.
    * fas email must be the same of bugzilla email (to allow be added as PoC).
    * 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`).
    * Edit your account and upload your Public RSA SSH Key (see `man ssh-keygen` for more information) which is required for CVS authorization.
    * Once you get email confirmation that your account has been created and you're a member of the `cla_done` group, return to edit your account:
          * Apply for the packager group ==> https://admin.rpmfusion.org/accounts/group/view/packager .
          * Once this is done, your account will show up as "pending" to all of the RPM Fusion sponsors (who will receive an email).
          * When you are sponsored, you will be automatically added/approved to the `rpmfusionbugs` group as well. This will allow you to make changes to the state of bugs in Bugzilla, which is what you'll need to do to get them checked in. It will also allow you to do complete package reviews, including approving packages yourself!
Line 67: Line 92:
If your improved version is okay the reviewer will approve it, by adding a comment that the package is approved, removing the blocker on RF_REVIEW (#3) and setting the review request to block the tracker bug RF_ACCEPT (#4).

Ask for creation of a directory for your package in svn.

Once approved the submitter sends a private mail to Dams (anvil@rpmfusion.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.
When the reviewer approves the package, he adds a comment saying that the package has been approved, he
removes the blocker `RF_REVIEW` bug and sets the review request to block the tracker bug `RF_ACCEPT` (bug #4).

After that, you can ask for the creation of a directory for your package in the GIT repository by adding a comment as follow

{{{
Package CVS request
======================
Package Name:
Short Description:
Owners:
Branches:
InitialCC:
----------------------
License tag: [free|nonfree]
}}}

The license tag specifies the repository in which you want to import your package:

 * '''free''' for Open Source Software (as defined by the [[http://fedoraproject.org/wiki/Licensing|Fedora Licensing Guidelines]]) which the Fedora project cannot ship due to other reasons
 * '''nonfree''' for redistributable software that is not Open Source Software (as defined by the [[http://fedoraproject.org/wiki/Licensing|Fedora Licensing Guidelines]]); this includes software with publicly available source-code that has "no commercial use"-like restrictions. A '''free''' package that depends on a '''nonfree''' package goes to this repository too.


And also set to your review to block the bug tracker '''RF_CVSsync''' by adding bug number #33 to the blocks list.
If you have a new CVS request in the future, then you have to add #33 to the blocks list again. #33 is used as a list of bugs which currently require GIT.
<<Anchor(import_package)>>
Line 77: Line 120:
Once the dir has been created in svn, the package must be imported into svn. RPM Fusion recently has created an import script, but that's alpha, so you might want to do the manual import.

==== Configure SSH ====

The svn.rpmfusion.org Subversion sshd listens on a non-default port, 6868. To configure it, add something like this to your ~/.ssh/config:

{{{
Host svn.rpmfusion.org
     Port 6868
}}}

==== Import the manual way ====

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>/rpmfusion
   cd <some-convient-path>/rpmfusion
   svn co svn+ssh://<username>@svn.rpmfusion.org/rlo/plague-svn
   svn co svn+ssh://<username>@svn.rpmfusion.org/rlo/common
   mkdir packages
}}}

And then now the actual importing:
{{{
   cd <some-convenient-path>/rpmfusion/packages
   svn co svn+ssh://<username>@svn.rpmfusion.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, ...)

==== Automated import ====

If you already have a checkout of the common dir you can skip the steps below:
{{{
   mkdir <some-convenient-path>/rpmfusion
   cd <some-convient-path>/rpmfusion
   svn co svn+ssh://<username>@svn.rpmfusion.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
}}}
And sit back and relax while the script (hopefully) does the work for you.

=== Tag the imported sources ===

Now you should tag the just imported sources so that the plague buildsys can find them:
{{{
   cd <some-convenient-path>/rpmfusion/packages/<package-name>/devel
   make tag
   cd <some-convenient-path>/rpmfusion/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.
Once the git module has been created, the package must be imported.<<BR>>
The only file that you have to import is the "src.rpm" file, no more and one at a time.

First, set your environment :
{{{
dnf install rfpkg
}}}

Start ssh-agent to ensure that git uses your id_rsa key:

{{{
ssh-agent $SHELL
}}}

or
{{{
keychain -q ~/.ssh/id_rsa
}}}

Then, checkout the common tool and import your SRPM as follow :
{{{
rfpkg clone <namespace>/<my_new_package>
cd <my_new_package>
rfpkg import ~/*.src.rpm
}}}

During the GIT import procedure, your source files will be automatically tagged for the requested branch.<<BR>>


{i} <namespace> is the section where your git module should be imported/go ('''free''' or '''nonfree''').

If during import you get the following error:
{{{
Could not execute import_srpm: (35, 'Peer reports failure of signature verification or key exchange.')
}}}

You must manually download a client-side certificate from: https://admin.rpmfusion.org/accounts/user/gencert and make sure to save it as ~/.rpmfusion.cert
Line 153: Line 160:
Add a comment to the review that the import has been done, remove the blocker on RF_ACCEPT (#4) and close the bug as RESOLVED FIXED. First of all, install rpmfusion-packager
{{{
sudo dnf install rpmfusion-packager ( just work with pmfusion-packager >= 0.5.0-1, to have koji-rpmfusion command you need rpmfusion-packager-0.5.2-1 )
}}}
This provides a set of utilities that automatically helps a RPM Fusion packager in setting up their environment and access to the build server. It already includes the rfpkg command and does everything else you would need to do manually. Type: rpmfusion-packager-setup after its installed.

{{{
rpmfusion-packager-setup
}}}

If you have already done that, go on and request a build. Move to the directory where the source files are:

{{{
rfpkg clone free/my_package
cd my_package
vim my_package.spec
rfpkg new-sources my_packager-1.0.tar.gz
rfpkg commit
rfpkg push
}}}

Then request a build to the koji server

{{{
rfpkg build
}}}

This will trigger a build request for the branch. Easy! You can check the status of the build process from the [[http://koji.rpmfusion.org/koji/tasks|koji web interface]].

Once the package built successfully, go back to your bug review and add a comment to the review to notify the import and build have been done correctly. Then close the bug as `RESOLVED` `FIXED`.

If there is a request for your package in the [[Wishlist|RPM Fusion Wishlist]], please remove the related entry and commit the change in the wiki with a comment saying that the package is now in RPM Fusion.

== Co-maintaining an existing package ==

You can offer to co-maintain a package in RPM Fusion. Please see Fedora's documentation on [[http://fedoraproject.org/wiki/Package_maintainer_policy#Co-Maintainership|co-maintainership]]. To get commit privileges to an existing package, see "Package Change Requests for existing packages" in the [[Contributors/CVSRequests|CVS Requests]] documentation.

Even if you don't have an RPM Fusion account, it can be useful to anonymously checkout a package's GIT module for various reasons.
In such case, you can use the following command :
{{{
rfpkg clone -a <namespace>/<module>
}}}
where <namespace> is either free or nonfree and <module> is the package's name.
Line 157: Line 206:
   1. Update your local copy and test it
   2. 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.
   3. Commit your changes to svn, with a _useful_ changelog message (same command line syntax as cvs, see svn docs)
   4. After committing your change run "make tag" to tag your files so that the plague buildsystem can find the correct version to build.
   5. 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.
Make sure you have your environment set as in the [[http://rpmfusion.org/Contributors#import_package|Import your package]] subsection. You can then follow the [[http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo|Fedora Package Update HOWTO]].

'''Example:'''
{{{
# Set the environment:
rfpkg clone <namespace>/<module>

# Download the new upstream source and save it to the branch directory you are updating (if applies):
cd module
wget -N http://dl.sf.net/foo/foo-0.0.2.tar.bz2

# Upload the tarball to an external lookaside cache (not yet working)
rfpkg new-sources "foo-0.0.2.tar.bz2"

# Small patches, initscripts or otherwise plain text files can be commited directly to GIT:
git add foo-fix-the-bar.patch

# Change the required things in the specfile:
emacs foo.spec

# Check that the changes you made are correct:
git diff

# Create a changelog entry (clog):
rfpkg clog

# Commit the changes:
rfpkg commit -F clog

# Remove clog:
rm clog

# check what you going to push
git show

# Tag and request build (ex make tag build ) :
rfpkg push

#we may also do: rfpkg tag (but not required)
rfpkg build

# Resubmit a failed build:
koji-rpmfusion resubmit <taskID> (note is not the buildID)

# or as alternative
git checkout f24; rfpkg build; git checkout master

#"rfpkg build" is safe because check before if we already built it, if build is already
#done, reply something like:
#Could not execute build: Package mpgtx-1.3.1-9.fc23 has already been
#built
#Note: You can skip this check with --skip-nvr-check. See help for more
#info.

}}}

A package built for devel (i.e. rawhide) will directly go to the "devel" repository.

A package built for a stable release (e.g. f24, f23) will go to the "updates-testing" repository. You'll have to wait a period ranging from 10 to 14 days for your package to be transferred to the "updates" repository. It's a manual action, somebody real actually does that, so don't panic.

You can also find packages which are built but not yet pushed here: http://koji.rpmfusion.org/mash/

== Retiring a package ==
In order to retire a branch of a package, the maintainer needs to delete all but a '''dead.package''' file containing an explanation of why the package/branch has been retired.
Once that's done, the maintainer must file a [[https://bugzilla.rpmfusion.org/enter_bug.cgi?product=Infrastructure&component=Repo|bugzilla ticket in the '''Infrastructure''' product and '''Repo''' component]].
This can be done using the following command:
{{{
rfpkg retire
}}}
At this time, the command cannot retire the package in pkgdb. You need to Orphan it manually from the web interface on the related branches. Then fill a ticket for the package to be properly retired in koji.

== Orphaning a package ==

FIXME : Work out and describe the process to orphan a package.

== Requesting a buildroot override ==

You can use the following command to request a buildroot override :
{{{
koji-rpmfusion tag-build f2?-{,non}free-override your_rpmfusion_build_nvr
}}}
After wait for repo be ready:
{{{
koji-rpmfusion wait-repo f2?-{,non}free-build --build=your_rpmfusion_build_nvr
}}}
Exemplify
{{{
koji-rpmfusion tag-build f25-free-override VirtualBox-5.1.4-3.fc25
koji-rpmfusion wait-repo f25-free-build --build=VirtualBox-5.1.4-3.fc25
}}}
It's not possible to tag a fedora package, that's a manual task.
In this case, please file a bug in product "Infrastructure" and component "Build System".

It is currently not possible to expire a buildroot override, but that is being worked on.

== Requesting a buildroot override but for one package from Fedora ==

As we do not build with updates-testing repos enabled, it's sometime
needed for a package to be build and pushed in sync with others fedora
packages.

Please submit a specific bug for the package you want to build and
block this bug:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=4501

1. Contributing to RPM Fusion

So, you've decided to become a contributor to RPM Fusion? This guide will lead you through your first package submission and teach you how to update your package(s) in the future.

2. Becoming a RPM Fusion contributor

Having packaging experience in Fedora is much preferred, but newcomers are welcome too. However if you are a newcomer (i.e. you're not a Fedora sponsored packager) you must first get sponsored, which means find someone to guide you while you learn the procedures.

2.1. Create a Bugzilla Account

In either scenario you should create your first RPM Fusion package and submit it for review as described below. The review process is handled through Bugzilla, as will be 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 other things related to RPM Fusion.

2.2. Join the Mailing List

Once this is done, join the Developers Mailing Lists 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 RPM Fusion GIT commits mailing list. The GIT commits mailing list is used for commit messages from the GIT repository. You should subscribe to this list to track the changes to all the packages.

3. Submitting a new package

3.1. Read the packaging guidelines

RPM Fusion 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:

Please read the Kmod standard if you will be packaging an external kernel module:

3.2. Create a package review request

Before posting a review request, you should upload your SRPM and SPEC file to any accessible location on the internet.

Before your package can become part of RPM Fusion it must first be reviewed, create a new bug report as follows :

  • Choose "Package Reviews" as Product.
  • Choose "Review Requests" as Component.
  • Set Summary to: "Review request: %{name} - %{summary}", with %{name} and %{summary} from the package.

  • Put the following in the Description:
    • Full URLs to the spec file and source rpm of the package.
    • A short description for the package (usually, the %description from the spec file).
    • Why this package is not eligible to be included in Fedora.
    • The output rpmlint gives on both the source and binary packages. Explain for each message why you've chosen to ignore it.

    • Mention if this is your first RPM Fusion package.
    • Mention that you are seeking a sponsor if you are not a Fedora sponsored packager or an RPM Fusion sponsored packager.
  • The request should also be set to block the tracker bug: RF_NEW (bug #2). This way, other contributors can easily check for packages that need reviewing. If you want to help others by doing reviews yourself go to bug #2.

  • If you are seeking a sponsor you must also be set to block the tracker bug: NEEDSPONSORS (bug #30). Thus, some potential sponsors will look at the NEEDSPONSORS bug to find packages to review. The only allowed sponsors in RPM Fusion are Fedora sponsors.

Please do not submit more than one package per per Bugzilla entry. It would be very very difficult to follow the review otherwise. If you have related packages, it can be handy to trace all the dependencies using the "Depends On" or "Block" Bugzilla features.

3.3. Wait for your package to be reviewed

As time permits, a reviewer will review your package. A reviewer is either a Fedora sponsored packager or an RPM Fusion only sponsored packager. If you need a sponsor, the reviewer must be a Fedora sponsors. Sometimes other people add a few comments, this does not constitute a review.

When a proper review gets done the reviewer will assign the bug to him, remove the blocker on RF_NEW and set it to block the tracker bug RF_REVIEW (bug #3). This indicates that a review is in progress.

The reviewer should follow the Fedora Review Guidelines as close as possible, obviously taking into account any differences between Fedora and RPM Fusion. As RPM Fusion is more permissive with the content it allows, exceptions to these guidelines are allowed in some circumstances but care and common sense should prevail. The reviewer should ensure that any deviations from the Fedora Packaging Guidelines are sane and justified in the package they are reviewing. If in doubt, please ask on the RPM Fusion mailing list. The reviewer should inform the contributor of any changes that need to be made to their package, if any. The contributor should update their package as necessary, including bumping the release version and submit the new SPEC file and source rpm URL. The reviewer should verify the changes. This is repeated as many times as necessary until the contributor and reviewer are happy with the final package.

3.4. Get an RPM Fusion Account

Create an account in the RPM Fusion Account System

  • Visit the account system home: https://admin.rpmfusion.org/accounts/

  • Click on New account and fill in the blanks.

  • fas email must be the same of bugzilla email (to allow be added as PoC).
  • 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).

  • Edit your account and upload your Public RSA SSH Key (see man ssh-keygen for more information) which is required for CVS authorization.

  • Once you get email confirmation that your account has been created and you're a member of the cla_done group, return to edit your account:

    • Apply for the packager group ==> https://admin.rpmfusion.org/accounts/group/view/packager .

    • Once this is done, your account will show up as "pending" to all of the RPM Fusion sponsors (who will receive an email).
    • When you are sponsored, you will be automatically added/approved to the rpmfusionbugs group as well. This will allow you to make changes to the state of bugs in Bugzilla, which is what you'll need to do to get them checked in. It will also allow you to do complete package reviews, including approving packages yourself!

3.5. Your package gets approved

When the reviewer approves the package, he adds a comment saying that the package has been approved, he removes the blocker RF_REVIEW bug and sets the review request to block the tracker bug RF_ACCEPT (bug #4).

After that, you can ask for the creation of a directory for your package in the GIT repository by adding a comment as follow

Package CVS request
======================
Package Name:
Short Description:
Owners:
Branches:
InitialCC:
----------------------
License tag: [free|nonfree]

The license tag specifies the repository in which you want to import your package:

  • free for Open Source Software (as defined by the Fedora Licensing Guidelines) which the Fedora project cannot ship due to other reasons

  • nonfree for redistributable software that is not Open Source Software (as defined by the Fedora Licensing Guidelines); this includes software with publicly available source-code that has "no commercial use"-like restrictions. A free package that depends on a nonfree package goes to this repository too.

And also set to your review to block the bug tracker RF_CVSsync by adding bug number #33 to the blocks list. If you have a new CVS request in the future, then you have to add #33 to the blocks list again. #33 is used as a list of bugs which currently require GIT.

3.6. Import your package

Once the git module has been created, the package must be imported.
The only file that you have to import is the "src.rpm" file, no more and one at a time.

First, set your environment :

dnf install rfpkg

Start ssh-agent to ensure that git uses your id_rsa key:

ssh-agent $SHELL

or

keychain -q ~/.ssh/id_rsa

Then, checkout the common tool and import your SRPM as follow :

rfpkg clone <namespace>/<my_new_package>
cd <my_new_package>
rfpkg import ~/*.src.rpm

During the GIT import procedure, your source files will be automatically tagged for the requested branch.

{i} <namespace> is the section where your git module should be imported/go (free or nonfree).

If during import you get the following error:

Could not execute import_srpm: (35, 'Peer reports failure of signature verification or key exchange.')

You must manually download a client-side certificate from: https://admin.rpmfusion.org/accounts/user/gencert and make sure to save it as ~/.rpmfusion.cert

3.7. Request a build

First of all, install rpmfusion-packager

sudo dnf install rpmfusion-packager ( just work with pmfusion-packager >= 0.5.0-1, to have koji-rpmfusion command you need rpmfusion-packager-0.5.2-1 )

This provides a set of utilities that automatically helps a RPM Fusion packager in setting up their environment and access to the build server. It already includes the rfpkg command and does everything else you would need to do manually. Type: rpmfusion-packager-setup after its installed.

rpmfusion-packager-setup

If you have already done that, go on and request a build. Move to the directory where the source files are:

rfpkg clone free/my_package
cd my_package
vim my_package.spec
rfpkg new-sources my_packager-1.0.tar.gz
rfpkg commit
rfpkg push

Then request a build to the koji server

rfpkg build

This will trigger a build request for the branch. Easy! You can check the status of the build process from the koji web interface.

Once the package built successfully, go back to your bug review and add a comment to the review to notify the import and build have been done correctly. Then close the bug as RESOLVED FIXED.

If there is a request for your package in the RPM Fusion Wishlist, please remove the related entry and commit the change in the wiki with a comment saying that the package is now in RPM Fusion.

4. Co-maintaining an existing package

You can offer to co-maintain a package in RPM Fusion. Please see Fedora's documentation on co-maintainership. To get commit privileges to an existing package, see "Package Change Requests for existing packages" in the CVS Requests documentation.

Even if you don't have an RPM Fusion account, it can be useful to anonymously checkout a package's GIT module for various reasons. In such case, you can use the following command :

rfpkg clone -a <namespace>/<module>

where <namespace> is either free or nonfree and <module> is the package's name.

5. Updating an existing package

Make sure you have your environment set as in the Import your package subsection. You can then follow the Fedora Package Update HOWTO.

Example:

# Set the environment:
rfpkg clone <namespace>/<module>

# Download the new upstream source and save it to the branch directory you are updating (if applies):
cd module
wget -N http://dl.sf.net/foo/foo-0.0.2.tar.bz2

# Upload the tarball to an external lookaside cache (not yet working)
rfpkg new-sources "foo-0.0.2.tar.bz2"

# Small patches, initscripts or otherwise plain text files can be commited directly to GIT:
git add foo-fix-the-bar.patch

# Change the required things in the specfile:
emacs foo.spec

# Check that the changes you made are correct:
git diff 

# Create a changelog entry (clog):
rfpkg clog

# Commit the changes:
rfpkg commit -F clog

# Remove clog:
rm clog

# check what you going to push 
git show

# Tag and request build (ex make tag build ) :
rfpkg push 

#we may also do: rfpkg tag (but not required)
rfpkg build

# Resubmit a failed build:
koji-rpmfusion resubmit <taskID>  (note is not the buildID) 

# or as alternative 
git checkout f24; rfpkg build; git checkout master

#"rfpkg build" is safe because check before if we already built it, if build is already
#done, reply something like: 
#Could not execute build: Package mpgtx-1.3.1-9.fc23 has already been
#built
#Note: You can skip this check with --skip-nvr-check. See help for more
#info.

A package built for devel (i.e. rawhide) will directly go to the "devel" repository.

A package built for a stable release (e.g. f24, f23) will go to the "updates-testing" repository. You'll have to wait a period ranging from 10 to 14 days for your package to be transferred to the "updates" repository. It's a manual action, somebody real actually does that, so don't panic.

You can also find packages which are built but not yet pushed here: http://koji.rpmfusion.org/mash/

6. Retiring a package

In order to retire a branch of a package, the maintainer needs to delete all but a dead.package file containing an explanation of why the package/branch has been retired. Once that's done, the maintainer must file a bugzilla ticket in the '''Infrastructure''' product and '''Repo''' component. This can be done using the following command:

rfpkg retire

At this time, the command cannot retire the package in pkgdb. You need to Orphan it manually from the web interface on the related branches. Then fill a ticket for the package to be properly retired in koji.

7. Orphaning a package

FIXME : Work out and describe the process to orphan a package.

8. Requesting a buildroot override

You can use the following command to request a buildroot override :

koji-rpmfusion tag-build f2?-{,non}free-override your_rpmfusion_build_nvr

After wait for repo be ready:

koji-rpmfusion wait-repo f2?-{,non}free-build --build=your_rpmfusion_build_nvr

Exemplify

koji-rpmfusion tag-build f25-free-override VirtualBox-5.1.4-3.fc25
koji-rpmfusion wait-repo f25-free-build --build=VirtualBox-5.1.4-3.fc25

It's not possible to tag a fedora package, that's a manual task. In this case, please file a bug in product "Infrastructure" and component "Build System".

It is currently not possible to expire a buildroot override, but that is being worked on.

9. Requesting a buildroot override but for one package from Fedora

As we do not build with updates-testing repos enabled, it's sometime needed for a package to be build and pushed in sync with others fedora packages.

Please submit a specific bug for the package you want to build and block this bug: https://bugzilla.rpmfusion.org/show_bug.cgi?id=4501

CategoryContributing

Contributors (last edited 2023-11-14 09:37:57 by anonymous)