Auks is a must to manage kerberos V credentials in a slurm environment. especially for non interactive (where the user can issue a kinit after job allocation). It serializes, sends and refresh --as needed- for the duration of a job. kerberized NFS shares is an obvious use case source: https://github.com/cea-hpc/auks Reproducible: Always
I'd like to volunteer in an unofficial capacity. I'm no expert in writing ebuilds. I cobbled this [1] together some time ago it worked for me so far (It's missing openrc scripts as I opted for systemd when I'm using auks) any pointers to make it better are very welcome. [1] https://github.com/kenshin33/gentoo-overlay
You've piqued my interest; Gentoo HPC is on my agenda! At a glance the ebuild looks pretty good, I'll take a look in a few hours and provide any feedback; once we're happy with the it we can raise a PR. Thanks for the contribution!
no problem at all.
OK, overall this is a _really good_ first ebuild submission for ::gentoo. There's a bunch of QA items that we need to address to bring this ebuild up to speed. Some may seem quite nitpicky, but it's important that ebuilds in ::gentoo meet certain QA standards First, the prerequisites for becoming an ebuild maintainer; You'll be a Proxy Maintainer, so read up on that: https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers Next, get your maintainer bug filed: https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/Maintainer_Bugs_and_Maintainership_Requests#Maintainer_Bug Onto ebuild feedback. You obviously know a bit about this so I'll offer pointers rather than direct 'do x' feedback; if you get lost or the hint isn't enough let me know - there's no shame in asking but you'll learn more this way! 1. cat /var/db/repos/gentoo/skel.ebuild and a few other examples in the repo; ::gentoo, there's some conventions as to blank lines after certain ebuild variables are set, though some are typically grouped. 2. Update the EAPI to the latest version, adjust the copyright year, alphabetise inherits 3. We need a LICENSE; I've checked and the one you need is already in ::gentoo 4. We can't keyword something as stable directly 5. x86 testing requires either running on x86 hardware or a special chroot https://wiki.gentoo.org/wiki/Project:X86/Chroot_Guide 6. Drop the systemd USE: https://wiki.gentoo.org/wiki/Project:Systemd/Ebuild_policy Just install the files unconditionally. 7. use optfeature.eclass for slurm unless it's actually required for auks to run; it seems like installing the 8. I know that the spec file does it, but is `-DSYSCONFDIR=\\\"/etc/auks\\\"` really required, or is there an alternative? If not, is it something that we can patch and send upstream? 9. `${FILESDIR}/*.service` doesn't exist, I assume the patch replaced it 10. libauksapi.la is mentioned in a few warnings. I'm sure we'll find a little more, but it's a there's plenty above to work with! Finally there's a few nice QA tools that you can run over the ebuild: dev-util/pkgcheck (to check for common QA issues in the ebuild) dev-util/pkgdev will be needed used later to commit to ::gentoo All of the nitpicking above aside - this is a great first ebuild and it won't be too much trouble to get it into ::gentoo!
I made few modifications, I hope they're ok. (see bellow, there are inline responses) (In reply to Matt Jolly from comment #4) > OK, overall this is a _really good_ first ebuild submission for ::gentoo. > > There's a bunch of QA items that we need to address to bring this ebuild up > to speed. Some may seem quite nitpicky, but it's important that ebuilds in > ::gentoo meet certain QA standards > > First, the prerequisites for becoming an ebuild maintainer; You'll be a > Proxy Maintainer, so read up on that: > > https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers > > Next, get your maintainer bug filed: > https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/ > Maintainer_Bugs_and_Maintainership_Requests#Maintainer_Bug > > Onto ebuild feedback. You obviously know a bit about this so I'll offer > pointers rather than direct 'do x' feedback; if you get lost or the hint > isn't enough let me know - there's no shame in asking but you'll learn more > this way! > > 1. cat /var/db/repos/gentoo/skel.ebuild and a few other examples in the > repo; ::gentoo, there's some conventions as to blank lines after certain > ebuild variables are set, though some are typically grouped. > > 2. Update the EAPI to the latest version, adjust the copyright year, > alphabetise inherits > > 3. We need a LICENSE; I've checked and the one you need is already in > ::gentoo > > 4. We can't keyword something as stable directly > forgot to adjuste it when extracting the ebuild. I use the stable dist at work (excepte for a few ebuilds). > 5. x86 testing requires either running on x86 hardware or a special chroot > https://wiki.gentoo.org/wiki/Project:X86/Chroot_Guide > removed it for the time being > 6. Drop the systemd USE: > https://wiki.gentoo.org/wiki/Project:Systemd/Ebuild_policy > Just install the files unconditionally. > > 7. use optfeature.eclass for slurm unless it's actually required for auks to > run; > it seems like installing the > It's the other way around, slurm would needs auks if the plugin is built and enabled in slurm. In a nutshell, the plugin is loaded by srun (or sbatch), ispushes the users credential cache to auksd, then at the start of the job on the compute node said credential cache is retrieved. > 8. I know that the spec file does it, but is > `-DSYSCONFDIR=\\\"/etc/auks\\\"` really required, or is there an > alternative? If not, is it something that we can patch and send upstream? > I patched it, I'll see if upstream is interesed. > 9. `${FILESDIR}/*.service` doesn't exist, I assume the patch replaced it > I removed them by accident when extracting the ebuild from the real local overlay I use at work. They are back. > 10. libauksapi.la is mentioned in a few warnings. > Followed the advice given here : https://projects.gentoo.org/qa/policy-guide/installed-files.html#pg0303 > I'm sure we'll find a little more, but it's a there's plenty above to work > with! > > Finally there's a few nice QA tools that you can run over the ebuild: > > dev-util/pkgcheck (to check for common QA issues in the ebuild) > dev-util/pkgdev will be needed used later to commit to ::gentoo > > All of the nitpicking above aside - this is a great first ebuild and it > won't be too much trouble to get it into ::gentoo!
Hey, that's looking great! A little more feedback, then we can look at submitting a PR. 1. You added a `pam` use, which is nice, but the ebuild doesn't yet depend on `sys-libs/pam`. 2. Please remove the newline before SRC_URI and indent your RDEPEND content. 3. Drop BDEPEND (autotools.eclass does that for you) 4. in src_configure, let's use an array for myconf. 5. We prefer to be explicit about files we're installing from FILESDIR, while the glob is acceptable it would be ideal to specify each file 6. add a metadata.xml to your package - There will be an example with the proxy-maint project in ::gentoo that you can use as a starting point. Once you've done that, I think it'll be good to go - any additional feedback that comes up can be addressed on your GitHub PR! The TL;DR on your next steps are: 1. create a fork of ::gentoo (and to make life easier with automation, make and switch to an 'auks' branch) 2. copy your package (and associated files) into it 3. `git add` your files and use `pkgdev commit` to create the commit 4. run `pkgcheck scan --commits` to scan the commit on your branch; address any feedback that it provides. 5. push your changes and submit a PR The below is useful reading, particularly about configuring Git for signoff and the GLEP 76 requirement to sign off your commits - you don't need a gpg key or anything at this stage. The 'Workflow walkthrough' is also quite nice; it's a more elaborate version of what I've described above: https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Configuration Also be sure to add a line to your commit referencing this bug for the Pull Request bot to link with it. `Closes: https://bugs.gentoo.org/878477`
