[gentoo-dev] Last rites: games-util/higan-purify dev-games/higan-ananke
# Ionen Wolkens (2022-01-03) # Obsolete, higan-purify is now provided by games-emulation/higan # as the icarus utility (bug #821121) and dev-games/higan-ananke # has no known uses without higan-purify (bug #821124). Further # stuck on gtk2 with dead HOMEPAGE / SRC_URI. # Removal after 2022-02-02. games-util/higan-purify dev-games/higan-ananke signature.asc Description: PGP signature
Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.
On Sat, Jan 1, 2022 at 2:22 PM Piotr Karbowski wrote: > > Hi, > > I'd like to get some insight how others see the concept of narrowing the > scope of USE flags in Gentoo. > > Taking a quote from devmanual: > >> USE flags are to control optional dependencies and settings which > the user may reasonably want to select. > > I'd like to focus on the 'reasonably want' here. While it is commonly > agreed on that we interface as USE flags only things that make sense to > be togglable, it is not always the case. It is not uncommon to see > packages that puts every possible option as USE flag which hardly > benefit anyone in some cases. > > It creates artificial choice of USE flag that makes as much sense as > building and trying to use solar-powered night vision googles. Possible > to be engineered, but makes absolute no sense to exist, yet, there will > be someone who will go with it and then things will not work in desired > way, bugs will be reported, effort will be wasted on investigation and > patching things up. > > As example I'd like to use 'ipv6' USE flag, at the moment of writing > this email there's 351 ebuilds in tree that expose ipv6 as USE flag, > allow it to be disabled. > > The thing is, it's 2022, and it does not make any sense to *not* support > IPv6, even if one does not connect to any network with IPv6, there's no > harm to just have it there. > > While I am all for choice, I am for choice on things that do make sense. > For instance, Linux kernel can be built with CONFIG_MULTIUSER=n, someone > could argue that since Linux kernel, that is user-configured in Gentoo, > can be built without support for other than UID 0, then Gentoo should > support it. One of the extreme examples of not supporting something that > does not make sense to be supported. > > Beside 'ipv6', there are other USE flags that I have on mind. 'pam' > being another of them. > > Whats your view on it? I'm trying to understand your principles here. Like on what basis do you remove or add flags (in general). I want to remove: - bash-completion - acl - ldap - policykit - readline - sound (Part of this is just to have a meta discussion so we settle on some driving principles on why we keep one flag over the other.) I can easily craft a narrative for getting rid of ipv6, for example, but I cannot really craft a good narrative for getting rid of pam, or policykit, or ldap as flags. So why do we keep some and remove others? -A > > -- Piotr. >
[gentoo-dev] [PATCH v3] kernel-2.eclass: Respect portage toolchain variables
Starting with kernel>=v5.7 the build system can override the
tools vars by setting LLVM=1 [1], but older kernels still use
the default GNU tools, so to be able to use a full LLVM/Clang
build, CC & co should be set to their respective portage values.
[1] a0d1c951ef08 kbuild: support LLVM=1 to switch the default tools to
Clang/LLVM
Co-authored-by: Manoj Gupta
Signed-off-by: Adrian Ratiu
---
Changes in v3:
- Add rest of vars used by kernel builds (suggested by James)
- Minor commit msg rewording
Changes in v2:
- Set AR variable which is also required for linux-headers
- Reword msg for clarity
---
eclass/kernel-2.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index adc1425bc2e..865c43d3153 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -692,7 +692,7 @@ env_setup_xmakeopts() {
elif type -p ${CHOST}-ar >/dev/null; then
xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-"
fi
- xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC)"
+ xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC) CC=$(tc-getCC)
LD=$(tc-getLD) AR=$(tc-getAR) NM=$(tc-getNM) NM=$(tc-getNM)
OBOBJCOPY=$(tc-getOBJCOPY) READELF=$(tc-getREADELF) STRIP=$(tc-getSTRIP)"
export xmakeopts
}
--
2.34.1
Re: [gentoo-dev] [PATCH v3] kernel-2.eclass: Respect portage toolchain variables
On Mon, Jan 3, 2022 at 12:49 PM Adrian Ratiu wrote:
>
> Starting with kernel>=v5.7 the build system can override the
> tools vars by setting LLVM=1 [1], but older kernels still use
> the default GNU tools, so to be able to use a full LLVM/Clang
> build, CC & co should be set to their respective portage values.
>
> [1] a0d1c951ef08 kbuild: support LLVM=1 to switch the default tools to
> Clang/LLVM
>
> Co-authored-by: Manoj Gupta
> Signed-off-by: Adrian Ratiu
> ---
> Changes in v3:
> - Add rest of vars used by kernel builds (suggested by James)
> - Minor commit msg rewording
>
> Changes in v2:
> - Set AR variable which is also required for linux-headers
> - Reword msg for clarity
> ---
> eclass/kernel-2.eclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> index adc1425bc2e..865c43d3153 100644
> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -692,7 +692,7 @@ env_setup_xmakeopts() {
> elif type -p ${CHOST}-ar >/dev/null; then
> xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-"
> fi
> - xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC)"
> + xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC) CC=$(tc-getCC)
> LD=$(tc-getLD) AR=$(tc-getAR) NM=$(tc-getNM) NM=$(tc-getNM)
> OBOBJCOPY=$(tc-getOBJCOPY) READELF=$(tc-getREADELF) STRIP=$(tc-getSTRIP)"
> export xmakeopts
> }
This seems ok to me, at least given the way the eclass currently works.
At some point, we should really convert xmakeopts into an array. Any
of these variables might contain spaces, and that would break the
current implementation.
Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.
On Mon, Jan 3, 2022 at 12:16 PM Alec Warner wrote: > > On Sat, Jan 1, 2022 at 2:22 PM Piotr Karbowski wrote: > > > > Hi, > > > > I'd like to get some insight how others see the concept of narrowing the > > scope of USE flags in Gentoo. > > > > Taking a quote from devmanual: > > > >> USE flags are to control optional dependencies and settings which > > the user may reasonably want to select. > > > > I'd like to focus on the 'reasonably want' here. While it is commonly > > agreed on that we interface as USE flags only things that make sense to > > be togglable, it is not always the case. It is not uncommon to see > > packages that puts every possible option as USE flag which hardly > > benefit anyone in some cases. > > > > It creates artificial choice of USE flag that makes as much sense as > > building and trying to use solar-powered night vision googles. Possible > > to be engineered, but makes absolute no sense to exist, yet, there will > > be someone who will go with it and then things will not work in desired > > way, bugs will be reported, effort will be wasted on investigation and > > patching things up. > > > > As example I'd like to use 'ipv6' USE flag, at the moment of writing > > this email there's 351 ebuilds in tree that expose ipv6 as USE flag, > > allow it to be disabled. > > > > The thing is, it's 2022, and it does not make any sense to *not* support > > IPv6, even if one does not connect to any network with IPv6, there's no > > harm to just have it there. > > > > While I am all for choice, I am for choice on things that do make sense. > > For instance, Linux kernel can be built with CONFIG_MULTIUSER=n, someone > > could argue that since Linux kernel, that is user-configured in Gentoo, > > can be built without support for other than UID 0, then Gentoo should > > support it. One of the extreme examples of not supporting something that > > does not make sense to be supported. > > > > Beside 'ipv6', there are other USE flags that I have on mind. 'pam' > > being another of them. > > > > Whats your view on it? > > I'm trying to understand your principles here. Like on what basis do > you remove or add flags (in general). > > I want to remove: > - bash-completion > - acl > - ldap > - policykit > - readline > - sound > > (Part of this is just to have a meta discussion so we settle on some > driving principles on why we keep one flag over the other.) > > I can easily craft a narrative for getting rid of ipv6, for example, > but I cannot really craft a good narrative for getting rid of pam, or > policykit, or ldap as flags. So why do we keep some and remove others? The devmanual has a section on this topic: https://devmanual.gentoo.org/general-concepts/use-flags/index.html#when-not-to-use-use-flags Personally, I use the following principles: Is there an optional build time dependency, and is the package still useful without said dependency? If so, a USE flag is warranted. Is there some optional feature/behavior that can only be toggled at build time? If so, a USE flag is probably warranted. Is there some optional feature/behavior that can be toggled at run time (via config)? Does disabling it at build time have a minimal effect on the installed size? If so, I will NOT add a USE flag.
Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.
Hi, On 03/01/2022 18.16, Alec Warner wrote: I'm trying to understand your principles here. Like on what basis do you remove or add flags (in general). My principals is to end-user experience over exposing as much as possible as USE flags. A real life example media-sound/deadbeef The .mp3 support can either use libmad or libmpg123. The first one is dead upstream, while code work currently with it, because it is dead, I rather avoid some setups where users setup +mad instead of +mpg123 that are mutually exclusive and run into some issues, like crashes, that would waste a lot of time on debugging it, so I made it that mp3 depends on libmpg123 without option for libmad. Some overlay-provided ebuilds for it do have option for libmad, I decided to not include it. If you'd decide to give user a choice, you would make it as USE flag, but from end-user perspective it does not provide any benefit, and from maintainer perspective it's better to reduce error surface. Perhaps the 'pam' example was extreme, but ipv6, or threads as Sam shared, does not make sense to be togglable. -- Piotr
Re: [gentoo-dev] [PATCH] readme.gentoo-r1.eclass: Document the DOC_CONTENTS variable
El sáb, 01-01-2022 a las 12:04 +0100, Ulrich Müller escribió:
> This fixes a spurious "UnusedInherits" warning from pkgcheck.
>
> Signed-off-by: Ulrich Müller
> ---
> eclass/readme.gentoo-r1.eclass | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/eclass/readme.gentoo-r1.eclass b/eclass/readme.gentoo-r1.eclass
> index 3ad36fac2588..0d302179127b 100644
> --- a/eclass/readme.gentoo-r1.eclass
> +++ b/eclass/readme.gentoo-r1.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2021 Gentoo Authors
> +# Copyright 1999-2022 Gentoo Authors
> # Distributed under the terms of the GNU General Public License v2
>
> # @ECLASS: readme.gentoo-r1.eclass
> @@ -25,6 +25,11 @@ case ${EAPI} in
> *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
> esac
>
> +# @ECLASS-VARIABLE: DOC_CONTENTS
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# The information that is used to create the README.gentoo file.
> +
> # @ECLASS-VARIABLE: DISABLE_AUTOFORMATTING
> # @DEFAULT_UNSET
> # @DESCRIPTION:
LGTM
Thanks!
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Up for grabs: media-tv/plex-media-server
I'm not exactly sure what's involved but I'll offer help where I can. I have a personal overlay that includes pms. Steve On 01/01/2022 21:13, Wolfgang E. Sanyer wrote: If no one's interested in this I can take a look at it as proxy maint, I like pms El dom, 26 de dic. de 2021 12:19 a. m., Sam James escribió: media-tv/plex-media-server is up for grabs as the result of a proxied maintainer retiring. It's a popular package. There are some active overlays with Plex in them, it'd be nice to pull in their work / approach their authors and ask if they'd be willing to share their work in ::gentoo. Best, sam
Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.
On Mon, 2022-01-03 at 21:29 +0100, Piotr Karbowski wrote: > > Perhaps the 'pam' example was extreme, but ipv6, or threads as Sam > shared, does not make sense to be togglable. > Many packages need their ipv6 code disabled if the kernel has no ipv6 support, and enabling ipv6 in the kernel is a pointless security risk for pretty much anyone in the United States.
Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.
On Mon, Jan 3, 2022 at 4:29 PM Michael Orlitzky wrote: > > On Mon, 2022-01-03 at 21:29 +0100, Piotr Karbowski wrote: > > > > Perhaps the 'pam' example was extreme, but ipv6, or threads as Sam > > shared, does not make sense to be togglable. > > > > Many packages need their ipv6 code disabled if the kernel has no ipv6 > support, and enabling ipv6 in the kernel is a pointless security risk > for pretty much anyone in the United States. https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption Go troll somewhere else? -A > > >
Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.
On Mon, 2022-01-03 at 16:51 -0800, Alec Warner wrote: > > > > > > Many packages need their ipv6 code disabled if the kernel has no ipv6 > > support, and enabling ipv6 in the kernel is a pointless security risk > > for pretty much anyone in the United States. > > https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption > > Go troll somewhere else? > Anyway, leave the USE flag please.
Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.
> On 4 Jan 2022, at 00:29, Michael Orlitzky wrote: > > On Mon, 2022-01-03 at 21:29 +0100, Piotr Karbowski wrote: >> >> Perhaps the 'pam' example was extreme, but ipv6, or threads as Sam >> shared, does not make sense to be togglable. >> > > Many packages need their ipv6 code disabled if the kernel has no ipv6 > support, and enabling ipv6 in the kernel is a pointless security risk > for pretty much anyone in the United States. > Obviously for such cases, the flag should be kept. But that's not the case for plenty of packages. Best, sam signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.
> On 3 Jan 2022, at 17:16, Alec Warner wrote:
>> [snip]
>
> I'm trying to understand your principles here. Like on what basis do
> you remove or add flags (in general).
>
> I want to remove:
> - bash-completion
FWIW, I've managed to remove basically all instances of {bash,zsh}-completion
and made upstream PRs (all of one of which have been merged!) for fixing
`./configure` behaviour accordingly.
This is in align with our small files policy:
https://projects.gentoo.org/qa/policy-guide/installed-files.html#pg0301
.
> - acl
> - ldap
ACL is kind of similar to what Ionen said for PAM, i.e. sometimes
people may want to turn it off and it makes sense to expose
this option for those who do, but we don't need to try support it.
I think some of this kind of comes back to "how do we better
make clear what is/isn't okay (supported)to customise?"
LDAP is a fun one because IIRC we had it enabled by default
for too long and it didn't really break anything when we turned
It off.
Overall, I think we kind of come back to this idea of
trying to just set better IUSE defaults rather than
in profiles, so that it's per-package where possible.
> - policykit
This is a reasonable flag to keep given the heavy polkit
dependency of spidermonkey (for now) and it's somewhat
heavy-handed as a concept anyway.
> - readline
readline is a tricky one because of its relation with libedit too.
> - sound
>
> (Part of this is just to have a meta discussion so we settle on some
> driving principles on why we keep one flag over the other.)
>
> I can easily craft a narrative for getting rid of ipv6, for example,
> but I cannot really craft a good narrative for getting rid of pam, or
> policykit, or ldap as flags. So why do we keep some and remove others?
>
>
It's very hard to quantify :(
Best,
sam
signature.asc
Description: Message signed with OpenPGP
Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.
On Tue, 2022-01-04 at 03:38 +, Sam James wrote: > > ACL is kind of similar to what Ionen said for PAM, i.e. sometimes > people may want to turn it off and it makes sense to expose > this option for those who do, but we don't need to try support it. > This is another important one. It has security implications, is highly confusing, requires kernel support, and is nonstandard as a USE flag and as an implementation. Most people should have it off to avoid surprises, but disabling it in the kernel can make the userland software complain when explicitly built with ACL support.
Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.
On Mon, Jan 3, 2022 at 7:39 PM Sam James wrote:
>
>
>
> On 3 Jan 2022, at 17:16, Alec Warner wrote:
>
> [snip]
>
>
> I'm trying to understand your principles here. Like on what basis do
> you remove or add flags (in general).
>
> I want to remove:
> - bash-completion
>
>
> FWIW, I've managed to remove basically all instances of {bash,zsh}-completion
> and made upstream PRs (all of one of which have been merged!) for fixing
> `./configure` behaviour accordingly.
>
> This is in align with our small files policy:
> https://projects.gentoo.org/qa/policy-guide/installed-files.html#pg0301.
>
> - acl
> - ldap
>
>
> ACL is kind of similar to what Ionen said for PAM, i.e. sometimes
> people may want to turn it off and it makes sense to expose
> this option for those who do, but we don't need to try support it.
I feel like 'acl' or 'pam' or 'policykit' are not really USE flags in
the general sense. They are more like profile settings. You don't want
to toggle these flags, you want to switch profiles. I think
conceptually profile migrations are larger changes that require a
rebuild of a bunch of stuff, and typically have downtime (e.g. where
your system isn't expected to work the entire time.)
There are practical problems with profile proliferation, but I think
it is closer to what these flags represent, if that makes sense.
-A
>
> I think some of this kind of comes back to "how do we better
> make clear what is/isn't okay (supported)to customise?"
>
> LDAP is a fun one because IIRC we had it enabled by default
> for too long and it didn't really break anything when we turned
> It off.
>
> Overall, I think we kind of come back to this idea of
> trying to just set better IUSE defaults rather than
> in profiles, so that it's per-package where possible.
>
> - policykit
>
>
> This is a reasonable flag to keep given the heavy polkit
> dependency of spidermonkey (for now) and it's somewhat
> heavy-handed as a concept anyway.
>
> - readline
>
>
> readline is a tricky one because of its relation with libedit too.
>
> - sound
>
> (Part of this is just to have a meta discussion so we settle on some
> driving principles on why we keep one flag over the other.)
>
> I can easily craft a narrative for getting rid of ipv6, for example,
> but I cannot really craft a good narrative for getting rid of pam, or
> policykit, or ldap as flags. So why do we keep some and remove others?
>
>
>
> It's very hard to quantify :(
>
>
> Best,
> sam
>
