[gentoo-dev] [PATCH 2/2] virtual/{c,}blas: add sci-libs/blis as a candidate.
From: Benda Xu
On ld.so-based systems, runtime library switching is possible. We
use 'eselect-ldso' to flag this possibility. In this case, blis can
used as a drop-in replacement via an `eselect` call.
Otherwise If USE eselect-ldso is not set, only reference
implementation will be pulled in.
Package-Manager: Portage-2.3.52, Repoman-2.3.12
Signed-off-by: Benda Xu
---
virtual/blas/blas-3.8.ebuild | 5 -
virtual/cblas/cblas-3.8.ebuild | 5 -
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/virtual/blas/blas-3.8.ebuild b/virtual/blas/blas-3.8.ebuild
index e3807aaa8c4a..45bf1cc03013 100644
--- a/virtual/blas/blas-3.8.ebuild
+++ b/virtual/blas/blas-3.8.ebuild
@@ -9,6 +9,9 @@ KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~mips ~ppc
~ppc64 ~s390 ~sparc ~
IUSE="eselect-ldso"
RDEPEND="
- >=sci-libs/lapack-3.8.0[eselect-ldso?]
+ !eselect-ldso? ( >=sci-libs/lapack-3.8.0[-eselect-ldso] )
+ eselect-ldso? ( || (
+ >=sci-libs/lapack-3.8.0[eselect-ldso]
+ sci-libs/blis[eselect-ldso] ) )
"
DEPEND="${RDEPEND}"
diff --git a/virtual/cblas/cblas-3.8.ebuild b/virtual/cblas/cblas-3.8.ebuild
index 0b295963f8de..440e9fc4a540 100644
--- a/virtual/cblas/cblas-3.8.ebuild
+++ b/virtual/cblas/cblas-3.8.ebuild
@@ -9,6 +9,9 @@ KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~ppc ~ppc64
~s390 ~sparc ~x86 ~a
IUSE="eselect-ldso"
RDEPEND="
- >=sci-libs/lapack-3.8.0[eselect-ldso?]
+ !eselect-ldso? ( >=sci-libs/lapack-3.8.0[-eselect-ldso] )
+ eselect-ldso? ( || (
+ >=sci-libs/lapack-3.8.0[eselect-ldso]
+ sci-libs/blis[eselect-ldso] ) )
"
DEPEND="${RDEPEND}"
--
2.17.0
[gentoo-dev] [PATCH 0/2] RFC: Introducing ldso switching to BLAS/LAPACK
From: Benda Xu
The following 2 patches are to introduce the runtime switching
mechanism to BLAS/LAPACK libraries in Gentoo.
This feature is turned off by default and only the reference
BLAS/LAPACK is used to satisfy the dependencies. It can be enabled by
USE=eselect-ldso.
Sorry for the glitch to the tree caused by my mistake yesterday. I am
looking forward to your review. I am cross posting to -dev and -sci
so as to attract atention from all interested parties.
Cheers,
Benda
Benda Xu (2):
virtual/{blas,cblas,lapack,lapacke}: add virtual packages.
virtual/{c,}blas: add sci-libs/blis as a candidate.
virtual/blas/blas-3.8.ebuild | 17 +
virtual/blas/metadata.xml | 10 +++---
virtual/cblas/cblas-3.8.ebuild | 17 +
virtual/cblas/metadata.xml | 10 +++---
virtual/lapack/lapack-3.8.ebuild | 14 ++
virtual/lapack/metadata.xml| 10 +++---
virtual/lapacke/lapacke-3.8.ebuild | 14 ++
virtual/lapacke/metadata.xml | 16
8 files changed, 99 insertions(+), 9 deletions(-)
create mode 100644 virtual/blas/blas-3.8.ebuild
create mode 100644 virtual/cblas/cblas-3.8.ebuild
create mode 100644 virtual/lapack/lapack-3.8.ebuild
create mode 100644 virtual/lapacke/lapacke-3.8.ebuild
create mode 100644 virtual/lapacke/metadata.xml
--
2.17.0
[gentoo-dev] [PATCH 1/2] virtual/{blas,cblas,lapack,lapacke}: add virtual packages.
From: Benda Xu
These virtual packages are used by the BLAS/LAPACK runtime switching
mechanism.
Closes: https://github.com/gentoo/gentoo/pull/12323
Closes: https://bugs.gentoo.org/373613
Closes: https://bugs.gentoo.org/381801
Closes: https://bugs.gentoo.org/498490
Closes: https://bugs.gentoo.org/563674
Closes: https://bugs.gentoo.org/564546
Closes: https://bugs.gentoo.org/565776
Closes: https://bugs.gentoo.org/646316
Closes: https://bugs.gentoo.org/657984
Closes: https://bugs.gentoo.org/659014
Closes: https://bugs.gentoo.org/659264
Closes: https://bugs.gentoo.org/669644
Signed-off-by: Mo Zhou
Signed-off-by: Benda Xu
---
virtual/blas/blas-3.8.ebuild | 14 ++
virtual/blas/metadata.xml | 10 +++---
virtual/cblas/cblas-3.8.ebuild | 14 ++
virtual/cblas/metadata.xml | 10 +++---
virtual/lapack/lapack-3.8.ebuild | 14 ++
virtual/lapack/metadata.xml| 10 +++---
virtual/lapacke/lapacke-3.8.ebuild | 14 ++
virtual/lapacke/metadata.xml | 16
8 files changed, 93 insertions(+), 9 deletions(-)
create mode 100644 virtual/blas/blas-3.8.ebuild
create mode 100644 virtual/cblas/cblas-3.8.ebuild
create mode 100644 virtual/lapack/lapack-3.8.ebuild
create mode 100644 virtual/lapacke/lapacke-3.8.ebuild
create mode 100644 virtual/lapacke/metadata.xml
diff --git a/virtual/blas/blas-3.8.ebuild b/virtual/blas/blas-3.8.ebuild
new file mode 100644
index ..e3807aaa8c4a
--- /dev/null
+++ b/virtual/blas/blas-3.8.ebuild
@@ -0,0 +1,14 @@
+# Copyright 1999-2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI="7"
+
+DESCRIPTION="Virtual for FORTRAN 77 BLAS implementation"
+SLOT="0"
+KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sparc
~x86 ~amd64-fbsd ~x86-fbsd ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos
~x86-macos ~sparc-solaris"
+IUSE="eselect-ldso"
+
+RDEPEND="
+ >=sci-libs/lapack-3.8.0[eselect-ldso?]
+"
+DEPEND="${RDEPEND}"
diff --git a/virtual/blas/metadata.xml b/virtual/blas/metadata.xml
index 1b4d6e817c05..35dd50fb4450 100644
--- a/virtual/blas/metadata.xml
+++ b/virtual/blas/metadata.xml
@@ -6,7 +6,11 @@
Gentoo Science Project
-Gentoo virtual package for the Basic Linear Algebra Subprograms
-FORTRAN 77 implementation.
-
+Gentoo virtual package for the Basic Linear Algebra Subprograms
+FORTRAN 77 implementation.
+
+
+Enable runtime library switching by
+eselect and ld.so.
+
diff --git a/virtual/cblas/cblas-3.8.ebuild b/virtual/cblas/cblas-3.8.ebuild
new file mode 100644
index ..0b295963f8de
--- /dev/null
+++ b/virtual/cblas/cblas-3.8.ebuild
@@ -0,0 +1,14 @@
+# Copyright 1999-2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI="7"
+
+DESCRIPTION="Virtual for BLAS C implementation"
+SLOT="0"
+KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~ppc ~ppc64 ~s390 ~sparc ~x86
~amd64-fbsd ~x86-fbsd ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos"
+IUSE="eselect-ldso"
+
+RDEPEND="
+ >=sci-libs/lapack-3.8.0[eselect-ldso?]
+"
+DEPEND="${RDEPEND}"
diff --git a/virtual/cblas/metadata.xml b/virtual/cblas/metadata.xml
index 9aac1c20c93f..204ea7552ca9 100644
--- a/virtual/cblas/metadata.xml
+++ b/virtual/cblas/metadata.xml
@@ -6,7 +6,11 @@
Gentoo Science Project
-Gentoo virtual package for the Basic Linear Algebra Subprograms
-C implementation.
-
+Gentoo virtual package for the Basic Linear Algebra Subprograms
+C implementation.
+
+
+Enable runtime library switching by
+eselect and ld.so.
+
diff --git a/virtual/lapack/lapack-3.8.ebuild b/virtual/lapack/lapack-3.8.ebuild
new file mode 100644
index ..93ddd49d8b79
--- /dev/null
+++ b/virtual/lapack/lapack-3.8.ebuild
@@ -0,0 +1,14 @@
+# Copyright 1999-2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+DESCRIPTION="Virtual for Linear Algebra Package FORTRAN 77 (LAPACK)
implementation"
+SLOT="0"
+KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~ppc ~ppc64 ~s390 ~sparc ~x86
~amd64-fbsd ~x86-fbsd ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos"
+IUSE="eselect-ldso"
+
+RDEPEND="
+ >=sci-libs/lapack-3.8.0[eselect-ldso?]
+"
+DEPEND="${RDEPEND}"
diff --git a/virtual/lapack/metadata.xml b/virtual/lapack/metadata.xml
index ccb7a1fa1fad..0b91d851efe1 100644
--- a/virtual/lapack/metadata.xml
+++ b/virtual/lapack/metadata.xml
@@ -6,7 +6,11 @@
Gentoo Science Project
-Gentoo virtual package for the Linear Algebra PACKAge
-FORTRAN 77 implementation.
-
+Gentoo virtual package for the Linear Algebra PACKAge
+FORTRAN 77 implementation.
+
+
+Enable runtime library switching by
+eselect and ld.so.
+
diff --git a/virtual/lapacke/lapacke-3.8.ebuild
b/virtual/lapacke/lapacke-3.8.ebuild
new file mode 100644
index ..fc61bf733e2e
--- /dev/
[gentoo-dev] Re: Why aren't GSoC projects affecting ::gentoo discussed on regular mls?
Dear Michał, Michał Górny writes: > I would like to ask our this year's GSoC mentors a single question: > why weren't the GSoC proposals given proper discussion on our regular > mailing lists *before* they were accepted? > I can understand that most developers in Gentoo don't really care about > GSoC. However, both projects we have this year [1] involve major > changes to ::gentoo that -- by policy -- require prior RFC. In case > of the BLAS/LAPACK project there was a RFC *after* the project was > accepted, that was never fully answered. In case of the MPI project, > I'm not aware of any public RFC or announcement. The proposal has been discussed in regular mailing lists. https://archives.gentoo.org/gentoo-science/message/4d0186acdce6df538a2740e0f1146ae6 At the proposal stage it was not sent to gentoo-dev, because I thought only science project was relevant to BLAS/LAPACK. Later we find it to be affecting more ebuilds, thus the RFC was sent to gentoo-dev. https://archives.gentoo.org/gentoo-dev/message/d917547f7a9e1226fca63632a1e02026 > I believe such decisions put all of us in a very bad position. There is > a major work going on, almost secretly. In the end, we will either be > forced to accept the result even if it doesn't meet our expectations, or > reject it and turn GSoC into some kind of grotesque situation. Michał, you were overreacting to the word "GSoC" since our original RFC at gentoo-dev. Please, just ignore GSoC when you are executing your experise of QA. Gentoo should be developed independently, regardless of whether any development effort is supported by 3rd party. > The former is of course unacceptable from my point of view. It would > mean that one or two developers are able to abuse paid programs such > as GSoC to unilaterally push their preferences into Gentoo. We would be > forced to accept them unconditionally just because 'it's a done deal'. See above. > The latter means the students has wasted their summer doing work that's > not going anywhere. This is certainly demotivating and a bad PR for > Gentoo. I suppose it also reduces our chance of getting into GSoC > again, if Google finds out that GSoC is spent on code going to trash. That's why we are working together to find the best solution and reach a consensus. > So, again, why do single developers unilaterally decide on which > projects third party money is spent, and never bother discussing whether > those projects are really applicable beforehand? I will leave this question to our GSoC manager. Personally I don't regard the GSoC selection and decision process interesting to all the Gentoo devs. If you are interested in GSoC and would like share your ideas to recruit student enthusiasts, you are more than welcomed to join our team. > [1] > https://summerofcode.withgoogle.com/organizations/6416323580526592/ Cheers, Benda signature.asc Description: PGP signature
[gentoo-dev] Why aren't GSoC projects affecting ::gentoo discussed on regular mls?
(GSoC project mentors in CC) Hi, I would like to ask our this year's GSoC mentors a single question: why weren't the GSoC proposals given proper discussion on our regular mailing lists *before* they were accepted? I can understand that most developers in Gentoo don't really care about GSoC. However, both projects we have this year [1] involve major changes to ::gentoo that -- by policy -- require prior RFC. In case of the BLAS/LAPACK project there was a RFC *after* the project was accepted, that was never fully answered. In case of the MPI project, I'm not aware of any public RFC or announcement. I believe such decisions put all of us in a very bad position. There is a major work going on, almost secretly. In the end, we will either be forced to accept the result even if it doesn't meet our expectations, or reject it and turn GSoC into some kind of grotesque situation. The former is of course unacceptable from my point of view. It would mean that one or two developers are able to abuse paid programs such as GSoC to unilaterally push their preferences into Gentoo. We would be forced to accept them unconditionally just because 'it's a done deal'. The latter means the students has wasted their summer doing work that's not going anywhere. This is certainly demotivating and a bad PR for Gentoo. I suppose it also reduces our chance of getting into GSoC again, if Google finds out that GSoC is spent on code going to trash. So, again, why do single developers unilaterally decide on which projects third party money is spent, and never bother discussing whether those projects are really applicable beforehand? [1] https://summerofcode.withgoogle.com/organizations/6416323580526592/ -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Amazon Corretto openjdk builds?
On Wed, Jun 26, 2019 at 12:50:11PM -0700, Georgy Yakovlev wrote: > As a maintainer of most jdks in gentoo I'm not looking at adding even > more JDK versions this time as there is little to no reason of doing > that. Cool, thanks for the perspective. > if there is significant performance or technical difference I could > take a look at it, so let me know if I'm wrong in my assessment. The main difference from just an initial look is that the Amazon release is officially "Java SE compatible" as it passes the TCK certification. AdoptOpenJDK evidentally has some issue with oracle (a problem with oracle 8-/? Imagine that) such that they aren't able to use the TCK for testing. Then from an applications view, one of our most important java apps is the shibboleth idp, which officially supports amazon's release but not the adoptopenjdk one. They do support Redhat's OpenJDK build for RHEL and CentOS, I assume the adoptopenjdk built will work too but just adds an additional fuzzy if opening a support ticket. Thanks again...
Re: [gentoo-dev] Amazon Corretto openjdk builds?
On Wednesday, June 26, 2019 11:03:58 AM PDT Paul B. Henson wrote: > Is anybody looking at Amazon's new openjdk distribution? > > https://aws.amazon.com/corretto/ > > Advertised as production ready with long term support, no-cost. I'm not > sure how it compares to the current AdoptJDK builds, but seems like it > might be another good option. Hi, As a maintainer of most jdks in gentoo I'm not looking at adding even more JDK versions this time as there is little to no reason of doing that. adoptopenjdk is open, lts, managed by community and not corporate entity, gaining more attention lately. it supports arches amazon doesn't. the only valuable feature of corretto I can think of is presence of javafx.*, but openjdk:8 and openjdk-bin:8 will soon have it as well and we already have it for openjdk:11 if there is significant performance or technical difference I could take a look at it, so let me know if I'm wrong in my assessment. - Georgy signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Amazon Corretto openjdk builds?
Is anybody looking at Amazon's new openjdk distribution? https://aws.amazon.com/corretto/ Advertised as production ready with long term support, no-cost. I'm not sure how it compares to the current AdoptJDK builds, but seems like it might be another good option.
Re: [gentoo-dev] [PATCH 0/6] User/group assignment: burp, rtkit, syncthing
> On Wed, 26 Jun 2019, Marek Szuba wrote: > Here is the RFC for acct-* packages corresponding to users and groups > created by packages I currently maintain. This is also a request to > reserve the respective UIDs/GIDs, namely: > Groups: > - burp - 501 > - rtkit - 133 > Users: > - burp - 501 > - rtkit - 133 > - syncthing - 502 > rtkit user and group have got their IDs reserved in both Arch and > Fedora, I have opted for consistency with the former. Is there any particular reason for using 501 and 502? I'd suggest that for the time being we should stay within the LSB range (<= 499), in order to be compatible with distros that assign normal users starting at 500. There's still plenty of ids available in that range. https://refspecs.linuxfoundation.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/uidrange.html Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 0/6] User/group assignment: burp, rtkit, syncthing
On Wed, 2019-06-26 at 11:35 +0100, Marek Szuba wrote: > Here is the RFC for acct-* packages corresponding to users and groups > created by packages I currently maintain. This is also a request to > reserve the respective UIDs/GIDs, namely: > > Groups: > - burp - 501 > - rtkit - 133 > > Users: > - burp - 501 > - rtkit - 133 > - syncthing - 502 > I don't see any of those UIDs/GIDs being used in Gentoo, and I don't see any fixed UID/GID for those users/groups at the moment, so all good. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 0/6] User/group assignment: burp, rtkit, syncthing
On 6/26/19 6:35 AM, Marek Szuba wrote: > Here is the RFC for acct-* packages corresponding to users and groups > created by packages I currently maintain. This is also a request to > reserve the respective UIDs/GIDs, namely: > > Groups: > - burp - 501 > - rtkit - 133 And syncthing GID 502.
[gentoo-dev] [PATCH 6/6] acct-user/syncthing: Add 'syncthing' user (UID 502)
Signed-off-by: Marek Szuba --- acct-user/syncthing/metadata.xml | 8 acct-user/syncthing/syncthing-0.ebuild | 14 ++ 2 files changed, 22 insertions(+) create mode 100644 acct-user/syncthing/metadata.xml create mode 100644 acct-user/syncthing/syncthing-0.ebuild diff --git a/acct-user/syncthing/metadata.xml b/acct-user/syncthing/metadata.xml new file mode 100644 index 000..3e5026ee375 --- /dev/null +++ b/acct-user/syncthing/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + mare...@gentoo.org + Marek Szuba + + diff --git a/acct-user/syncthing/syncthing-0.ebuild b/acct-user/syncthing/syncthing-0.ebuild new file mode 100644 index 000..e9a04702f3d --- /dev/null +++ b/acct-user/syncthing/syncthing-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 system-wide net-p2p/syncthing server" +ACCT_USER_ID=502 +ACCT_USER_HOME=/var/lib/syncthing +ACCT_USER_HOME_PERMS=0770 +ACCT_USER_GROUPS=( syncthing ) + +acct-user_add_deps -- 2.21.0
[gentoo-dev] [PATCH 5/6] acct-user/rtkit: Add 'rtkit' user (UID 133)
Same UID as in Arch Linux. Signed-off-by: Marek Szuba --- acct-user/rtkit/metadata.xml | 8 acct-user/rtkit/rtkit-0.ebuild | 12 2 files changed, 20 insertions(+) create mode 100644 acct-user/rtkit/metadata.xml create mode 100644 acct-user/rtkit/rtkit-0.ebuild diff --git a/acct-user/rtkit/metadata.xml b/acct-user/rtkit/metadata.xml new file mode 100644 index 000..3e5026ee375 --- /dev/null +++ b/acct-user/rtkit/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + mare...@gentoo.org + Marek Szuba + + diff --git a/acct-user/rtkit/rtkit-0.ebuild b/acct-user/rtkit/rtkit-0.ebuild new file mode 100644 index 000..0e63e6514a1 --- /dev/null +++ b/acct-user/rtkit/rtkit-0.ebuild @@ -0,0 +1,12 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-user + +DESCRIPTION="User for the Realtime Policy and Watchdog Daemon" +ACCT_USER_ID=133 +ACCT_USER_GROUPS=( rtkit ) + +acct-user_add_deps -- 2.21.0
[gentoo-dev] [PATCH 1/6] acct-group/burp: Add 'burp' group (GID 501)
Signed-off-by: Marek Szuba --- acct-group/burp/burp-0.ebuild | 9 + acct-group/burp/metadata.xml | 8 2 files changed, 17 insertions(+) create mode 100644 acct-group/burp/burp-0.ebuild create mode 100644 acct-group/burp/metadata.xml diff --git a/acct-group/burp/burp-0.ebuild b/acct-group/burp/burp-0.ebuild new file mode 100644 index 000..ff29d3a2cd7 --- /dev/null +++ b/acct-group/burp/burp-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="Group for the app-backup/burp server" +ACCT_GROUP_ID=501 diff --git a/acct-group/burp/metadata.xml b/acct-group/burp/metadata.xml new file mode 100644 index 000..3e5026ee375 --- /dev/null +++ b/acct-group/burp/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + mare...@gentoo.org + Marek Szuba + + -- 2.21.0
[gentoo-dev] [PATCH 4/6] acct-user/burp: Add 'burp' user (UID 501)
Signed-off-by: Marek Szuba --- acct-user/burp/burp-0.ebuild | 12 acct-user/burp/metadata.xml | 8 2 files changed, 20 insertions(+) create mode 100644 acct-user/burp/burp-0.ebuild create mode 100644 acct-user/burp/metadata.xml diff --git a/acct-user/burp/burp-0.ebuild b/acct-user/burp/burp-0.ebuild new file mode 100644 index 000..660c98f57b9 --- /dev/null +++ b/acct-user/burp/burp-0.ebuild @@ -0,0 +1,12 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-user + +DESCRIPTION="User for the app-backup/burp server" +ACCT_USER_ID=501 +ACCT_USER_GROUPS=( burp ) + +acct-user_add_deps diff --git a/acct-user/burp/metadata.xml b/acct-user/burp/metadata.xml new file mode 100644 index 000..3e5026ee375 --- /dev/null +++ b/acct-user/burp/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + mare...@gentoo.org + Marek Szuba + + -- 2.21.0
[gentoo-dev] [PATCH 2/6] acct-group/rtkit: Add 'rtkit' group (GID 133)
Same GID as in Arch Linux. Signed-off-by: Marek Szuba --- acct-group/rtkit/metadata.xml | 8 acct-group/rtkit/rtkit-0.ebuild | 9 + 2 files changed, 17 insertions(+) create mode 100644 acct-group/rtkit/metadata.xml create mode 100644 acct-group/rtkit/rtkit-0.ebuild diff --git a/acct-group/rtkit/metadata.xml b/acct-group/rtkit/metadata.xml new file mode 100644 index 000..3e5026ee375 --- /dev/null +++ b/acct-group/rtkit/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + mare...@gentoo.org + Marek Szuba + + diff --git a/acct-group/rtkit/rtkit-0.ebuild b/acct-group/rtkit/rtkit-0.ebuild new file mode 100644 index 000..9361f86968b --- /dev/null +++ b/acct-group/rtkit/rtkit-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="Group for the Realtime Policy and Watchdog Daemon" +ACCT_GROUP_ID=133 -- 2.21.0
[gentoo-dev] [PATCH 3/6] acct-group/syncthing: Add 'syncthing' group (GID 502)
Signed-off-by: Marek Szuba --- acct-group/syncthing/metadata.xml | 8 acct-group/syncthing/syncthing-0.ebuild | 9 + 2 files changed, 17 insertions(+) create mode 100644 acct-group/syncthing/metadata.xml create mode 100644 acct-group/syncthing/syncthing-0.ebuild diff --git a/acct-group/syncthing/metadata.xml b/acct-group/syncthing/metadata.xml new file mode 100644 index 000..3e5026ee375 --- /dev/null +++ b/acct-group/syncthing/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + mare...@gentoo.org + Marek Szuba + + diff --git a/acct-group/syncthing/syncthing-0.ebuild b/acct-group/syncthing/syncthing-0.ebuild new file mode 100644 index 000..a015336764f --- /dev/null +++ b/acct-group/syncthing/syncthing-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="Group for the system-wide net-p2p/syncthing server" +ACCT_GROUP_ID=502 -- 2.21.0
[gentoo-dev] [PATCH 0/6] User/group assignment: burp, rtkit, syncthing
Here is the RFC for acct-* packages corresponding to users and groups created by packages I currently maintain. This is also a request to reserve the respective UIDs/GIDs, namely: Groups: - burp - 501 - rtkit - 133 Users: - burp - 501 - rtkit - 133 - syncthing - 502 rtkit user and group have got their IDs reserved in both Arch and Fedora, I have opted for consistency with the former.
