Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo

[Alec Warner]

On Sun, Nov 28, 2021 at 8:07 PM Michał Górny  wrote:
>
> On Sun, 2021-11-28 at 16:31 -0600, William Hubbs wrote:
> > All,
> >
> > I want to discuss why we ban -1 as the ACCT_USER_ID and ACCT_GROUP_ID 
> > setting
> > for all acct-user and acct-group packages in ::gentoo.
> >
> > Here are my thoughts about it.
> >
> > - As Gordon pointed out, it isn't necessary for us to care about UIDS/GIDS
> >   most of the time.
> >
> > - I realize that our settings are suggestions, but the values we can
> >   suggest are not infinite. We have run out once, and it is only a matter of
> >   time until we do again.
> >
> > - If an end user needs to care about the UID/GID, they can easily override
> >   the settings in make.conf.
> >
> > In short, I don't think we should be forcing maintainers to pick a
> > specific UID/GID for every package that needs a user/group. Most of the
> > time they can set ACCT_USER_ID and ACCT_GROUP_ID to -1.
> >
> > Thoughts? In particular, I want to hear from folks who disagree with me
> > about using -1 in the main tree for most packages.
> >
>
> Let me put this bluntly.  Yes, most users don't care.  However:
>
> 1) if we don't assign static UIDs/GIDs, the few users who care are gonna
> be in hell having to assign them all manually.  Every single one of
> them, on every one of their systems.

I think the challenge here for me is twofold:

 - I need some source of truth in gid / uids. Most places already have
one (some kind of identity provider.)
 - I need some way to distribute the truth to my machines. In industry
we use nsscache, or sssd, or ldap, or nis+, or yp, or samba, or you
hardcode uid / gids in our configuration management pipeline (ansible,
chef, puppet, our container build scripts!) For instance Gentoo Infra
does a mix of LDAP (our source of truth for uid / gid) and nsscache
(to distribute the uids and gids to machines) as well as hardcoded uid
/ gids (often for services.)

Many people have both of these already. They have some identity
provider (LDAP, AD, FreeIPA, a yaml file!) and they have some way of
getting those identities to their boxes. So when you say things like
"well these people have to do this manually" I struggle to really
understand who these people are; and how things like a yaml file +
ansible script is not sufficient to address this problem for them.
Syncing uid / gids across machines is a solved problem. Some of the
solutions (freeIPA, LDAP) are gross for home use; but ansible is
pretty lightweight, for example.

>
> 2) if we do assign static UIDs/GIDs... what's the problem, again?
> Little extra work for a few devs?

I think we are back to like "why do we care about the uid / gid ranges
at all?" and the answer is because many people have an existing
identity scheme and the gentoo scheme interacts poorly with it.

- If Gentoo adds an acct-user/foo user, and that user already exists
on my system with the wrong UID: the eclass dies[0].
- If Gentoo adds an acct-user/foo user, with uid=12345, and that uid
is assigned to a user on my system already, the eclass dies.
- Some environments are very old, and so real users have unexpected
uids; this includes Gentoo itself.
   - Gentoo (the community) used to allocate UIDs to devs in the
500-1000 range and we have 17 active developers with UIDs in that
range. So for example if we allocate one of these UIDs to an acct-*
package; that package will not be installable on woodpecker without
modification because those UIDs are already taken.
   - Other organizations are similarly encumbered with state; and
these systems do not interact well with the current defaults.

I'm looking for a documented way to say "hey I want dynamic allocation
on this machine; even in ::gentoo, because I have an existing scheme I
want to use." I want to do it in one place, and not have to set dozens
of package.env files, or copy ebuilds, or hack the eclasses. One idea
I had was some bashrc hacks to always set ACCT_USER_ID=-1 (and
ACCT_GROUP_ID=-1); as this might achieve that goal...but it would be
nicer to probably just set some accepted make.conf var.

-A

[0] Also there are just hilarious stories of weird names in industry.
We had one person who joined who got assigned the username 'lib' and
so their homedirectory was '/home/lib/'. All kinds of random crap
broke with that name and we had to bughunting in some apps...and we
reserved a bunch of similar names so they would not be taken. Or
another case: our uid allocator had a bug and we assigned a real
person the nobody uid; turns out NFS does not work well when you do
that.



>
> --
> Best regards,
> Michał Górny
>
>

Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo

[Sam James]

> On 29 Nov 2021, at 00:06, Michael Orlitzky  wrote:
> 
> On Sun, 2021-11-28 at 23:39 +, Sam James wrote:
>> 
>> Whissi and others raised some points that I think you may have some views on
>> (and I'm interested in hearing them).
>> 
> 
> I don't want to put words in his mouth, but I think Whissi takes issue
> with using the package manager to manage users, period. Not
> specifically with our use of a UID/GID hint.
> 
> I didn't respond to the first thread because I didn't want to pick a
> fight when the correct conclusion (IMO) was already reached. In the
> first thread I see only hypothetical problems raised (and a bunch of
> people who didn't realize the numbers are only a hint). If any of those
> problems are real and solved by allowing ACCT_USER_ID=-1 in ::gentoo,
> you'll have to point them out.
> 

Yeah, that seems like a fair interpretation (and matches my understanding).

I don't really see the problem with people who want manual administration
just setting the relevant variables in make.conf.

What I wish we had done (and there's still time to do, albeit belated --
it's still useful for the remaining big bits like Apache and nginx) is
write a news item explaining the implications and linked to a page
like https://wiki.gentoo.org/wiki/Practical_guide_to_the_GLEP_81_migration 

(which ConiKost created after we discussed how to inform users better)
that explains how to work around/express their preferences/give their own hints.

Sorry, I should've been explicit. The main thing I'd like to understand better
from your POV is:

this isn't new, but you're quite clear you feel that the UID/GID range 
limitations
are completely arbitrary and without merit(?).

Whissi essentially says the opposite: 
https://archives.gentoo.org/gentoo-dev/message/17a22877f5f18dae44a2f0859d807450 
.

I'd like to understand if this is just a result of beliefs about what the PM 
should/shouldn't do
or if there's genuine problems with continuing to extend the range?

I think I'd like to see sources on various UID ranges being hardcoded in places 
as
I suspect any such software may have dubious quality anyway, but that's on him,
not you.

It still seems like in terms of interoperability, there's little impact:
folks can force whatever UIDs/GIDs they want. It's not like the situation was
any better with dynamic allocation unless you installed in exactly the right 
order
(so some precise setup wasrequired in the past anyway, the difference is now you
explicitly state what you want if you need it).

Best,
sam


signature.asc
Description: Message signed with OpenPGP

Re: [gentoo-dev] [PATCH] go-module.eclass: Add GO_OPTIONAL flag

[Sam James]

> On 28 Nov 2021, at 19:23, Zac Medico  wrote:
> 
>> [snip]
> 
> How about if we also add a GO_DEPEND variable, so that eclasshi consumers can 
> do something like BDEPEND="go? ( ${GO_DEPEND} )" ?
> --

My preference is to go with what we've been doing more recently (do _OPTIONAL) 
so that
consumers handle things properly and we don't have to try account for various 
cases
(this was the problem with eclass variables which add a USE flag or depend only
if a USE flag is set).

But that said, I can't immediately think of any such annoying edge
cases with this idea. It'd be additional to GO_OPTIONAL and it'd
ensure a sane baseline Go version is chosen. So, why not?



signature.asc
Description: Message signed with OpenPGP

Re: [gentoo-dev] [PATCH] go-module.eclass: Add GO_OPTIONAL flag

[Alec Warner]

On Sun, Nov 28, 2021 at 11:52 AM William Hubbs  wrote:
>
> On Sun, Nov 28, 2021 at 11:23:16AM -0800, Zac Medico wrote:
> > On 11/21/21 02:57, Florian Schmaus wrote:
> > > Following the pattern found in other eclasses, add GO_OPTIONAL to the
> > > go-module eclass. This allows to inherit the eclass without pulling
> > > its dependencies. See, e.g., bug #775779 for the motivation.
> > >
> > > Signed-off-by: Florian Schmaus 
> > > ---
> > >   eclass/go-module.eclass | 31 ++-
> > >   1 file changed, 22 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
> > > index 3ad8542a28ae..c9eb90ac62ea 100644
> > > --- a/eclass/go-module.eclass
> > > +++ b/eclass/go-module.eclass
> > > @@ -1,4 +1,4 @@
> > > -# Copyright 2019-2020 Gentoo Authors
> > > +# Copyright 2019-2021 Gentoo Authors
> > >   # Distributed under the terms of the GNU General Public License v2
> > >
> > >   # @ECLASS: go-module.eclass
> > > @@ -55,13 +55,17 @@ if [[ -z ${_GO_MODULE} ]]; then
> > >
> > >   _GO_MODULE=1
> > >
> > > -BDEPEND=">=dev-lang/go-1.12"
> > > +if [[ ! ${GO_OPTIONAL} ]]; then
> > > +   BDEPEND=">=dev-lang/go-1.12"
> > >
> > > -# Workaround for pkgcheck false positive: 
> > > https://github.com/pkgcore/pkgcheck/issues/214
> > > -# MissingUnpackerDep: version ...: missing BDEPEND="app-arch/unzip"
> > > -# Added here rather than to each affected package, so it can be cleaned 
> > > up just
> > > -# once when pkgcheck is improved.
> > > -BDEPEND+=" app-arch/unzip"
> > > +   # Workaround for pkgcheck false positive: 
> > > https://github.com/pkgcore/pkgcheck/issues/214
> > > +   # MissingUnpackerDep: version ...: missing BDEPEND="app-arch/unzip"
> > > +   # Added here rather than to each affected package, so it can be 
> > > cleaned up just
> > > +   # once when pkgcheck is improved.
> > > +   BDEPEND+=" app-arch/unzip"
> > > +
> > > +   EXPORT_FUNCTIONS src_unpack
> > > +fi
> > >
> > >   # Force go to build in module mode.
> > >   # In this mode the GOPATH environment variable is ignored.
> > > @@ -83,8 +87,6 @@ QA_FLAGS_IGNORED='.*'
> > >   # Go packages should not be stripped with strip(1).
> > >   RESTRICT+=" strip"
> > >
> > > -EXPORT_FUNCTIONS src_unpack
> > > -
> > >   # @ECLASS-VARIABLE: EGO_SUM
> > >   # @DESCRIPTION:
> > >   # This is an array based on the go.sum content from inside the target 
> > > package.
> > > @@ -147,6 +149,17 @@ EXPORT_FUNCTIONS src_unpack
> > >   # directory structure.
> > >   declare -A -g _GOMODULE_GOSUM_REVERSE_MAP
> > >
> > > +# @ECLASS-VARIABLE: GO_OPTIONAL
> > > +# @DEFAULT_UNSET
> > > +# @PRE_INHERIT
> > > +# @DESCRIPTION:
> > > +# If set to a non-null value before inherit, then the Go part of the
> > > +# ebuild will be considered optional. No dependencies will be added and
> > > +# no phase functions will be exported.
> > > +#
> > > +# If you enable GO_OPTIONAL, you have to set BDEPEND on 
> > > >=dev-lang/go-1.12
> > > +# for your package and call go-module_src_unpack manually.
> > > +
> > >   # @FUNCTION: go-module_set_globals
> > >   # @DESCRIPTION:
> > >   # Convert the information in EGO_SUM for other usage in the ebuild.
> > >
> >
> > How about if we also add a GO_DEPEND variable, so that eclasshi
> > consumers can do something like BDEPEND="go? ( ${GO_DEPEND} )" ?
> > --
> > Thanks,
> > Zac
>
> this is on my radar. I haven't read the bug yet, but I'll look at it, if
> not today, sometime this week.
>
> Without looking at the bug, I'm not sure why you would want to use this
> eclass without depending on dev-lang/go.

I was going to say "just read the bug" but bugs have been misbehaving
recently, so I will summarize.

A package has an optional component that is golang based; users can
enable the component via a USE flag.
That component needs the go eclasses to build. While we can have USE
flag'd components, it's a QA violation to conditionally inherit an
eclass. This results in packages of this type needed to always inherit
the golang eclasses; even if the user has not enabled the golang
functionality.
The eclass always adds a dep on dev-lang/go
(https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/go-module.eclass)
This change let's ebuild callers control that golang dep; because it
should only be added when it's required, not on the eclass inherit.

You could also do other stuff (like not modify DEPEND in global scope
in the go eclasses), which is what Zac was suggesting. Many ways to
skin a cat and all that.

-A

>
> Also, if you have to write src_unpack you can call go-module_setup_proxy
> in src_unpack to set things up.
>
> William
>

Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo

[Michał Górny]

On Sun, 2021-11-28 at 16:31 -0600, William Hubbs wrote:
> All,
> 
> I want to discuss why we ban -1 as the ACCT_USER_ID and ACCT_GROUP_ID setting
> for all acct-user and acct-group packages in ::gentoo.
> 
> Here are my thoughts about it.
> 
> - As Gordon pointed out, it isn't necessary for us to care about UIDS/GIDS
>   most of the time.
> 
> - I realize that our settings are suggestions, but the values we can
>   suggest are not infinite. We have run out once, and it is only a matter of
>   time until we do again.
> 
> - If an end user needs to care about the UID/GID, they can easily override
>   the settings in make.conf.
> 
> In short, I don't think we should be forcing maintainers to pick a
> specific UID/GID for every package that needs a user/group. Most of the
> time they can set ACCT_USER_ID and ACCT_GROUP_ID to -1.
> 
> Thoughts? In particular, I want to hear from folks who disagree with me
> about using -1 in the main tree for most packages.
> 

Let me put this bluntly.  Yes, most users don't care.  However:

1) if we don't assign static UIDs/GIDs, the few users who care are gonna
be in hell having to assign them all manually.  Every single one of
them, on every one of their systems.

2) if we do assign static UIDs/GIDs... what's the problem, again? 
Little extra work for a few devs?

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Clang/LLVM profile

[Sam James]

> On 29 Nov 2021, at 01:45, 2b57 <2...@protonmail.com> wrote:
> 
> Sorry all, it seems that I've confused the lists. I'll forward this to user
> 
> ‐‐‐ Original Message ‐‐‐
> On Monday, November 29th, 2021 at 2:42 AM, 2b57 <2...@protonmail.com> wrote:
>> Hello all,
>> 
>> I'm in the middle of developing a proof-of-concept "native" Clang/LLVM 
>> profile – such, that stage3 built using this profile will not even contain 
>> GCC and binutils. Why? Well, because Clang is in pretty good shape lately, 
>> you can compile kernel and elfutils even. Also just for fun!
>> 
>> The approach I've decided to take is to create virtual/toolchain and 
>> virtual/binutils packages with RDEPEND attributes set to gcc || clang and 
>> binutils || llvm. I've reached a point where modifications to 
>> ::gentoo/scripts/bootstrap.sh are needed, and currently I've solved it with 
>> making an OverlayFS overlay, which combines both ::gentoo repo and my custom 
>> script. General idea is that once LLVM toolchain is in place (stage1), 
>> custom profile for stage2 masks gcc/binutils and virtuals get resolved by 
>> LLVM stuff. However, that is not the case; something goes wrong and it seems 
>> that binutils package is deeply embedded somewhere else...
>> 
>> Anyway, I'd appreciate any feedback and suggestions, since I'm sure I'm not 
>> the only one interested in this topic.
>> 
>> Grab the src here: https://github.com/2b57/toolchain-clang 
>> 
> 

Honestly, I think this is pretty on-topic for gentoo-dev given a lot of us are 
quite interested in this.

That said, a few notes:
- I'm not sure why you would need virtual/toolchain or virtual/binutils unless 
it's just for usage within bootstrapping scripts? Seems more like you could 
just remove gcc from @system and such?

- _personally_, I'd prefer to do experimentation using libstdc++ from GCC and 
try libcxx later on as a fair amount of things still fail to build with LLVM's 
libcxx. But that doesn't mean others have the same view
or that it's invalid to try! They're still bugs nonetheless.

Please do let us know via Bugzilla if there's some quirks we need to add to 
ebuilds.

We also have a group of us interested in using Clang in #gentoo-arm on 
libera.chat (IRC) -- the channel is not super restricted to ARM chat.

Best,
sam


signature.asc
Description: Message signed with OpenPGP

[gentoo-portage-dev] [PATCH] emerge: Default enable soname dependencies (bug 687956)

[Zac Medico]

Default emerge --ignore-soname-deps=n, in order to enable
soname dependencies by default. As always, soname dependencies
remain inapplicable in the absence of the --usepkgonly option
(or --getbinpkgonly). Therefore, this change only affects
commands that specify --usepkgonly or --getbinpkgonly.

Bug: https://bugs.gentoo.org/687956
Signed-off-by: Zac Medico 
---
 lib/_emerge/create_depgraph_params.py | 2 +-
 man/emerge.1  | 7 ---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/lib/_emerge/create_depgraph_params.py 
b/lib/_emerge/create_depgraph_params.py
index 11c3e3736..95c4c2035 100644
--- a/lib/_emerge/create_depgraph_params.py
+++ b/lib/_emerge/create_depgraph_params.py
@@ -104,7 +104,7 @@ def create_depgraph_params(myopts, myaction):
 if ignore_built_slot_operator_deps is not None:
 myparams["ignore_built_slot_operator_deps"] = 
ignore_built_slot_operator_deps
 
-myparams["ignore_soname_deps"] = myopts.get("--ignore-soname-deps", "y")
+myparams["ignore_soname_deps"] = myopts.get("--ignore-soname-deps", "n")
 
 dynamic_deps = myopts.get("--dynamic-deps", "y") != "n" and "--nodeps" not 
in myopts
 if dynamic_deps:
diff --git a/man/emerge.1 b/man/emerge.1
index 8f6d12925..ff565b46f 100644
--- a/man/emerge.1
+++ b/man/emerge.1
@@ -639,9 +639,10 @@ supported beginning with \fBEAPI 5\fR.
 .TP
 .BR "\-\-ignore\-soname\-deps < y | n >"
 Ignore the soname dependencies of binary and installed packages. This
-option is enabled by default, since soname dependencies are relatively
-new, and the required metadata is not guaranteed to exist for binary and
-installed packages built with older versions of portage. Also, soname
+option may be useful when working with binary or installed packages
+that lack appropriate soname dependency metadata because they were built
+with a package manager that does not support soname dependencies (perhaps
+an older version of portage). Soname
 dependencies will be automatically ignored for dependency calculations
 that can pull unbuilt ebuilds into the dependency graph, since unbuilt
 ebuilds do not have any soname dependency metadata, making it impossible
-- 
2.32.0

Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo

[Michael Orlitzky]

On Sun, 2021-11-28 at 23:39 +, Sam James wrote:
> 
> Whissi and others raised some points that I think you may have some views on
> (and I'm interested in hearing them).
> 

I don't want to put words in his mouth, but I think Whissi takes issue
with using the package manager to manage users, period. Not
specifically with our use of a UID/GID hint.

I didn't respond to the first thread because I didn't want to pick a
fight when the correct conclusion (IMO) was already reached. In the
first thread I see only hypothetical problems raised (and a bunch of
people who didn't realize the numbers are only a hint). If any of those
problems are real and solved by allowing ACCT_USER_ID=-1 in ::gentoo,
you'll have to point them out.

Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo

[Sam James]

> On 28 Nov 2021, at 23:26, Michael Orlitzky  wrote:
> [sinp]
> The only problem that anyone has put forth is one that does not exist.
> UIDs and GIDs are still assigned dynamically in Gentoo. The number you
> type in the ebuild is only a hint: it's the first number that will be
> tried during the dynamic assignment. There is no limit on the number of
> hints, and we will never run out because a conflict is never possible,
> because the damned things are assigned dynamically.
> 
> Is there an actual problem?
> 

Could you look at this thread?

https://archives.gentoo.org/gentoo-dev/message/5bad6853520e3ab182f6399a53198fec 


Whissi and others raised some points that I think you may have some views on
(and I'm interested in hearing them).

best,
sam


signature.asc
Description: Message signed with OpenPGP

Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo

[Michael Orlitzky]

On Sun, 2021-11-28 at 16:31 -0600, William Hubbs wrote:
> All,
> 
> I want to discuss why we ban -1 as the ACCT_USER_ID and ACCT_GROUP_ID setting
> for all acct-user and acct-group packages in ::gentoo.
> 
> Here are my thoughts about it.
> 
> - As Gordon pointed out, it isn't necessary for us to care about UIDS/GIDS
>   most of the time.

It's not for you. It's for end users. And you don't have to care about
them. Just pick any old number.


> - I realize that our settings are suggestions, but the values we can
>   suggest are not infinite. We have run out once, and it is only a matter of
>   time until we do again.

We did not run out. The council placed an arbitrary limit on them once,
and then had to raise their own arbitrary limit.

Nobody complaining about "running out" understands what the GLEP says.
If we ever hit 2^16 acct-group packages, feel free to reuse them, or
keep counting. Nothing bad will happen. The worst case scenario is
still better than if no hint was given at all.


> - If an end user needs to care about the UID/GID, they can easily override
>   the settings in make.conf.

The point of the feature is to encourage all new installs to have
consistent UIDs/GIDs by default, without user intervention. Your
suggestion does not solve the same problem, and requires more work to
not solve it.


> 
> Thoughts? In particular, I want to hear from folks who disagree with me
> about using -1 in the main tree for most packages.
> 

The only problem that anyone has put forth is one that does not exist.
UIDs and GIDs are still assigned dynamically in Gentoo. The number you
type in the ebuild is only a hint: it's the first number that will be
tried during the dynamic assignment. There is no limit on the number of
hints, and we will never run out because a conflict is never possible,
because the damned things are assigned dynamically.

Is there an actual problem?

[gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo

[William Hubbs]

All,

I want to discuss why we ban -1 as the ACCT_USER_ID and ACCT_GROUP_ID setting
for all acct-user and acct-group packages in ::gentoo.

Here are my thoughts about it.

- As Gordon pointed out, it isn't necessary for us to care about UIDS/GIDS
  most of the time.

- I realize that our settings are suggestions, but the values we can
  suggest are not infinite. We have run out once, and it is only a matter of
  time until we do again.

- If an end user needs to care about the UID/GID, they can easily override
  the settings in make.conf.

In short, I don't think we should be forcing maintainers to pick a
specific UID/GID for every package that needs a user/group. Most of the
time they can set ACCT_USER_ID and ACCT_GROUP_ID to -1.

Thoughts? In particular, I want to hear from folks who disagree with me
about using -1 in the main tree for most packages.

Thanks,

William



signature.asc
Description: PGP signature

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[William Hubbs]

On Sun, Nov 28, 2021 at 02:46:24PM -0600, William Hubbs wrote:
> On Sun, Nov 28, 2021 at 08:15:13PM +0100, Michał Górny wrote:
> > On Sun, 2021-11-28 at 13:06 -0600, William Hubbs wrote:
> > > On Sun, Nov 28, 2021 at 11:06:36AM +0100, Ulrich Mueller wrote:
> > > > > > > > > On Sun, 28 Nov 2021, William Hubbs wrote:
> > > > 
> > > > > On Mon, Nov 15, 2021 at 09:36:32AM +0300, Eray Aslan wrote:
> > > > > > 1/ Static allocation does not really solve a problem. Not really not
> > > > > > nowadays
> > > > > > 2/ We cant keep adding new IDs to a distribution as new software 
> > > > > > gets
> > > > > > added - one side is unbounded.  This is losing game.
> > > > 
> > > > Not sure. In practice, the number of packages is limited. (And if the
> > > > argument was valid, it would apply to dynamic alloction too.)
> > > > 
> > > > > > Switching back to dynamic allocation seems to be the best option.
> > > > 
> > > > > I realize I'm very late to this party, but +1 from me also.
> > > > 
> > > > > We should use dynamic uid/git assignment by default and maybe provide
> > > > > a way to force certain uids/gids to be constant if users want this.
> > > > 
> > > > While the rationale for static allocation that made it into GLEP 81 [1]
> > > > is rather weak, several people had argued in favour of it on the mailing
> > > > list [2].
> > > > 
> > > > In any case, let's cross that bridge when we reach it. For now, we're
> > > > good with 250 additional IDs.
> > > 
> > > It is inevitable that we will reach this bridge again -- whether or not
> > > it is in a month or a year, it will happen.
> > > 
> > > Why are we just kicking the can down the road instead of admitting that
> > > static allocation wasn't a good idea and going back to dynamic
> > > allocation? Let's find out what the people who argued for static
> > > allocation think.
> > > 
> > 
> > Why are you assuming that something "wasn't a good idea" just because
> > you think so?
> 
> ulm and others on the thread also mentioned the possibility of going
> back to dynamic allocation, so it isn't just me who brought it up.
> 
> I honestly am just looking for a discussion.
> 
> Do other distros statically allocate all of their system users? If not,
> why do we by default? I understand why enterprise users might need to,
> and they can with the glep 81 eclasses by setting uids/gids in
> make.conf, but is there a reason we force the issue at the distro level
> and ban -1 as the setting for ACCT_USER_ID and ACCT_GROUP_ID?
> 
> William
> 


Ok, based on floppym's response, I'm going to start a new thread.

William



signature.asc
Description: PGP signature

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[William Hubbs]

On Sun, Nov 28, 2021 at 02:42:23PM -0600, Gordon Pettey wrote:
> On Sun, Nov 28, 2021 at 2:27 PM William Hubbs  wrote:
> 
> > On Sun, Nov 28, 2021 at 02:57:39PM -0500, Michael Orlitzky wrote:
> > > We don't even do static allocation.
> 
> > There are a few exceptional cases where a user or group needs a
> > > specific identifier; but those were always statically allocated and
> > > nothing has changed in that regard.
> >
> > Doesn't the emerge fail if a different user with ACCT_USER_ID already
> > exists on
> > the system (unless ACCT_USER_ID is set to -1, which is forbidden by qa
> > policy)?
> >
> > If that's the case I don't see how we aren't doing static allocation.
> >
> 
> User PoV when I see a bunch of acct-* packages pop up in emerge @world
> updates:
> 
> A bunch of of acct-* ebuilds make claims for specific uid/gid for
> applications
> that don't have a reason I can think of to be requiring a specific number,
> and
> would never be used in a way (e.g. NFS-shared /etc) where the numeric
> value actually matters.

That's because qa mandates that any acct-group/acct-user packages in the
tree must claim a uid/gid.

Ultimately, we will run out of uids/gids to claim.

William



signature.asc
Description: PGP signature

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[William Hubbs]

On Sun, Nov 28, 2021 at 08:15:13PM +0100, Michał Górny wrote:
> On Sun, 2021-11-28 at 13:06 -0600, William Hubbs wrote:
> > On Sun, Nov 28, 2021 at 11:06:36AM +0100, Ulrich Mueller wrote:
> > > > > > > > On Sun, 28 Nov 2021, William Hubbs wrote:
> > > 
> > > > On Mon, Nov 15, 2021 at 09:36:32AM +0300, Eray Aslan wrote:
> > > > > 1/ Static allocation does not really solve a problem. Not really not
> > > > > nowadays
> > > > > 2/ We cant keep adding new IDs to a distribution as new software gets
> > > > > added - one side is unbounded.  This is losing game.
> > > 
> > > Not sure. In practice, the number of packages is limited. (And if the
> > > argument was valid, it would apply to dynamic alloction too.)
> > > 
> > > > > Switching back to dynamic allocation seems to be the best option.
> > > 
> > > > I realize I'm very late to this party, but +1 from me also.
> > > 
> > > > We should use dynamic uid/git assignment by default and maybe provide
> > > > a way to force certain uids/gids to be constant if users want this.
> > > 
> > > While the rationale for static allocation that made it into GLEP 81 [1]
> > > is rather weak, several people had argued in favour of it on the mailing
> > > list [2].
> > > 
> > > In any case, let's cross that bridge when we reach it. For now, we're
> > > good with 250 additional IDs.
> > 
> > It is inevitable that we will reach this bridge again -- whether or not
> > it is in a month or a year, it will happen.
> > 
> > Why are we just kicking the can down the road instead of admitting that
> > static allocation wasn't a good idea and going back to dynamic
> > allocation? Let's find out what the people who argued for static
> > allocation think.
> > 
> 
> Why are you assuming that something "wasn't a good idea" just because
> you think so?

ulm and others on the thread also mentioned the possibility of going
back to dynamic allocation, so it isn't just me who brought it up.

I honestly am just looking for a discussion.

Do other distros statically allocate all of their system users? If not,
why do we by default? I understand why enterprise users might need to,
and they can with the glep 81 eclasses by setting uids/gids in
make.conf, but is there a reason we force the issue at the distro level
and ban -1 as the setting for ACCT_USER_ID and ACCT_GROUP_ID?

William



signature.asc
Description: PGP signature

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Gordon Pettey]

On Sun, Nov 28, 2021 at 2:27 PM William Hubbs  wrote:

> On Sun, Nov 28, 2021 at 02:57:39PM -0500, Michael Orlitzky wrote:
> > We don't even do static allocation.

> There are a few exceptional cases where a user or group needs a
> > specific identifier; but those were always statically allocated and
> > nothing has changed in that regard.
>
> Doesn't the emerge fail if a different user with ACCT_USER_ID already
> exists on
> the system (unless ACCT_USER_ID is set to -1, which is forbidden by qa
> policy)?
>
> If that's the case I don't see how we aren't doing static allocation.
>

User PoV when I see a bunch of acct-* packages pop up in emerge @world
updates:

A bunch of of acct-* ebuilds make claims for specific uid/gid for
applications
that don't have a reason I can think of to be requiring a specific number,
and
would never be used in a way (e.g. NFS-shared /etc) where the numeric
value actually matters.

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Mike Gilbert]

On Sun, Nov 28, 2021 at 3:26 PM William Hubbs  wrote:
>
> On Sun, Nov 28, 2021 at 02:57:39PM -0500, Michael Orlitzky wrote:
> > On 2021-11-28 11:06:36, Ulrich Mueller wrote:
> > >
> > > While the rationale for static allocation that made it into GLEP 81 [1]
> > > is rather weak, several people had argued in favour of it on the mailing
> > > list [2].
> > >
> >
> > We don't even do static allocation. The UIDs and GIDs in the ebuilds
> > are suggestions, meant to benefit the people who will benefit from
> > them, and be ignored by everyone else.
> >
> > There are a few exceptional cases where a user or group needs a
> > specific identifier; but those were always statically allocated and
> > nothing has changed in that regard.
>
> Doesn't the emerge fail if a different user with ACCT_USER_ID already exists 
> on
> the system (unless ACCT_USER_ID is set to -1, which is forbidden by qa 
> policy)?

Not by default. If the eclass finds that ACCT_USER_ID is already
taken, it will allow useradd to assign a different one.

This behavior can be overridden by ebuilds (or a user) by setting
ACCT_USER_ENFORCE_ID.

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[William Hubbs]

On Sun, Nov 28, 2021 at 02:57:39PM -0500, Michael Orlitzky wrote:
> On 2021-11-28 11:06:36, Ulrich Mueller wrote:
> > 
> > While the rationale for static allocation that made it into GLEP 81 [1]
> > is rather weak, several people had argued in favour of it on the mailing
> > list [2].
> > 
> 
> We don't even do static allocation. The UIDs and GIDs in the ebuilds
> are suggestions, meant to benefit the people who will benefit from
> them, and be ignored by everyone else.
> 
> There are a few exceptional cases where a user or group needs a
> specific identifier; but those were always statically allocated and
> nothing has changed in that regard.

Doesn't the emerge fail if a different user with ACCT_USER_ID already exists on
the system (unless ACCT_USER_ID is set to -1, which is forbidden by qa policy)?

If that's the case I don't see how we aren't doing static allocation.

William



signature.asc
Description: PGP signature

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Michael Orlitzky]

On 2021-11-28 11:06:36, Ulrich Mueller wrote:
> 
> While the rationale for static allocation that made it into GLEP 81 [1]
> is rather weak, several people had argued in favour of it on the mailing
> list [2].
> 

We don't even do static allocation. The UIDs and GIDs in the ebuilds
are suggestions, meant to benefit the people who will benefit from
them, and be ignored by everyone else.

There are a few exceptional cases where a user or group needs a
specific identifier; but those were always statically allocated and
nothing has changed in that regard.

Re: [gentoo-dev] [PATCH] go-module.eclass: Add GO_OPTIONAL flag

[William Hubbs]

On Sun, Nov 28, 2021 at 11:23:16AM -0800, Zac Medico wrote:
> On 11/21/21 02:57, Florian Schmaus wrote:
> > Following the pattern found in other eclasses, add GO_OPTIONAL to the
> > go-module eclass. This allows to inherit the eclass without pulling
> > its dependencies. See, e.g., bug #775779 for the motivation.
> > 
> > Signed-off-by: Florian Schmaus 
> > ---
> >   eclass/go-module.eclass | 31 ++-
> >   1 file changed, 22 insertions(+), 9 deletions(-)
> > 
> > diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
> > index 3ad8542a28ae..c9eb90ac62ea 100644
> > --- a/eclass/go-module.eclass
> > +++ b/eclass/go-module.eclass
> > @@ -1,4 +1,4 @@
> > -# Copyright 2019-2020 Gentoo Authors
> > +# Copyright 2019-2021 Gentoo Authors
> >   # Distributed under the terms of the GNU General Public License v2
> >   
> >   # @ECLASS: go-module.eclass
> > @@ -55,13 +55,17 @@ if [[ -z ${_GO_MODULE} ]]; then
> >   
> >   _GO_MODULE=1
> >   
> > -BDEPEND=">=dev-lang/go-1.12"
> > +if [[ ! ${GO_OPTIONAL} ]]; then
> > +   BDEPEND=">=dev-lang/go-1.12"
> >   
> > -# Workaround for pkgcheck false positive: 
> > https://github.com/pkgcore/pkgcheck/issues/214
> > -# MissingUnpackerDep: version ...: missing BDEPEND="app-arch/unzip"
> > -# Added here rather than to each affected package, so it can be cleaned up 
> > just
> > -# once when pkgcheck is improved.
> > -BDEPEND+=" app-arch/unzip"
> > +   # Workaround for pkgcheck false positive: 
> > https://github.com/pkgcore/pkgcheck/issues/214
> > +   # MissingUnpackerDep: version ...: missing BDEPEND="app-arch/unzip"
> > +   # Added here rather than to each affected package, so it can be cleaned 
> > up just
> > +   # once when pkgcheck is improved.
> > +   BDEPEND+=" app-arch/unzip"
> > +
> > +   EXPORT_FUNCTIONS src_unpack
> > +fi
> >   
> >   # Force go to build in module mode.
> >   # In this mode the GOPATH environment variable is ignored.
> > @@ -83,8 +87,6 @@ QA_FLAGS_IGNORED='.*'
> >   # Go packages should not be stripped with strip(1).
> >   RESTRICT+=" strip"
> >   
> > -EXPORT_FUNCTIONS src_unpack
> > -
> >   # @ECLASS-VARIABLE: EGO_SUM
> >   # @DESCRIPTION:
> >   # This is an array based on the go.sum content from inside the target 
> > package.
> > @@ -147,6 +149,17 @@ EXPORT_FUNCTIONS src_unpack
> >   # directory structure.
> >   declare -A -g _GOMODULE_GOSUM_REVERSE_MAP
> >   
> > +# @ECLASS-VARIABLE: GO_OPTIONAL
> > +# @DEFAULT_UNSET
> > +# @PRE_INHERIT
> > +# @DESCRIPTION:
> > +# If set to a non-null value before inherit, then the Go part of the
> > +# ebuild will be considered optional. No dependencies will be added and
> > +# no phase functions will be exported.
> > +#
> > +# If you enable GO_OPTIONAL, you have to set BDEPEND on >=dev-lang/go-1.12
> > +# for your package and call go-module_src_unpack manually.
> > +
> >   # @FUNCTION: go-module_set_globals
> >   # @DESCRIPTION:
> >   # Convert the information in EGO_SUM for other usage in the ebuild.
> > 
> 
> How about if we also add a GO_DEPEND variable, so that eclasshi 
> consumers can do something like BDEPEND="go? ( ${GO_DEPEND} )" ?
> -- 
> Thanks,
> Zac

this is on my radar. I haven't read the bug yet, but I'll look at it, if
not today, sometime this week.

Without looking at the bug, I'm not sure why you would want to use this
eclass without depending on dev-lang/go.

Also, if you have to write src_unpack you can call go-module_setup_proxy
in src_unpack to set things up.

William



signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH] go-module.eclass: Add GO_OPTIONAL flag

[Zac Medico]

On 11/21/21 02:57, Florian Schmaus wrote:

Following the pattern found in other eclasses, add GO_OPTIONAL to the
go-module eclass. This allows to inherit the eclass without pulling
its dependencies. See, e.g., bug #775779 for the motivation.

Signed-off-by: Florian Schmaus 
---
  eclass/go-module.eclass | 31 ++-
  1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index 3ad8542a28ae..c9eb90ac62ea 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -1,4 +1,4 @@
-# Copyright 2019-2020 Gentoo Authors
+# Copyright 2019-2021 Gentoo Authors
  # Distributed under the terms of the GNU General Public License v2
  
  # @ECLASS: go-module.eclass

@@ -55,13 +55,17 @@ if [[ -z ${_GO_MODULE} ]]; then
  
  _GO_MODULE=1
  
-BDEPEND=">=dev-lang/go-1.12"

+if [[ ! ${GO_OPTIONAL} ]]; then
+   BDEPEND=">=dev-lang/go-1.12"
  
-# Workaround for pkgcheck false positive: https://github.com/pkgcore/pkgcheck/issues/214

-# MissingUnpackerDep: version ...: missing BDEPEND="app-arch/unzip"
-# Added here rather than to each affected package, so it can be cleaned up just
-# once when pkgcheck is improved.
-BDEPEND+=" app-arch/unzip"
+   # Workaround for pkgcheck false positive: 
https://github.com/pkgcore/pkgcheck/issues/214
+   # MissingUnpackerDep: version ...: missing BDEPEND="app-arch/unzip"
+   # Added here rather than to each affected package, so it can be cleaned 
up just
+   # once when pkgcheck is improved.
+   BDEPEND+=" app-arch/unzip"
+
+   EXPORT_FUNCTIONS src_unpack
+fi
  
  # Force go to build in module mode.

  # In this mode the GOPATH environment variable is ignored.
@@ -83,8 +87,6 @@ QA_FLAGS_IGNORED='.*'
  # Go packages should not be stripped with strip(1).
  RESTRICT+=" strip"
  
-EXPORT_FUNCTIONS src_unpack

-
  # @ECLASS-VARIABLE: EGO_SUM
  # @DESCRIPTION:
  # This is an array based on the go.sum content from inside the target package.
@@ -147,6 +149,17 @@ EXPORT_FUNCTIONS src_unpack
  # directory structure.
  declare -A -g _GOMODULE_GOSUM_REVERSE_MAP
  
+# @ECLASS-VARIABLE: GO_OPTIONAL

+# @DEFAULT_UNSET
+# @PRE_INHERIT
+# @DESCRIPTION:
+# If set to a non-null value before inherit, then the Go part of the
+# ebuild will be considered optional. No dependencies will be added and
+# no phase functions will be exported.
+#
+# If you enable GO_OPTIONAL, you have to set BDEPEND on >=dev-lang/go-1.12
+# for your package and call go-module_src_unpack manually.
+
  # @FUNCTION: go-module_set_globals
  # @DESCRIPTION:
  # Convert the information in EGO_SUM for other usage in the ebuild.



How about if we also add a GO_DEPEND variable, so that eclasshi 
consumers can do something like BDEPEND="go? ( ${GO_DEPEND} )" ?

--
Thanks,
Zac


OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Michał Górny]

On Sun, 2021-11-28 at 13:06 -0600, William Hubbs wrote:
> On Sun, Nov 28, 2021 at 11:06:36AM +0100, Ulrich Mueller wrote:
> > > > > > > On Sun, 28 Nov 2021, William Hubbs wrote:
> > 
> > > On Mon, Nov 15, 2021 at 09:36:32AM +0300, Eray Aslan wrote:
> > > > 1/ Static allocation does not really solve a problem. Not really not
> > > > nowadays
> > > > 2/ We cant keep adding new IDs to a distribution as new software gets
> > > > added - one side is unbounded.  This is losing game.
> > 
> > Not sure. In practice, the number of packages is limited. (And if the
> > argument was valid, it would apply to dynamic alloction too.)
> > 
> > > > Switching back to dynamic allocation seems to be the best option.
> > 
> > > I realize I'm very late to this party, but +1 from me also.
> > 
> > > We should use dynamic uid/git assignment by default and maybe provide
> > > a way to force certain uids/gids to be constant if users want this.
> > 
> > While the rationale for static allocation that made it into GLEP 81 [1]
> > is rather weak, several people had argued in favour of it on the mailing
> > list [2].
> > 
> > In any case, let's cross that bridge when we reach it. For now, we're
> > good with 250 additional IDs.
> 
> It is inevitable that we will reach this bridge again -- whether or not
> it is in a month or a year, it will happen.
> 
> Why are we just kicking the can down the road instead of admitting that
> static allocation wasn't a good idea and going back to dynamic
> allocation? Let's find out what the people who argued for static
> allocation think.
> 

Why are you assuming that something "wasn't a good idea" just because
you think so?

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[William Hubbs]

On Sun, Nov 28, 2021 at 11:06:36AM +0100, Ulrich Mueller wrote:
> > On Sun, 28 Nov 2021, William Hubbs wrote:
> 
> > On Mon, Nov 15, 2021 at 09:36:32AM +0300, Eray Aslan wrote:
> >> 1/ Static allocation does not really solve a problem. Not really not
> >> nowadays
> >> 2/ We cant keep adding new IDs to a distribution as new software gets
> >> added - one side is unbounded.  This is losing game.
> 
> Not sure. In practice, the number of packages is limited. (And if the
> argument was valid, it would apply to dynamic alloction too.)
> 
> >> Switching back to dynamic allocation seems to be the best option.
> 
> > I realize I'm very late to this party, but +1 from me also.
> 
> > We should use dynamic uid/git assignment by default and maybe provide
> > a way to force certain uids/gids to be constant if users want this.
> 
> While the rationale for static allocation that made it into GLEP 81 [1]
> is rather weak, several people had argued in favour of it on the mailing
> list [2].
> 
> In any case, let's cross that bridge when we reach it. For now, we're
> good with 250 additional IDs.

It is inevitable that we will reach this bridge again -- whether or not
it is in a month or a year, it will happen.

Why are we just kicking the can down the road instead of admitting that
static allocation wasn't a good idea and going back to dynamic
allocation? Let's find out what the people who argued for static
allocation think.

William


signature.asc
Description: PGP signature

[gentoo-dev] last-rite: some dev-java/*

[Miroslav Šulc]

# Volkmar W. Pogatzki  (2021-11-28)
# Libraries without consumers. Removal in 30 days.
dev-java/commons-pool
dev-java/dict4j
dev-java/felix-gogo-command
dev-java/jama
dev-java/janino
dev-java/jchardet
dev-java/jcommon
dev-java/jdynamite
dev-java/jfreesvg
dev-java/jgrapht
dev-java/jmdns
dev-java/jsr225
dev-java/jsr311-api
dev-java/jsr322
dev-java/jung
dev-java/mojarra
dev-java/neuroph
dev-java/ognl
dev-java/piccolo
dev-java/portletapi
dev-java/vldocking
dev-java/ws-commons-util
dev-java/xml-security
dev-java/xmpcore

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Ulrich Mueller]

> On Sun, 28 Nov 2021, William Hubbs wrote:

> On Mon, Nov 15, 2021 at 09:36:32AM +0300, Eray Aslan wrote:
>> 1/ Static allocation does not really solve a problem. Not really not
>> nowadays
>> 2/ We cant keep adding new IDs to a distribution as new software gets
>> added - one side is unbounded.  This is losing game.

Not sure. In practice, the number of packages is limited. (And if the
argument was valid, it would apply to dynamic alloction too.)

>> Switching back to dynamic allocation seems to be the best option.

> I realize I'm very late to this party, but +1 from me also.

> We should use dynamic uid/git assignment by default and maybe provide
> a way to force certain uids/gids to be constant if users want this.

While the rationale for static allocation that made it into GLEP 81 [1]
is rather weak, several people had argued in favour of it on the mailing
list [2].

In any case, let's cross that bridge when we reach it. For now, we're
good with 250 additional IDs.

Ulrich

[1] https://www.gentoo.org/glep/glep-0081.html#rationale
[2] 
https://archives.gentoo.org/gentoo-dev/message/33903763d46d193a25e4c03c4851bfc3


signature.asc
Description: PGP signature

[gentoo-dev] last-rite: dev-java/jss

[Miroslav Šulc]

# Volkmar W. Pogatzki  (2021-11-26)
# Library without consumers. Removal in 30 days.
dev-java/jss

[gentoo-dev] [PATCH 1/1] eclass/java-{utils-2,pkg-2,pkg-simple}: bump to eapi8

[Miroslav Šulc]

Signed-off-by: Miroslav Šulc 
---
 eclass/java-pkg-2.eclass  | 4 ++--
 eclass/java-pkg-simple.eclass | 4 ++--
 eclass/java-utils-2.eclass| 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/eclass/java-pkg-2.eclass b/eclass/java-pkg-2.eclass
index b0573eea4d0b..764aa95ba373 100644
--- a/eclass/java-pkg-2.eclass
+++ b/eclass/java-pkg-2.eclass
@@ -6,7 +6,7 @@
 # j...@gentoo.org
 # @AUTHOR:
 # Thomas Matthijs 
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 5 6 7 8
 # @PROVIDES: java-utils-2
 # @BLURB: Eclass for Java Packages
 # @DESCRIPTION:
@@ -14,7 +14,7 @@
 # need to use Java.
 
 case ${EAPI:-0} in
-   [567]) ;;
+   [5678]) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
 esac
 
diff --git a/eclass/java-pkg-simple.eclass b/eclass/java-pkg-simple.eclass
index fc006ff2fcc4..26dc06b1a6fa 100644
--- a/eclass/java-pkg-simple.eclass
+++ b/eclass/java-pkg-simple.eclass
@@ -6,7 +6,7 @@
 # j...@gentoo.org
 # @AUTHOR:
 # Java maintainers 
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 5 6 7 8
 # @BLURB: Eclass for packaging Java software with ease.
 # @DESCRIPTION:
 # This class is intended to build pure Java packages from Java sources
@@ -17,7 +17,7 @@
 # directory before calling the src_compile function of this eclass.
 
 case ${EAPI:-0} in
-   [567]) ;;
+   [5678]) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
 esac
 
diff --git a/eclass/java-utils-2.eclass b/eclass/java-utils-2.eclass
index 2c93cbdf0eeb..050a5c4847a6 100644
--- a/eclass/java-utils-2.eclass
+++ b/eclass/java-utils-2.eclass
@@ -6,7 +6,7 @@
 # j...@gentoo.org
 # @AUTHOR:
 # Thomas Matthijs , Karl Trygve Kalleberg 
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 5 6 7 8
 # @BLURB: Base eclass for Java packages
 # @DESCRIPTION:
 # This eclass provides functionality which is used by java-pkg-2.eclass,
@@ -18,7 +18,7 @@
 # Ant-based packages.
 
 case ${EAPI:-0} in
-   [567]) ;;
+   [5678]) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
 esac
 
-- 
2.34.1

[gentoo-dev] [PATCH 0/1] support for eapi8 in java-pkg-simple.eclass and the eclasses in the chain

[Miroslav Šulc]

hi devs,

here is a part eapi8 support for java, in this case java-pkg-simple.eclas and 
all the eclasses in the chain. i will continue on the other eclasses once this 
gets merged.

i did test these eclasses on several java packages and all seems fine.

any comments or improvements are welcome.

fordfrog

Miroslav Šulc (1):
  eclass/java-{utils-2,pkg-2,pkg-simple}: bump to eapi8

 eclass/java-pkg-2.eclass  | 4 ++--
 eclass/java-pkg-simple.eclass | 4 ++--
 eclass/java-utils-2.eclass| 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

-- 
2.34.1