[gentoo-dev] [PATCH 2/2] EXAMPLE, NOMERGE sys-kernel/gentoo-kernel: use ppc_pagesize expand

[Georgy Yakovlev]

Signed-off-by: Georgy Yakovlev 
---
 .../gentoo-kernel/gentoo-kernel-5.15.11.ebuild | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/sys-kernel/gentoo-kernel/gentoo-kernel-5.15.11.ebuild 
b/sys-kernel/gentoo-kernel/gentoo-kernel-5.15.11.ebuild
index e4ac32a7019..05ae8331c84 100644
--- a/sys-kernel/gentoo-kernel/gentoo-kernel-5.15.11.ebuild
+++ b/sys-kernel/gentoo-kernel/gentoo-kernel-5.15.11.ebuild
@@ -1,123 +1,135 @@
-# Copyright 2020-2021 Gentoo Authors
+# Copyright 2020-2022 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=7
 
 inherit kernel-build toolchain-funcs
 
 MY_P=linux-${PV%.*}
 GENPATCHES_P=genpatches-${PV%.*}-$(( ${PV##*.} + 2 ))
 CONFIG_VER=5.15.10
 CONFIG_HASH=4882b85cc85fb2b7df396c4d671cc6432596eca0
 GENTOO_CONFIG_VER=5.15.5
 
 DESCRIPTION="Linux kernel built with Gentoo patches"
 HOMEPAGE="https://www.kernel.org/;
 SRC_URI+=" https://cdn.kernel.org/pub/linux/kernel/v$(ver_cut 
1).x/${MY_P}.tar.xz

https://dev.gentoo.org/~mpagano/dist/genpatches/${GENPATCHES_P}.base.tar.xz

https://dev.gentoo.org/~mpagano/dist/genpatches/${GENPATCHES_P}.extras.tar.xz

https://github.com/mgorny/gentoo-kernel-config/archive/v${GENTOO_CONFIG_VER}.tar.gz
-> gentoo-kernel-config-${GENTOO_CONFIG_VER}.tar.gz
amd64? (

https://src.fedoraproject.org/rpms/kernel/raw/${CONFIG_HASH}/f/kernel-x86_64-fedora.config
-> kernel-x86_64-fedora.config.${CONFIG_VER}
)
arm64? (

https://src.fedoraproject.org/rpms/kernel/raw/${CONFIG_HASH}/f/kernel-aarch64-fedora.config
-> kernel-aarch64-fedora.config.${CONFIG_VER}
)
ppc64? (

https://src.fedoraproject.org/rpms/kernel/raw/${CONFIG_HASH}/f/kernel-ppc64le-fedora.config
-> kernel-ppc64le-fedora.config.${CONFIG_VER}
)
x86? (

https://src.fedoraproject.org/rpms/kernel/raw/${CONFIG_HASH}/f/kernel-i686-fedora.config
-> kernel-i686-fedora.config.${CONFIG_VER}
)"
 S=${WORKDIR}/${MY_P}
 
 LICENSE="GPL-2"
 KEYWORDS="amd64 ~arm arm64 ~ppc ppc64 ~x86"
-IUSE="debug hardened"
-REQUIRED_USE="arm? ( savedconfig )"
+IUSE="debug hardened ppc_pagesize_4K +ppc_pagesize_64K"
+REQUIRED_USE="
+   arm? ( savedconfig )
+   ppc64? ( ^^ ( ppc_pagesize_4K ppc_pagesize_64K ) )
+"
 
 RDEPEND="
!sys-kernel/gentoo-kernel-bin:${SLOT}"
 BDEPEND="
debug? ( dev-util/pahole )"
 PDEPEND="
>=virtual/dist-kernel-${PV}"
 
 QA_FLAGS_IGNORED="
usr/src/linux-.*/scripts/gcc-plugins/.*.so
usr/src/linux-.*/vmlinux
usr/src/linux-.*/arch/powerpc/kernel/vdso.*/vdso.*.so.dbg
 "
 
 src_prepare() {
local PATCHES=(
# meh, genpatches have no directory
"${WORKDIR}"/*.patch
)
default
 
local biendian=false
 
# prepare the default config
case ${ARCH} in
amd64)
cp 
"${DISTDIR}/kernel-x86_64-fedora.config.${CONFIG_VER}" .config || die
;;
arm)
return
;;
arm64)
cp 
"${DISTDIR}/kernel-aarch64-fedora.config.${CONFIG_VER}" .config || die
biendian=true
;;
ppc)
# assume powermac/powerbook defconfig
# we still package.use.force savedconfig
cp 
"${WORKDIR}/${MY_P}/arch/powerpc/configs/pmac32_defconfig" .config || die
;;
ppc64)
cp 
"${DISTDIR}/kernel-ppc64le-fedora.config.${CONFIG_VER}" .config || die
biendian=true
;;
x86)
cp "${DISTDIR}/kernel-i686-fedora.config.${CONFIG_VER}" 
.config || die
;;
*)
die "Unsupported arch ${ARCH}"
;;
esac
 
local myversion="-gentoo-dist"
use hardened && myversion+="-hardened"
echo "CONFIG_LOCALVERSION=\"${myversion}\"" > "${T}"/version.config || 
die
local 
dist_conf_path="${WORKDIR}/gentoo-kernel-config-${GENTOO_CONFIG_VER}"
 
local merge_configs=(
"${T}"/version.config
"${dist_conf_path}"/base.config
)
use debug || merge_configs+=(
"${dist_conf_path}"/no-debug.config
)
if use hardened; then
merge_configs+=( "${dist_conf_path}"/hardened-base.config )
 
tc-is-gcc && merge_configs+=( 
"${dist_conf_path}"/hardened-gcc-plugins.config )
 
if [[ -f "${dist_conf_path}/hardened-${ARCH}.config" ]]; then
merge_configs+=( 

[gentoo-dev] [PATCH 1/2] profiles: add PPC_PAGESIZE use expand

[Georgy Yakovlev]

Hardware can use either size, it's a built time option.
64K is standard and is what we use by default and 99% of distros use.
4K is more compatible with desktop applications and GPU drivers,
which often assume 4K page size.

Problem from switching page sizes on reboot:
btrfs and swaps break, other filesystems like ext4 may become
unmountable, sepending on direction of switch 4K <-> 64K.

Our installcd provides both kernel options, so users can choose which
one to boot.

Planned consumers of this flag:
sys-kernel/gentoo-kernel
sys-kernel/gentoo-kernel-bin ( in the future )
sys-kernel/vanilla-kernel
dev-util/google-perftools

any other application that has a build time switch to optimize for or
set page size.
Also can be used by applications that are known to be broken with
specific page size.
Mesa and amdgpu drivers used to have some problems in the past, but it
was fixed, however broken apps still exist.

Signed-off-by: Georgy Yakovlev 
---
 profiles/arch/powerpc/ppc64/make.defaults | 6 +-
 profiles/base/make.defaults   | 4 ++--
 profiles/desc/ppc_pagesize.desc   | 5 +
 profiles/embedded/make.defaults   | 4 ++--
 4 files changed, 14 insertions(+), 5 deletions(-)
 create mode 100644 profiles/desc/ppc_pagesize.desc

diff --git a/profiles/arch/powerpc/ppc64/make.defaults 
b/profiles/arch/powerpc/ppc64/make.defaults
index ff2526a2530..6555ec277b7 100644
--- a/profiles/arch/powerpc/ppc64/make.defaults
+++ b/profiles/arch/powerpc/ppc64/make.defaults
@@ -1,41 +1,45 @@
-# Copyright 1999-2021 Gentoo Authors
+# Copyright 1999-2022 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # All extra USE/etc should be specified in sub-profiles.
 # DO NOT POLLUTE USE ON THIS PROFILE.
 
+# Georgy Yakovlev  (2022-01-04)
+# Unhide PPC specific USE_EXPANDs.
+USE_EXPAND_HIDDEN="-PPC_PAGESIZE"
+
 ARCH="ppc64"
 ACCEPT_KEYWORDS="${ARCH}"
 
 CHOST="powerpc64-unknown-linux-gnu"
 CFLAGS="-O2 -pipe"
 CXXFLAGS="${CFLAGS}"
 FFLAGS="${CFLAGS}"
 FCFLAGS="${CFLAGS}"
 
 USE="ibm"
 
 MULTILIB_ABIS="ppc64"
 DEFAULT_ABI="ppc64"
 KERNEL_ABI="ppc64"
 PROFILE_ARCH="ppc64"
 ABI="ppc64"
 
 #CFLAGS_ppc64="-m64"
 LDFLAGS_ppc64="-m elf64ppc"
 CHOST_ppc64="powerpc64-unknown-linux-gnu"
 
 CFLAGS_ppc="-m32"
 LDFLAGS_ppc="-m elf32ppc"
 CHOST_ppc="powerpc-unknown-linux-gnu"
 
 # Michał Górny  (2014-06-27)
 # Make the ABI flag implicit for compatibility with native ebuilds.
 IUSE_IMPLICIT="abi_ppc_64"
 
 # Donnie Berkholz  (2006-08-18)
 # Defaults for video drivers
 VIDEO_CARDS="fbdev mga nv r128 radeon"
 
 # Enable abi_ppc_64 for packages that don't have it forced.
 ABI_PPC="64"
diff --git a/profiles/base/make.defaults b/profiles/base/make.defaults
index 547c7b31e83..0056543be29 100644
--- a/profiles/base/make.defaults
+++ b/profiles/base/make.defaults
@@ -1,179 +1,179 @@
 # Copyright 1999-2022 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 #
 # System-wide defaults for the Portage system
 # See portage(5) manpage
 
 # Profile IUSE injection (applies only to ebuilds which use EAPI 5 or later)
 IUSE_IMPLICIT="prefix prefix-guest prefix-stack"
 USE_EXPAND_IMPLICIT="ELIBC KERNEL USERLAND"
 USE_EXPAND_VALUES_ELIBC="AIX bionic Cygwin Darwin DragonFly glibc HPUX Interix 
mingw musl NetBSD OpenBSD SunOS Winnt"
 USE_EXPAND_VALUES_KERNEL="AIX Darwin FreeBSD freemint HPUX linux NetBSD 
OpenBSD SunOS Winnt"
 USE_EXPAND_VALUES_USERLAND="BSD GNU"
 
 # Env vars to expand into USE vars.  Modifying this requires prior
 # discussion on gentoo-dev@lists.gentoo.org.
-USE_EXPAND="ABI_MIPS ABI_PPC ABI_S390 ABI_X86 ADA_TARGET ALSA_CARDS 
APACHE2_MODULES APACHE2_MPMS CALLIGRA_FEATURES CAMERAS COLLECTD_PLUGINS 
CPU_FLAGS_ARM CPU_FLAGS_PPC CPU_FLAGS_X86 CURL_SSL ELIBC FFTOOLS GPSD_PROTOCOLS 
GRUB_PLATFORMS INPUT_DEVICES KERNEL L10N LCD_DEVICES LIBREOFFICE_EXTENSIONS 
LLVM_TARGETS LUA_SINGLE_TARGET LUA_TARGETS MONKEYD_PLUGINS NGINX_MODULES_HTTP 
NGINX_MODULES_MAIL NGINX_MODULES_STREAM OFED_DRIVERS OFFICE_IMPLEMENTATION 
OPENMPI_FABRICS OPENMPI_OFED_FEATURES OPENMPI_RM PHP_TARGETS POSTGRES_TARGETS 
PYTHON_SINGLE_TARGET PYTHON_TARGETS QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS 
ROS_MESSAGES RUBY_TARGETS SANE_BACKENDS USERLAND UWSGI_PLUGINS VIDEO_CARDS 
VOICEMAIL_STORAGE XTABLES_ADDONS"
+USE_EXPAND="ABI_MIPS ABI_PPC ABI_S390 ABI_X86 ADA_TARGET ALSA_CARDS 
APACHE2_MODULES APACHE2_MPMS CALLIGRA_FEATURES CAMERAS COLLECTD_PLUGINS 
CPU_FLAGS_ARM CPU_FLAGS_PPC CPU_FLAGS_X86 CURL_SSL ELIBC FFTOOLS GPSD_PROTOCOLS 
GRUB_PLATFORMS INPUT_DEVICES KERNEL L10N LCD_DEVICES LIBREOFFICE_EXTENSIONS 
LLVM_TARGETS LUA_SINGLE_TARGET LUA_TARGETS MONKEYD_PLUGINS NGINX_MODULES_HTTP 
NGINX_MODULES_MAIL NGINX_MODULES_STREAM OFED_DRIVERS OFFICE_IMPLEMENTATION 
OPENMPI_FABRICS OPENMPI_OFED_FEATURES OPENMPI_RM PHP_TARGETS POSTGRES_TARGETS 
PPC_PAGESIZE PYTHON_SINGLE_TARGET PYTHON_TARGETS QEMU_SOFTMMU_TARGETS 
QEMU_USER_TARGETS ROS_MESSAGES RUBY_TARGETS SANE_BACKENDS USERLAND 
UWSGI_PLUGINS VIDEO_CARDS 

Re: [gentoo-dev] [PATCH v3] kernel-2.eclass: Respect portage toolchain variables

[Mike]

On 1/4/22 18:25, Sam James wrote:
> 
> 
>> On 3 Jan 2022, at 18:23, Mike Gilbert > > wrote: 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 
>>> mailto:adrian.ra...@collabora.com>> 
>>> [snip]
>> 
>> 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.
> 
> agreed, but lgtm


Thanks to both authors for your work, this has been committed. 

-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Lead 
E-Mail : mpag...@gentoo.org
GnuPG FP   : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137
Public Key : 
http://http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137=index

Re: [gentoo-dev] [PATCH v3] kernel-2.eclass: Respect portage toolchain variables

[Sam James]

> On 3 Jan 2022, at 18:23, Mike Gilbert  wrote:
> 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 
>> [snip]
> 
> 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.


agreed, but lgtm


signature.asc
Description: Message signed with OpenPGP

Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage

[Sam James]

> On 4 Jan 2022, at 22:58, Sam James  wrote:
> 
> Crank down MAKEOPTS jobs if MAKEOPTS="-jN" is too high for the
> amount of RAM available (uses amount declared as needed
> in the ebuild). Typically should be ~2GB per job.
> 
> Bug: https://bugs.gentoo.org/570534
> Signed-off-by: Sam James 
> ---
> eclass/check-reqs.eclass | 42 +---
> 1 file changed, 39 insertions(+), 3 deletions(-)

Note that we discussed this on GitHub a bit when I just posted it there
for some rough feedback: https://github.com/gentoo/gentoo/pull/23311 
.

I think this is valuable for reducing invalid bug reports from OOM and
easing user experience.

Still kind of a WIP/rough draft, but may be ready in this state. Need
more testing, so not planning on pushing yet or anything.


signature.asc
Description: Message signed with OpenPGP

[gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage

[Sam James]

Crank down MAKEOPTS jobs if MAKEOPTS="-jN" is too high for the
amount of RAM available (uses amount declared as needed
in the ebuild). Typically should be ~2GB per job.

Bug: https://bugs.gentoo.org/570534
Signed-off-by: Sam James 
---
 eclass/check-reqs.eclass | 42 +---
 1 file changed, 39 insertions(+), 3 deletions(-)

diff --git a/eclass/check-reqs.eclass b/eclass/check-reqs.eclass
index 2130e2e349141..8c4adc8b4f121 100644
--- a/eclass/check-reqs.eclass
+++ b/eclass/check-reqs.eclass
@@ -43,6 +43,8 @@ case ${EAPI} in
*) die "${ECLASS}: EAPI=${EAPI:-0} is not supported" ;;
 esac
 
+inherit multiprocessing
+
 EXPORT_FUNCTIONS pkg_pretend pkg_setup
 
 if [[ ! ${_CHECK_REQS_ECLASS} ]]; then
@@ -53,6 +55,13 @@ _CHECK_REQS_ECLASS=1
 # @DESCRIPTION:
 # How much RAM is needed? Eg.: CHECKREQS_MEMORY=15M
 
+# @ECLASS-VARIABLE: CHECKREQS_MEMORY_MANGLE_JOBS
+# @USER_VARIABLE
+# @DESCRIPTION:
+# Allow packages to reduce the number of multiprocessing (e.g. make, ninja) 
jobs
+# to lower memory usage.
+: ${CHECKREQS_MEMORY_MANGLE_JOBS=yes}
+
 # @ECLASS-VARIABLE: CHECKREQS_DISK_BUILD
 # @DEFAULT_UNSET
 # @DESCRIPTION:
@@ -346,9 +355,36 @@ _check-reqs_memory() {
eend 0
else
eend 1
-   _check-reqs_unsatisfied \
-   ${size} \
-   "RAM"
+
+   # Has the user allowed us to mangle their MAKEOPTS?
+   if [[ ${CHECKREQS_MEMORY_MANGLE_JOBS} == "yes" ]] ; then
+   local jobs=$(makeopts_jobs)
+
+   local 
estimated_max_memory=$((${actual_memory}/$(_check-reqs_get_kibibytes 1G)))
+   if [[ $((jobs*2)) -gt ${estimated_max_memory} 
]] ; then
+   # Number of jobs exceeds RAM/2GB, so 
clamp it.
+   local 
new_jobs=$(($(_check-reqs_get_number ${estimated_max_memory}G)*10/20))
+
+   # This might _still_ be too big on 
small machines. Give up in such cases.
+   # (Users can still set the do nothing 
variable which is independent of this.)
+   if [[ $((new_jobs*2)) -gt 
${estimated_max_memory} ]] ; then
+   _check-reqs_unsatisfied \
+   ${size} \
+   "RAM"
+   else
+   # The clamped jobs seem to be 
enough to satisfy the check-reqs requirement from the ebuild.
+   ewarn "Clamping MAKEOPTS jobs 
to -j${new_jobs} to reduce memory usage"
+   ewarn "Compiler jobs may use 
around ~2GB each: https://wiki.gentoo.org/wiki/MAKEOPTS;
+   ewarn "To disable this, set 
CHECKREQS_MEMORY_MANGLE_JOBS=no."
+
+   MAKEOPTS+=" -j${new_jobs}"
+   fi
+   fi
+   else
+   _check-reqs_unsatisfied \
+   ${size} \
+   "RAM"
+   fi
fi
else
eend 1
-- 
2.34.1

Re: [gentoo-dev] [PATCH 1/2] linux-mod.eclass: drop unnecessary IUSE="kernel_linux"

[Sam James]

> On 4 Jan 2022, at 21:54, Michał Górny  wrote:
> 
> On Tue, 2022-01-04 at 11:17 -0500, Mike Gilbert wrote:
>> On Tue, Jan 4, 2022 at 5:23 AM Sam James  wrote:
>>> 
>>> It's already an implicit IUSE, so we don't need this.
>> 
>> I think it is better to declare it explicitly rather than relying on
>> the IUSE_IMPLICIT setting in profiles.
> 
> I agree.  Perhaps we should go even further and remove them from
> implicit flags.
> 

(Note: I did push this change already to coalesce this
with FreeBSD and other removals.)

I don't think declaring it explicitly is helpful given
in most cases (and even more now after recent
cleanups), it's relied upon without declaring it anyway.

Use within IUSE while it's implicit also means
IUSE seems to regularly get out of sync with
actual use within the ebuilds.

As for removing implicit use entirely: while you might
argue this could be okay for the Linux kernel, it would cause
unnecessary rebuilds indefinitely whenever we add a new dep
to an ebuild for e.g. Darwin, or if we did it for libcs,
for say, musl/non-glibc.

best,
sam


signature.asc
Description: Message signed with OpenPGP

Re: [gentoo-dev] [PATCH 1/2] linux-mod.eclass: drop unnecessary IUSE="kernel_linux"

[Michał Górny]

On Tue, 2022-01-04 at 11:17 -0500, Mike Gilbert wrote:
> On Tue, Jan 4, 2022 at 5:23 AM Sam James  wrote:
> > 
> > It's already an implicit IUSE, so we don't need this.
> 
> I think it is better to declare it explicitly rather than relying on
> the IUSE_IMPLICIT setting in profiles.

I agree.  Perhaps we should go even further and remove them from
implicit flags.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Piotr Karbowski]

On 04/01/2022 20.18, Michael Orlitzky wrote:

On Tue, 2022-01-04 at 19:26 +0100, Piotr Karbowski wrote:


And none of which happens unless you intentionally trigger it.

...

Sure, acl and how chmod manipulate mask on ACL-enabled entities is not
very simple, but nothing will break by itself just because you have acl
support enabled, you would need to try very hard to run into problems.




Even if you're right, and if no other tools invoke tar, and the user is
smart enough not to copy/paste commands from the web, and if no other
archivers can extract ACLs when invoked directly or indirectly...
you're still burdening the user to either have faith that this is all
true, or to verify it himself. Repeat the argument for other flags like
ipv6, and you wind up requiring either a lot of faith, or a lot of
diligence, both of which are antithetical to basic principles of
security.

You may not buy the argument, but it's why people disable this stuff,
and the ability to disable it is why a lot of our users user Gentoo to
begin with.


I was challenging here your opinion that most people should disable acl 
support.


And what I showed is that, by keeping it enabled, does not bring on you 
potential problems beside possible security issues in the code that you 
keep around and not want to have around.


Sure, there are valid reasons to strip things from kernel, I've seen 
some tor nodes running kernel without input devices all out of 
initramfs, such usecase do make sense.


However I am strongly against opinion that most people should not enable 
acl, unless you have 16 MB NOR flash storage and every kB of kernel 
image counts, but then it's unlikely that you'd use gentoo there in the 
first place, since bundling headers and whole toolchain would east a lot 
of storage.


I know there are people who love to disable things, there are even 
people who says that pam is bloatware and strip it, or people who, 
security reason as they claim, refuse to use logind provider (elogind or 
systemd) and instead choose to run Xorg as root.


-- Piotr.

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Michael Orlitzky]

On Tue, 2022-01-04 at 19:26 +0100, Piotr Karbowski wrote:
> 
> And none of which happens unless you intentionally trigger it.
> 
> ...
> 
> Sure, acl and how chmod manipulate mask on ACL-enabled entities is not 
> very simple, but nothing will break by itself just because you have acl 
> support enabled, you would need to try very hard to run into problems.
> 
> 

Even if you're right, and if no other tools invoke tar, and the user is
smart enough not to copy/paste commands from the web, and if no other
archivers can extract ACLs when invoked directly or indirectly...
you're still burdening the user to either have faith that this is all
true, or to verify it himself. Repeat the argument for other flags like
ipv6, and you wind up requiring either a lot of faith, or a lot of
diligence, both of which are antithetical to basic principles of
security.

You may not buy the argument, but it's why people disable this stuff,
and the ability to disable it is why a lot of our users user Gentoo to
begin with.

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Piotr Karbowski]

Hi,

On 04/01/2022 18.35, Michael Orlitzky wrote:

On Tue, 2022-01-04 at 12:03 -0500, Mike Gilbert wrote:


I disagree with the claim that "most people" should disable ACL
support at build time. That just gives you partially functional tools.
The ACL behavior can generally be controlled using runtime options.


I understand why people would disagree in this case, but isn't that a
an argument for having the flag?

There are plenty of great uses for ACLs, but unless you're extremely
knowledgeable, they also add a million new ways to compromise your
system. For example, if you untar a file with a default-ACL'd directory
in it and don't notice the little plus sign, you might wind up
unknowingly creating world-writable files. Even if you do notice the
ACL, you have to be an expert in the interaction between umask,
permission bits, the ACL mask, effective permissions, conflicting ACLs,
and all of the tools you're using to understand what will actually
happen or how to properly fix it. It's not something normal people can
handle.

And none of which happens unless you intentionally trigger it.

1. To have ACL break things on new (extracted) files you'd first need to 
have default ACL set on parent directory where you extract to -- 
otherwise they won't be carried and no problem


2. unless you add --acl to both create and extract, no acl will be added 
to tarball and/or extracted onto system


Running 'tar --acl ...' or 'setfacl -d ...' does not happen by accident 
and argument that you should disable acl to not run into issues with 
above does not make much sense.


Sure, acl and how chmod manipulate mask on ACL-enabled entities is not 
very simple, but nothing will break by itself just because you have acl 
support enabled, you would need to try very hard to run into problems.


-- Piotr.

Re: [gentoo-dev] [PATCH 2/2] linux-info.eclass: drop unnecessary IUSE="kernel_linux"

[Brian Evans]

On 1/4/2022 5:23 AM, Sam James wrote:

It's already an implicit IUSE, so we don't need this.

Signed-off-by: Sam James 
---


This seems a bit excessive for something that will not change the end 
compilations in any way.


This one could just stay and not hurt anything.

The commits by soap on the same topic of kernel_* and elibc_* could have 
been done differently and eased into.


I really disagree with this move which just forces recompilation on 
@world update to dozens of packages in an install for no gain.


Brian


OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Michael Orlitzky]

On Tue, 2022-01-04 at 12:03 -0500, Mike Gilbert wrote:
> 
> I disagree with the claim that "most people" should disable ACL
> support at build time. That just gives you partially functional tools.
> The ACL behavior can generally be controlled using runtime options.

I understand why people would disagree in this case, but isn't that a
an argument for having the flag?

There are plenty of great uses for ACLs, but unless you're extremely
knowledgeable, they also add a million new ways to compromise your
system. For example, if you untar a file with a default-ACL'd directory
in it and don't notice the little plus sign, you might wind up
unknowingly creating world-writable files. Even if you do notice the
ACL, you have to be an expert in the interaction between umask,
permission bits, the ACL mask, effective permissions, conflicting ACLs,
and all of the tools you're using to understand what will actually
happen or how to properly fix it. It's not something normal people can
handle.

If you don't need them for anything, it's just nice not to have to
worry about those issues.

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Piotr Karbowski]

Hi,

On 04/01/2022 18.03, Mike Gilbert wrote:

On Tue, Jan 4, 2022 at 12:31 AM Michael Orlitzky  wrote:


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.


I disagree with the claim that "most people" should disable ACL
support at build time. That just gives you partially functional tools.
The ACL behavior can generally be controlled using runtime options.

Also, you might be able to get away with disabling ACL support on a
server, but desktop users will want ACL support enabled to get
properly functioning udev rules.



I second this.

As far as Desktop is concerned acl is basic feature that should be there 
along with extended attributes, for example, I am pretty sure 
systemd-login will use acl to grant access to inputs in /dev for the 
logged user.


acl is as much needed as support for multiple users (CONFIG_MULTIUSER), 
and it also needs support on kernel level, because without this symbol 
hardly anything will work for you. What I mean here is that argument 
'needs support in kernel' is not a problem, because everything does need 
a support in kernel. Try to boot without CONFIG_FUTEX as example, it can 
be disabled so you could say that it needs support in kernel in a way to 
constitute that this is something bad and thus should be avoided.


-- Piotr.

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Mike Gilbert]

On Tue, Jan 4, 2022 at 12:31 AM Michael Orlitzky  wrote:
>
> 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.

I disagree with the claim that "most people" should disable ACL
support at build time. That just gives you partially functional tools.
The ACL behavior can generally be controlled using runtime options.

Also, you might be able to get away with disabling ACL support on a
server, but desktop users will want ACL support enabled to get
properly functioning udev rules.

Re: [gentoo-dev] [PATCH 1/2] linux-mod.eclass: drop unnecessary IUSE="kernel_linux"

[Mike Gilbert]

On Tue, Jan 4, 2022 at 5:23 AM Sam James  wrote:
>
> It's already an implicit IUSE, so we don't need this.

I think it is better to declare it explicitly rather than relying on
the IUSE_IMPLICIT setting in profiles.

[gentoo-dev] Last rites: games-util/springlobby

[Florian Schmaus]

# Florian Schmaus  (2022-01-04)
# Outdated, unmaintained, and has multiple open bugs (bug #732582, bug
# #739398, bug #756715). As discussed at
# https://github.com/gentoo/gentoo/pull/23483#issuecomment-1004363556,
# in its current form it is better maintained in the 'spring' overlay.
# Removal after 2022-02-04. Bug #830588.
games-util/springlobby

- Flow

[gentoo-dev] [PATCH 1/2] linux-mod.eclass: drop unnecessary IUSE="kernel_linux"

[Sam James]

It's already an implicit IUSE, so we don't need this.

Signed-off-by: Sam James 
---
 eclass/linux-mod.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
index 9f4ae64f6b55..496b9c98b526 100644
--- a/eclass/linux-mod.eclass
+++ b/eclass/linux-mod.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: linux-mod.eclass
@@ -170,7 +170,7 @@ esac
0) die "EAPI=${EAPI} is not supported with 
MODULES_OPTIONAL_USE_IUSE_DEFAULT due to lack of IUSE defaults" ;;
 esac
 
-IUSE="kernel_linux dist-kernel
+IUSE="dist-kernel

${MODULES_OPTIONAL_USE:+${_modules_optional_use_iuse_default}}${MODULES_OPTIONAL_USE}"
 SLOT="0"
 RDEPEND="
-- 
2.34.1

[gentoo-dev] [PATCH 2/2] linux-info.eclass: drop unnecessary IUSE="kernel_linux"

[Sam James]

It's already an implicit IUSE, so we don't need this.

Signed-off-by: Sam James 
---
 eclass/linux-info.eclass | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
index 568f7a1a2832..a0942f0e554c 100644
--- a/eclass/linux-info.eclass
+++ b/eclass/linux-info.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: linux-info.eclass
@@ -137,8 +137,6 @@ inherit toolchain-funcs
 
 EXPORT_FUNCTIONS pkg_setup
 
-IUSE="kernel_linux"
-
 # Bug fixes
 # fix to bug #75034
 case ${ARCH} in
-- 
2.34.1