User:stefanCristian
From Gentoo Wiki
| Community member | |
|---|---|
| Name | Stefan Cristian Brindusa |
| Nickname | stefancristian |
| stefan.cristian+git@rogentos.ro
| |
| Website | https://argentlinux.io |
| Packages ::gentoo | p.g.o/stefan.cristian+git@rogentos.ro (commits)
|
GPG Fingerprint
15D3 9E71 ED95 0063 AD35 26ED 3735 D60F 3E0E C356Contact info
stefancristian+git@rogentos.ro
stefancristian (IRC)
Dev advises on contributing, TL;DR version:
- If you fixed a security bug, write Bug: in commit, not Closes:
- Use separate commit when dropping ebuilds, but make sure you drop the exact syntax from Manifest file that refers to the dropped app version, not more, not less. In case someone wants to restore it, to restore it completely.
- When using Gentoo vars with if conditionals, don't quote them. i.e. if [[ ${PN} ]] not if [[ "${PN}" ]]
- When two ebuilds from 2 packages are identical, bugs should still be assigned per package
- Create scenarios out of all possible dependency issues real or imagined, i.e.: if the package can be run with musl or not, if it doesn't, then put a dependency on sys-libs/glibc, and propose a global mask for musl on it - although preferable part here is masking globally only if it directly conflicts, otherwise check with the devs if they will provide musl support in the future or not. Out of such scenarios I actually found out it's not okay to put a condition like amd64? ( sys-libs/glibc && ! sys-libs/musl ) because they can't actually be installed in the same time, so the && condition is absolutely useless.
- If it's a compiled language, first check with qa-vdb <package> to check dependencies first.
- If dependencies are dubious, missing or otherwise, you should scanelf everything in that package, as example:
root #qlist -e clion | xargs scanelf -BF '%n'
also check if there are stuff like not found
- Basically get familiar with everyhing in the devtools like iwdevtools
- Commits message should look like this:
CODE
category/package: <version> commit message
* details 1
details 2, but about details 1
details 3, still about details 1
* new details
Bug: https://bugs.gentoo.org/numbers
Closes: https://bugs.gentoo.org/numbers
Closes: https://bugs.gentoo.org/numbers (obsolete)
Signed-off-by: UserOnGit <email@something>
- If you want to maintain something, you have to have 1 commit for maintainer change, and 1 commit for the rest, per package.
- When stripping binaries and libraries of debug symbols (to fix a conflict issue), best to use ${PN} for /usr/lib/debug/ path via debugedit, not ${P} or ${PVR} or anything else, if it's not slotted.
- If it's a binary package and doesn't run on anything but amd64, x86 and arm64 best to use: KEYWORDS="-* ~amd64 ~arm64 ~x86" for unstable and KEYWORDS="-* amd64 arm64 x86", basically the difference here is this little guy -*, docs about this one here:
- Definitely you don't need me to tell you that you need GPG signing on your commits :-)
- If the tools you're using are part of @system, you don't need to add them as build dependencies (like file, grep, sed, so forth)
- If you have something using xdg, please note that you can inherit xdg directly, and don't need to have postrm or postinst anymore for stuff like those.
- If you inherit something from a previous maintainer in a ebuild, something like RESTRICT="test" without any explanation why, make sure you find out the truth about it with all its details, and test with its removal. Some ebuilds inherit things that are do not have any meaning anymore. Pay attention for those.
- Sometimes you gotta make sure some ebuild functions don't run on some type of packages, ebuild functions such as src_configure(), which might collide with package installation because it doesn't have any ./configure or make. Best to avoid those is a empty src_configure() { :; }
- If you change a bug that might help 2 different programs, you might wanna use Bug: instead of Closes:, so the maintainer from the other package might get some notifications and help from the other package, if the issues are shared
- Don't forget about pkgcheck-ing your commits, I personally use pkgcheck scan --commits <commithash> to check for everything after I've done a commit and did not push it yet.
- Commit messages with more than 80 character provoke warnings to pkgcheck
- For java apps & dependencies: Java_Developer_Guide
- It seems to be a good practice to use arrow SRC_URI for packages that don't change name and version for their sources. I.e. something.tar.gz -> ${P}.tar.gz.