Proxied Maintainer FAQ

From Gentoo Wiki
Jump to: navigation, search

Proxied maintainers and Gentoo developers are invited to work on this page and collect FAQ and common mistakes here. Please also see the style guide.


Adding acct-{group,user}/packages as a proxied maintainer

Every newly added package needs to have a maintainer. Thus add yourself and proxy-maint project to metadata.xml files like normally. Check the latest state of uid-gid.txt file, and choose the first available number when counting downwards from 500. Creating a pull request to api.gentoo.org reserving an ID is not necessary - if it's taken while your submission is being reviewed, new first available number will be assigned while merging your contribution.


Breaking tests in parallel building mode

Tests after an ebuild has successfully finished the compile phase run in the same mode (environment). Individual (source-) files can be translated and compiled concurrently and independently from each other. However test-commands can fail when run in parallel!

Parallelism for the make utility is handled via the -j or --jobs Option to make i.e.: MAKEOPTS.

In those cases the tests and test-commands should be run with the --jobs option explicitly set to 1 i.e.: -j1.

CODE
src_test() {
    # Via environment method 1
    MAKEOPTS+=" -j1" test-command
  }

Alternatively:

CODE
src_test() {
    # Via environment method 2
    # Need check
    local MAKEOPTS+=" -j1" 
    test-command
  }

Using the cmake.eclass allows for a direct setting of the --jobs Option -j1:

CODE
# When cmake.eclass src_test function
  src_test() {
    cmake_src_test -j1
  }


"Copy/paste" style of contributions

If you commit new version bump and base your new ebuild on an old ebuild that uses old EAPI and has multiple modern QA issues, you are asked to update your new ebuild contribution to match today's Gentoo standards. However if you fix a bug on a current ebuild that requires a revbump and therefore a new ebuild copy, we will use common sense and accept the contribution to current ebuild revision.

Unfortunately ::gentoo tree is full of outdated ebuilds by modern standards. You can read the devmanual and QA Policy Guide, in addition to EAPI 6 & 7 guides if unsure about state of the current ebuild you're working on.


Keywording after EAPI bump

An EAPI bump requires usually that all keywords are set to `~` (unstable). This can be done with:

user $ekeyword ~all foo-2.0.ebuild

From the package app-portage/gentoolkit.

However there are some special cases where a stabilization can remain, if the developer can be 100% sure, that the EAPI change does not change anything. But this is not the case for usual packages.


Retiring from proxied maintainer status

We get it, sometimes life happens, distro hop happens. If you have packages assigned to you and you wish to stop being a proxied maintainer for them, please open a pull request where you update metadata.xml files putting maintainer status to <!-- maintainer-needed -->, using a Closes: tag against your proxy-maint bug, and sending a "packages up for grabs" e-mail to gentoo-dev mailing list.

Or at least please inform us by messaging your updated status in your proxy-maint bug, and we will do the rest for you.


Sorting of KEYWORDS

We usually sort the KEYWORDS values as ekeyword does. This makes comparison between packages easier. Simply run ekeyword on the ebuild to let it sort.

user $ ekeyword foo-2.0.ebuild


Use the latest EAPI for a pull request

We always try to use the latest EAPI if possible. If a required eclass is not yet compatible with the latest EAPI this can not be fulfilled directly.


Using a sub-slot binder, :=

Refer to devmanual in case sub-slots are not familiar to you. Sub-slot binders should only be used when your program links to specific SONAME of a library during build-time.

Note: sys-libs/zlib is a special case and doesn't have a changing ABI. Don't add sub-slot binder, :=, to it.


When an ebuild needs a revbump (-r1)

Refer to the devmanual.


When and how to stabilize a package?

Common rules for stabilization. If you don't want to keep a calendar and count days for stabilization, pkgcheck tool can be utilized to help.

user $pkgcheck scan app-emulation/lxd dev-libs/efl dev-python/python-efl media-libs/rlottie -c StableRequestCheck
app-emulation/lxd
  StableRequest: version 4.0.1: slot(0) no change in 30 days for unstable keyword: [ ~amd64 ]

dev-python/python-efl
  StableRequest: version 1.24.0: slot(0) no change in 45 days for unstable keywords: [ ~amd64, ~x86 ]

Stabilization is requested through bugzilla which uses nattka tool for its syntax. If nattka informs that sanity check succeeds, sit back and relax, arch teams will handle the stabilization next. If sanity check doesn't succeed, most likely some required dep is not stabilized/keyworded yet, and you will either need to handle it in a new bug, or add it to package list.