Dribble is no longer updated as part of the migration process to
RPM Fusion.
Users are strongly encourage to migrate as soon as
RPM Fusion is active.
Dribble welcomes new contributors wishing to build RPMs for inclusion in the repository. Please familiarise yourself with the contents of this
page, particularly the
RPM Packaging Guidelines, before posting your first review request. If you already
contribute to Fedora or Livna, you should find this familiar. New contributors should also join the
Dribble Maintainers Mailinglist and create an account in the
Dribble Bugzilla system. The email address you use should be the same for both the
mailinglist and
bugzilla. If you
are looking for ideas on what to package, please have a look at the
requests page
in the wiki which contains a list of user submitted package requests.
We understand that this process may be difficult to follow for the beginner but please feel free to ask for help on the
mailinglist if you need it. Before a package can be accepted for inclusion
in Dribble, it must have been reviewed and accepted by a current Dribble maintainer. If the package you intend to submit is suitable for
inclusion in Fedora or Livna, then please consider submitting the package there. Dribble will remove any packages from its repository
that subsequently appear in Fedora or Livna. After taking that under advisement, you may still submit the package to Dribble if you wish.
Before posting a review request, you should upload your SRPM and SPEC file to any accessible location on the internet or alternatively Dribble
has a specific
upload area that contributors may use. A review request is made
by posting a new bug in the
Dribble Bugzilla system. The bug should be filed against the
'Infrastructure' product and the 'Review Requests' component. It should include the name of the package and a brief summary of what it
does in the summary field and a link to your SPEC file and SRPM in the description field. Please also include an extended description of the
package. The request should also be set to block the
tracker bug:
DRB_NEW (#2). If this is your first Dribble
package, it's helpful to mention this in the description field. See the screenshot below for an example of how to layout your review request.
The important fields are highlighted in red. All other fields can be left at the default value.
After posting the review request you must wait until a maintainer decides to review your package. Normally this happens within a few days.
A review request should only be accepted by a maintainer that has at least one package in the Dribble repository. To accept a review request,
the reviewer should assign the review request to themselves, remove the blocker on
DRB_NEW (#2) and set it to block the
tracker bug:
DRB_REVIEW (#4). 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 Dribble. As Dribble 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 within the context of what Dribble permits. If in doubt, please ask on the
Dribble 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. The reviewer should then state in the review request that the package is approved,
remove the blocker on
DRB_REVIEW (#4) and set the review request to block the
tracker bug:
DRB_ACCEPT (#5).
This indicates to Dribble admin that the package is ready to be built and published in the Dribble repository using mock. At this point, the
reviewers job is complete, pending any failures in the package building.
Once a review request blocks the
tracker bug:
DRB_ACCEPT (#5), Dribble admin will push the package through the
build system. The build system uses 'mock', a program that creates a chroot-jail build environment to ensure that the 'buildrequires' are
accurate. Unless excluded from doing so (with good reason) in the SPEC file, the rpm will be built for the i386, x86_64 and ppc architectures.
A failure to build under any one of these architectures is considered a complete fail and must be fixed, regardless of whether it was successful
under the other architectures. Similarly the rpm will be built for all versions of Fedora supported by Dribble. If a specific version of
Fedora should be excluded, it must be stated in the review request. A failure to build under a supported version of Fedora is also considered
a complete fail. If the package fails to build, the review request will be moved back to
DRB_REVIEW (#4) by Dribble admin with a failure
notice. The contributor and reviewer should fix any issues before blocking
DRB_ACCEPT (#5) again. The
buildlogs
should be consulted for additional information. If the package builds successfully, Dribble admin will close the review request as fixed. An
entry will be created for the RPM in
bugzilla and the contributor will be assigned as the owner.
The packages will be signed and published in the repository.
Packages built for the Dribble repository should follow the
Fedora Packaging Guidelines as close as possible, particularly with
regard to packaging style. As Dribble is more permissive with the content it allows, exceptions to these guidelines are allowed in some
circumstances but care and common sense should prevail. If in doubt, please ask on the
Dribble mailinglist. Significant deviations from these guidelines should be
stated in the review request along with the rationale. For example:
- Packages do not have to be strictly free (as in freedom), however they must be distributable.
- Packages built from binaries are permitted only if the source code is not available for compilation (eg libcapsimage).
In addition to the
Fedora Packaging Guidelines, the following Dribble
specific guidelines also apply.
- RPMs must not replace, upgrade or obsolete any existing package in Fedora or Livna. Similarly if a package is already available
in any of these repos, it is not permitted for inclusion in Dribble, regardless of the package version
- In cases where packages included in Dribble subsequently become available in Fedora or Livna, they will be removed from the Dribble
repository, regardless of the version.
- RPMs built for inclusion in Dribble must only have dependancies on RPMs in Fedora, Livna or Dribble.
- The --vendor tag for desktop-file-utils should be 'dribble' and not 'fedora'
A rebuild request should be posted when an existing package in the Dribble repository needs to be updated. Except in unusual circumstances,
a rebuild request should only be posted by the maintainer of the package needing to be rebuilt. Package updates are often necessary
when bugs are fixed, dependancies change or when new versions of the software are released. Rebuild requests are not subject to any review
process. A rebuild request is made by posting a new bug in the
Dribble Bugzilla system. The rebuild
request should be filed against the 'Infrastructure' product and the 'Rebuild Requests' component. It should include the name of the package
in the summary field and a link to your SRPM in the description field. If any special instructions are required, such as excluding building
for a specific Fedora version, they should be included. See the screenshot below for an example of how to layout your rebuild request.
The important fields are highlighted in red. All other fields can be left at the default value.
After a successful build, Dribble admin will close the bug as fixed. In the case of a failed build, the bug will remain open and a failure
notification will be posted. The
buildlogs should be consulted for useful information. Note, you are permitted to
reopen 'old' rebuild requests for the specific purpose of attaching a new build rather that continually creating new bug entries each time
you wish to make a rebuild.
Tracker bugs are used to track the review and accept process for new packages in Bugzilla. At various stages of the review process, the
review request should block one of the following depending on what stage the review is at. They are defined as follows:
| Bug ID |
Alias |
Description |
| 2 |
DRB_NEW |
New RPMs waiting for review should block this bug. |
| 4 |
DRB_REVIEW |
RPMs currently under review should block this bug and be ASSIGNED to the reviewer. |
| 5 |
DRB_ACCEPT |
RPMs that have been accepted should block this bug. Once the RPM has been published it will be resolved as fixed
by Dribble Admin |
Dribble offers contributors an upload area where they may scp files such as SRPMs for review or building. Use of this area is optional and
available on request. To request access, please send an email to XXXX and attach your publish ssh key. You'll be
granted access and sent instructions on how to access the area.
The Dribble MailinglistDribble BugzillaThe Dribble BuildlogsThe Dribble WikiUser submitted RPM requests- Fedora Extras Packaging Guidelines
- Game Packaging Guidelines
- Fedora Extras Review Guidelines
- RPM scriptlets
- RPATH Checking
- Frequently made RPM mistakes
- Fedora Extras Repository
- The Livna Repository
