This guide explains how to submit ebuilds for inclusion in the Gentoo ebuild repository, through the Bugzilla bug tracking web application.
Create a Bugzilla account
Point your web browser to https://bugs.gentoo.org/. This is the URL for the Bugzilla bug tracking database. In the list of links, one of the items reads "Open a new Bugzilla account". If you have not done so already (e.g. for submitting a bug), click on this link and create a new account.
Do not submit CPAN ebuilds
The app-portage/g-cpan package provides a tool called g-cpan.pl which installs a given CPAN module on your Gentoo system using Portage, storing the necessary information (such as dependencies, provided files, etc.) in the Portage database, just like it would when you install an ebuild. It is therefore not needed (nor recommended) to submit CPAN ebuilds.
For more information on g-cpan.pl, please consult its man page: man g-cpan.pl
Submitting an ebuild
Create a new bug
At the bottom of the main page or login page, there is a yellow box. Choose the New - Expert link. Or, you can just go to the URL https://bugs.gentoo.org/enter_bug.cgi. Either will bring you to the
Enter Bug page.
In the Bugzilla system, all entries are bugs. That includes newly submitted ebuilds. Each bug is assigned a tracking id. Take note of the ID, especially if you have other ebuilds that depend on this package.
Bugzilla can track multiple products. For example, in Gentoo, other products may include documentation or tools used to administrate the website. From the list of products, Ebuilds should always be submitted to Gentoo Linux.
Clicking on the Gentoo Linux product should bring up a new bug entry form.
Completing the bug form
The first field on the form is
version. If you know which version the package belongs in, set it here. Otherwise, select
unspecified. Next, set the component. All ebuild scripts are of the component type
New packages or
Ebuilds should always be of component type
Current packages. Categories such as
Servermay look like they apply to your ebuild, but they are used for filing bugs against packages, not submitting ebuilds.
Priority do not need to be set for ebuilds.
Severity field should be set to
Assigned To field blank. If you haven't changed Bugzilla's mail settings, you, as a reporter, will automatically receive email on bug updates.
Fill in the
Summary field with a brief note of what package you are submitting and whether it's an update or a new submission. Something like the following is great:
foo-bar-x.y.z.ebuild (New Package) or
Description field should be filled in as completely as possible. Here's an example from bug #7:
Hi! Please find attached gramps-4.2.0.ebuild and a patch so that it will compile against python-3.2 Gramps is the Genealogical Research and Analysis Management Programming System. It is a very cool gnome/python app. If you are in the US, you can head over to http://www.familysearch.com/ and you can probably find a GEDCOM file for your family tree to import into Gramps. (Mormons sure do like genealogy) I suggest app-misc/gramps Also, this ebuild depend on Imaging and Graphviz previously submitted tod
Once the summary is complete, click
Attaching the ebuild script
submit on the Enter Bug page, you will go to the
Posting Bug page. Take note of the bug number.
Toward the bottom of this page, there is a link to Create a new attachment. Click on this link.
Select the file using the text entry box or the
Browse dialog. In the
Description field, type the name of the ebuild file, much the same as you did in the
Summary section of the last page.
Make sure that the content type is set to
text/plain, and that the radio button for
select from list is marked.
There are no other required fields on this form. Click
Submit and you are done!
In cases where you might submit multiple ebuilds, and some of them depend on others, it is very helpful if these dependencies are noted. Viewing the bug again should allow you to enter another note. Please add dependency information here.
Alternate Submission Methods
Ebuilds can also be submitted through Pull Requests on the Gentoo Mirror on GitHub. From there they can be picked up by Proxy Maintainers and merged by Gentoo developers into the main repository. The review for new packages can take a while because of the need to test the ebuid and go through upstream files and issues.
GURU is an official Gentoo overlay that is maintained by Gentoo users. Ebuilds submitted here have a less stringent review process.
- Ebuild — a text file, usually stored in a repository, which identifies a specific software package and tells the Gentoo package manager how to handle it.
- Basic guide to write Gentoo Ebuilds — getting started writing ebuilds, to harness the power of Portage, to install and manage even more software.
- Github Pull Requests — how to contribute to Gentoo by creating pull requests on GitHub.
- Project:GURU — an official repository of new Gentoo packages that are maintained collaboratively by Gentoo users
This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Matt Butcher
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.