Re: [gentoo-dev] sys-kernel/gentoo-kernel on riscv
В письме от понедельник, 3 июля 2023 г. 14:52:21 MSK пользователь Michał Górny написал: > On Mon, 2023-07-03 at 14:43 +0300, Alexey 'Alexxy' Shvetsov wrote: > > Hi! > > > > In order to use sys-kernel/gentoo-kernel with enabled savedconfig on riscv > > (i tested on starfive2) kernel-build eclass should be modifyed as in > > included patches. > > WFM. Feel free to push it straight into ::gentoo after waiting some > time for more comments. Ok. Pushing it, since there were no objections. And it shouldnt hurt anyone -- Best regards, Alexey 'Alexxy' Shvetsov signature.asc Description: This is a digitally signed message part.
[gentoo-dev] sys-kernel/gentoo-kernel on riscv
Hi!
In order to use sys-kernel/gentoo-kernel with enabled savedconfig on riscv (i
tested on starfive2) kernel-build eclass should be modifyed as in included
patches.
--
Best regards,
Alexey 'Alexxy' Shvetsov>From 85ce6d67a537ddbfe19fc817cde687dd99ebec0a Mon Sep 17 00:00:00 2001
From: Alexey Shvetsov
Date: Mon, 3 Jul 2023 14:35:33 +0300
Subject: [PATCH 2/2] eclass/kernel-build.eclass: should depend on dtc for arm*
and riscv
Signed-off-by: Alexey Shvetsov
---
eclass/kernel-build.eclass | 3 +++
1 file changed, 3 insertions(+)
diff --git a/eclass/kernel-build.eclass b/eclass/kernel-build.eclass
index 2123f165846a..0c8eaf3c1cd5 100644
--- a/eclass/kernel-build.eclass
+++ b/eclass/kernel-build.eclass
@@ -39,6 +39,9 @@ BDEPEND="
sys-devel/flex
virtual/libelf
app-alternatives/yacc
+ arm? ( sys-apps/dtc )
+ arm64? ( sys-apps/dtc )
+ riscv? ( sys-apps/dtc )
"
IUSE="+strip"
--
2.41.0
>From d1ca6ded9d043ac06c55cd20213cad9b0ef89b27 Mon Sep 17 00:00:00 2001
From: Alexey Shvetsov
Date: Mon, 3 Jul 2023 14:34:27 +0300
Subject: [PATCH 1/2] eclass/kernel-build.eclass: riscv also need dtbs
Signed-off-by: Alexey Shvetsov
---
eclass/kernel-build.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/kernel-build.eclass b/eclass/kernel-build.eclass
index 963e020b3746..2123f165846a 100644
--- a/eclass/kernel-build.eclass
+++ b/eclass/kernel-build.eclass
@@ -188,7 +188,7 @@ kernel-build_src_test() {
debug-print-function ${FUNCNAME} "${@}"
local targets=( modules_install )
# on arm or arm64 you also need dtb
- if use arm || use arm64; then
+ if use arm || use arm64 || use riscv; then
targets+=( dtbs_install )
fi
@@ -216,7 +216,7 @@ kernel-build_src_install() {
# on what kind of installkernel is installed
local targets=( modules_install )
# on arm or arm64 you also need dtb
- if use arm || use arm64; then
+ if use arm || use arm64 || use riscv; then
targets+=( dtbs_install )
fi
--
2.41.0
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Progress of the Gentoo/LoongArch port, and question on upstreaming procedure
Hi! Its interesting thing. Is there a possibility to get LoongArch hw outside of China? В письме от суббота, 1 января 2022 г. 20:28:16 MSK пользователь WANG Xuerui написал: > Hi everyone, > > I'm the guy who previously announced the Gentoo/LoongArch port [1]; > since that post, some nice progress has been made, and here's a heads-up > and a procedural question regarding how to continue work upstream. > > > ## Progress of the port > > After some minimal forking and tweaking, it's already possible to build > working stage3 tarballs with catalyst; > with quick-and-dirty catalyst[2] and genkernel[3] patches, even working > installation CDs can be built (confirmed by LiveUSB-making and booting > on real 3A5000 hardware). > The built stages and installation CD images are already available in > several mirrors like [4] or [5]. > > The toolchain development of Loongson has gone more-or-less quiet > lately, and many projects (eselect, icu, systemd, etc.) have already had > releases that contain LoongArch bring-up changes, so it's time to push > more things upstream (in this case, the main gentoo.git repo). > > > ## How to test this? > > The necessary changes are all brewing in the loongson-overlay[6], which > is available via layman (`sudo layman -a loongson`). You'll need this > for the loong profile and toolchain patches. > > The stages can be tested with QEMU linux-user emulation, if you don't > have the LoongArch hardware; > but the LoongArch target is not upstream yet, so you'll have to compile > Loongson's fork ([7]; qemu-devel threads [8] [9]) yourself. The > necessary binfmt-misc declaration is like this (remove all whitespaces > > and newlines before using): > > :loongarch64:M:: > > \x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x02\x01: > > \xff\xff\xff\xff\xff\xff\xff\xfc\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff > > > \xff\xff:/usr/local/bin/qemu-loongarch64: > You can use your favorite way to set up this (manually, via rc-scripts, > via systemd-binfmt.service, whatever), replacing the interpreter path to > suit your setup, then just proceed like every chroot. > > Inside the chroot, you need to `git clone` the loongson-overlay, add it > to /etc/portage/repos.conf, and fix the profile symlink; after that you > should be able to emerge packages as usual. Keywords are mostly missing, > so you may use ACCEPT_KEYWORDS=~riscv or something similar to get > through, in case everything is masked and not package.accept_keywords-ed. > > Note that their system emulation is currently in a worse state than > linux-user (horribly slow and dependent on prebuilt firmware blob), > according to review comments, so you may as well ignore the installation > CDs for now. > > > ## Problem regarding further upstream work > > As described above, there is already some nice progress, but a > procedural problem still remains: every new architecture needs a backing > project and arch team [10], yet I'm not a Gentoo dev and it's unclear if > any Gentoo dev would be interested in such a niche architecture with > limited hardware availability outside China, so we may get stuck in this > state for an extended period. > > Any suggestion is welcome; and thank you for your attention. > > > Regards, > WANG "xen0n" Xuerui > > > [1]: > https://archives.gentoo.org/gentoo-dev/message/ef0b1812e9b66cdf5978ecc2ad4ed > a4e [2]: https://github.com/xen0n/catalyst/tree/3.0.20-for-loong > [3]: https://github.com/xen0n/genkernel/tree/loong > [4]: https://mirrors.tuna.tsinghua.edu.cn/loongson/gentoo/experimental/ > [5]: https://mirrors.bfsu.edu.cn/loongson/gentoo/experimental/ > [6]: https://github.com/xen0n/loongson-overlay > [7]: https://github.com/loongson/qemu/tree/tcg-dev > [8]: > https://patchew.org/QEMU/1638610165-15036-1-git-send-email-gaosong@loongson. > cn/ [9]: > https://patchew.org/QEMU/1638619645-11283-1-git-send-email-yangxiaojuan@loon > gson.cn/ [10]: > https://projects.gentoo.org/council/meeting-logs/20180114-summary.txt -- Best regards, Alexey 'Alexxy' Shvetsov signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Trying to use Python3.9 as default for my laptop
В письме от четверг, 15 октября 2020 г. 01:03:08 MSK пользователь Sergei Trofimovich написал: > On Thu, 15 Oct 2020 00:01:58 +0300 > Alexey 'Alexxy' Shvetsov wrote: > > ... > > > sys-devel/gdb > > > > So i wanna ask maintainers of this packages add python3_9 to pytargets > > (they builds and works fine for me) or if they dont mind give me a right > > to do so =) > Sure. Go ahead. done -- Best regards, Alexey 'Alexxy' Shvetsov signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Trying to use Python3.9 as default for my laptop
Hi! Recently i give a try for python 3.9 as default for my work laptop. So i created a list of packages that laks python3_9 flag in pytargets app-admin/system-config-printer app-misc/solaar app-text/gnome-doc-utils dev-games/freecell-solver dev-java/java-config dev-libs/gobject-introspection dev-python/pysol_cards dev-python/pyudev dev-python/random2 dev-util/gdbus-codegen dev-util/itstool dev-util/systemtap media-gfx/fontforge media-libs/lensfun net-analyzer/speedtest-cli net-libs/gupnp net-libs/libaccounts-glib/ sys-apps/fwupd sys-devel/gdb sys-libs/libblockdev So i wanna ask maintainers of this packages add python3_9 to pytargets (they builds and works fine for me) or if they dont mind give me a right to do so =) -- Best regards, Alexey 'Alexxy' Shvetsov signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: uid/gid for octoprint
В письме от вторник, 11 февраля 2020 г. 14:27:08 MSK пользователь Ulrich Mueller написал: > >>>>> On Tue, 11 Feb 2020, Alexey 'Alexxy' Shvetsov wrote: > > Ok. What is you're suggestion? > > If you really need that kind of mnemonics, how about 368 (68 being the > ASCII code for "D")? > > Ulrich i think Ulrich suggestion is better =D -- Best regards, Alexey 'Alexxy' Shvetsov signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: uid/gid for octoprint
Ok. So it can be 340 for both uid an gid (its free) В письме от вторник, 11 февраля 2020 г. 14:17:48 MSK пользователь Michał Górny написал: > On Tue, 2020-02-11 at 14:15 +0300, Alexey 'Alexxy' Shvetsov wrote: > > В письме от вторник, 11 февраля 2020 г. 13:52:46 MSK пользователь Michał > > Górny> > > написал: > > > On Tue, 2020-02-11 at 13:18 +0300, Alexey 'Alexxy' Shvetsov wrote: > > > > В письме от вторник, 11 февраля 2020 г. 13:15:48 MSK пользователь > > > > Michał > > > > Górny> > > > > > > > > написал: > > > > > On Tue, 2020-02-11 at 13:06 +0300, Alexey 'Alexxy' Shvetsov wrote: > > > > > > Hi all! > > > > > > > > > > > > I'd like to reserve uid/gid 34 (3D printing) for > > > > > > www-apps/octoprint > > > > > > (cups > > > > > > analog for 3d printing) > > > > > > > > > > What is the rationale for taking UID/GID from the low range? > > > > > > > > 3 D (D is the 4 letter in latin alphabet) > > > > > > That's not a good justification. NAK. > > > > Ok. What is you're suggestion? > > Take any number in the 101..499 range, as indicated in the policy. -- Best regards, Alexey 'Alexxy' Shvetsov signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: uid/gid for octoprint
В письме от вторник, 11 февраля 2020 г. 13:52:46 MSK пользователь Michał Górny написал: > On Tue, 2020-02-11 at 13:18 +0300, Alexey 'Alexxy' Shvetsov wrote: > > В письме от вторник, 11 февраля 2020 г. 13:15:48 MSK пользователь Michał > > Górny> > > написал: > > > On Tue, 2020-02-11 at 13:06 +0300, Alexey 'Alexxy' Shvetsov wrote: > > > > Hi all! > > > > > > > > I'd like to reserve uid/gid 34 (3D printing) for www-apps/octoprint > > > > (cups > > > > analog for 3d printing) > > > > > > What is the rationale for taking UID/GID from the low range? > > > > 3 D (D is the 4 letter in latin alphabet) > > That's not a good justification. NAK. Ok. What is you're suggestion? -- Best regards, Alexey 'Alexxy' Shvetsov signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: uid/gid for octoprint
В письме от вторник, 11 февраля 2020 г. 13:15:48 MSK пользователь Michał Górny
написал:
> On Tue, 2020-02-11 at 13:06 +0300, Alexey 'Alexxy' Shvetsov wrote:
> > Hi all!
> >
> > I'd like to reserve uid/gid 34 (3D printing) for www-apps/octoprint (cups
> > analog for 3d printing)
>
> What is the rationale for taking UID/GID from the low range?
Also i seems need a group/user for uucp as dep (since octoprint need access to
/dev/tty{USB,ACM} or other types of com ports
--
Best regards,
Alexey 'Alexxy' Shvetsov
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: uid/gid for octoprint
В письме от вторник, 11 февраля 2020 г. 13:15:48 MSK пользователь Michał Górny написал: > On Tue, 2020-02-11 at 13:06 +0300, Alexey 'Alexxy' Shvetsov wrote: > > Hi all! > > > > I'd like to reserve uid/gid 34 (3D printing) for www-apps/octoprint (cups > > analog for 3d printing) > > What is the rationale for taking UID/GID from the low range? 3 D (D is the 4 letter in latin alphabet) -- Best regards, Alexey 'Alexxy' Shvetsov signature.asc Description: This is a digitally signed message part.
[gentoo-dev] RFC: uid/gid for octoprint
Hi all! I'd like to reserve uid/gid 34 (3D printing) for www-apps/octoprint (cups analog for 3d printing) -- Best regards, Alexey 'Alexxy' Shvetsov signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Why adding python3_8 to Gentoo sucks?
В письме от пятница, 15 ноября 2019 г. 15:19:31 MSK пользователь Michael Orlitzky написал: > On 11/15/19 7:04 AM, Alexey 'Alexxy' Shvetsov wrote: > > As i remember some decades ago policy was: revbump needed if you change > > chnages stuff installed on filesystem. So in case of py addition it is. So > > what changed? > > > > Are there some new written rules that says in what case you need revbump > > and in what it needed? > > To avoid breaking dependency resolution on users' systems, you have to > make a new revision whenever you change a metadata variable that the > package manager uses: DEPEND, RDEPEND, BDEPEND, IUSE, LICENSE, > PYTHON_COMPAT, etc. > > Basically, unless your change is completely trivial (updated comment, > typo fix...), you should be making a new revision by default. Yep. That that i remember. -- Best regards, Alexey 'Alexxy' Shvetsov signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Why adding python3_8 to Gentoo sucks?
В письме от пятница, 15 ноября 2019 г. 13:47:12 MSK пользователь Mart Raudsepp написал: > Ühel kenal päeval, R, 15.11.2019 kell 13:20, kirjutas Alexey 'Alexxy' > > Shvetsov: > > В письме от пятница, 15 ноября 2019 г. 11:45:32 MSK пользователь > > Michał Górny > > > > написал: > > > On Fri, 2019-11-15 at 11:41 +0300, Alexey 'Alexxy' Shvetsov wrote: > > > > I think problem is more global: > > > > * many python3_6 packages dont have python3_7 keywords, because > > > > its > > > > maintainers dont bother about it. So if you want to switch to > > > > python3_7 > > > > you > > > > still need manualy add python3_7 use for many packages (that > > > > actualy work > > > > without problems > > > > * we need policy for python packages that force enablement of new > > > > python > > > > version on existing packages. > > > > > > Policy makes little sense if there's no way to enforce it. > > > > > > If you tested some package on py3.7 and depgraph, just add it > > > there. > > > > Some people dont like it =D And some arches (doesnt matter if i have > > such hw > > and tested on it) > > People mostly don't like it when you throw unrelated changes on top of > that, under the guise of just python target addition, especially when > they are also broken changes and involve a revbump without maintainers > involvement (just PYTHON_TARGETS addition doesn't). Or if it actually > doesn't work with the added python targets. As i remember some decades ago policy was: revbump needed if you change chnages stuff installed on filesystem. So in case of py addition it is. So what changed? Are there some new written rules that says in what case you need revbump and in what it needed? -- Best regards, Alexey 'Alexxy' Shvetsov signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Why adding python3_8 to Gentoo sucks?
В письме от пятница, 15 ноября 2019 г. 11:45:32 MSK пользователь Michał Górny написал: > On Fri, 2019-11-15 at 11:41 +0300, Alexey 'Alexxy' Shvetsov wrote: > > I think problem is more global: > > * many python3_6 packages dont have python3_7 keywords, because its > > maintainers dont bother about it. So if you want to switch to python3_7 > > you > > still need manualy add python3_7 use for many packages (that actualy work > > without problems > > * we need policy for python packages that force enablement of new python > > version on existing packages. > > Policy makes little sense if there's no way to enforce it. > > If you tested some package on py3.7 and depgraph, just add it there. Some people dont like it =D And some arches (doesnt matter if i have such hw and tested on it) -- Best regards, Alexey 'Alexxy' Shvetsov signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Why adding python3_8 to Gentoo sucks?
I think problem is more global: * many python3_6 packages dont have python3_7 keywords, because its maintainers dont bother about it. So if you want to switch to python3_7 you still need manualy add python3_7 use for many packages (that actualy work without problems * we need policy for python packages that force enablement of new python version on existing packages. В письме от четверг, 14 ноября 2019 г. 00:16:10 MSK пользователь Michał Górny написал: > Hi, > > I'd like to share my frustration at the state of Python in general, > and Python packages in Gentoo. So I'd like to 'bootstrap' python3_8 -- > that is, add it to the most common dependency, dev-python/setuptools. > Simple thing, right? > > > 1. There's no such thing as trivial dependency graph in Python. If you > think that setuptools has a few deps, you're entirely wrong. I actually > had to write a tool to even assemble list of deps to start with, > and the number is: 174. I mean, in order to enable py3.8 on setuptools, > you have to enable it on at least 173 other packages. > > Sure, some of those packages are just doc-deps or test-deps, and some > could be avoided one way or another. However, avoiding them is only > temporary and involves more effort than it saves. > > > 2. There are some packages that dropped Python 2.7 but still have 2.7 > deps. So we need to also add py3.8 to older versions that still has > 2.7. Plus, some packages have explicit <-deps. So we need to add 3.8 > to them, and hope that the old version will actually work with 3.8, > and then to their extra dependencies. > > This is all handiwork. The number is now 178 packages, or 187 ebuilds. > > > 3. Of course there are packages with new deps dropping keywords whose > maintainers (or bumpers) never bothered filing a keywordreq. Because > why bother, somebody else will do that when it blocks everything, > right?! > > Well, guess what. python3_8 flag is going to be masked on non-amd64 > because people didn't bother keywording new versions of their packages > on other arches. > > If you choose to realize your mistake now, and are willing to fix it, > start keywording new versions. > > > Here's the initial CI run: > > https://github.com/gentoo/gentoo/pull/13638 > > The packages haven't been tested yet. If you want to help, feel free to > apply it locally, and run tests in all those packages, and try to > assemble a reasonably readable report of what fails. Then probably diff > the failures against py3.7 because some packages probably fail there > as well. > > Of course many of those packages don't have tests at all. Because it > was too much effort, and the four-letter company didn't pay for them. > Because it was too hard to use GitHub snapshot over pypi tarball that > doesn't bundle tests because obviously nobody wants them. Help with > that welcome too. > > Help with getting rid of py2 revdeps of py3-only packages would be very > welcome too. > > In other words, there's a lot of work to get Python near-sane in Gentoo, > and we'd welcome all the help we can get. TIA. -- Best regards, Alexey 'Alexxy' Shvetsov signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Reserve slurm user and group uid/gid 400/400
Since 500/500 is reserved uid/gid then i'll proceed with 400|400 > Hi! > > I'd like to reserve slurm user and group for sys-cluster/slurm. I plan to > use old uid/gid for it (500/500) -- Best regards, Alexey 'Alexxy' Shvetsov signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Reserve slurm user and group uid/gid 500/500
В письме от пятница, 23 августа 2019 г. 22:40:54 MSK пользователь Michael Orlitzky написал: > On 8/23/19 3:27 PM, Alexey 'Alexxy' Shvetsov wrote: > > +DESCRIPTION="User for the slurm - Highly Scalable Resource Manager" > > +ACCT_USER_ID=500 > > +ACCT_USER_HOME=/var/lib/slurm > > +ACCT_USER_HOME_PERMS=0770 > > +ACCT_USER_GROUPS=( slurm ) > > If your package uses that directory, I would recommend you not rely on > it being created (with special permissions) as a side effect of > installing the acct-user package: > > https://archives.gentoo.org/gentoo-dev/message/fc55ac57cd92d9c1e156d13c882b0 > 8cf > > That used to be acceptable, since the "enewuser" command with the home > directory was part of the package that used that directory. But now that > the user data are in another package, we can't depend on them reliably. I'll check if it will work for me. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Reserve slurm user and group uid/gid 500/500
В письме от пятница, 23 августа 2019 г. 22:39:29 MSK пользователь Mike Gilbert написал: > On Fri, Aug 23, 2019 at 3:27 PM Alexey 'Alexxy' Shvetsov > > wrote: > > Hi! > > > > I'd like to reserve slurm user and group for sys-cluster/slurm. I plan to > > use old uid/gid for it (500/500) > > I think we are trying to avoid using 500 too 999 for the time being. > Can you pick another number lower than 500? uid/gid 500 was used for historical reasons. So i can change it to other uid/ gid like 300 or 400 signature.asc Description: This is a digitally signed message part.
[gentoo-dev] [RFC] Reserve slurm user and group uid/gid 500/500
Hi! I'd like to reserve slurm user and group for sys-cluster/slurm. I plan to use old uid/gid for it (500/500) >From f8545efd0d615a44083f9a416e6eb195c627ebaf Mon Sep 17 00:00:00 2001 From: Alexey Shvetsov Date: Fri, 23 Aug 2019 22:16:49 +0300 Subject: [PATCH 1/2] acct-group/slurm: Add slurm group Package-Manager: Portage-2.3.72, Repoman-2.3.17 RepoMan-Options: --force Signed-off-by: Alexey Shvetsov --- acct-group/slurm/metadata.xml | 12 acct-group/slurm/slurm-0.ebuild | 9 + 2 files changed, 21 insertions(+) create mode 100644 acct-group/slurm/metadata.xml create mode 100644 acct-group/slurm/slurm-0.ebuild diff --git a/acct-group/slurm/metadata.xml b/acct-group/slurm/metadata.xml new file mode 100644 index ..afbbd16e7d0d --- /dev/null +++ b/acct-group/slurm/metadata.xml @@ -0,0 +1,12 @@ + +http://www.gentoo.org/dtd/metadata.dtd;> + + + ale...@gentoo.org + Alexey Shvetsov + + + clus...@gentoo.org + Gentoo Cluster Project + + diff --git a/acct-group/slurm/slurm-0.ebuild b/acct-group/slurm/slurm-0.ebuild new file mode 100644 index ..685064b8a4fe --- /dev/null +++ b/acct-group/slurm/slurm-0.ebuild @@ -0,0 +1,9 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-group + +DESCRIPTION="A group for the slurm - Highly Scalable Resource Manager" +ACCT_GROUP_ID=500 -- 2.23.0 >From b821fcb711b3ebb7f3b01cde30a6c142ec518d7d Mon Sep 17 00:00:00 2001 From: Alexey Shvetsov Date: Fri, 23 Aug 2019 22:22:35 +0300 Subject: [PATCH 2/2] acct-user/slurm: Add slurm user Package-Manager: Portage-2.3.72, Repoman-2.3.17 RepoMan-Options: --force Signed-off-by: Alexey Shvetsov --- acct-user/slurm/metadata.xml | 12 acct-user/slurm/slurm-0.ebuild | 14 ++ 2 files changed, 26 insertions(+) create mode 100644 acct-user/slurm/metadata.xml create mode 100644 acct-user/slurm/slurm-0.ebuild diff --git a/acct-user/slurm/metadata.xml b/acct-user/slurm/metadata.xml new file mode 100644 index ..afbbd16e7d0d --- /dev/null +++ b/acct-user/slurm/metadata.xml @@ -0,0 +1,12 @@ + +http://www.gentoo.org/dtd/metadata.dtd;> + + + ale...@gentoo.org + Alexey Shvetsov + + + clus...@gentoo.org + Gentoo Cluster Project + + diff --git a/acct-user/slurm/slurm-0.ebuild b/acct-user/slurm/slurm-0.ebuild new file mode 100644 index ..1b68993e398a --- /dev/null +++ b/acct-user/slurm/slurm-0.ebuild @@ -0,0 +1,14 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-user + +DESCRIPTION="User for the slurm - Highly Scalable Resource Manager" +ACCT_USER_ID=500 +ACCT_USER_HOME=/var/lib/slurm +ACCT_USER_HOME_PERMS=0770 +ACCT_USER_GROUPS=( slurm ) + +acct-user_add_deps -- 2.23.0 signature.asc Description: This is a digitally signed message part.
