This is Gentoo's testing wiki. It is a non-operational environment and its textual content is outdated.
Please visit our production wiki at https://wiki.gentoo.org
Project:Games
| Gentoo Games Project | |
|---|---|
| Description | The Gentoo Games Project manages the game categories (dev-games, games-*) in Portage |
| Project email | games@gentoo.org |
| IRC channel | #gentoo-games |
| Lead(s) |
No lead election date set |
| Member(s) |
|
| Subproject(s) (and inherited member(s)) |
(none) |
| Parent Project | Gentoo |
| Project listing | |
The Gentoo Games Project manages some of the games in the Portage tree. We're the guys that put the fun into Gentoo. We also manage a few utilities that are used heavily in many games, such as the SDL* libraries. Please note that we don't manage heavily integrated games packages such as 'gnome-games' or 'kdegames'.
Goals
The games project aims to turn Gentoo into the premiere Linux gaming platform. We strive to have the best compatibility not only for free games, but also for commercial titles.
Gentoo Games bugs FAQ
Which product/component should I pick?
You should always select the "Gentoo Linux" product and the "Games" component when filing any bug for an ebuild in games-* or dev-games . This ensures that the bug is immediately assigned to the Games team, which allows for us to get the bug as quickly as possible.
What severity should I use for version bumps or new game requests?
Requests for having an ebuild bumped to the latest version or to have an ebuild for a new game written or added to the portage tree should always be filed with a severity of "enhancement" since these are not bugs affecting functionality.
Why shouldn't I mark a Games bug as "blocker"?
This one is not only quite common, but also quite simple to answer. A bug in a Games ebuild will never cause your system to be destroyed or otherwise unusable. Games are for entertainment purposes and as such, immediately get a lower priority than more important aspects of a Gentoo system, such as the toolchain.
How long should I wait before filing a version bump request?
We typically follow the development of many of the more popular games. In many cases, we maintain contact with the authors and are active in the community. We are generally aware of new events in the Linux gaming community before the public. A good rule of thumb is to wait at least 48 hours before posting an enhancement request for a new game or a version upgrade to an existing game. This allows the developers time to work bugs which are possibly of higher priority than the game request. It also allows us to verify that the game passes at least preliminary quality assurance. Remember once again that all of us have other functions in Gentoo which usually take a higher priority.
Should I attach an ebuild to a version bump request?
Usually, no. If simply copying the ebuild to the new name and creating a new digest works for the upgrade, then please mention that in the bug. It will save us time from looking at an ebuild and trying to determine what has changed. If there has been a few minor changes, then a diff between the two ebuilds using diff -u old.ebuild new.ebuild is perfect. If there has been major changes between versions, then an ebuild is appropriate and appreciated.
What information do I need to post with my bug report?
As in any bug report, you should always post the output of emerge --info into every bug report that you submit. If you think there are other pertinent pieces of information that could possibly help us in tracking down the bug, then be sure to include that information, too. One example is the opengl implementation that you are using when filing a bug against an opengl-based game. Anything you can provide us could possibly be the one piece of information that we need to accurately and quickly resolve the bug. This could include information such as your method of installation in a CD-based install, or the situation in which the bug occurs.
What if I am not running on an x86 kit?
You should be sure to make note of your using a non-x86 architecture. You should also set the platform to your appropriate platform. Last, you should add the architecture team alias to the CC list for the bug. This is the architecture name at gentoo.org, ex. amd64@gentoo.org. This ensures that not only the Games team, but also the developers on the architecture team which your problem is occurring get all of the information as quickly as possible.
When should I open a new bug rather than comment on an old one?
You should always open a new bug unless your problem is producing the exact same error, you have tried the workarounds or fixes in the ebuild, and your error is occurring on a same-versioned ebuild. Do not make comments on an already resolved bug if you are seeing a similar problem in a newer version of a game, as this makes it hard to track individual problems. You should also never add a comment about a new version of to an existing bug about the same package.
When is it appropriate to ask when a bug will be resolved/a new ebuild will be added?
Never. Bugs are worked on by their priority given to them by the developers themselves. All of the Games team are also developers in other areas of Gentoo, and Games bugs are never as critical as a toolchain or release bug. Bugs do not get forgotten. They will go in eventually. If the bug is for a new ebuild, we suggest putting the ebuild into a local overlay and adding yourself to the CC on the bug. Asking when the bug will be closed is not only selfish, but quite rude to the developers that volunteer their time to try to make Gentoo better for everyone. While your bug may be very important to you, we have a larger view of what we have on our own plates and are better able to make decisions on how to spend our own precious time to best help Gentoo.
Should I report a bug on an ebuild that does not have the proper KEYWORDS for my architecture?
Not if you want the games developers to like you. We will not support games that do not have proper KEYWORDS. More than likely, the game does not work on that architecture, which is why it doesn't have KEYWORDS. The only exception to this rule is if you are also providing a patch to fix the game for your architecture. Patches are always welcome.
This download is too big. Can we make it download the patches?
No. In general, ebuilds are designed to be used as if one is not upgrading from a previous version. As soon as we start having people download version $foo and patch $bar, people complain that there is a $foo-$bar distfile. We can't please both camps, so we simply do not offer incremental downloads. While this can be a pain for users on dial-up, it makes things easier on us.
Want to help?
If you want to get involved with improving Gentoo's gaming experience, we'd like to hear from you! The main thing you'll want to do is be active on Gentoo's Bugzilla . A good start is to provide patches or ebuilds to bug reports that have already been filed by other users. Simply adding new bug reports is helpful in getting problems resolved in the long term, but does not help get them resolved in the near term. Also, please join games project members in #gentoo-games on Freenode.
There is also a HOWTO for writing proper games ebuilds. You will definitely want to read it if you plan on contributing as it is the standard by which games ebuilds are written. This information is in addition to the standard ebuild policies and procedures.
This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Chris Gianelloni
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.