Contributors page on wiki
Sérgio Basto
sergio at serjux.com
Wed Jul 13 23:19:11 CEST 2016
This is a copy of last version, I had it in my browser ! I was about to
edit it today , but don't remember if I edit it or not , but I intend
to fix :
# Resubmit a failed build:
rfpkg resubmit <job id>
Since rfpkg resubmit doesn't exist, but thinking again, maybe is
"rpmfusion-koji resubmit <job id>" or as alternative "git checkout f24;
git merge master; git push ; rfpkg build; git checkout master"
because "rfpkg build" check if already build 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.
Anyway what happened ?
Contributors
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.
Contents
Contributing to RPM Fusion
Becoming a RPM Fusion contributor
Create a Bugzilla Account
Join the Mailing List
Submitting a new package
Read the packaging guidelines
Create a package review request
Wait for your package to be reviewed
Get an RPM Fusion Account
Your package gets approved
Import your package
Request a build
Co-maintaining an existing package
Updating an existing package
Retiring a package
Orphaning a package
Requesting a buildroot override
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:
Naming Guidelines
Guidelines
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:
Review Guidelines
Please read the Kmod standard if you will be packaging an external
kernel module:
Kmods2: Packaging kernel modules
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://fas.rpmfusion.org/
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).
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 cvsextras group ==> https://fas.rpmfusion.org/acc
ounts/group/view/cvsextras.
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 (grab it from http://koji.rpmfusion.org/koji/packagei
nfo?packageID=447 )
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://fas.
rpmfusion.org/accounts/ 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 (grab it from http://koji.rpmfusion
.org/koji/packageinfo?packageID=207)
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:
rfpkg resubmit <job id>
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: htt
p://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
7. Orphaning a package
FIXME : Work out and describe the process to orphan a package.
8. Requesting a buildroot override
FIXME : This is only a placeholder. It is said to be possible, but is
not documented anywhere.
CategoryContributing
Contributors (last edited 2016-07-11 19:25:34 by Sérgio Basto)
On Qua, 2016-07-13 at 22:21 +0200, Andrea Musuruane wrote:
> Hi!
> This page has been deleted from the wiki:
> http://rpmfusion.org/Contributors
>
> Does somebody have the knowledge to recover it?
>
> Bye,
>
> Andrea
>
--
Sérgio M. B.
More information about the rpmfusion-developers
mailing list