Re: [gentoo-dev] [PATCH 3/4] user-info.eclass: Fix for when building in a rooted prefix (EROOT)

2022-12-06 Thread Mike Gilbert
On Tue, Dec 6, 2022 at 5:24 PM James Le Cuirot  wrote:
>
> Users are largely irrelevant for prefix, but we still don't want the
> build to break.
>
> Signed-off-by: James Le Cuirot 
> ---
>  eclass/user-info.eclass | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/eclass/user-info.eclass b/eclass/user-info.eclass
> index 5550e4f08eeb..1339e36634a8 100644
> --- a/eclass/user-info.eclass
> +++ b/eclass/user-info.eclass
> @@ -48,7 +48,7 @@ egetent() {
> fi
>
> # Handle different ROOT
> -   [[ -n ${ROOT} ]] && opts+=( -R "${ROOT}" )
> +   [[ -n ${ROOT} ]] && opts+=( -R "${EROOT}" )

Another case where the [[ -n ${ROOT} ]] should probably be changed to
[[ -n ${EROOT} ]] if you actually want this to be prefix-aware.



Re: [gentoo-dev] [PATCH 4/4] user.eclass: Fix for when building in a rooted prefix (EROOT)

2022-12-06 Thread Mike Gilbert
On Tue, Dec 6, 2022 at 5:24 PM James Le Cuirot  wrote:
>
> Users are largely irrelevant for prefix, but we still don't want the
> build to break.
>
> I left the home and shell related bits alone, as it's less clear whether
> these should be prefixed or not. Obviously /dev/null should not be. It's
> slightly academic anyway, as nothing in the main repo uses this eclass
> any more.

I just deleted user.eclass, so you can probably drop this patch. :-)



Re: [gentoo-dev] [PATCH 1/4] acct-group.eclass: Fix for when building in a rooted prefix (EROOT)

2022-12-06 Thread Mike Gilbert
On Tue, Dec 6, 2022 at 5:24 PM James Le Cuirot  wrote:
>
> Groups are largely irrelevant for prefix, but we still don't want the
> build to break.
>
> Signed-off-by: James Le Cuirot 
> ---
>  eclass/acct-group.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass
> index 590a2f20ed8e..ada5fe386693 100644
> --- a/eclass/acct-group.eclass
> +++ b/eclass/acct-group.eclass
> @@ -176,7 +176,7 @@ acct-group_pkg_preinst() {
> fi
>
> if [[ -n ${ROOT} ]]; then

You should probably change this to [[ -n ${EROOT} ]]. Same goes for
acct-user.eclass.

Also see bug 779181; I'm not sure updating ${EROOT}/etc/group and
${EROOT}/etc/passwd makes any sense at all.



Re: [gentoo-dev] [RFC] Removing the distinction between UNCONFIRMED and CONFIRMED bugs

2022-12-03 Thread Mike Gilbert
On Sat, Dec 3, 2022 at 2:09 AM Michał Górny  wrote:
>
> Hi,
>
> I'd like to propose replacing the current UNCONFIRMED and CONFIRMED bug
> states with a simple NEW state.  Why?
>
> 1. Only a handful of developers actually uses these two statuses
> in a meaningful way.
>
> 2. Some users are confused and demotivated by having their bugs stay
> UNCONFIRMED for a long time.

I think I could be counted among the devs who at least try to use the
two statuses. If I stumble upon bugs that I have run into myself, I
will flip them from UNCONFIRMED to CONFIRMED. On the opposite end, I
occasionally downgrade bugs from CONFIRMED to UNCONFIRMED if they are
particularly strange looking and were filed by a script (tinderbox).

Anyway, if you decide to make the change, please ensure that it
doesn't generate a bunch of pointless bugmail. I have noticed that
some devs will replace obsolete values in Product/Component without
making any other meaningful changes to the bug. Let's avoid that
situation if possible here.



Re: [gentoo-dev] [PATCH] linux-info.eclass: getfilevar: pass 'need-compiler=' to make

2022-11-29 Thread Mike Gilbert
On Tue, Nov 29, 2022 at 5:14 PM James Le Cuirot  wrote:
>
> On Tue, 2022-11-29 at 13:55 -0500, Mike Gilbert wrote:
> > This avoids some unnecessary Makefile logic and gives a nice speed up.
> >
> > Before the change, linux-info_pkg_setup takes 11 to 15 seconds on my
> > AMD Phenom II. After, it takes 3 to 4 seconds.
> >
> > Signed-off-by: Mike Gilbert 
> > ---
> >  eclass/linux-info.eclass | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
> > index fc125b0d751..3e64cb9457a 100644
> > --- a/eclass/linux-info.eclass
> > +++ b/eclass/linux-info.eclass
> > @@ -238,7 +238,9 @@ getfilevar() {
> >   # Pass dot-config=0 to avoid the config check in kernels 
> > prior to 5.4.
> >   [[ ${EAPI:-0} == [0123] ]] && nonfatal() { "$@"; }
> >   echo -e "e:\\n\\t@echo \$(${1})\\ninclude ${basefname}" | \
> > - nonfatal emake -C "${basedname}" --no-print-directory 
> > M="${T}" dot-config=0 need-config= ${BUILD_FIXES} -s -f - 2>/dev/null
> > + nonfatal emake -C "${basedname}" --no-print-directory 
> > M="${T}" \
> > + dot-config=0 need-config= need-compiler= \
> > + ${BUILD_FIXES} -s -f - 2>/dev/null
> >
> >   ARCH=${myARCH}
> >   fi
>
> I'm confused. Breaking up the line makes it faster?

The change is stated in the email subject.



[gentoo-dev] [PATCH] linux-info.eclass: getfilevar: pass 'need-compiler=' to make

2022-11-29 Thread Mike Gilbert
This avoids some unnecessary Makefile logic and gives a nice speed up.

Before the change, linux-info_pkg_setup takes 11 to 15 seconds on my
AMD Phenom II. After, it takes 3 to 4 seconds.

Signed-off-by: Mike Gilbert 
---
 eclass/linux-info.eclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
index fc125b0d751..3e64cb9457a 100644
--- a/eclass/linux-info.eclass
+++ b/eclass/linux-info.eclass
@@ -238,7 +238,9 @@ getfilevar() {
# Pass dot-config=0 to avoid the config check in kernels prior 
to 5.4.
[[ ${EAPI:-0} == [0123] ]] && nonfatal() { "$@"; }
echo -e "e:\\n\\t@echo \$(${1})\\ninclude ${basefname}" | \
-   nonfatal emake -C "${basedname}" --no-print-directory 
M="${T}" dot-config=0 need-config= ${BUILD_FIXES} -s -f - 2>/dev/null
+   nonfatal emake -C "${basedname}" --no-print-directory 
M="${T}" \
+   dot-config=0 need-config= need-compiler= \
+   ${BUILD_FIXES} -s -f - 2>/dev/null
 
ARCH=${myARCH}
fi
-- 
2.38.1




Re: [gentoo-portage-dev] sys-kernel/vanilla-sources not supported any more?

2022-11-25 Thread Mike Gilbert
On Fri, Nov 25, 2022 at 5:50 AM Joakim Tjernlund
 wrote:
>
> I have noticed sys-kernel/vanilla-sources lagging behind for a while now and 
> I wonder if this pkg is obsolete?

I think you sent this message to the wrong place. This list is for
discussion of Portage development, not packages in the gentoo
repository.



Re: [gentoo-portage-dev] Fixing EAPI 8 --enable-static once and for all

2022-11-19 Thread Mike Gilbert
On Sat, Nov 19, 2022 at 3:33 AM Ulrich Mueller  wrote:
>
> > On Sat, 19 Nov 2022, David Seifert wrote:
>
> > With this extensive analysis, I believe this patch to be safe.
>
> Still looks like an incompatible change, so it will need an EAPI bump.
>
> EAPI 9 feature bug is here: https://bugs.gentoo.org/815169

I support this patch to fix Portage, regardless of what PMS says.
Coding to the spec doesn't make sense if the spec is broken.



[gentoo-dev] [PATCH] 2022-11-19-tmpfiles-clean: new item

2022-11-16 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 .../2022-11-19-tmpfiles-clean.en.txt  | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 2022-11-19-tmpfiles-clean/2022-11-19-tmpfiles-clean.en.txt

diff --git a/2022-11-19-tmpfiles-clean/2022-11-19-tmpfiles-clean.en.txt 
b/2022-11-19-tmpfiles-clean/2022-11-19-tmpfiles-clean.en.txt
new file mode 100644
index 000..8e17e2a
--- /dev/null
+++ b/2022-11-19-tmpfiles-clean/2022-11-19-tmpfiles-clean.en.txt
@@ -0,0 +1,19 @@
+Title: systemd-tmpfiles --clean enabled by default
+Author: Mike Gilbert 
+Posted: 2022-11-19
+Revision: 1
+News-Item-Format: 2.0
+Display-If-Installed: sys-apps/systemd-utils[tmpfiles]
+
+Starting with sys-apps/systemd-utils-251.8-r1, a script is installed in
+/etc/cron.daily to run "systemd-tmpfiles --clean" once per day. This
+will remove stale temp files based on settings specified in tmpfiles.d.
+
+This change is meant to mimic the behavior of
+systemd-tmpfiles-clean.timer from systemd on systems running OpenRC.
+
+If you wish to opt-out, take any of the following actions:
+
+1. Comment out the command in /etc/cron.daily/systemd-tmpfiles-clean, or
+2. Add /etc/cron.daily/systemd-tmpfiles-clean to INSTALL_MASK, or
+3. Disable or remove the cron daemon on your system.
-- 
2.38.1




Re: [gentoo-dev] Re: Last rites: user.eclass

2022-10-19 Thread Mike Gilbert
On Wed, Oct 19, 2022 at 3:08 PM Martin Vaeth  wrote:
>
> Mike Gilbert  wrote:
> > user.eclass has been deprecated for two years. In the gentoo repo, it
> > is currently only used by acct-group.eclass and acct-user.eclass
>
> It is needed for ebuilds in non-gentoo repositories which cannot
> reserve a fixed number for users and groups.

Such ebuilds should be converted into acct-user and acct-group
packages instead. If you set ACCT_USER_ID=-1 or ACCT_GROUP_ID=-1, they
will pick an available UID/GID upon installation.



[gentoo-dev] Last rites: user.eclass

2022-10-19 Thread Mike Gilbert
user.eclass has been deprecated for two years. In the gentoo repo, it
is currently only used by acct-group.eclass and acct-user.eclass, and a
patchset is currently under review remedy that [1].

Planned removal is in 30 days on 2022-11-18.

[1] https://github.com/gentoo/gentoo/pull/27825



Re: [gentoo-dev] [PATCH] profiles/arch/amd64: add "-mfpmath=sse" to CFLAGS_x86

2022-10-18 Thread Mike Gilbert
On Tue, Oct 18, 2022 at 12:47 PM Ulrich Mueller  wrote:
>
> > On Tue, 18 Oct 2022, David Seifert wrote:
>
> > What if I want to build Gentoo on an old AMD Thunderbird which has
> > neither SSE1 nor the more important SSE2?
>
> The -mfpmath=sse option is a no-op if the CPU doesn't support SSE,
> i.e. it will use 387 arithmetics nevertheless.

I don't really see an "effective" way to deploy this via profiles on x86.

We could add it to the default CFLAGS setting in
profiles/arch/x86/make.defaults. However, we also default to
-march=i686 there, and that doesn't support SSE or SSE2. Also, the
entire CFLAGS variable is likely to be overridden by the CFLAGS
setting in /etc/make.conf.

The CFLAGS_x86 profile variable is only used by the
multilib_toolchain_setup function in multilib.eclass. In other words,
it only affects ebuilds that utilize the multilib eclasses to build
libraries for multiple ABIs. That covers all 32-bit libraries on
amd64, but doesn't cover all packages on x86.



Re: [gentoo-dev] [PATCH] profiles/arch/amd64: add "-mfpmath=sse" to CFLAGS_x86

2022-10-18 Thread Mike Gilbert
On Tue, Oct 18, 2022 at 5:56 AM David Seifert  wrote:
>
> On Tue, 2022-10-18 at 10:14 +0200, Ulrich Mueller wrote:
> > > > > > > On Tue, 18 Oct 2022, Mike Gilbert wrote:
> >
> > > Reference: https://gcc.gnu.org/wiki/x87note
> >
> > Which says:
> >
> > > ... the amount of worst-case error that could possibly happen using
> > > the x87 (with any amount of intermediate rounding) is at worst the
> > > same as true 64 or 32 bit arithmetic, and in practice is almost
> > > always
> > > better.
> >
> > and:
> >
> > > Note, however, that this greater repeatability comes at the cost of
> > > lost precision (i.e. SSE always gets the same precision because it
> > > always takes the equivalent of the x87's worst case: a forced round
> > > down at each step).
> >
> > So, it comes with a price, and I wonder if we shouldn't leave that
> > choice to the user, and go with the upstream GCC default?
> >
> > > -CFLAGS_x86="-m32"
> > > +CFLAGS_x86="-m32 -mfpmath=sse"
>
> -mfpmath=sse is already the default on amd64.

I have amended the first paragraph to make this more clear:

GCC uses x87 floating point instructions when building 32-bit x86
code by default. When building 64-bit code, SSE2 instructions are used
instead.



Re: [gentoo-dev] [PATCH] profiles/arch/amd64: add "-mfpmath=sse" to CFLAGS_x86

2022-10-18 Thread Mike Gilbert
On Tue, Oct 18, 2022 at 9:37 AM David Seifert  wrote:
>
> On Tue, 2022-10-18 at 13:40 +0200, Ulrich Mueller wrote:
> > > > > > > On Tue, 18 Oct 2022, David Seifert wrote:
> >
> > > > > -CFLAGS_x86="-m32"
> > > > > +CFLAGS_x86="-m32 -mfpmath=sse"
> >
> > > -mfpmath=sse is already the default on amd64.
> >
> > I see. This change makes sense then.
> >
> > What about profiles/arch/x86 though? IIUC we'll end up with an
> > inconsistency between x86 and multilib amd64.
> >
> > Ulrich
>
> What if I want to build Gentoo on an old AMD Thunderbird which has
> neither SSE1 nor the more important SSE2?

Right. On amd64 CPU always supports SSE2, so -mfpmath=sse will always
work there.

On x86, we need to consider a more diverse set of supported instructions.



[gentoo-dev] [PATCH] profiles/arch/amd64: add "-mfpmath=sse" to CFLAGS_x86

2022-10-17 Thread Mike Gilbert
GCC uses x87 floating point instructions when building 32-bit x86
code by default. This is true even for x86-64 multilib.

Using the x87 floating point unit can lead to strange behavior when
calculating intermediate values for single and double precision floats.
It uses 80 bits for all calculations, which is larger than the 32 or 64
bits specified for floats and doubles.

Using the SSE2 instructions available on x86-64 for floating point
arithmetic leads to more consistent behavior, and is usually faster.

Reference: https://gcc.gnu.org/wiki/x87note
Signed-off-by: Mike Gilbert 
---
 profiles/arch/amd64/make.defaults | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/profiles/arch/amd64/make.defaults 
b/profiles/arch/amd64/make.defaults
index 0c05dec124e..e7e18ff6a91 100644
--- a/profiles/arch/amd64/make.defaults
+++ b/profiles/arch/amd64/make.defaults
@@ -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
 
 ARCH="amd64"
@@ -28,7 +28,7 @@ LDFLAGS_amd64="-m elf_x86_64"
 CHOST_amd64="x86_64-pc-linux-gnu"
 
 # 32bit specific settings.
-CFLAGS_x86="-m32"
+CFLAGS_x86="-m32 -mfpmath=sse"
 LDFLAGS_x86="-m elf_i386"
 CHOST_x86="i686-pc-linux-gnu"
 
-- 
2.37.3




Re: [gentoo-dev] [PATCH 1/2] profiles/profiles.desc: add systemd/selinux/merged-usr subprofiles

2022-10-12 Thread Mike Gilbert
On Wed, Oct 12, 2022 at 10:03 AM Kenton Groombridge  wrote:
>
> Signed-off-by: Kenton Groombridge 
> ---
>  profiles/profiles.desc | 3 +++
>  1 file changed, 3 insertions(+)

You should reverse the order of these commits: add the profile
directories first, and then add them to profiles.desc.



[gentoo-dev] [PATCH] profiles: move merged-usr profiles from dev to stable

2022-10-12 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 profiles/profiles.desc | 50 +-
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/profiles/profiles.desc b/profiles/profiles.desc
index 5702a9dc7c4..58abd888bbe 100644
--- a/profiles/profiles.desc
+++ b/profiles/profiles.desc
@@ -30,12 +30,12 @@ amd64   
default/linux/amd64/17.1/hardened/selinux   stable
 amd64  default/linux/amd64/17.1/desktop
stable
 amd64  default/linux/amd64/17.1/desktop/gnome  
stable
 amd64  default/linux/amd64/17.1/desktop/gnome/systemd  
stable
-amd64  default/linux/amd64/17.1/desktop/gnome/systemd/merged-usr   
dev
+amd64  default/linux/amd64/17.1/desktop/gnome/systemd/merged-usr   
stable
 amd64  default/linux/amd64/17.1/desktop/plasma 
stable
 amd64  default/linux/amd64/17.1/desktop/plasma/systemd 
stable
-amd64  default/linux/amd64/17.1/desktop/plasma/systemd/merged-usr  
dev
+amd64  default/linux/amd64/17.1/desktop/plasma/systemd/merged-usr  
stable
 amd64  default/linux/amd64/17.1/desktop/systemd
stable
-amd64  default/linux/amd64/17.1/desktop/systemd/merged-usr 
dev
+amd64  default/linux/amd64/17.1/desktop/systemd/merged-usr 
stable
 amd64  default/linux/amd64/17.1/developer  
exp
 amd64  default/linux/amd64/17.1/no-multilib
stable
 amd64  default/linux/amd64/17.1/no-multilib/hardened   
stable
@@ -44,7 +44,7 @@ amd64 default/linux/amd64/17.1/no-multilib/systemd
dev
 amd64  default/linux/amd64/17.1/no-multilib/systemd/merged-usr 
dev
 amd64  default/linux/amd64/17.1/no-multilib/systemd/selinux
exp
 amd64  default/linux/amd64/17.1/systemd
stable
-amd64  default/linux/amd64/17.1/systemd/merged-usr 
dev
+amd64  default/linux/amd64/17.1/systemd/merged-usr 
stable
 amd64  default/linux/amd64/17.1/systemd/selinux
exp
 amd64  default/linux/amd64/17.1/clang  
exp
 amd64  default/linux/amd64/17.1/systemd/clang  
exp
@@ -130,15 +130,15 @@ arm64 
default/linux/arm64/17.0/hardened/selinux   dev
 arm64  default/linux/arm64/17.0/desktop
stable
 arm64  default/linux/arm64/17.0/desktop/gnome  
stable
 arm64  default/linux/arm64/17.0/desktop/gnome/systemd  
stable
-arm64  default/linux/arm64/17.0/desktop/gnome/systemd/merged-usr   
dev
+arm64  default/linux/arm64/17.0/desktop/gnome/systemd/merged-usr   
stable
 arm64  default/linux/arm64/17.0/desktop/plasma 
stable
 arm64  default/linux/arm64/17.0/desktop/plasma/systemd 
stable
-arm64  default/linux/arm64/17.0/desktop/plasma/systemd/merged-usr  
dev
+arm64  default/linux/arm64/17.0/desktop/plasma/systemd/merged-usr  
stable
 arm64  default/linux/arm64/17.0/desktop/systemd
stable
-arm64  default/linux/arm64/17.0/desktop/systemd/merged-usr 
dev
+arm64  default/linux/arm64/17.0/desktop/systemd/merged-usr 
stable
 arm64  default/linux/arm64/17.0/developer  
exp
 arm64  default/linux/arm64/17.0/systemd
stable
-arm64  default/linux/arm64/17.0/systemd/merged-usr 
dev
+arm64  default/linux/arm64/17.0/systemd/merged-usr 
stable
 arm64  default/linux/arm64/17.0/systemd/selinux
exp
 
 
@@ -162,7 +162,7 @@ ia64default/linux/ia64/17.0 
stable
 ia64   default/linux/ia64/17.0/desktop 
stable
 ia64   default/linux/ia64/17.0/desktop/gnome   
stable
 ia64   default/linux/ia64/17.0/desktop/gnome/systemd   
stable
-ia64   default/linux/ia64/17.0/desktop/gnome/systemd/merged-usr
dev
+ia64   default/linux/ia64/17.0/desktop/gnome/systemd/merged-usr
stable
 ia64   default/linux/ia64/17.0/developer   
exp
 ia64   default/linux/ia64/17.0/systemd 
exp
 ia64   default/linux/ia64/17.0/systemd/merged-usr  
exp
@@ -216,9 +216,9 @@ ppc default/linux/ppc/17.0

[gentoo-dev] [PATCH] 2022-12-01-systemd-usrmerge: add news item

2022-10-11 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 .../2022-12-01-systemd-usrmerge.en.txt| 35 +++
 1 file changed, 35 insertions(+)
 create mode 100644 
2022-12-01-systemd-usrmerge/2022-12-01-systemd-usrmerge.en.txt

diff --git a/2022-12-01-systemd-usrmerge/2022-12-01-systemd-usrmerge.en.txt 
b/2022-12-01-systemd-usrmerge/2022-12-01-systemd-usrmerge.en.txt
new file mode 100644
index 000..19849bf
--- /dev/null
+++ b/2022-12-01-systemd-usrmerge/2022-12-01-systemd-usrmerge.en.txt
@@ -0,0 +1,35 @@
+Title: /usr merge for systemd users
+Author: Mike Gilbert 
+Posted: 2022-12-01
+Revision: 1
+News-Item-Format 2.0
+Display-If-Installed: sys-apps/systemd
+
+In the latter half of 2023, systemd will drop support for
+split-usr/unmerged-usr systems [1]. All Gentoo systems running systemd
+will need to be migrated to merged-usr.
+
+Migrating to merged-usr will move all data from /bin, /sbin, and /lib
+into the /usr/bin and /usr/lib directories. The directories in / are
+replaced with symlinks.
+
+To facilitate this, a new set of sub-profiles has been created, and a
+script is availble to perform the actual migration.
+
+To migrate a system to merged-usr, follow this procedure:
+
+1. Ensure your system backups are up to date.
+
+2. Install sys-apps/merge-usr.
+
+3. Run the merge-usr script. The --dryrun option may be used to
+   check for error conditions before running the script for real.
+
+4. Switch to a merged-usr profile.
+ eg. eselect profile set default/linux/amd64/17.1/systemd/merged-usr
+
+5. Run emerge with the --newuse or --changed-use option to rebuild
+   any packages that have a "split-usr" USE flag.
+ eg. emerge -uDN @world
+
+[1] 
https://lists.freedesktop.org/archives/systemd-devel/2022-September/048352.html
-- 
2.37.3




Re: [gentoo-dev] RFC: check A's size in go-module.eclass

2022-10-11 Thread Mike Gilbert
On Tue, Oct 11, 2022 at 6:06 AM Florian Schmaus  wrote:
>
>
> This is a first suggestion in an effort to reach a compromise that
> allows EGO_SUM to be un-depracted.
>
> I have decided to check the size of A, instead of counting the entries
> in EGO_SUM, because that seemed more sensible given that as A's size
> caused functional issues in the past (bug #719202 [1]).
>
> 1: https://bugs.gentoo.org/719202

I would suggest we simply add a comment to warn ebuild developers that
some unknown large number of modules may cause build failures. If/when
the ebuild starts to fail, they will know they went over the limit and
will have to start collapsing files into tarballs.



Re: [gentoo-dev] [PATCH] go-module.eclass: ensure that A is less than 112 KiB

2022-10-11 Thread Mike Gilbert
On Tue, Oct 11, 2022 at 6:06 AM Florian Schmaus  wrote:
>
> Packages with a large number of EGO_SUM entries, i.e., many thousands,
> cause SRC_URI, and in turn A, to become quite large. Prevent issues that
> are caused by large environment variables, e.g., execve() errors (see
> bug #719203), by ensuring that A stays below a reasonable size.

This code will never be reached: if the A environment variable is too
large, portage will fail to execute /bin/bash, and the phase function
will not be executed.

If you want to add an error for this, I think it would require changes
to Portage's python code.



[gentoo-dev] [PATCH 2/3] systemd.eclass: add systemd_get_sleepdir

2022-10-10 Thread Mike Gilbert
Closes: https://bugs.gentoo.org/873172
Signed-off-by: Mike Gilbert 
---
 eclass/systemd.eclass | 8 
 1 file changed, 8 insertions(+)

diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
index 9e9a9b0cf20..fbed387e0ca 100644
--- a/eclass/systemd.eclass
+++ b/eclass/systemd.eclass
@@ -132,6 +132,14 @@ systemd_get_systempresetdir() {
_systemd_get_dir systemdsystempresetdir /lib/systemd/system-preset
 }
 
+# @FUNCTION: systemd_get_sleepdir
+# @DESCRIPTION:
+# Output the path for the system sleep directory.
+systemd_get_sleepdir() {
+   debug-print-function ${FUNCNAME} "${@}"
+   _systemd_get_dir systemdsleepdir /lib/systemd/system-sleep
+}
+
 # @FUNCTION: systemd_dounit
 # @USAGE: ...
 # @DESCRIPTION:
-- 
2.37.3




[gentoo-dev] [PATCH 3/3] eclass/tests: add systemd tests

2022-10-10 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 eclass/tests/systemd.sh | 50 +
 1 file changed, 50 insertions(+)
 create mode 100755 eclass/tests/systemd.sh

diff --git a/eclass/tests/systemd.sh b/eclass/tests/systemd.sh
new file mode 100755
index 000..f870df4b7a1
--- /dev/null
+++ b/eclass/tests/systemd.sh
@@ -0,0 +1,50 @@
+#!/usr/bin/env bash
+# Copyright 2022 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+source tests-common.sh || exit
+
+inherit systemd
+
+test_system_dir() {
+   local exp1="${EPREFIX}$1"
+   local exp2="${EPREFIX}/usr$1"
+   shift
+   tbegin "$@"
+   local act=$("$@")
+   [[ ${act} == ${exp1} || ${act} == ${exp2} ]]
+   tend $?
+}
+
+test_user_dir() {
+   local exp="${EPREFIX}$1"
+   shift
+   tbegin "$@"
+   local act=$("$@")
+   [[ ${act} == ${exp} ]]
+   tend $?
+}
+
+test_systemd_unprefix() {
+   local exp=$1
+   local EPREFIX=$2
+   shift 2
+   tbegin "EPREFIX=${EPREFIX} _systemd_unprefix $@"
+   [[ "$(_systemd_unprefix "$@")" == "${exp}" ]]
+   tend $?
+}
+
+test_system_dir /lib/systemd/system systemd_get_systemunitdir
+test_system_dir /lib/systemd systemd_get_utildir
+test_system_dir /lib/systemd/system-generators systemd_get_systemgeneratordir
+test_system_dir /lib/systemd/system-preset systemd_get_systempresetdir
+test_system_dir /lib/systemd/system-sleep systemd_get_sleepdir
+
+test_user_dir /usr/lib/systemd/user systemd_get_userunitdir
+
+test_systemd_unprefix /lib/systemd /prefix echo /prefix/lib/systemd
+test_systemd_unprefix /lib/systemd '' echo /lib/systemd
+test_systemd_unprefix /lib/systemd '/*' echo '/*/lib/systemd'
+
+texit
-- 
2.37.3




[gentoo-dev] [PATCH 1/3] systemd.eclass: rework EPREFIX handling

2022-10-10 Thread Mike Gilbert
Instead of adding a private function to get the unprefixed version of
every path, use a new "_systemd_unprefix" helper function.

Signed-off-by: Mike Gilbert 
---
 eclass/systemd.eclass | 69 ---
 1 file changed, 19 insertions(+), 50 deletions(-)

diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
index 7731bede094..9e9a9b0cf20 100644
--- a/eclass/systemd.eclass
+++ b/eclass/systemd.eclass
@@ -1,4 +1,4 @@
-# Copyright 2011-2021 Gentoo Authors
+# Copyright 2011-2022 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: systemd.eclass
@@ -53,20 +53,21 @@ _systemd_get_dir() {
 
if $(tc-getPKG_CONFIG) --exists systemd; then
d=$($(tc-getPKG_CONFIG) --variable="${variable}" systemd) || die
-   d=${d#${EPREFIX}}
else
-   d=${fallback}
+   d="${EPREFIX}${fallback}"
fi
 
echo "${d}"
 }
 
-# @FUNCTION: _systemd_get_systemunitdir
+# @FUNCTION: _systemd_unprefix
+# @USAGE: 
 # @INTERNAL
 # @DESCRIPTION:
-# Get unprefixed unitdir.
-_systemd_get_systemunitdir() {
-   _systemd_get_dir systemdsystemunitdir /lib/systemd/system
+# Calls the specified function and removes ${EPREFIX} from the result.
+_systemd_unprefix() {
+   local d=$("${@}")
+   echo "${d#"${EPREFIX}"}"
 }
 
 # @FUNCTION: systemd_get_systemunitdir
@@ -77,7 +78,7 @@ _systemd_get_systemunitdir() {
 systemd_get_systemunitdir() {
debug-print-function ${FUNCNAME} "${@}"
 
-   echo "${EPREFIX}$(_systemd_get_systemunitdir)"
+   _systemd_get_dir systemdsystemunitdir /lib/systemd/system
 }
 
 # @FUNCTION: systemd_get_unitdir
@@ -89,14 +90,6 @@ systemd_get_unitdir() {
systemd_get_systemunitdir
 }
 
-# @FUNCTION: _systemd_get_userunitdir
-# @INTERNAL
-# @DESCRIPTION:
-# Get unprefixed userunitdir.
-_systemd_get_userunitdir() {
-   _systemd_get_dir systemduserunitdir /usr/lib/systemd/user
-}
-
 # @FUNCTION: systemd_get_userunitdir
 # @DESCRIPTION:
 # Output the path for the systemd user unit directory (not including
@@ -105,15 +98,7 @@ _systemd_get_userunitdir() {
 systemd_get_userunitdir() {
debug-print-function ${FUNCNAME} "${@}"
 
-   echo "${EPREFIX}$(_systemd_get_userunitdir)"
-}
-
-# @FUNCTION: _systemd_get_utildir
-# @INTERNAL
-# @DESCRIPTION:
-# Get unprefixed utildir.
-_systemd_get_utildir() {
-   _systemd_get_dir systemdutildir /lib/systemd
+   _systemd_get_dir systemduserunitdir /usr/lib/systemd/user
 }
 
 # @FUNCTION: systemd_get_utildir
@@ -124,15 +109,7 @@ _systemd_get_utildir() {
 systemd_get_utildir() {
debug-print-function ${FUNCNAME} "${@}"
 
-   echo "${EPREFIX}$(_systemd_get_utildir)"
-}
-
-# @FUNCTION: _systemd_get_systemgeneratordir
-# @INTERNAL
-# @DESCRIPTION:
-# Get unprefixed systemgeneratordir.
-_systemd_get_systemgeneratordir() {
-   _systemd_get_dir systemdsystemgeneratordir 
/lib/systemd/system-generators
+   _systemd_get_dir systemdutildir /lib/systemd
 }
 
 # @FUNCTION: systemd_get_systemgeneratordir
@@ -142,15 +119,7 @@ _systemd_get_systemgeneratordir() {
 systemd_get_systemgeneratordir() {
debug-print-function ${FUNCNAME} "${@}"
 
-   echo "${EPREFIX}$(_systemd_get_systemgeneratordir)"
-}
-
-# @FUNCTION: _systemd_get_systempresetdir
-# @INTERNAL
-# @DESCRIPTION:
-# Get unprefixed systempresetdir.
-_systemd_get_systempresetdir() {
-   _systemd_get_dir systemdsystempresetdir /lib/systemd/system-preset
+   _systemd_get_dir systemdsystemgeneratordir 
/lib/systemd/system-generators
 }
 
 # @FUNCTION: systemd_get_systempresetdir
@@ -160,7 +129,7 @@ _systemd_get_systempresetdir() {
 systemd_get_systempresetdir() {
debug-print-function ${FUNCNAME} "${@}"
 
-   echo "${EPREFIX}$(_systemd_get_systempresetdir)"
+   _systemd_get_dir systemdsystempresetdir /lib/systemd/system-preset
 }
 
 # @FUNCTION: systemd_dounit
@@ -172,7 +141,7 @@ systemd_dounit() {
 
(
insopts -m 0644
-   insinto "$(_systemd_get_systemunitdir)"
+   insinto "$(_systemd_unprefix systemd_get_systemunitdir)"
doins "${@}"
)
 }
@@ -186,7 +155,7 @@ systemd_newunit() {
 
(
insopts -m 0644
-   insinto "$(_systemd_get_systemunitdir)"
+   insinto "$(_systemd_unprefix systemd_get_systemunitdir)"
newins "${@}"
)
 }
@@ -200,7 +169,7 @@ systemd_douserunit() {
 
(
insopts -m 0644
-   insinto "$(_systemd_get_userunitdir)"
+   insinto "$(_systemd_unprefix systemd_get_userunitdir)"
doins "${@}"
)
 }
@@ -215,7 +184,7 @@ systemd_newuseruni

[gentoo-dev] [PATCH 0/3] systemd.eclass improvements

2022-10-10 Thread Mike Gilbert
A few improvements to systemd.eclass.

Mike Gilbert (3):
  systemd.eclass: rework EPREFIX handling
  systemd.eclass: add systemd_get_sleepdir
  eclass/tests: add systemd tests

 eclass/systemd.eclass   | 77 +++--
 eclass/tests/systemd.sh | 50 ++
 2 files changed, 77 insertions(+), 50 deletions(-)
 create mode 100755 eclass/tests/systemd.sh

-- 
2.37.3




[gentoo-dev] Last rites: net-misc/netkit-bootpd

2022-10-05 Thread Mike Gilbert
# Mike Gilbert  (2022-10-05)
# Implements the obsolete BOOTP protocol; use DHCP instead.
# No activity upstream for over two decades.
# Fails to build with -Werror=implicit-function-declaration (#875536).
# Removal on 2022-11-04.
net-misc/netkit-bootpd



[gentoo-dev] Last rites: app-portage/repoman

2022-09-12 Thread Mike Gilbert
# Mike Gilbert  (2022-09-12)
# repoman is no longer maintained and has been removed from the portage
# git repository. Please use dev-util/pkgcheck and dev-util/pkgdev instead.
# Removal on 2022-11-11. Bug #835013.
app-portage/repoman



[gentoo-dev] [PATCH] Convert 'apparmor' to a global USE flag

2022-09-09 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 app-benchmarks/stress-ng/metadata.xml  | 1 -
 app-containers/containerd/metadata.xml | 1 -
 app-containers/docker/metadata.xml | 3 ---
 app-containers/lxc/metadata.xml| 1 -
 app-containers/lxd/metadata.xml| 3 ---
 app-containers/podman/metadata.xml | 3 ---
 app-containers/runc/metadata.xml   | 3 ---
 app-containers/snapd/metadata.xml  | 3 ---
 app-emulation/libvirt/metadata.xml | 1 -
 media-libs/libextractor/metadata.xml   | 1 -
 profiles/use.desc  | 1 +
 sys-apps/dbus-broker/metadata.xml  | 1 -
 sys-apps/systemd/metadata.xml  | 1 -
 13 files changed, 1 insertion(+), 22 deletions(-)

diff --git a/app-benchmarks/stress-ng/metadata.xml 
b/app-benchmarks/stress-ng/metadata.xml
index 70cc3234093..70bbe8858a5 100644
--- a/app-benchmarks/stress-ng/metadata.xml
+++ b/app-benchmarks/stress-ng/metadata.xml
@@ -14,7 +14,6 @@
and over 20 virtual memory stress tests.


-   Add support for AppArmor.



https://github.com/ColinIanKing/stress-ng/issues
diff --git a/app-containers/containerd/metadata.xml 
b/app-containers/containerd/metadata.xml
index 5641ef37219..5d63e8606e9 100644
--- a/app-containers/containerd/metadata.xml
+++ b/app-containers/containerd/metadata.xml
@@ -17,7 +17,6 @@
Georgy Yakovlev


-   Support for AppArmor
Support for BTRFS snapshot driver
Support for Kubernetes CRI
Support for device mapper snapshot 
driver
diff --git a/app-containers/docker/metadata.xml 
b/app-containers/docker/metadata.xml
index bc364de188b..5f163941881 100644
--- a/app-containers/docker/metadata.xml
+++ b/app-containers/docker/metadata.xml
@@ -21,9 +21,6 @@
Enables dependencies for the "aufs" graph driver, 
including
necessary kernel flags.

-   
-   Enable AppArmor support.
-   

Enables dependencies for the "btrfs" graph driver, 
including
necessary kernel flags.
diff --git a/app-containers/lxc/metadata.xml b/app-containers/lxc/metadata.xml
index 8c08b596f2e..2d20f0346cc 100644
--- a/app-containers/lxc/metadata.xml
+++ b/app-containers/lxc/metadata.xml
@@ -10,7 +10,6 @@
 Gentoo Virtualization Project
   
   
-Enable AppArmor support
 Enable io_uring support, and use io_uring instead of 
epoll
 Build and install additional command line tools
   
diff --git a/app-containers/lxd/metadata.xml b/app-containers/lxd/metadata.xml
index a666d3414c4..dd209643cdb 100644
--- a/app-containers/lxd/metadata.xml
+++ b/app-containers/lxd/metadata.xml
@@ -9,9 +9,6 @@
 virtualizat...@gentoo.org
 Gentoo Virtualization Project
   
-  
-Enable AppArmor support
-  
   
 LXD is a modern, secure and powerful system container and virtual machine 
manager.
 
diff --git a/app-containers/podman/metadata.xml 
b/app-containers/podman/metadata.xml
index 11d7dc7603d..3a429ae4898 100644
--- a/app-containers/podman/metadata.xml
+++ b/app-containers/podman/metadata.xml
@@ -15,9 +15,6 @@
and volumes.


-   
-   Enable AppArmor support.
-   

Enables dependencies for the "btrfs" graph driver, 
including
necessary kernel flags.
diff --git a/app-containers/runc/metadata.xml b/app-containers/runc/metadata.xml
index d27ad6413b0..76423a90314 100644
--- a/app-containers/runc/metadata.xml
+++ b/app-containers/runc/metadata.xml
@@ -14,9 +14,6 @@
Georgy Yakovlev


-   
-   Enable AppArmor support.
-   

Enable Kernel Memory Accounting.

diff --git a/app-containers/snapd/metadata.xml 
b/app-containers/snapd/metadata.xml
index 0109791c93f..730665fd01e 100644
--- a/app-containers/snapd/metadata.xml
+++ b/app-containers/snapd/metadata.xml
@@ -9,9 +9,6 @@
snapcore/snapd


-   
-   Enable AppArmor support.
-   

Automatically disable application confinement if 
feature detection fails.

diff --git a/app-emulation/libvirt/metadata.xml 
b/app-emulation/libvirt/metadata.xml
index aa7a5f87067..9784c19f417 100644
--- a/app-emulation/libvirt/metadata.xml
+++ b/app-emulation/libvirt/metadata.xml
@@ -52,7 +52,6 @@
Support management of VirtualBox virtualisation 
(app-emulation/virtualbox)


-   Enable AppArmor support
Enable dtrace support via 
dev-util/systemtap
Allow LXC to use sys-fs/fuse for 
mountpoints
  

Re: [gentoo-dev] [PATCH 1/8] dist-kernel-utils.eclass: support EAPI 8

2022-09-08 Thread Mike Gilbert
On Thu, Sep 8, 2022 at 1:38 PM Ulrich Mueller  wrote:
>
> >>>>> On Thu, 08 Sep 2022, Mike Gilbert wrote:
>
> > @@ -18,7 +18,7 @@ case "${EAPI:-0}" in
> >   0|1|2|3|4|5|6)
> >   die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
> >   ;;
> > - 7)
> > + 7|8)
> >   ;;
> >   *)
> >   die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
>
> While at it, maybe convert the conditional to the standard form in all
> these eclasses? Like this:
>
> case ${EAPI} in
> 7|8) ;;
> *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
> esac
>
> I'd also drop EAPI 5 where it is applicable.

Done. Check the PR for updates.



[gentoo-dev] [PATCH 8/8] sys-kernel/gentoo-kernel-bin: switch to EAPI 8

2022-09-08 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.10.142.ebuild | 2 +-
 sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.15.67.ebuild  | 2 +-
 sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.19.8.ebuild   | 2 +-
 sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.4.212.ebuild  | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.10.142.ebuild 
b/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.10.142.ebuild
index da84e07f808..6fa6637df87 100644
--- a/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.10.142.ebuild
+++ b/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.10.142.ebuild
@@ -1,7 +1,7 @@
 # Copyright 2020-2022 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
-EAPI=7
+EAPI=8
 
 inherit kernel-install toolchain-funcs
 
diff --git a/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.15.67.ebuild 
b/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.15.67.ebuild
index 0787e9b25ee..f81e1d1736a 100644
--- a/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.15.67.ebuild
+++ b/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.15.67.ebuild
@@ -1,7 +1,7 @@
 # Copyright 2020-2022 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
-EAPI=7
+EAPI=8
 
 inherit kernel-install toolchain-funcs
 
diff --git a/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.19.8.ebuild 
b/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.19.8.ebuild
index 0432fc354ea..368d398ae20 100644
--- a/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.19.8.ebuild
+++ b/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.19.8.ebuild
@@ -1,7 +1,7 @@
 # Copyright 2020-2022 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
-EAPI=7
+EAPI=8
 
 inherit kernel-install toolchain-funcs
 
diff --git a/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.4.212.ebuild 
b/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.4.212.ebuild
index b6c3ce9ca64..f69958baf0a 100644
--- a/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.4.212.ebuild
+++ b/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.4.212.ebuild
@@ -1,7 +1,7 @@
 # Copyright 2020-2022 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
-EAPI=7
+EAPI=8
 
 inherit kernel-install toolchain-funcs
 
-- 
2.37.3




[gentoo-dev] [PATCH 7/8] sys-kernel/gentoo-kernel: switch to EAPI 8

2022-09-08 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 sys-kernel/gentoo-kernel/gentoo-kernel-5.10.142.ebuild | 2 +-
 sys-kernel/gentoo-kernel/gentoo-kernel-5.15.67.ebuild  | 2 +-
 sys-kernel/gentoo-kernel/gentoo-kernel-5.19.8.ebuild   | 2 +-
 sys-kernel/gentoo-kernel/gentoo-kernel-5.4.212.ebuild  | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/sys-kernel/gentoo-kernel/gentoo-kernel-5.10.142.ebuild 
b/sys-kernel/gentoo-kernel/gentoo-kernel-5.10.142.ebuild
index 8cc3f580387..4824ab95a1f 100644
--- a/sys-kernel/gentoo-kernel/gentoo-kernel-5.10.142.ebuild
+++ b/sys-kernel/gentoo-kernel/gentoo-kernel-5.10.142.ebuild
@@ -1,7 +1,7 @@
 # Copyright 2020-2022 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
-EAPI=7
+EAPI=8
 
 inherit kernel-build toolchain-funcs
 
diff --git a/sys-kernel/gentoo-kernel/gentoo-kernel-5.15.67.ebuild 
b/sys-kernel/gentoo-kernel/gentoo-kernel-5.15.67.ebuild
index 64c99e19532..4ea02f952ba 100644
--- a/sys-kernel/gentoo-kernel/gentoo-kernel-5.15.67.ebuild
+++ b/sys-kernel/gentoo-kernel/gentoo-kernel-5.15.67.ebuild
@@ -1,7 +1,7 @@
 # Copyright 2020-2022 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
-EAPI=7
+EAPI=8
 
 inherit kernel-build toolchain-funcs
 
diff --git a/sys-kernel/gentoo-kernel/gentoo-kernel-5.19.8.ebuild 
b/sys-kernel/gentoo-kernel/gentoo-kernel-5.19.8.ebuild
index ca4fd408583..915ecbec450 100644
--- a/sys-kernel/gentoo-kernel/gentoo-kernel-5.19.8.ebuild
+++ b/sys-kernel/gentoo-kernel/gentoo-kernel-5.19.8.ebuild
@@ -1,7 +1,7 @@
 # Copyright 2020-2022 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
-EAPI=7
+EAPI=8
 
 inherit kernel-build toolchain-funcs
 
diff --git a/sys-kernel/gentoo-kernel/gentoo-kernel-5.4.212.ebuild 
b/sys-kernel/gentoo-kernel/gentoo-kernel-5.4.212.ebuild
index ffd40f039fd..5fa543cace3 100644
--- a/sys-kernel/gentoo-kernel/gentoo-kernel-5.4.212.ebuild
+++ b/sys-kernel/gentoo-kernel/gentoo-kernel-5.4.212.ebuild
@@ -1,7 +1,7 @@
 # Copyright 2020-2022 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
-EAPI=7
+EAPI=8
 
 inherit kernel-build
 
-- 
2.37.3




[gentoo-dev] [PATCH 6/8] sys-kernel/vanilla-kernel: switch to EAPI 8

2022-09-08 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 sys-kernel/vanilla-kernel/vanilla-kernel-5.10.142.ebuild | 2 +-
 sys-kernel/vanilla-kernel/vanilla-kernel-5.15.67.ebuild  | 2 +-
 sys-kernel/vanilla-kernel/vanilla-kernel-5.19.8.ebuild   | 2 +-
 sys-kernel/vanilla-kernel/vanilla-kernel-5.4.212.ebuild  | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/sys-kernel/vanilla-kernel/vanilla-kernel-5.10.142.ebuild 
b/sys-kernel/vanilla-kernel/vanilla-kernel-5.10.142.ebuild
index 718e3ea8262..beb11365e70 100644
--- a/sys-kernel/vanilla-kernel/vanilla-kernel-5.10.142.ebuild
+++ b/sys-kernel/vanilla-kernel/vanilla-kernel-5.10.142.ebuild
@@ -1,7 +1,7 @@
 # Copyright 2020-2022 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
-EAPI=7
+EAPI=8
 
 inherit kernel-build toolchain-funcs verify-sig
 
diff --git a/sys-kernel/vanilla-kernel/vanilla-kernel-5.15.67.ebuild 
b/sys-kernel/vanilla-kernel/vanilla-kernel-5.15.67.ebuild
index 13b58c5c983..e9d460c7094 100644
--- a/sys-kernel/vanilla-kernel/vanilla-kernel-5.15.67.ebuild
+++ b/sys-kernel/vanilla-kernel/vanilla-kernel-5.15.67.ebuild
@@ -1,7 +1,7 @@
 # Copyright 2020-2022 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
-EAPI=7
+EAPI=8
 
 inherit kernel-build toolchain-funcs verify-sig
 
diff --git a/sys-kernel/vanilla-kernel/vanilla-kernel-5.19.8.ebuild 
b/sys-kernel/vanilla-kernel/vanilla-kernel-5.19.8.ebuild
index 1b962183c7b..410aa49eb43 100644
--- a/sys-kernel/vanilla-kernel/vanilla-kernel-5.19.8.ebuild
+++ b/sys-kernel/vanilla-kernel/vanilla-kernel-5.19.8.ebuild
@@ -1,7 +1,7 @@
 # Copyright 2020-2022 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
-EAPI=7
+EAPI=8
 
 inherit kernel-build toolchain-funcs verify-sig
 
diff --git a/sys-kernel/vanilla-kernel/vanilla-kernel-5.4.212.ebuild 
b/sys-kernel/vanilla-kernel/vanilla-kernel-5.4.212.ebuild
index bffac796479..ae90752d5ab 100644
--- a/sys-kernel/vanilla-kernel/vanilla-kernel-5.4.212.ebuild
+++ b/sys-kernel/vanilla-kernel/vanilla-kernel-5.4.212.ebuild
@@ -1,7 +1,7 @@
 # Copyright 2020-2022 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
-EAPI=7
+EAPI=8
 
 inherit kernel-build verify-sig
 
-- 
2.37.3




[gentoo-dev] [PATCH 5/8] kernel-build.eclass: support EAPI 8

2022-09-08 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 eclass/kernel-build.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/kernel-build.eclass b/eclass/kernel-build.eclass
index 750a8e873d9..43d46f94108 100644
--- a/eclass/kernel-build.eclass
+++ b/eclass/kernel-build.eclass
@@ -6,7 +6,7 @@
 # Distribution Kernel Project 
 # @AUTHOR:
 # Michał Górny 
-# @SUPPORTED_EAPIS: 7
+# @SUPPORTED_EAPIS: 7 8
 # @PROVIDES: kernel-install
 # @BLURB: Build mechanics for Distribution Kernels
 # @DESCRIPTION:
@@ -26,7 +26,7 @@ case "${EAPI:-0}" in
0|1|2|3|4|5|6)
die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
;;
-   7)
+   7|8)
;;
*)
die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
-- 
2.37.3




[gentoo-dev] [PATCH 4/8] savedconfig.eclass: support EAPI 8

2022-09-08 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 eclass/savedconfig.eclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/eclass/savedconfig.eclass b/eclass/savedconfig.eclass
index 20669c08b33..52286caee6c 100644
--- a/eclass/savedconfig.eclass
+++ b/eclass/savedconfig.eclass
@@ -1,10 +1,10 @@
-# Copyright 1999-2021 Gentoo Authors
+# Copyright 1999-2022 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: savedconfig.eclass
 # @MAINTAINER:
 # base-sys...@gentoo.org
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 5 6 7 8
 # @BLURB: common API for saving/restoring complex configuration files
 # @DESCRIPTION:
 # It is not uncommon to come across a package which has a very fine
@@ -35,7 +35,7 @@ inherit portability
 IUSE="savedconfig"
 
 case ${EAPI} in
-   [5-7]) ;;
+   5|6|7|8) ;;
*) die "EAPI=${EAPI:-0} is not supported" ;;
 esac
 
-- 
2.37.3




[gentoo-dev] [PATCH 3/8] portability.eclass: support EAPI 8

2022-09-08 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 eclass/portability.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/portability.eclass b/eclass/portability.eclass
index 8df8fcebc47..0ef6bd40c21 100644
--- a/eclass/portability.eclass
+++ b/eclass/portability.eclass
@@ -6,11 +6,11 @@
 # base-sys...@gentoo.org
 # @AUTHOR:
 # Diego Pettenò 
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 5 6 7 8
 # @BLURB: This eclass is created to avoid using non-portable GNUisms inside 
ebuilds
 
 case ${EAPI:-0} in
-   [567]) ;;
+   5|6|7|8) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
 esac
 
-- 
2.37.3




[gentoo-dev] [PATCH 2/8] kernel-install.eclass: support EAPI 8

2022-09-08 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 eclass/kernel-install.eclass | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/eclass/kernel-install.eclass b/eclass/kernel-install.eclass
index 8acf1ad1bc0..b7f9abe7bc9 100644
--- a/eclass/kernel-install.eclass
+++ b/eclass/kernel-install.eclass
@@ -6,7 +6,7 @@
 # Distribution Kernel Project 
 # @AUTHOR:
 # Michał Górny 
-# @SUPPORTED_EAPIS: 7
+# @SUPPORTED_EAPIS: 7 8
 # @PROVIDES: dist-kernel-utils
 # @BLURB: Installation mechanics for Distribution Kernels
 # @DESCRIPTION:
@@ -34,7 +34,7 @@ case "${EAPI:-0}" in
0|1|2|3|4|5|6)
die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
;;
-   7)
+   7|8)
;;
*)
die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
@@ -51,14 +51,18 @@ RESTRICT+="
arm? ( test )
 "
 
-# install-DEPEND actually
 # note: we need installkernel with initramfs support!
-RDEPEND="
+INSTALL_DEPEND="
|| (
sys-kernel/installkernel-gentoo
sys-kernel/installkernel-systemd-boot
)
initramfs? ( >=sys-kernel/dracut-049-r3 )"
+if [[ ${EAPI} == 7 ]]; then
+   RDEPEND="${INSTALL_DEPEND}"
+else
+   IDEPEND="${INSTALL_DEPEND}"
+fi
 # needed by objtool that is installed along with the kernel and used
 # to build external modules
 # NB: linux-mod.eclass also adds this dep but it's cleaner to have
-- 
2.37.3




[gentoo-dev] [PATCH 1/8] dist-kernel-utils.eclass: support EAPI 8

2022-09-08 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 eclass/dist-kernel-utils.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/dist-kernel-utils.eclass b/eclass/dist-kernel-utils.eclass
index d192c31db27..649363ad3e4 100644
--- a/eclass/dist-kernel-utils.eclass
+++ b/eclass/dist-kernel-utils.eclass
@@ -6,7 +6,7 @@
 # Distribution Kernel Project 
 # @AUTHOR:
 # Michał Górny 
-# @SUPPORTED_EAPIS: 7
+# @SUPPORTED_EAPIS: 7 8
 # @BLURB: Utility functions related to Distribution Kernels
 # @DESCRIPTION:
 # This eclass provides various utility functions related to Distribution
@@ -18,7 +18,7 @@ case "${EAPI:-0}" in
0|1|2|3|4|5|6)
die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
;;
-   7)
+   7|8)
;;
*)
die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
-- 
2.37.3




[gentoo-dev] [PATCH 0/8] Migrate dist-kernel packages to EAPI 8

2022-09-08 Thread Mike Gilbert
This series adds support for EAPI 8 to relevant eclasses, and updates
the latest version in each kernel branch to EAPI 8.

The only significant change is in kernel-install.eclass where we
populate IDEPEND instead of RDEPEND.

PR: https://github.com/gentoo/gentoo/pull/27191

Mike Gilbert (8):
  dist-kernel-utils.eclass: support EAPI 8
  kernel-install.eclass: support EAPI 8
  portability.eclass: support EAPI 8
  savedconfig.eclass: support EAPI 8
  kernel-build.eclass: support EAPI 8
  sys-kernel/vanilla-kernel: switch to EAPI 8
  sys-kernel/gentoo-kernel: switch to EAPI 8
  sys-kernel/gentoo-kernel-bin: switch to EAPI 8

 eclass/dist-kernel-utils.eclass  |  4 ++--
 eclass/kernel-build.eclass   |  4 ++--
 eclass/kernel-install.eclass | 12 
 eclass/portability.eclass|  4 ++--
 eclass/savedconfig.eclass|  6 +++---
 .../gentoo-kernel-bin-5.10.142.ebuild|  2 +-
 .../gentoo-kernel-bin-5.15.67.ebuild |  2 +-
 .../gentoo-kernel-bin-5.19.8.ebuild  |  2 +-
 .../gentoo-kernel-bin-5.4.212.ebuild |  2 +-
 .../gentoo-kernel/gentoo-kernel-5.10.142.ebuild  |  2 +-
 .../gentoo-kernel/gentoo-kernel-5.15.67.ebuild   |  2 +-
 sys-kernel/gentoo-kernel/gentoo-kernel-5.19.8.ebuild |  2 +-
 .../gentoo-kernel/gentoo-kernel-5.4.212.ebuild   |  2 +-
 .../vanilla-kernel/vanilla-kernel-5.10.142.ebuild|  2 +-
 .../vanilla-kernel/vanilla-kernel-5.15.67.ebuild |  2 +-
 .../vanilla-kernel/vanilla-kernel-5.19.8.ebuild  |  2 +-
 .../vanilla-kernel/vanilla-kernel-5.4.212.ebuild |  2 +-
 17 files changed, 29 insertions(+), 25 deletions(-)

-- 
2.37.3




[gentoo-dev] Re: RFC: virtual/dbus

2022-09-07 Thread Mike Gilbert
On Wed, Sep 7, 2022 at 11:56 AM Marek Szuba  wrote:
>
> Dear everyone,
>
> I wonder if we should create a virtual package to allow our users - or
> at least those who run systemd anyway - to choose between sys-apps/dbus
> and sys-apps/dbus-broken as D-Bus implementation for their systems. The
> usual "Gentoo is about choice" thing aside, there is now at least one,
> security-related, problem with the former which can be worked around by
> switching to the latter: https://github.com/systemd/systemd/issues/22737
>
> WDYT?

A virtual seems a bit pointless for the following reasons:

1. dbus and dbus-broker can be (and usually are) installed simultaneously.
2. dbus-broker[launcher] utilizes config files installed by dbus, and
actually RDEPENDs on sys-apps/dbus for that reason.
3. Many client applications depend on sys-apps/dbus for libdbus.

If you can think of some way to encourage users to install/enable
dbus-broker, that seems like a good idea to me.



Re: [gentoo-dev] Add systemd/merged-usr profiles

2022-09-02 Thread Mike Gilbert
On Fri, Sep 2, 2022 at 11:05 AM Mike Gilbert  wrote:
>
> On Fri, Sep 2, 2022 at 9:01 AM Marc Schiffbauer  wrote:
> >
> > * Mike Gilbert schrieb am 01.09.22 um 03:38 Uhr:
> > > On Wed, Aug 31, 2022 at 12:29 PM Jaco Kroon  wrote:
> > > >
> > > > Hi,
> > > >
> > > > That really depends.
> > > >
> > > > If the expectation is that everything in /usr/{bin,sbin,lib*} needs to 
> > > > now fit on / rather than /usr we're queued to re-install a very, very 
> > > > large number of hosts.
> > >
> > > You have that reversed: the expectation is that everything in
> > > /{bin,sbin,lib} will fit in /usr. In other words, we move files from /
> > > into /usr.
> >
> > So does this mean, that having /usr on a seperate filesystem remains
> > "supported" but is now only possible with a proper initrd?
>
> Switching to merged-usr does make it pretty much impossible to boot
> without an initramfs if /usr is on a separate filesystem.
>
> Having /usr on a separate filesystem without an initramfs to mount it
> has been "unsupported" for several years; the council made a decision
> on that in 2013 [1].
>
> [1] https://projects.gentoo.org/council/meeting-logs/20130813-summary.txt

To more directly answer your question: yes, having /usr on a separate
filesystem is still "supported" with an appropriate initramfs.



Re: [gentoo-dev] Add systemd/merged-usr profiles

2022-09-02 Thread Mike Gilbert
On Fri, Sep 2, 2022 at 9:01 AM Marc Schiffbauer  wrote:
>
> * Mike Gilbert schrieb am 01.09.22 um 03:38 Uhr:
> > On Wed, Aug 31, 2022 at 12:29 PM Jaco Kroon  wrote:
> > >
> > > Hi,
> > >
> > > That really depends.
> > >
> > > If the expectation is that everything in /usr/{bin,sbin,lib*} needs to 
> > > now fit on / rather than /usr we're queued to re-install a very, very 
> > > large number of hosts.
> >
> > You have that reversed: the expectation is that everything in
> > /{bin,sbin,lib} will fit in /usr. In other words, we move files from /
> > into /usr.
>
> So does this mean, that having /usr on a seperate filesystem remains
> "supported" but is now only possible with a proper initrd?

Switching to merged-usr does make it pretty much impossible to boot
without an initramfs if /usr is on a separate filesystem.

Having /usr on a separate filesystem without an initramfs to mount it
has been "unsupported" for several years; the council made a decision
on that in 2013 [1].

[1] https://projects.gentoo.org/council/meeting-logs/20130813-summary.txt



Re: [gentoo-dev] Add systemd/merged-usr profiles

2022-08-31 Thread Mike Gilbert
On Wed, Aug 31, 2022 at 12:29 PM Jaco Kroon  wrote:
>
> Hi,
>
> That really depends.
>
> If the expectation is that everything in /usr/{bin,sbin,lib*} needs to now 
> fit on / rather than /usr we're queued to re-install a very, very large 
> number of hosts.

You have that reversed: the expectation is that everything in
/{bin,sbin,lib} will fit in /usr. In other words, we move files from /
into /usr.



Re: [gentoo-dev] Add systemd/merged-usr profiles

2022-08-31 Thread Mike Gilbert
On Wed, Aug 31, 2022 at 12:01 PM Jeff Gazso  wrote:
>
> Just out of curiosity, how much pain is this likely to cause existing 
> installations that will need to migrate from a split-usr setup to a 
> merged-usr setup?

We haven't deployed this to users, so feedback is limited thus far.

At least a handful of Gentoo devs have successfully migrated real
systems from split-usr to merged-usr without any major problems. It's
a relatively simple process: move the existing files (see
sys-apps/merge-usr), flip the split-usr USE flag off, and then run
"emege --update --deep --changed-use @world".

The only pain point I see is for users with /usr on a separate
filesystem and that are not using an appropriate initramfs. This has
been an "unsupported" configuration on Gentoo for several years, but
there are probably some users who do it anyway.



[gentoo-dev] [PATCH 4/4] profiles/profiles.desc: fix alignment

2022-08-30 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 profiles/profiles.desc | 288 -
 1 file changed, 144 insertions(+), 144 deletions(-)

diff --git a/profiles/profiles.desc b/profiles/profiles.desc
index 4bc94f910ab..0a8a4d84bfb 100644
--- a/profiles/profiles.desc
+++ b/profiles/profiles.desc
@@ -7,47 +7,47 @@
 # DO NOT ADD PROFILES WITH A "die" or "exit" IN THEM OR IT KILLS REPOMAN
 #
 #layout:
-#arch  profile_directory   status
+#arch  profile_directory   
status
 
 # Alpha Profiles
 # @MAINTAINER: al...@gentoo.org
-alpha  default/linux/alpha/17.0exp
-alpha  default/linux/alpha/17.0/systemdexp
+alpha  default/linux/alpha/17.0
exp
+alpha  default/linux/alpha/17.0/systemd
exp
 alpha  default/linux/alpha/17.0/systemd/merged-usr 
exp
-alpha  default/linux/alpha/17.0/desktopexp
-alpha  default/linux/alpha/17.0/desktop/gnome  exp
-alpha  default/linux/alpha/17.0/desktop/gnome/systemd  exp
+alpha  default/linux/alpha/17.0/desktop
exp
+alpha  default/linux/alpha/17.0/desktop/gnome  
exp
+alpha  default/linux/alpha/17.0/desktop/gnome/systemd  
exp
 alpha  default/linux/alpha/17.0/desktop/gnome/systemd/merged-usr   
exp
-alpha  default/linux/alpha/17.0/developer  exp
+alpha  default/linux/alpha/17.0/developer  
exp
 
 # SYMLINK_LIB=no profiles
 # Run app-portage/unsymlink-lib *before* switching the profile.
 # @MAINTAINER: mgo...@gentoo.org
-amd64  default/linux/amd64/17.1stable
-amd64  default/linux/amd64/17.1/selinuxstable
-amd64  default/linux/amd64/17.1/hardened   stable
-amd64  default/linux/amd64/17.1/hardened/selinux   stable
-amd64  default/linux/amd64/17.1/desktopstable
-amd64  default/linux/amd64/17.1/desktop/gnome  stable
-amd64  default/linux/amd64/17.1/desktop/gnome/systemd  stable
+amd64  default/linux/amd64/17.1
stable
+amd64  default/linux/amd64/17.1/selinux
stable
+amd64  default/linux/amd64/17.1/hardened   
stable
+amd64  default/linux/amd64/17.1/hardened/selinux   
stable
+amd64  default/linux/amd64/17.1/desktop
stable
+amd64  default/linux/amd64/17.1/desktop/gnome  
stable
+amd64  default/linux/amd64/17.1/desktop/gnome/systemd  
stable
 amd64  default/linux/amd64/17.1/desktop/gnome/systemd/merged-usr   
dev
-amd64  default/linux/amd64/17.1/desktop/plasma stable
-amd64  default/linux/amd64/17.1/desktop/plasma/systemd stable
+amd64  default/linux/amd64/17.1/desktop/plasma 
stable
+amd64  default/linux/amd64/17.1/desktop/plasma/systemd 
stable
 amd64  default/linux/amd64/17.1/desktop/plasma/systemd/merged-usr  
dev
-amd64  default/linux/amd64/17.1/desktop/systemdstable
+amd64  default/linux/amd64/17.1/desktop/systemd
stable
 amd64  default/linux/amd64/17.1/desktop/systemd/merged-usr 
dev
-amd64  default/linux/amd64/17.1/developer  exp
-amd64  default/linux/amd64/17.1/no-multilibstable
-amd64  default/linux/amd64/17.1/no-multilib/hardened   stable
-amd64  default/linux/amd64/17.1/no-multilib/hardened/selinux   stable
-amd64  default/linux/amd64/17.1/no-multilib/systemddev
+amd64  default/linux/amd64/17.1/developer  
exp
+amd64  default/linux/amd64/17.1/no-multilib
stable
+amd64  default/linux/amd64/17.1/no-multilib/hardened   
stable
+amd64  default/linux/amd64/17.1/no-multilib/hardened/selinux   
stable
+amd64  default/linux/amd64/17.1/no-multilib/systemd
dev
 amd64  default/linux/amd64/17.1/no-multilib/systemd/merged-usr 
dev
-amd64  default/linux/amd64/17.1/no-multilib/systemd/selinuxexp
-amd64  default/linux/amd64/17.1/systemdstable
+amd64  default/linux/amd64/17.1/no-multilib/systemd/selinux
exp
+amd64  default/linu

[gentoo-dev] [PATCH 3/4] profiles/profiles.desc: add systemd/merged-usr subprofiles

2022-08-30 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 profiles/profiles.desc | 54 ++
 1 file changed, 54 insertions(+)

diff --git a/profiles/profiles.desc b/profiles/profiles.desc
index 894b0377d33..4bc94f910ab 100644
--- a/profiles/profiles.desc
+++ b/profiles/profiles.desc
@@ -13,9 +13,11 @@
 # @MAINTAINER: al...@gentoo.org
 alpha  default/linux/alpha/17.0exp
 alpha  default/linux/alpha/17.0/systemdexp
+alpha  default/linux/alpha/17.0/systemd/merged-usr 
exp
 alpha  default/linux/alpha/17.0/desktopexp
 alpha  default/linux/alpha/17.0/desktop/gnome  exp
 alpha  default/linux/alpha/17.0/desktop/gnome/systemd  exp
+alpha  default/linux/alpha/17.0/desktop/gnome/systemd/merged-usr   
exp
 alpha  default/linux/alpha/17.0/developer  exp
 
 # SYMLINK_LIB=no profiles
@@ -28,16 +30,21 @@ amd64   
default/linux/amd64/17.1/hardened/selinux   stable
 amd64  default/linux/amd64/17.1/desktopstable
 amd64  default/linux/amd64/17.1/desktop/gnome  stable
 amd64  default/linux/amd64/17.1/desktop/gnome/systemd  stable
+amd64  default/linux/amd64/17.1/desktop/gnome/systemd/merged-usr   
dev
 amd64  default/linux/amd64/17.1/desktop/plasma stable
 amd64  default/linux/amd64/17.1/desktop/plasma/systemd stable
+amd64  default/linux/amd64/17.1/desktop/plasma/systemd/merged-usr  
dev
 amd64  default/linux/amd64/17.1/desktop/systemdstable
+amd64  default/linux/amd64/17.1/desktop/systemd/merged-usr 
dev
 amd64  default/linux/amd64/17.1/developer  exp
 amd64  default/linux/amd64/17.1/no-multilibstable
 amd64  default/linux/amd64/17.1/no-multilib/hardened   stable
 amd64  default/linux/amd64/17.1/no-multilib/hardened/selinux   stable
 amd64  default/linux/amd64/17.1/no-multilib/systemddev
+amd64  default/linux/amd64/17.1/no-multilib/systemd/merged-usr 
dev
 amd64  default/linux/amd64/17.1/no-multilib/systemd/selinuxexp
 amd64  default/linux/amd64/17.1/systemdstable
+amd64  default/linux/amd64/17.1/systemd/merged-usr 
dev
 amd64  default/linux/amd64/17.1/systemd/selinuxexp
 amd64  default/linux/amd64/17.1/clang  exp
 amd64  default/linux/amd64/17.1/systemd/clang  exp
@@ -66,8 +73,10 @@ arm  default/linux/arm/17.0  
stable
 armdefault/linux/arm/17.0/desktop  dev
 armdefault/linux/arm/17.0/desktop/gnomedev
 armdefault/linux/arm/17.0/desktop/gnome/systemddev
+armdefault/linux/arm/17.0/desktop/gnome/systemd/merged-usr 
dev
 armdefault/linux/arm/17.0/desktop/plasma   dev
 armdefault/linux/arm/17.0/desktop/plasma/systemd   dev
+armdefault/linux/arm/17.0/desktop/plasma/systemd/merged-usr
dev
 armdefault/linux/arm/17.0/developerexp
 armdefault/linux/arm/17.0/armv4dev
 armdefault/linux/arm/17.0/armv4/desktopdev
@@ -80,12 +89,14 @@ arm default/linux/arm/17.0/armv4t/desktop/gnome 
dev
 armdefault/linux/arm/17.0/armv4t/desktop/plasmadev
 armdefault/linux/arm/17.0/armv4t/developer exp
 armdefault/linux/arm/17.0/armv4t/systemd   dev
+armdefault/linux/arm/17.0/armv4t/systemd/merged-usr
dev
 armdefault/linux/arm/17.0/armv5te  dev
 armdefault/linux/arm/17.0/armv5te/desktop  dev
 armdefault/linux/arm/17.0/armv5te/desktop/gnomedev
 armdefault/linux/arm/17.0/armv5te/desktop/plasma   dev
 armdefault/linux/arm/17.0/armv5te/developerexp
 armdefault/linux/arm/17.0/armv5te/systemd  dev
+armdefault/linux/arm/17.0/armv5te/systemd/merged-usr   
dev
 armdefault/linux/arm/17.0/armv6j   stable
 armdefault/linux/arm/17.0/armv6j/hardened  exp
 armdefault/linux/arm/17.0/armv7a/hardened/selinux  exp
@@ -95,16 +106,21 @@ arm
default/linux/arm/17.0/armv6j/desktop/plasmadev
 armdefault/linux/arm/17.0/armv6j/developer exp
 armdefault/linux/arm/17.0/armv6j/selinux   exp
 armdefault/linux/arm/17.0/armv6j/systemd   dev
+armdefault/linux/arm/17.0/armv6j/systemd/merged-usr
dev
 arm

[gentoo-dev] [PATCH 2/4] profiles/default/linux: add systemd/merged-usr subprofiles

2022-08-30 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 .../linux/alpha/17.0/desktop/gnome/systemd/merged-usr/eapi  | 1 +
 .../linux/alpha/17.0/desktop/gnome/systemd/merged-usr/parent| 2 ++
 profiles/default/linux/alpha/17.0/systemd/merged-usr/eapi   | 1 +
 profiles/default/linux/alpha/17.0/systemd/merged-usr/parent | 2 ++
 .../linux/amd64/17.1/desktop/gnome/systemd/merged-usr/eapi  | 1 +
 .../linux/amd64/17.1/desktop/gnome/systemd/merged-usr/parent| 2 ++
 .../linux/amd64/17.1/desktop/plasma/systemd/merged-usr/eapi | 1 +
 .../linux/amd64/17.1/desktop/plasma/systemd/merged-usr/parent   | 2 ++
 .../default/linux/amd64/17.1/desktop/systemd/merged-usr/eapi| 1 +
 .../default/linux/amd64/17.1/desktop/systemd/merged-usr/parent  | 2 ++
 .../linux/amd64/17.1/no-multilib/systemd/merged-usr/eapi| 1 +
 .../linux/amd64/17.1/no-multilib/systemd/merged-usr/parent  | 2 ++
 profiles/default/linux/amd64/17.1/systemd/merged-usr/eapi   | 1 +
 profiles/default/linux/amd64/17.1/systemd/merged-usr/parent | 2 ++
 profiles/default/linux/arm/17.0/armv4t/systemd/merged-usr/eapi  | 1 +
 .../default/linux/arm/17.0/armv4t/systemd/merged-usr/parent | 2 ++
 profiles/default/linux/arm/17.0/armv5te/systemd/merged-usr/eapi | 1 +
 .../default/linux/arm/17.0/armv5te/systemd/merged-usr/parent| 2 ++
 profiles/default/linux/arm/17.0/armv6j/systemd/merged-usr/eapi  | 1 +
 .../default/linux/arm/17.0/armv6j/systemd/merged-usr/parent | 2 ++
 .../linux/arm/17.0/armv7a/desktop/gnome/systemd/merged-usr/eapi | 1 +
 .../arm/17.0/armv7a/desktop/gnome/systemd/merged-usr/parent | 2 ++
 .../arm/17.0/armv7a/desktop/plasma/systemd/merged-usr/eapi  | 1 +
 .../arm/17.0/armv7a/desktop/plasma/systemd/merged-usr/parent| 2 ++
 profiles/default/linux/arm/17.0/armv7a/systemd/merged-usr/eapi  | 1 +
 .../default/linux/arm/17.0/armv7a/systemd/merged-usr/parent | 2 ++
 .../linux/arm/17.0/desktop/gnome/systemd/merged-usr/eapi| 1 +
 .../linux/arm/17.0/desktop/gnome/systemd/merged-usr/parent  | 2 ++
 .../linux/arm/17.0/desktop/plasma/systemd/merged-usr/eapi   | 1 +
 .../linux/arm/17.0/desktop/plasma/systemd/merged-usr/parent | 2 ++
 .../linux/arm64/17.0/desktop/gnome/systemd/merged-usr/eapi  | 1 +
 .../linux/arm64/17.0/desktop/gnome/systemd/merged-usr/parent| 2 ++
 .../linux/arm64/17.0/desktop/plasma/systemd/merged-usr/eapi | 1 +
 .../linux/arm64/17.0/desktop/plasma/systemd/merged-usr/parent   | 2 ++
 .../default/linux/arm64/17.0/desktop/systemd/merged-usr/eapi| 1 +
 .../default/linux/arm64/17.0/desktop/systemd/merged-usr/parent  | 2 ++
 profiles/default/linux/arm64/17.0/systemd/merged-usr/eapi   | 1 +
 profiles/default/linux/arm64/17.0/systemd/merged-usr/parent | 2 ++
 profiles/default/linux/hppa/17.0/systemd/merged-usr/eapi| 1 +
 profiles/default/linux/hppa/17.0/systemd/merged-usr/parent  | 2 ++
 .../linux/ia64/17.0/desktop/gnome/systemd/merged-usr/eapi   | 1 +
 .../linux/ia64/17.0/desktop/gnome/systemd/merged-usr/parent | 2 ++
 profiles/default/linux/ia64/17.0/systemd/merged-usr/eapi| 1 +
 profiles/default/linux/ia64/17.0/systemd/merged-usr/parent  | 2 ++
 .../loong/22.0/la64v100/lp64d/desktop/systemd/merged-usr/eapi   | 1 +
 .../loong/22.0/la64v100/lp64d/desktop/systemd/merged-usr/parent | 2 ++
 .../linux/loong/22.0/la64v100/lp64d/systemd/merged-usr/eapi | 1 +
 .../linux/loong/22.0/la64v100/lp64d/systemd/merged-usr/parent   | 2 ++
 profiles/default/linux/m68k/17.0/systemd/merged-usr/eapi| 1 +
 profiles/default/linux/m68k/17.0/systemd/merged-usr/parent  | 2 ++
 .../linux/mips/17.0/mipsel/multilib/n64/systemd/merged-usr/eapi | 1 +
 .../mips/17.0/mipsel/multilib/n64/systemd/merged-usr/parent | 2 ++
 .../default/linux/mips/17.0/mipsel/n64/systemd/merged-usr/eapi  | 1 +
 .../linux/mips/17.0/mipsel/n64/systemd/merged-usr/parent| 2 ++
 .../powerpc/ppc32/17.0/desktop/gnome/systemd/merged-usr/eapi| 1 +
 .../powerpc/ppc32/17.0/desktop/gnome/systemd/merged-usr/parent  | 2 ++
 .../17.0/32bit-userland/desktop/gnome/systemd/merged-usr/eapi   | 1 +
 .../17.0/32bit-userland/desktop/gnome/systemd/merged-usr/parent | 2 ++
 .../17.0/64bit-userland/desktop/gnome/systemd/merged-usr/eapi   | 1 +
 .../17.0/64bit-userland/desktop/gnome/systemd/merged-usr/parent | 2 ++
 .../linux/ppc/17.0/desktop/gnome/systemd/merged-usr/eapi| 1 +
 .../linux/ppc/17.0/desktop/gnome/systemd/merged-usr/parent  | 2 ++
 profiles/default/linux/ppc/17.0/systemd/merged-usr/eapi | 1 +
 profiles/default/linux/ppc/17.0/systemd/merged-usr/parent   | 2 ++
 .../linux/ppc64/17.0/desktop/gnome/systemd/merged-usr/eapi  | 1 +
 .../linux/ppc64/17.0/desktop/gnome/systemd/merged-usr/parent| 2 ++
 profiles/default/linux/ppc64/17.0/systemd/merged-usr/eapi   | 1 +
 profiles/default/linux/ppc64/17.0/systemd/merged-usr/parent | 2 ++
 .../linux/ppc64le/17.0/desktop/gnome/systemd/merged-usr/eapi| 1 +
 .../linux/ppc64le/17.0/desktop

[gentoo-dev] [PATCH 1/4] profiles/features/merged-usr: unforce/mask 'split-usr' USE flag

2022-08-30 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 profiles/features/merged-usr/eapi  | 1 +
 profiles/features/merged-usr/use.force | 1 +
 profiles/features/merged-usr/use.mask  | 1 +
 3 files changed, 3 insertions(+)
 create mode 100644 profiles/features/merged-usr/eapi
 create mode 100644 profiles/features/merged-usr/use.force
 create mode 100644 profiles/features/merged-usr/use.mask

diff --git a/profiles/features/merged-usr/eapi 
b/profiles/features/merged-usr/eapi
new file mode 100644
index 000..7ed6ff82de6
--- /dev/null
+++ b/profiles/features/merged-usr/eapi
@@ -0,0 +1 @@
+5
diff --git a/profiles/features/merged-usr/use.force 
b/profiles/features/merged-usr/use.force
new file mode 100644
index 000..115196048d6
--- /dev/null
+++ b/profiles/features/merged-usr/use.force
@@ -0,0 +1 @@
+-split-usr
diff --git a/profiles/features/merged-usr/use.mask 
b/profiles/features/merged-usr/use.mask
new file mode 100644
index 000..a887bff5d14
--- /dev/null
+++ b/profiles/features/merged-usr/use.mask
@@ -0,0 +1 @@
+split-usr
-- 
2.37.2




[gentoo-dev] Add systemd/merged-usr profiles

2022-08-30 Thread Mike Gilbert
This patch series adds a "merged-usr" feature profile, and subprofiles
for each systemd profile.

As background: systemd upstream is preparing to drop support for
split-usr systems soon. All systemd users on Gentoo will eventually
need to migrate to a merged-usr system.




Re: [gentoo-dev] [RFC] Encouraging using hardening options in systemd units

2022-08-25 Thread Mike Gilbert
On Thu, Aug 25, 2022 at 1:41 PM Kenton Groombridge  wrote:
>
> On 22/08/25 01:04PM, Mike Gilbert wrote:
> > We could introduce a new function to install distro-specific overrides
> > in [/usr]/lib/systemd/system.
> >
>
> I think that's a good idea. systemd_{new,do}serviceconf maybe?
>
> As I understand it these should go to /usr/lib/[...].

The correct path to use depends on the type of unit and the
"split-usr" USE flag.

With split-usr enabled, overrides for system service units go in
/lib/systemd/system/foo.service.d.
With split-usr disabled, overrides for system services units go in
/usr/lib/systemd/system/foo.service.d.
Overrides for user service units would always go in
/usr/lib/systemd/user/foo.service.d.

We will be phasing out split-usr later this year due to pressure from
systemd upstream to stop supporting it.

Anyway, there are already functions to get the correct path based on
pkg-config in the systemd.eclass.



Re: [gentoo-dev] [RFC] Encouraging using hardening options in systemd units

2022-08-25 Thread Mike Gilbert
On Thu, Aug 25, 2022 at 10:29 AM Kenton Groombridge  wrote:
>
> On 22/08/25 04:06PM, Florian Schmaus wrote:
> > Wouldn't the proper place for overrides installed by a distributions package
> > manager be
> >
> > /usr/lib/systemd/system/miniflux.service.d/gentoo.conf
> >
>
> Yes... I was wondering that too. Currently systemd_install_serviced installs 
> to
> /etc/systemd/system instead of /usr/lib/systemd/system appears to be wrong.
> systemd's own documentation says distributions should be installing contents 
> to
> /usr/lib/systemd/system while /etc/systemd/system is intended for "System 
> units
> created by the administrator" (users).

The existing function is meant to install "placeholder" drop-ins that
would be populated by the sysadmin.

We could introduce a new function to install distro-specific overrides
in [/usr]/lib/systemd/system.



Re: [gentoo-dev] [RFC] Encouraging using hardening options in systemd units

2022-08-22 Thread Mike Gilbert
On Mon, Aug 22, 2022 at 2:10 PM Kenton Groombridge  wrote:
> What do you think?

I am concerned that people will start mass filing bugs with
suggestions without fully understanding them or without testing them
thoroughly. Please don't do that.

Also, ideally we would not need to provide systemd units at a distro
level, and they would instead be provided by upstream. I certainly
don't want to start installing distro-customized units where upstream
already provides unit files.



Re: [gentoo-dev] [PATCH 1/1] linux-info.eclass: Provide ability to skip CONFIG_* checks

2022-08-05 Thread Mike Gilbert
On Fri, Aug 5, 2022 at 7:15 PM Ionen Wolkens  wrote:
>
> On Fri, Aug 05, 2022 at 06:47:42PM -0400, Mike Pagano wrote:
> > Based upon code from check-reqs.eclass by Andreas Sturmlechner
> >
> > Provide support for users who requested the ability to skip
> > CONFIG_* checks. (e.g. from within a chroot for testing purposes)
> >
> > Bug: https://bugs.gentoo.org/862315
> > Signed-off-by: Mike Pagano 
> > ---
> >   eclass/linux-info.eclass | 11 ++-
> >   1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
> > index 7e130062a..59e86490f 100644
> > --- a/eclass/linux-info.eclass
> > +++ b/eclass/linux-info.eclass
> > @@ -29,6 +29,15 @@
> >   # A Couple of env vars are available to effect usage of this eclass
> >   # These are as follows:
> >
> > +
> > +# @ECLASS_VARIABLE: CHECKCONFIG_DONOTHING
> > +# @USER_VARIABLE
> > +# @DEFAULT_UNSET
> > +# @DESCRIPTION:
> > +# Do not error out in check_extra_config if CONFIG settings are not met.
> > +# This is a user flag and should under _no circumstances_ be set in the 
> > ebuild.
> > +[[ -n ${I_KNOW_WHAT_I_AM_DOING} ]] && CHECKCONFIG_DONOTHING=1
>
> So this enables it if I_KNOW_WHAT_I_AM_DOING is set?
>
> Generally I feel giving more purposes to that variable is a bad idea.
> What starts out as "don't bother me about size/ram checks" ignores
> a lot of other things that may be not be expected.

I agree. Please avoid abusing the I_KNOW_WHAT_I_AM_DOING variable any further.



Re: [gentoo-portage-dev] [PATCH] phase-functions: make ED, EROOT read-only

2022-07-25 Thread Mike Gilbert
On Mon, Jul 25, 2022 at 1:03 PM Fabian Groffen  wrote:
>
> bin/phase-functions.sh: make ED and EROOT read-only too
>
> Like D, make ED and EROOT read-only vars.

Makes sense.



Re: [gentoo-portage-dev] [PATCH] misc-functions: Prefix fixes

2022-07-25 Thread Mike Gilbert
On Mon, Jul 25, 2022 at 12:47 PM Fabian Groffen  wrote:
>
> bin/misc-functions.sh: some Prefix fixes
>
> - ED needs not to exist, whereas D does, so ensure we check for that,
>   and create ED if absent, necessary for further checks to succeed
> - use EPREFIX in INSTALL_MASK

Seems good to me.



Re: [gentoo-portage-dev] [PATCH] world-writable: tune for Prefix

2022-07-25 Thread Mike Gilbert
On Mon, Jul 25, 2022 at 12:41 PM Fabian Groffen  wrote:
>
> bin/install-qa-check.d/90world-writable: include EPREFIX in reports
>
> It is much less confusing and consistent to report full paths including
> the leading EPREFIX.

Makes sense to me.



Re: [gentoo-portage-dev] [PATCH] multilib-strict: fix for Prefix

2022-07-25 Thread Mike Gilbert
On Mon, Jul 25, 2022 at 12:26 PM Fabian Groffen  wrote:
>
> bin/install-qa-check.d/80multilib-strict: use file/find from Prefix
>
> diff --git a/bin/install-qa-check.d/80multilib-strict 
> b/bin/install-qa-check.d/80multilib-strict
> index afd223250..3db4ecce3 100644
> --- a/bin/install-qa-check.d/80multilib-strict
> +++ b/bin/install-qa-check.d/80multilib-strict
> @@ -1,7 +1,7 @@
>  # Strict multilib directory checks
>  multilib_strict_check() {
> if has multilib-strict ${FEATURES} && \
> -  [[ -x /usr/bin/file && -x /usr/bin/find ]] && \
> +  [[ -x ${EPREFIX}/usr/bin/file && -x ${EPREFIX}/usr/bin/find ]] && \
>[[ -n ${MULTILIB_STRICT_DIRS} && -n ${MULTILIB_STRICT_DENY} ]]
> then
> rm -f "${T}/multilib-strict.log"

Seems good to me.



Re: [gentoo-portage-dev] [PATCH] emake: explicitly set SHELL

2022-07-25 Thread Mike Gilbert
On Mon, Jul 25, 2022 at 11:28 AM Fabian Groffen  wrote:
>
> bin/ebuild-helpers/emake: force SHELL to be set
>
> On Prefix systems /bin/sh can be anything, including very ancient.  So
> ensure we're running with bash, since that's what Gentoo Linux is
> expecting /bin/sh to be (by default, at least).
>
> Provide a fallback for the (near impossible) case that we use a bash
> that doesn't set BASH, or when we don't use bash at all.  This is not
> expected, though, as we explicitly require bash throughout all Portage,
> so we don't really care about using a non-Prefixed one, for this really
> shouldn't happen.

I'm a little on the fence about this: in theory, Makefiles should use
POSIX-compatible shell commands unless the author explicitly chooses
to use bash.

I guess we can get away with this since ebuilds always require bash anyway.



Re: [gentoo-portage-dev] [PATCH] 80libraries: add support for Darwin targets

2022-07-25 Thread Mike Gilbert
On Mon, Jul 25, 2022 at 11:38 AM Fabian Groffen  wrote:
>
> bin/install-qa-check.d/80libraries: support Darwin/Mach-O objects
>
> Check for dylib on Darwin, so on everything else.
>
> Signed-off-by: Fabian Groffen 
>
> diff --git a/bin/install-qa-check.d/80libraries 
> b/bin/install-qa-check.d/80libraries
> index 8dc35bb87..a477ec9cb 100644
> --- a/bin/install-qa-check.d/80libraries
> +++ b/bin/install-qa-check.d/80libraries
> @@ -140,7 +140,9 @@ lib_check() {
> local abort="no"
> local a s
> for a in "${ED%/}"/usr/lib*/*.a ; do
> -   s=${a%.a}.so
> +   [[ ${CHOST} == *-darwin* ]] \
> +   && s=${a%.a}.dylib \
> +   || s=${a%.a}.so

I would find this much easier to read if you converted it to an
if/else statement instead of chaining && and ||.



Re: [gentoo-portage-dev] [PATCH] doins: fix D check, add EPREFIX check

2022-07-25 Thread Mike Gilbert
Could you please create a PR at https://github.com/gentoo/portage so
that the CI system can test the changes for this patch series?



Re: [gentoo-dev] Switching default password hashes from sha512 to yescrypt

2022-07-23 Thread Mike Gilbert
On Fri, Jul 22, 2022 at 3:10 PM Mikhail Koliada  wrote:
>
> Hello!
>
>
>
> This idea has been fluctuating in my head for quite a while given that the 
> migration had happened
>
> a while ago [0] and some other major distributions have already adopted 
> yescrypt as their default algo
>
> by now [1]. For us switching is as easy as changing the default use flag in 
> pambase and rehashing the password
>
> with the ‘passwd’ call (a news item will be required).
>
>
>
> What do you think?

Seems like a reasonable idea to me.



Re: [gentoo-dev] [PATCH] glep-0076: Require real name instead of legal name

2022-07-12 Thread Mike Gilbert
On Tue, Jul 12, 2022 at 12:37 PM Ulrich Mueller  wrote:
>
> >>>>> On Tue, 12 Jul 2022, Mike Gilbert wrote:
>
> >> The snarkiness of Michał's comment left aside, in general "the name that
> >> you would use to present yourself to your colleagues" won't work. It is
> >> one of the examples in [1]:
> >>
> >> | 4. People have, at this point in time, one full name which they go by.
> >> | Not so, even in Western countries, where a woman may choose to retain
> >> | her unmarried name at work (where she is already known by that name),
> >> | and use her husband’s surname on social occasions, and even on legal
> >> | documents such as mortgages and loans.
>
> > So what's the problem? That people can have more than one "real name"?
> > Can't they just pick one?
>
> With the suggested new wording she would have to use the name by which
> she is known at work. That may not be the name she prefers otherwise.

The suggested wording uses that as an example.



Re: [gentoo-dev] [PATCH] glep-0076: Require real name instead of legal name

2022-07-12 Thread Mike Gilbert
On Tue, Jul 12, 2022 at 7:47 AM Ulrich Mueller  wrote:
>
> > On Tue, 12 Jul 2022, Michał Górny wrote:
>
> >>  to the commit message as a separate line.  The sign-off must contain
> >> -the committer's legal name as a natural person, i.e., the name that
> >> -would appear in a government issued document.
> >> +the committer's real name as a natural person, i.e., the name that
> >> +you would use to present yourself to your colleagues.
>
> > This is insensitive to people who don't have any colleagues.
>
> The snarkiness of Michał's comment left aside, in general "the name that
> you would use to present yourself to your colleagues" won't work. It is
> one of the examples in [1]:
>
> | 4. People have, at this point in time, one full name which they go by.
> | Not so, even in Western countries, where a woman may choose to retain
> | her unmarried name at work (where she is already known by that name),
> | and use her husband’s surname on social occasions, and even on legal
> | documents such as mortgages and loans.

So what's the problem? That people can have more than one "real name"?
Can't they just pick one?



Re: [gentoo-dev] [PATCH v2] python-utils-r1.eclass: avoid nested ebegin calls

2022-07-11 Thread Mike Gilbert
On Mon, Jul 11, 2022 at 2:20 PM Mike Gilbert  wrote:
>
> On Mon, Jul 11, 2022 at 2:01 PM Anna  wrote:
> >
> > On 2022-07-11 19:57, Ulrich Mueller wrote:
> > > >>>>> On Mon, 11 Jul 2022, Mike Gilbert wrote:
> > >
> > > >> Maybe leave ebegin/eend in place then, which was invented precisely for
> > > >> this use case? What's so bad about nesting it?
> > >
> > > > It leads to odd looking output.
> > >
> > > > https://gitweb.gentoo.org/proj/portage.git/commit/?id=eba088af8f335c0adb386461e6df1267e24800e7
> > >
> > > IIUC it would look like this, with the patch applied:
> > >
> > >  *   task 1
> > >  * Doing task 2 ... [ ok ]
> > >  *   task 1 succeeded
> > >
> > > That's not the most beautiful of outputs either.
> >
> > I think ebegin/eend output should be buffered so it can be nested
> > properly.
> >
>
> My take: the main purpose of ebegin is to inform the user that we are
> starting a silent long-running task. eend tells you the result of that
> task.
>
> Buffering ebegin calls would sort of defeat that purpose of informing
> the user that something is happening.
>
> In other words, I don't think it makes sense to call ebegin before
> starting a task that is expected to produce output. This includes
> tasks that call ebegin themselves, since ebegin always produces
> output.

I've decided this is a hill I don't want to die on, so I've submitted
a PR to update the QA check.

https://github.com/gentoo/portage/pull/854



Re: [gentoo-dev] [PATCH v2] python-utils-r1.eclass: avoid nested ebegin calls

2022-07-11 Thread Mike Gilbert
On Mon, Jul 11, 2022 at 2:49 PM Frederik Pfautsch
 wrote:
>
> Am 11.07.22 um 20:14 schrieb Mike Gilbert:
> > On Mon, Jul 11, 2022 at 1:57 PM Ulrich Mueller  wrote:
> >>
> >>>>>>> On Mon, 11 Jul 2022, Mike Gilbert wrote:
> >>
> >>>> Maybe leave ebegin/eend in place then, which was invented precisely for
> >>>> this use case? What's so bad about nesting it?
> >>
> >>> It leads to odd looking output.
> >>
> >>> https://gitweb.gentoo.org/proj/portage.git/commit/?id=eba088af8f335c0adb386461e6df1267e24800e7
> >>
> >> IIUC it would look like this, with the patch applied:
> >>
> >>   *   task 1
> >>   * Doing task 2 ... [ ok ]
> >>   *   task 1 succeeded
> >>
> >> That's not the most beautiful of outputs either.
> >
> > Right. I would prefer to apply the first patch I submitted instead.
>
> How about output like:
>
>   * Doing task 1 ...
>
>   |  * Doing task 2 ...
>
>   |  \> [ ok ]
>
>   |
>
>   | additional log from task 1
>
>   | line 2 of task 1 log
>
>   \> [ !! ]
>
> This would require keeping track of the current "indentation"
> level/prepend "| " to each output for every level. But not sure if is
> possible/how difficult it is to implement. Just sort of a quick idea.

That seems like it would be somewhat involved to implement, and it
seems like a lot of complexity to solve relatively minor problem.



Re: [gentoo-dev] [PATCH v2] python-utils-r1.eclass: avoid nested ebegin calls

2022-07-11 Thread Mike Gilbert
On Mon, Jul 11, 2022 at 2:01 PM Anna  wrote:
>
> On 2022-07-11 19:57, Ulrich Mueller wrote:
> > >>>>> On Mon, 11 Jul 2022, Mike Gilbert wrote:
> >
> > >> Maybe leave ebegin/eend in place then, which was invented precisely for
> > >> this use case? What's so bad about nesting it?
> >
> > > It leads to odd looking output.
> >
> > > https://gitweb.gentoo.org/proj/portage.git/commit/?id=eba088af8f335c0adb386461e6df1267e24800e7
> >
> > IIUC it would look like this, with the patch applied:
> >
> >  *   task 1
> >  * Doing task 2 ... [ ok ]
> >  *   task 1 succeeded
> >
> > That's not the most beautiful of outputs either.
>
> I think ebegin/eend output should be buffered so it can be nested
> properly.
>

My take: the main purpose of ebegin is to inform the user that we are
starting a silent long-running task. eend tells you the result of that
task.

Buffering ebegin calls would sort of defeat that purpose of informing
the user that something is happening.

In other words, I don't think it makes sense to call ebegin before
starting a task that is expected to produce output. This includes
tasks that call ebegin themselves, since ebegin always produces
output.



Re: [gentoo-dev] [PATCH v2] python-utils-r1.eclass: avoid nested ebegin calls

2022-07-11 Thread Mike Gilbert
On Mon, Jul 11, 2022 at 1:57 PM Ulrich Mueller  wrote:
>
> >>>>> On Mon, 11 Jul 2022, Mike Gilbert wrote:
>
> >> Maybe leave ebegin/eend in place then, which was invented precisely for
> >> this use case? What's so bad about nesting it?
>
> > It leads to odd looking output.
>
> > https://gitweb.gentoo.org/proj/portage.git/commit/?id=eba088af8f335c0adb386461e6df1267e24800e7
>
> IIUC it would look like this, with the patch applied:
>
>  *   task 1
>  * Doing task 2 ... [ ok ]
>  *   task 1 succeeded
>
> That's not the most beautiful of outputs either.

Right. I would prefer to apply the first patch I submitted instead.



Re: [gentoo-dev] [PATCH v2] python-utils-r1.eclass: avoid nested ebegin calls

2022-07-11 Thread Mike Gilbert
On Mon, Jul 11, 2022 at 1:17 PM Ionen Wolkens  wrote:
>
> On Mon, Jul 11, 2022 at 01:08:52PM -0400, Mike Gilbert wrote:
> > On Mon, Jul 11, 2022 at 12:56 PM Ulrich Mueller  wrote:
> > >
> > > >>>>> On Mon, 11 Jul 2022, Ionen Wolkens wrote:
> > > >> -ebegin "  python_check_deps"
> > > >> -python_check_deps
> > > >> -eend ${?}
> > > >> +einfo "  python_check_deps"
> > > >> +if python_check_deps; then
> > > >> +einfo "  python_check_deps succeeded"
> > > >> +else
> > > >> +einfo "  python_check_deps failed"
> > > >> +fi
> > > >> }
> > >
> > > > I was about to go about merging this as suggested, but this masks the
> > > > return value, and then things like this always succeed:
> > >
> > > > if _python_run_check_deps "${impl}"; then
> > >
> > > Maybe leave ebegin/eend in place then, which was invented precisely for
> > > this use case? What's so bad about nesting it?
> >
> > It leads to odd looking output.
> >
> > https://gitweb.gentoo.org/proj/portage.git/commit/?id=eba088af8f335c0adb386461e6df1267e24800e7
> >
>
> Isn't that a portage problem? I don't think stopping legitimate use
> because portage displays messages weird is the right thing to do but
> should rather improve how portage displays them in this situation.

What is a "good" way to display it? I don't really think you can make
ebegin/eend look good when there are lines of output between them.



Re: [gentoo-dev] [PATCH v2] python-utils-r1.eclass: avoid nested ebegin calls

2022-07-11 Thread Mike Gilbert
On Mon, Jul 11, 2022 at 12:11 PM Ionen Wolkens  wrote:
>
> On Mon, Jul 11, 2022 at 09:16:10AM -0400, Mike Gilbert wrote:
> > It's common for python_check_deps to call python_has_version, which
> > calls ebegin itself.
> >
> > Signed-off-by: Mike Gilbert 
> > ---
> >  eclass/python-utils-r1.eclass | 9 ++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> > index a18ca58475f..5c678c524ae 100644
> > --- a/eclass/python-utils-r1.eclass
> > +++ b/eclass/python-utils-r1.eclass
> > @@ -1399,9 +1399,12 @@ _python_run_check_deps() {
> >
> >   local PYTHON_USEDEP="python_targets_${impl}(-)"
> >   local PYTHON_SINGLE_USEDEP="python_single_target_${impl}(-)"
> > - ebegin "  python_check_deps"
> > - python_check_deps
> > - eend ${?}
> > + einfo "  python_check_deps"
> > + if python_check_deps; then
> > + einfo "  python_check_deps succeeded"
> > + else
> > + einfo "  python_check_deps failed"
> > + fi
> >  }
>
> I was about to go about merging this as suggested, but this masks the
> return value, and then things like this always succeed:
>
> if _python_run_check_deps "${impl}"; then

Thanks for catching that.



[gentoo-dev] [PATCH v3] python-utils-r1.eclass: avoid nested ebegin calls

2022-07-11 Thread Mike Gilbert
It's common for python_check_deps to call python_has_version, which
calls ebegin itself.

Closes: https://bugs.gentoo.org/851822
Signed-off-by: Mike Gilbert 
---
 eclass/python-utils-r1.eclass | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index a18ca58475f..ab59db9954e 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -1399,9 +1399,15 @@ _python_run_check_deps() {
 
local PYTHON_USEDEP="python_targets_${impl}(-)"
local PYTHON_SINGLE_USEDEP="python_single_target_${impl}(-)"
-   ebegin "  python_check_deps"
+   einfo "  python_check_deps"
python_check_deps
-   eend ${?}
+   local status=$?
+   if [[ ${status} -eq 0 ]]; then
+   einfo "  python_check_deps succeeded"
+   else
+   einfo "  python_check_deps failed"
+   fi
+   return ${status}
 }
 
 # @FUNCTION: python_has_version
-- 
2.37.0




Re: [gentoo-dev] [PATCH v2] python-utils-r1.eclass: avoid nested ebegin calls

2022-07-11 Thread Mike Gilbert
On Mon, Jul 11, 2022 at 12:56 PM Ulrich Mueller  wrote:
>
> > On Mon, 11 Jul 2022, Ionen Wolkens wrote:
> >> -ebegin "  python_check_deps"
> >> -python_check_deps
> >> -eend ${?}
> >> +einfo "  python_check_deps"
> >> +if python_check_deps; then
> >> +einfo "  python_check_deps succeeded"
> >> +else
> >> +einfo "  python_check_deps failed"
> >> +fi
> >> }
>
> > I was about to go about merging this as suggested, but this masks the
> > return value, and then things like this always succeed:
>
> > if _python_run_check_deps "${impl}"; then
>
> Maybe leave ebegin/eend in place then, which was invented precisely for
> this use case? What's so bad about nesting it?

It leads to odd looking output.

https://gitweb.gentoo.org/proj/portage.git/commit/?id=eba088af8f335c0adb386461e6df1267e24800e7



[gentoo-dev] [PATCH v2] python-utils-r1.eclass: avoid nested ebegin calls

2022-07-11 Thread Mike Gilbert
It's common for python_check_deps to call python_has_version, which
calls ebegin itself.

Signed-off-by: Mike Gilbert 
---
 eclass/python-utils-r1.eclass | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index a18ca58475f..5c678c524ae 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -1399,9 +1399,12 @@ _python_run_check_deps() {
 
local PYTHON_USEDEP="python_targets_${impl}(-)"
local PYTHON_SINGLE_USEDEP="python_single_target_${impl}(-)"
-   ebegin "  python_check_deps"
-   python_check_deps
-   eend ${?}
+   einfo "  python_check_deps"
+   if python_check_deps; then
+   einfo "  python_check_deps succeeded"
+   else
+   einfo "  python_check_deps failed"
+   fi
 }
 
 # @FUNCTION: python_has_version
-- 
2.37.0




Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: avoid nested ebegin calls

2022-07-11 Thread Mike Gilbert
On Mon, Jul 11, 2022 at 3:04 AM Michał Górny  wrote:
>
> On Sun, 2022-07-10 at 23:53 -0400, Mike Gilbert wrote:
> > It's common for python_check_deps to call python_has_version, which
> > calls ebegin itself.
> >
> > Signed-off-by: Mike Gilbert 
> > ---
> >  eclass/python-utils-r1.eclass | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> > index a18ca58475f..acfa83d5e18 100644
> > --- a/eclass/python-utils-r1.eclass
> > +++ b/eclass/python-utils-r1.eclass
> > @@ -1399,9 +1399,8 @@ _python_run_check_deps() {
> >
> >   local PYTHON_USEDEP="python_targets_${impl}(-)"
> >   local PYTHON_SINGLE_USEDEP="python_single_target_${impl}(-)"
> > - ebegin "  python_check_deps"
> > + einfo "  python_check_deps"
> >   python_check_deps
> > - eend ${?}
> >  }
> >
> >  # @FUNCTION: python_has_version
>
> What's the harm in nesting them?

It results in strange looking output, and triggers a QA warning in the
latest version of Portage.



[gentoo-dev] [PATCH] python-utils-r1.eclass: avoid nested ebegin calls

2022-07-10 Thread Mike Gilbert
It's common for python_check_deps to call python_has_version, which
calls ebegin itself.

Signed-off-by: Mike Gilbert 
---
 eclass/python-utils-r1.eclass | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index a18ca58475f..acfa83d5e18 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -1399,9 +1399,8 @@ _python_run_check_deps() {
 
local PYTHON_USEDEP="python_targets_${impl}(-)"
local PYTHON_SINGLE_USEDEP="python_single_target_${impl}(-)"
-   ebegin "  python_check_deps"
+   einfo "  python_check_deps"
python_check_deps
-   eend ${?}
 }
 
 # @FUNCTION: python_has_version
-- 
2.37.0




[gentoo-dev] [PATCH] meson.eclass: add "--no-rebuild" to meson install args

2022-07-09 Thread Mike Gilbert
This avoids rebuilding targets with no dependency information.

Bug: https://bugs.gentoo.org/857180
Signed-off-by: Mike Gilbert 
---
 eclass/meson.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 7ba6501688b..8dec315c1ae 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -427,6 +427,7 @@ meson_install() {
local mesoninstallargs=(
-C "${BUILD_DIR}"
--destdir "${D}"
+   --no-rebuild
"$@"
)
 
-- 
2.37.0




Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing

2022-07-05 Thread Mike Gilbert
On Tue, Jul 5, 2022 at 3:02 PM Georgy Yakovlev  wrote:
>
> ...snip
> >
> > > In that case, I think the only viable way to make this work is to
> > > disable automatic stripping and handle stripping via custom code in
> > > the ebuild/eclass.
> > >
> > might work indeed if we do something like (pseudo-bash)
> >
> > if [[ module_sign == yes ]]; then
> > dostrip -x /lib/modules # to stop portage stripping .ko objects
> > manual-strip-respecting-features-nostrip -r /lib/modules
> > sign-all-modules -r /lib/modules
> > fi
> > [[ compress_modules == yes ]] && compress-modules -r /lib/modules
> >
> >
> > this will equire eapi-bumping couple of packages
> > https://qa-reports.gentoo.org/output/eapi-per-eclass/linux-mod.eclass/6.txt
> > and restricting linux-mod.eclass to eapi7 or later.
> >
> >
> >
> started playing with my old code and got blocked right away:
>
> looks like dostrip just creates a list of files/directories to strip
> and processed at the very end of install phase.
>
> so skipping strip and doing manual one might be problematic.
> internally portage uses estrip
> https://github.com/gentoo/portage/blob/master/bin/estrip
> which contains quite a lot of logic and code and I don't think
> partially re-implementing this in eclass code is appropriate.
>

Looking at the kernel build system, it looks like modules don't get
stripped by default anyway: you have to explicitly pass
INSTALL_MOD_STRIP=1 to make modules_install.

I don't think it would be a major problem to just disable stripping
entirely for out-of-tree modules when module signing is enabled.

Alternatively, forget about trying to reimplement estrip and just
strip the files by calling ${STRIP} --strip-debug, as is done in
scripts/Makefile.modinst in the kernel sources. That will conflict
with FEATURES=splitdebug, but I doubt that's very useful for kernel
developers anyway.



[gentoo-dev] [PATCH] ruby-ng.eclass: replace ebegin with einfo in _ruby_invoke_environment

2022-07-03 Thread Mike Gilbert
Calling ebegin here makes no sense because it is likely that the called
function will also generate output. This will lead to the "[ ok ]"
potentially appearing many lines later.

It also leads to nested ebegin calls, which make no sense for the same
reason.

Closes: https://bugs.gentoo.org/839585
Closes: https://bugs.gentoo.org/839588
Signed-off-by: Mike Gilbert 
---
 eclass/ruby-ng.eclass | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/eclass/ruby-ng.eclass b/eclass/ruby-ng.eclass
index f0d6c4f6f6c..c43d5b4d982 100644
--- a/eclass/ruby-ng.eclass
+++ b/eclass/ruby-ng.eclass
@@ -410,9 +410,8 @@ _ruby_invoke_environment() {
pushd "${WORKDIR}" &>/dev/null || die
fi
 
-   ebegin "Running ${_PHASE:-${EBUILD_PHASE}} phase for $environment"
+   einfo "Running ${_PHASE:-${EBUILD_PHASE}} phase for $environment"
"$@"
-   eend $?
popd &>/dev/null || die
 
S=${old_S}
-- 
2.36.1




Re: [gentoo-dev] [PATCH] epatch.eclass: call ebegin to balance eend

2022-06-28 Thread Mike Gilbert
On Tue, Jun 28, 2022 at 2:05 AM Ulrich Mueller  wrote:
>
> >>>>> On Mon, 27 Jun 2022, Mike Gilbert wrote:
>
> >   if [[ ${SINGLE_PATCH} == "yes" ]] ; then
> >   if [[ -n ${EPATCH_SINGLE_MSG} ]] ; then
> > - einfo "${EPATCH_SINGLE_MSG}"
> > + ebegin "${EPATCH_SINGLE_MSG}"
> >   else
> > - einfo "Applying ${patchname} ..."
> > + ebegin "Applying ${patchname}"
> >   fi
>
> EPATCH_SINGLE_MSG isn't used in the tree, so this could be simplified to
> have the "else" part only, and delete the eclass variable. (Strange idea
> to make this message configurable, in the first place.)
>
> >   else
> > - einfo "  ${patchname} ..."
> > + ebegin "  ${patchname}"
> >   fi
>
> Maybe drop support for EAPIs 0 to 4 while at it?

I made both changes on the github PR.

https://github.com/gentoo/gentoo/pull/26122



Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing

2022-06-27 Thread Mike Gilbert
On Mon, Jun 27, 2022 at 5:11 PM Georgy Yakovlev  wrote:
>
> On Mon, 2022-06-27 at 15:49 -0400, Mike Gilbert wrote:
> > On Mon, Jun 27, 2022 at 3:42 PM Georgy Yakovlev
> >  wrote:
> > >
> > > On Mon, 2022-06-27 at 14:56 -0400, Mike Gilbert wrote:
> > > > On Mon, Jun 27, 2022 at 2:35 PM Kenton Groombridge
> > > >  wrote:
> > > > > > so looks like we need to combine both methods and do the
> > > > > > following:
> > > > > >  - if signing requested without compression - sign in
> > > > > > pkg_preinst.
> > > > > >  - if signing requested with compression - sign in
> > > > > > src_install
> > > > > >
> > > > >
> > > > > Why can't we do both in pkg_preinst? I am thinking it would be
> > > > > best
> > > > > if
> > > > > we drop the current compression implementation and rework your
> > > > > old
> > > > > code
> > > > > to handle both compression and signing since the signing code
> > > > > is
> > > > > more or
> > > > > less already complete.
> > > >
> > > > Signing modules in pkg_preinst seems like a bad idea to me. That
> > > > means
> > > > you need to copy your private keys around to every host where the
> > > > package might be installed.
> > > >
> > > > If you sign in src_compile or src_install, you only need private
> > > > keys
> > > > on the system building your binpkg.
> > > >
> > >
> > > unfortunately portage will unconditionally strip .ko objects,
> > > rendering
> > > modules unloadable by stripping signature,  unless we do dostrip -x
> > > (requires EAPI7+, which should not be a problem nowadays, but was a
> > > problem back in 2018), which can be quite unfortunate on debug
> > > enabled
> > > kernels.
> >
> > Sounds like something to fix/change in Portage. It could probably be
> > updated to not strip the signature. However, I would guess the
> > signature needs to be updated after the binary is modified in any
> > case.
> >
> > Or as a workaround you could disable automatic striping via dostrip -
> > x
> > and run the proper commands to strip the modules in src_install as
> > well.
> >
> I think even strip itself does not have proper options not to break
> module. Several years back it was the case, basically one has to strip
> first, sign second, otherwise module will be unloadable.
>
> "Signed modules are BRITTLE as the signature is outside of the defined
> ELF container. Thus they MAY NOT be stripped once the signature is
> computed and attached. Note the entire module is the signed payload,
> including any and all debug information present at the time of
> signing."
>
> https://www.kernel.org/doc/html/v4.15/admin-guide/module-signing.html#signed-modules-and-stripping
>

In that case, I think the only viable way to make this work is to
disable automatic stripping and handle stripping via custom code in
the ebuild/eclass.



Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing

2022-06-27 Thread Mike Gilbert
On Mon, Jun 27, 2022 at 3:42 PM Georgy Yakovlev  wrote:
>
> On Mon, 2022-06-27 at 14:56 -0400, Mike Gilbert wrote:
> > On Mon, Jun 27, 2022 at 2:35 PM Kenton Groombridge
> >  wrote:
> > > > so looks like we need to combine both methods and do the
> > > > following:
> > > >  - if signing requested without compression - sign in
> > > > pkg_preinst.
> > > >  - if signing requested with compression - sign in src_install
> > > >
> > >
> > > Why can't we do both in pkg_preinst? I am thinking it would be best
> > > if
> > > we drop the current compression implementation and rework your old
> > > code
> > > to handle both compression and signing since the signing code is
> > > more or
> > > less already complete.
> >
> > Signing modules in pkg_preinst seems like a bad idea to me. That
> > means
> > you need to copy your private keys around to every host where the
> > package might be installed.
> >
> > If you sign in src_compile or src_install, you only need private keys
> > on the system building your binpkg.
> >
>
> unfortunately portage will unconditionally strip .ko objects, rendering
> modules unloadable by stripping signature,  unless we do dostrip -x
> (requires EAPI7+, which should not be a problem nowadays, but was a
> problem back in 2018), which can be quite unfortunate on debug enabled
> kernels.

Sounds like something to fix/change in Portage. It could probably be
updated to not strip the signature. However, I would guess the
signature needs to be updated after the binary is modified in any
case.

Or as a workaround you could disable automatic striping via dostrip -x
and run the proper commands to strip the modules in src_install as
well.



Re: [gentoo-dev] [PATCH] java-vm-2.eclass: use "eselect java-vm update" if available

2022-06-27 Thread Mike Gilbert
On Mon, Jun 27, 2022 at 3:39 PM Georgy Yakovlev  wrote:
>
> On Mon, 2022-06-27 at 21:21 +0200, Florian Schmaus wrote:
> > Thanks to Mike Gilbert (floppym) for valuable feedback.
> >
> > Closes: https://bugs.gentoo.org/853928
> > Closes: https://github.com/gentoo/gentoo/pull/26069
> > Signed-off-by: Florian Schmaus 
> > ---
> >  eclass/java-vm-2.eclass | 30 --
> >  1 file changed, 28 insertions(+), 2 deletions(-)
> >
> > diff --git a/eclass/java-vm-2.eclass b/eclass/java-vm-2.eclass
> > index 8196b1cdc72a..dc0d87f4caf5 100644
> > --- a/eclass/java-vm-2.eclass
> > +++ b/eclass/java-vm-2.eclass
> > @@ -25,6 +25,7 @@ RDEPEND="
> >  "
> >  DEPEND="${RDEPEND}"
> >  BDEPEND="app-arch/unzip"
> > +IDEPEND="app-eselect/eselect-java"
>
> IDEPEND here will not do anything to current jdk source ebuilds.

I think that's fine. The eclass claims to support EAPI 8, so this will
make IDEPEND work properly if/when you update the JDK ebuilds.



Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing

2022-06-27 Thread Mike Gilbert
On Mon, Jun 27, 2022 at 2:35 PM Kenton Groombridge  wrote:
> > so looks like we need to combine both methods and do the following:
> >  - if signing requested without compression - sign in pkg_preinst.
> >  - if signing requested with compression - sign in src_install
> >
>
> Why can't we do both in pkg_preinst? I am thinking it would be best if
> we drop the current compression implementation and rework your old code
> to handle both compression and signing since the signing code is more or
> less already complete.

Signing modules in pkg_preinst seems like a bad idea to me. That means
you need to copy your private keys around to every host where the
package might be installed.

If you sign in src_compile or src_install, you only need private keys
on the system building your binpkg.



[gentoo-dev] [PATCH] epatch.eclass: call ebegin to balance eend

2022-06-27 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 eclass/epatch.eclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/eclass/epatch.eclass b/eclass/epatch.eclass
index 6a9c460da0a..6d000419b03 100644
--- a/eclass/epatch.eclass
+++ b/eclass/epatch.eclass
@@ -236,12 +236,12 @@ epatch() {
 
if [[ ${SINGLE_PATCH} == "yes" ]] ; then
if [[ -n ${EPATCH_SINGLE_MSG} ]] ; then
-   einfo "${EPATCH_SINGLE_MSG}"
+   ebegin "${EPATCH_SINGLE_MSG}"
else
-   einfo "Applying ${patchname} ..."
+   ebegin "Applying ${patchname}"
fi
else
-   einfo "  ${patchname} ..."
+   ebegin "  ${patchname}"
fi
 
# Handle aliased patch command #404447 #461568
-- 
2.36.1




Re: [gentoo-dev] Re: [PATCH 1/2] flag-o-matic.eclass: have is-flagq respect succeeding -fno-flag

2022-06-27 Thread Mike Gilbert
On Mon, Jun 27, 2022 at 10:55 AM Jannik Glückert
 wrote:
>
> This is not for stripping flags, it's for detecting a flag and e.g.
> changing the configure invocation accordingly.
>
> E.g. libreoffice has
> is-flagq "-flto*" && myeconfargs+=( --enable-lto )

Ah, that makes more sense. Thanks for explaining.



Re: [gentoo-dev] Can app-office/sc be replaced by app-office/sc-im from GURU?

2022-06-27 Thread Mike Gilbert
On Sun, Jun 26, 2022 at 11:24 PM Jeff Gazso  wrote:
> My thought is unless some serious deficiency is present in
> app-office/sc-im it should be moved to Gentoo's main ebuild repository
> and the last rites process should be started for app-office/sc. Does
> anyone else have thoughts or comments on this?

We could probably last rite app-office/sc. It has no maintainer, and a
couple of open bugs.

Moving app-office/sc-im to the Gentoo repo is a bit more of an ask.
Ideally, a Gentoo developer would maintain it. Alternatively, a
non-developer could maintain it by proxy, but you would need to find a
developer to act as proxy or get approval from the Proxy Maintainers
project. In any case, you should probably reach out to the current
maintainer in GURU to see what he wants to do.



[gentoo-dev] Re: [PATCH 1/2] flag-o-matic.eclass: have is-flagq respect succeeding -fno-flag

2022-06-27 Thread Mike Gilbert
On Mon, Jun 27, 2022 at 3:04 AM Sam James  wrote:
>
> From: Jannik Glückert 
>
> Handle bits like -flto -fno-lto.

Why would we care about this? If we just strip the -flto out, that
leaves -fno-lto and the result is the same.

What am I missing?



[gentoo-dev] [PATCH] toolchain-funcs.eclass: set LC_ALL=C where appropriate

2022-06-24 Thread Mike Gilbert
tc-ld-is-gold and tc-ld-is-lld check the output of ld --version.
This output may vary depending on the language selected by the user.
Set LC_ALL=C to force English output.

Bug: https://bugs.gentoo.org/854147
Signed-off-by: Mike Gilbert 
---
 eclass/toolchain-funcs.eclass | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index 54d4b0912a6..17c075895d5 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -453,6 +453,9 @@ econf_build() {
 tc-ld-is-gold() {
local out
 
+   # Ensure ld output is in English.
+   local -x LC_ALL=C
+
# First check the linker directly.
out=$($(tc-getLD "$@") --version 2>&1)
if [[ ${out} == *"GNU gold"* ]] ; then
@@ -483,6 +486,9 @@ tc-ld-is-gold() {
 tc-ld-is-lld() {
local out
 
+   # Ensure ld output is in English.
+   local -x LC_ALL=C
+
# First check the linker directly.
out=$($(tc-getLD "$@") --version 2>&1)
if [[ ${out} == *"LLD"* ]] ; then
-- 
2.36.1




[gentoo-dev] [PATCH] user.eclass: allow UID/GID 0 in enewuser/enewgroup

2022-06-24 Thread Mike Gilbert
Used by acct-{user,group}/root.

The check is skipped on most systems because root is created by baselayout.
An error may be produced if a user runs emerge --root=/myroot
acct-user/root, where /myroot is an empty directory.

Signed-off-by: Mike Gilbert 
---
 eclass/user.eclass | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/eclass/user.eclass b/eclass/user.eclass
index 906e84e83c6..d5b827d2e76 100644
--- a/eclass/user.eclass
+++ b/eclass/user.eclass
@@ -123,13 +123,13 @@ enewuser() {
# handle uid
local euid=${1}; shift
if [[ -n ${euid} && ${euid} != -1 ]] ; then
-   if [[ ${euid} -gt 0 ]] ; then
+   if [[ ${euid} -ge 0 ]] ; then
if [[ -n $(egetent passwd ${euid}) ]] ; then
[[ -n ${force_uid} ]] && die "${FUNCNAME}: UID 
${euid} already taken"
euid="next"
fi
else
-   eerror "Userid given but is not greater than 0!"
+   eerror "Userid given but is not greater than or equal 
to 0!"
die "${euid} is not a valid UID"
fi
else
@@ -289,13 +289,13 @@ enewgroup() {
# handle gid
local egid=${1}; shift
if [[ -n ${egid} && ${egid} != -1 ]] ; then
-   if [[ ${egid} -gt 0 ]] ; then
+   if [[ ${egid} -ge 0 ]] ; then
if [[ -n $(egetent group ${egid}) ]] ; then
[[ -n ${force_gid} ]] && die "${FUNCNAME}: GID 
${egid} already taken"
egid="next available; requested gid taken"
fi
else
-   eerror "Groupid given but is not greater than 0!"
+   eerror "Groupid given but is not greater than or equal 
to 0!"
die "${egid} is not a valid GID"
fi
else
-- 
2.36.1




[gentoo-dev] [PATCH] install-qa-check.d/60udev-eclass: check for udev_reload in pkg_postrm

2022-06-04 Thread Mike Gilbert
Bug: https://bugs.gentoo.org/847436
Signed-off-by: Mike Gilbert 
---
 metadata/install-qa-check.d/60udev-eclass | 5 +
 1 file changed, 5 insertions(+)

diff --git a/metadata/install-qa-check.d/60udev-eclass 
b/metadata/install-qa-check.d/60udev-eclass
index 4aadc9b1f18..24a4df38ec4 100644
--- a/metadata/install-qa-check.d/60udev-eclass
+++ b/metadata/install-qa-check.d/60udev-eclass
@@ -54,6 +54,11 @@ udev_rules_check() {
eqawarn "QA Notice: package is installing udev rules 
without calling"
eqawarn "udev_reload in pkg_postinst phase"
fi
+   local pkg_postrm_body="$(declare -fp pkg_postrm 2>&1)"
+   if [[ ! ${pkg_postrm_body} == *udev_reload* ]] ; then
+   eqawarn "QA Notice: package is installing udev rules 
without calling"
+   eqawarn "udev_reload in pkg_postrm phase"
+   fi
fi
 }
 
-- 
2.35.1




[gentoo-dev] [PATCH] udev.eclass: document when udev_reload should be called

2022-06-04 Thread Mike Gilbert
Closes: https://bugs.gentoo.org/847436
Signed-off-by: Mike Gilbert 
---
 eclass/udev.eclass | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/eclass/udev.eclass b/eclass/udev.eclass
index 073e5d8acbc..830e3eeb125 100644
--- a/eclass/udev.eclass
+++ b/eclass/udev.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: udev.eclass
@@ -26,6 +26,14 @@
 #  # udev_dorules contrib/99-foomatic
 #  # udev_newrules contrib/98-foomatic 99-foomatic
 # }
+#
+# pkg_postinst() {
+#  udev_reload
+# }
+#
+# pkg_postrm() {
+#  udev_reload
+# }
 # @CODE
 
 case ${EAPI} in
@@ -110,7 +118,9 @@ udev_newrules() {
 
 # @FUNCTION: udev_reload
 # @DESCRIPTION:
-# Run udevadm control --reload to refresh rules and databases
+# Run "udevadm control --reload" to refresh rules and databases.
+# Should be called from pkg_postinst and pkg_postrm in packages which install
+# udev rules or hwdb data.
 udev_reload() {
if [[ -n ${ROOT%/} ]]; then
return 0
-- 
2.35.1




Re: [gentoo-dev] [PATCH 1/5] ninja-utils.eclass: Support dev-util/samurai

2022-05-30 Thread Mike Gilbert
On Mon, May 30, 2022 at 3:57 PM Anna “CyberTailor”
 wrote:
>
> On 2022-05-08 23:07, Sam James wrote:
> > From: orbea 
> >
> > samurai is a ninja-compatible build tool written in C which
> > works with cmake, meson and other users of ninja.
> >
> > It is feature-complete and supports most of the same options
> > as ninja.
> >
> > Signed-off-by: orbea 
> > Signed-off-by: Sam James 
> > ---
> >  eclass/ninja-utils.eclass | 24 +++-
> >  1 file changed, 23 insertions(+), 1 deletion(-)
> >
> > diff --git a/eclass/ninja-utils.eclass b/eclass/ninja-utils.eclass
> > index c5f34934192f..67f7a6b5e8a7 100644
> > --- a/eclass/ninja-utils.eclass
> > +++ b/eclass/ninja-utils.eclass
> > @@ -26,6 +26,15 @@ esac
> >  if [[ -z ${_NINJA_UTILS_ECLASS} ]]; then
> >  _NINJA_UTILS_ECLASS=1
> >
> > +# @ECLASS_VARIABLE: NINJA
> > +# @PRE_INHERIT
>
> How about making it @USER_VARIABLE instead? Because it's more likely to
> be set in make.conf rather than in an ebuild.

It's "unofficially" supported as a user variable. If users set it in
make.conf, it will break metadata invariance and the dependency cache
will need to be rebuilt.

If we truly want to support it as a user variable, we need to provide
some alternate means of varying BDEPEND.



Re: [gentoo-dev] packages touching files in /dev

2022-05-23 Thread Mike Gilbert
On Mon, May 23, 2022 at 5:39 AM  wrote:
>
>  Dear package maintainers,
> please do not mess with preexisting files in /dev.
>
> I have static /dev and that suit me well for quite a few systems that
> has a static environment, especially system that are intended to run
> for a long time and where I tend to minimize the number of running
> processes, every running process is something that can go wrong.
> Their /dev/ files are set up for their intended use, and I don't want
> surprises there.
>
> When upgrading it isn't easy to see what package that did
> something to /dev so it isn't easy to bug the guilty party.
>
> If sys-fs/static-dev is installed, please do not touch /dev,
> if you want you can leave suggestions in some file.

This blanket request is unlikely to yield any useful results.

ebuilds don't generally do anything with /dev. Changing behavior based
on the presence of sys-fs/static-dev is probably not a good idea.

If you can identify specific packages that have caused you problems,
we can probably resolve them.



Re: [gentoo-dev] Should we join the which hunt?

2022-05-13 Thread Mike Gilbert
On Fri, May 13, 2022 at 11:44 AM Mike Gilbert  wrote:
>
> On Fri, May 13, 2022 at 3:11 AM Ulrich Mueller  wrote:
> >
> > Recently Debian has started to transition away from the "which" command.
> > [1]
> >
> > which is a non-POSIX command which prints out the location of specified
> > executables that are in your path. Unfortunately, there are several
> > versions of the program around which are not compatible with each other.
> > We package the GNU version as sys-apps/which, which is in the system set
> > since 2004.
> >
> > Already in 2007, vapier asked developers to avoid which in ebuilds. [2]
> > The replacement in most circumstances is "type -p" which is a bash
> > builtin command.
> >
> > So, should we join the "which hunt", with the goal of removing
> > sys-apps/which from the system set and from stage1? I think the first
> > step would be to identify which packages use which, and add it as an
> > explicit dependency. (Maybe the tinderbox could help there?) A bug for
> > this [3] has already been filed by mgorny some time ago.
> >
> > Unfortunately, the command pops up in unexpected places, e.g. it appears
> > to be an (indirect) build-time dependency of systemd. [4]
>
> "which" is a built-in command in bash, but not in dash. For most
> users, /bin/sh points at bash and I don't expect to see much breakage
> when /usr/bin/which is removed. The bug reports will come from people
> who like pain and run their systems with /bin/sh pointed at dash.

Oops, turns out I tested with zsh, not bash. Disregard the above.



Re: [gentoo-dev] Should we join the which hunt?

2022-05-13 Thread Mike Gilbert
On Fri, May 13, 2022 at 3:11 AM Ulrich Mueller  wrote:
>
> Recently Debian has started to transition away from the "which" command.
> [1]
>
> which is a non-POSIX command which prints out the location of specified
> executables that are in your path. Unfortunately, there are several
> versions of the program around which are not compatible with each other.
> We package the GNU version as sys-apps/which, which is in the system set
> since 2004.
>
> Already in 2007, vapier asked developers to avoid which in ebuilds. [2]
> The replacement in most circumstances is "type -p" which is a bash
> builtin command.
>
> So, should we join the "which hunt", with the goal of removing
> sys-apps/which from the system set and from stage1? I think the first
> step would be to identify which packages use which, and add it as an
> explicit dependency. (Maybe the tinderbox could help there?) A bug for
> this [3] has already been filed by mgorny some time ago.
>
> Unfortunately, the command pops up in unexpected places, e.g. it appears
> to be an (indirect) build-time dependency of systemd. [4]

"which" is a built-in command in bash, but not in dash. For most
users, /bin/sh points at bash and I don't expect to see much breakage
when /usr/bin/which is removed. The bug reports will come from people
who like pain and run their systems with /bin/sh pointed at dash.



[gentoo-dev] Re: [PATCH 1/5] ninja-utils.eclass: Support dev-util/samurai

2022-05-09 Thread Mike Gilbert
On Mon, May 9, 2022 at 1:13 PM orbea  wrote:
>
> On Mon, 9 May 2022 10:59:03 -0400
> Mike Gilbert  wrote:
> > The NINJA environment variable is used directly by meson and may
> > contain an absolute path. I don't think it makes sense to restrict
> > possible values to just "ninja" and "samu". That will make it more
> > difficult for users to override it with a local copy of either tool,
> > or to use a different implementation should someone write one in the
> > future.
> >
> > It might make sense to introduce a different eclass variable to
> > control NINJA_DEPEND and the default value for NINJA.
>
> The game antares (https://github.com/arescentral/antares) has a custom
> python based build system that also respects the NINJA variable.
>
> Your point is a good one, but I'm unsure how this would work? The
> NINJA_DEPEND variable has to be set to a valid package elsewhere in the
> eclass scripts, for example the 'has_version -b' check in the cmake
> eclass.
>
> Allowing the user to set an arbitrary value will require they also
> being able to set NINJA_DEPEND to a correct value. In some of these
> cases there may not be an applicable ebuild to set it to even. Maybe
> I'm missing something, but this seems like a good way to complicate the
> process and possibly introduce pebkac. Maybe it would be preferable to
> just add additional ninja implementations to the list as they are
> available?
>
> Also if its just testing local versions I think it could be worked
> around by setting the PATH and / or using symlinks? A user could
> create a dummy ebuild as well.

We could make the eclass ewarn on unknown NINJA values, and set
NINJA_DEPEND to empty in that case. Just don't call "die".

That would allow users to override NINJA without triggering a failure,
and still alerts ebuild maintainers in case they make a typo when
setting NINJA in an ebuild.



[gentoo-dev] Re: [PATCH 2/5] meson.eclass: Support dev-util/samurai

2022-05-09 Thread Mike Gilbert
On Sun, May 8, 2022 at 7:07 PM Sam James  wrote:
>
> From: orbea 
>
> samurai is a ninja-compatible build tool written in C which
> works with cmake, meson and other users of ninja.
>
> It is feature-complete and supports most of the same options
> as ninja.

The patch looks fine, but the commit message doesn't describe the
change very well. It should probably mention something like "use
NINJA_DEPEND variable from ninja-utils.eclass".



[gentoo-dev] Re: [PATCH 1/5] ninja-utils.eclass: Support dev-util/samurai

2022-05-09 Thread Mike Gilbert
On Sun, May 8, 2022 at 7:07 PM Sam James  wrote:
>
> From: orbea 
>
> samurai is a ninja-compatible build tool written in C which
> works with cmake, meson and other users of ninja.
>
> It is feature-complete and supports most of the same options
> as ninja.
>
> Signed-off-by: orbea 
> Signed-off-by: Sam James 
> ---
>  eclass/ninja-utils.eclass | 24 +++-
>  1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/eclass/ninja-utils.eclass b/eclass/ninja-utils.eclass
> index c5f34934192f..67f7a6b5e8a7 100644
> --- a/eclass/ninja-utils.eclass
> +++ b/eclass/ninja-utils.eclass
> @@ -26,6 +26,15 @@ esac
>  if [[ -z ${_NINJA_UTILS_ECLASS} ]]; then
>  _NINJA_UTILS_ECLASS=1
>
> +# @ECLASS_VARIABLE: NINJA
> +# @PRE_INHERIT
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# Specify a compatible ninja implementation to be used by eninja.
> +# At this point only "ninja" and "samu" are supported.
> +# The default is set to "ninja".
> +: ${NINJA:=ninja}

This is tagged as @DEFAULT_UNSET, but the description and
implementation indicate that it defaults to "ninja".

>  # @ECLASS_VARIABLE: NINJAOPTS
>  # @DEFAULT_UNSET
>  # @DESCRIPTION:
> @@ -35,6 +44,19 @@ _NINJA_UTILS_ECLASS=1
>
>  inherit multiprocessing
>
> +case "${NINJA}" in
> +   ninja)
> +   NINJA_DEPEND=">=dev-util/ninja-1.8.2"
> +   ;;
> +   samu)
> +   NINJA_DEPEND="dev-util/samurai"
> +   ;;
> +   *)
> +   eerror "Unknown value for \${NINJA}"
> +   die "Value ${NINJA} is not supported"
> +   ;;
> +esac

The NINJA environment variable is used directly by meson and may
contain an absolute path. I don't think it makes sense to restrict
possible values to just "ninja" and "samu". That will make it more
difficult for users to override it with a local copy of either tool,
or to use a different implementation should someone write one in the
future.

It might make sense to introduce a different eclass variable to
control NINJA_DEPEND and the default value for NINJA.



[gentoo-dev] Re: [PATCH 1/2] meson.eclass: disable PCH

2022-04-19 Thread Mike Gilbert
On Tue, Apr 19, 2022 at 2:21 PM Sam James  wrote:
>
> It's already masked and disabled in GCC and it causes a huge
> number of problems, but we need t odo this to avoid automagically
> trying to use PCH-even-once-it's-been-disabled-in-the-compiler.

ACK on both patches.



[gentoo-dev] [PATCH] 2022-04-17-systemd-utils-revbump: new emergency item

2022-04-17 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 .../2022-04-17-systemd-utils-revbump.en.txt  | 12 
 1 file changed, 12 insertions(+)
 create mode 100644 
2022-04-17-systemd-utils-revbump/2022-04-17-systemd-utils-revbump.en.txt

diff --git 
a/2022-04-17-systemd-utils-revbump/2022-04-17-systemd-utils-revbump.en.txt 
b/2022-04-17-systemd-utils-revbump/2022-04-17-systemd-utils-revbump.en.txt
new file mode 100644
index 000..0754447
--- /dev/null
+++ b/2022-04-17-systemd-utils-revbump/2022-04-17-systemd-utils-revbump.en.txt
@@ -0,0 +1,12 @@
+Title: sys-apps/systemd-utils revbump
+Author: Mike Gilbert 
+Posted: 2022-04-17
+Revision: 1
+News-Item-Format: 2.0
+Display-If-Installed: =sys-apps/systemd-utils-250.4
+
+The currently installed version of sys-apps/systemd-utils may cause
+kernel modules to fail to load on boot.
+
+Please upgrade to >=sys-apps/systemd-utils-250.4-r1 as soon as possible,
+and certainly before rebooting your system.
-- 
2.35.1




[gentoo-dev] [PATCH v2] 2022-04-21-systemd-utils: new entry

2022-04-17 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
v2: Wrapped text at 72 characters, incorporated suggestions by sam.

 .../2022-04-21-systemd-utils.en.txt   | 42 +++
 1 file changed, 42 insertions(+)
 create mode 100644 2022-04-21-systemd-utils/2022-04-21-systemd-utils.en.txt

diff --git a/2022-04-21-systemd-utils/2022-04-21-systemd-utils.en.txt 
b/2022-04-21-systemd-utils/2022-04-21-systemd-utils.en.txt
new file mode 100644
index 000..e365cd3
--- /dev/null
+++ b/2022-04-21-systemd-utils/2022-04-21-systemd-utils.en.txt
@@ -0,0 +1,42 @@
+Title: Migration to sys-apps/systemd-utils
+Author: Mike Gilbert 
+Posted: 2022-04-21
+Revision: 1
+News-Item-Format: 2.0
+Display-If-Installed: sys-apps/systemd-tmpfiles
+Display-If-Installed: sys-apps/systemd-utils
+Display-If-Installed: sys-boot/systemd-boot
+Display-If-Installed: sys-fs/udev
+
+The sys-apps/systemd-utils package was recently added to the gentoo
+repository. This replaces sys-apps/systemd-tmpfiles,
+sys-boot/systemd-boot, and sys-fs/udev with a single package. USE flags
+are provided to allow each component to be enabled or disabled. This
+change was made to significantly ease maintenance of tools split out
+from systemd.
+
+When upgrading to sys-apps/systemd-tmpfiles-250,
+sys-apps/systemd-utils[tmpfiles] will be pulled in as a dependency.
+
+When upgrading to sys-boot/systemd-boot-250,
+sys-apps/systemd-utils[boot] will be pulled in as a dependency.
+
+When upgrading to sys-fs/udev-250, sys-apps/systemd-utils[udev] will be
+pulled in as a dependency.
+
+At a later date, sys-apps/systemd-tmpfiles, sys-boot/systemd-boot, and
+sys-fs/udev will be masked for removal once a suitable version of
+sys-apps/systemd-utils has been marked stable and sufficient time has
+been provided for users to migrate.
+
+Possible problems when upgrading:
+
+1. If sys-fs/eudev is present in the world file (@selected), emerge will
+   abort the upgrade with a unsolvable blocker error. To resolve this,
+   either remove sys-fs/eudev from the world file
+   (emerge --deselect sys-fs/eudev), or disable the 'udev' USE flag for
+   sys-apps/systemd-utils.
+
+2. The 'boot' USE flag on sys-apps/systemd-utils is disabled by default.
+   Users migrating from sys-boot/systemd-boot will need to enable the
+   'boot' USE flag (in package.use) to continue receiving updates.
-- 
2.35.1




[gentoo-dev] [PATCH] 2022-04-21-systemd-utils: new entry

2022-04-17 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 .../2022-04-21-systemd-utils.en.txt   | 38 +++
 1 file changed, 38 insertions(+)
 create mode 100644 2022-04-21-systemd-utils/2022-04-21-systemd-utils.en.txt

diff --git a/2022-04-21-systemd-utils/2022-04-21-systemd-utils.en.txt 
b/2022-04-21-systemd-utils/2022-04-21-systemd-utils.en.txt
new file mode 100644
index 000..b8c6f14
--- /dev/null
+++ b/2022-04-21-systemd-utils/2022-04-21-systemd-utils.en.txt
@@ -0,0 +1,38 @@
+Title: Migration to sys-apps/systemd-utils
+Author: Mike Gilbert 
+Posted: 2022-04-21
+Revision: 1
+News-Item-Format: 2.0
+Display-If-Installed: sys-apps/systemd-tmpfiles
+Display-If-Installed: sys-boot/systemd-boot
+Display-If-Installed: sys-fs/udev
+
+The sys-apps/systemd-utils package was recently added to the gentoo
+repository. This replaces sys-apps/systemd-tmpfiles, sys-boot/systemd-boot,
+and sys-fs/udev with a single package. USE flags are provided to allow each
+component to be enabled or disabled.
+
+When upgrading to sys-apps/systemd-tmpfiles-250,
+sys-apps/systemd-utils[tmpfiles] will be pulled in as a dependency.
+
+When upgrading to sys-boot/systemd-boot-250, sys-apps/systemd-utils[boot] will
+be pulled in as a dependency.
+
+When upgrading to sys-fs/udev-250, sys-apps/systemd-utils[udev] will be pulled
+in as a depenendecy.
+
+At a later date, sys-apps/systemd-tmpfiles, sys-boot/systemd-boot, and
+sys-fs/udev will be masked for removal once a suitable version of
+sys-apps/systemd-utils has been marked stable and sufficient time has been
+provided for users to migrate.
+
+Possible problems when upgrading:
+
+1. If sys-fs/eudev is present in the world file (@selected), emerge will abort
+   the upgrade with a unsolvable blocker error. To resolve this, either remove
+   sys-fs/eudev from the world file, or disable the 'udev' USE flag on
+   sys-apps/systemd-utils.
+
+2. The 'boot' USE flag on sys-apps/systemd-utils is disabled by default. Users
+   migrating from sys-boot/systemd-boot will need to enable the 'boot' use
+   flag to continue receiving updates.
-- 
2.35.1




Re: [gentoo-dev] [PATCH] gnuconfig.eclass: fix eend w/o ebegin

2022-04-16 Thread Mike Gilbert
On Sat, Apr 16, 2022 at 2:28 AM Sam James  wrote:
>
> eend should be preceded by an begin call.

Looks ok.



  1   2   3   4   5   6   7   8   9   10   >