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

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

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

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



[gentoo-dev] Last rites: sys-fs/eudev

2021-11-26 Thread Mike Gilbert
# eudev will be removed on 2022-01-01.
# Please see the news item published on 2021-08-24 for more information.
sys-fs/eudev



Re: [gentoo-dev] [PATCHv2] 2021-11-23-mariadb-database-restore-maybe-required: add item

2021-11-25 Thread Mike Gilbert
On Thu, Nov 25, 2021 at 1:26 PM Thomas Deutschmann  wrote:
> +Keep in mind that due to the forced downgraded, point-in-time recovery
> +may not be available to the extent that you are used to.

Sorry, I guess I missed this instance of "forced". Also, "downgraded"
is the incorrect form to use here. It should be something like:

"Keep in mind that due to the downgrade, point-in-time recovery may
not be available to the extent that you are used to."



Re: [gentoo-dev] [PATCH] 2021-11-23-mariadb-database-restore-maybe-required: add item

2021-11-25 Thread Mike Gilbert
On Thu, Nov 25, 2021 at 12:01 PM Piotr Karbowski  wrote:
>
> > https://github.com/gentoo/gentoo/blob/master/sys-libs/glibc/glibc-2.34-r2.ebuild#L643
>
> Would you see something like this on more ebuilds, postgres, mysql,
> elasticsearch, or have proper FEATURE flag for it instead?
>
> It's all cool and giggles until you realize that even such random
> variable is not even prefixed with PORTAGE_ or anything, meaning it
> could be taken out of shell and meant for entirely different thing.

Another problem with such magic variables is that they are ineffective
when installing binpkgs. During pkg_preinst, portage will restore the
environment variables that were present when the package was built,
and ignore anything you have set in the environment since then.



Re: [gentoo-dev] [PATCH] profiles: mask sys-fs/eudev for removal

2021-11-25 Thread Mike Gilbert
On Thu, Nov 25, 2021 at 9:15 AM Thomas Deutschmann  wrote:
>
> Hi,
>
> why do you want to drop the package? Since news item, upstream changed.
> There will be a new release soon. Was this just on your list to finish
> or is there another reason?
>
> I am currently watching upstream and would wait to see if they really do
> the release and keep up with the promise. We can still last-rite next
> quarter, not?

I sincerely doubt eudev will be well maintained by anyone, and will
probably be poorly maintained in Gentoo. It's a maintenance burden we
don't need any longer now that sys-fs/udev can be installed on all of
the platforms we support. I would guess that the majority of active
developers in the base-system project want to see it gone.

Also, I am planning to replace the poorly maintained "hwids" package
with the "hwdata" package maintained by a Red Hat employee. Part of
this plan involved installing the hwdb data that is shipped with
udev/systemd. This plan would be blocked if eudev remained in Gentoo.



Re: [gentoo-dev] [PATCH] 2021-11-23-mariadb-database-restore-maybe-required: add item

2021-11-25 Thread Mike Gilbert
On Thu, Nov 25, 2021 at 8:59 AM Thomas Deutschmann  wrote:
>
> Hi,
>
> On 2021-11-25 04:49, Mike Gilbert wrote:
> > On 2021-11-21, keywords for dev-db/mariadb-10.6 were removed to
> > address a file collision with dev-db/mariadb-connector-c. This
> > unintentionally triggered a version downgrade for users who had
> > successfully upgraded to dev-db/mariadb-10.6 already.
>
> Works for me. However, I would write dev-db/mariadb:10.6. Is that
> acceptable for you?

Sure.

> > I don't like the phrase "forcefully downgraded" here. This implies
> > that something happened without the user's consent. emerge would have
> > informed them of the downgrade before it happened. I would suggest
> > removing the word "forcefully" from these paragraphs.
>
> If you do a normal world upgrade, this is the default portage behavior,
> not? I.e. package manager will downgrade if you don't stop. And
> especially on servers, people tend to use cronjobs/scripts to do that...

Something happening by default is not the same as forcing it to happen.

Using a cron job or other blind automation to do package upgrades on
any production system is a bad idea. We certainly do not recommend
that to people, nor force them to do it.

> And forcefully here refers to the undesirable result (at least that was
> my intention). Something the user doesn't want.

That's really not what "forcefully" means. It would be fine to use
"unintentional" or "unwanted" in its place.



Re: [gentoo-dev] [PATCH] 2021-11-23-mariadb-database-restore-maybe-required: add item

2021-11-24 Thread Mike Gilbert
On Wed, Nov 24, 2021 at 10:21 PM Thomas Deutschmann  wrote:
> +On 2021-11-21, a member of the QA project accidentially de-keyworded
> +MariaDB 10.6 to address a file collision, users, who also had latest
> +dev-db/mariadb-connector-c installed, experienced (NOTE: The default
> +MySQL connector in Gentoo Linux is provided by
> +dev-db/mysql-connector-c) [Link 1].

This sentence is very difficult to read. Also, I don't think it is
relevant to call out the mistake by the QA team in a news item
intended for end users. I would rewrite this as:

On 2021-11-21, keywords for dev-db/mariadb-10.6 were removed to
address a file collision with dev-db/mariadb-connector-c. This
unintentionally triggered a version downgrade for users who had
successfully upgraded to dev-db/mariadb-10.6 already.

> +However, downgrades are not supported in MySQL/MariaDB [Link 2].
> +
> +In case you already fully upgraded to MariaDB 10.6 (which includes
> +executing mysql_upgrade command) and forcefully downgraded your
> +MariaDB instance afterwards during the time window when keywords were
> +removed, you maybe experiencing different problems:
> +
> +At best, your forcefully downgraded MariaDB instance prevented startup
> +so all you have to do is upgrade to MariaDB 10.6 again to resume
> +services.

I don't like the phrase "forcefully downgraded" here. This implies
that something happened without the user's consent. emerge would have
informed them of the downgrade before it happened. I would suggest
removing the word "forcefully" from these paragraphs.



[gentoo-dev] [PATCH] profiles: mask sys-fs/eudev for removal

2021-11-24 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 profiles/package.mask | 5 +
 1 file changed, 5 insertions(+)

I am sending this as a patch to the list before pushing it in case
anybody has a reasonable objection.

diff --git a/profiles/package.mask b/profiles/package.mask
index e2aa00757e1..73f7a63474c 100644
--- a/profiles/package.mask
+++ b/profiles/package.mask
@@ -33,6 +33,11 @@
 
 #--- END OF EXAMPLES ---
 
+# Mike Gilbert  (2021-11-24)
+# eudev will be removed on 2022-01-01.
+# Please see the news item published on 2021-08-24 for more information.
+sys-fs/eudev
+
 # Lars Wendler  (2021-11-24)
 # No real development since Q1 2020. Last release from 2016.
 # Users should switch over to media-sound/strawberry which is an actively
-- 
2.34.0




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

2021-11-11 Thread Mike Gilbert
On Thu, Nov 11, 2021 at 2:08 PM Ulrich Mueller  wrote:
>
> >>>>> On Thu, 11 Nov 2021, Mike Gilbert wrote:
>
> >> - Open part of the range 60001..65533. Not sure if all software will be
> >> happy with that.
>
> > systemd has some code that special-cases ids in the "system" range.
> > I'm not exactly sure what impact creating system users outside above
> > SYS_UID_MAX (login.defs) will have.
>
> We also have some IDs below SYS_UID_MIN (= 101) which technically is
> outside the system account range of login.defs. Do these cause any
> problems with systemd?

That seems less likely to cause a problem. systemd considers any id <=
SYS_UID_MAX to be a system id.



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

2021-11-11 Thread Mike Gilbert
On Thu, Nov 11, 2021 at 5:59 AM Ulrich Mueller  wrote:
>
> May I remind everybody that by QA policy allocation of UIDs and GIDs
> in the range 0..100 needs explicit approval by the QA lead:
> https://projects.gentoo.org/qa/policy-guide/user-group.html#pg0901
>
> I have fixed the used_free_uidgids.sh script such that it will no longer
> recommend any IDs below 101.
>
> In any case, we have run out of GIDs:
>
>Recommended GID only: none
>Recommended UID only: 272
>Recommended UID+GID pair: none
>Free UIDs: 15
>Free GIDs: 0
>Free UID+GID pairs: 0
>
> The question is of course how we should move forward. Certainly, using
> IDs below 100 cannot be the solution, as we would run out of these very
> soon.
>
> We could:
>
> - Open some part of the range between 500 and 1000. For example,
>   500..799, which would leave 200 IDs for dynamic allocation.

This sounds like the simplest solution to me.

> - Open part of the range 60001..65533. Not sure if all software will be
>   happy with that.

systemd has some code that special-cases ids in the "system" range.
I'm not exactly sure what impact creating system users outside above
SYS_UID_MAX (login.defs) will have.



[gentoo-dev] [PATCH] savedconfig.eclass: do not re-use config file scheme

2021-10-31 Thread Mike Gilbert
This causes file collisions when save_config is used in a multi-slotted
package and the config file is named ${PN}.

Reverts: a0c35ad8ee8f8f89ba6044dd5b44e9479c6a1775
Bug: https://bugs.gentoo.org/686348
Closes: https://bugs.gentoo.org/818904
Signed-off-by: Mike Gilbert 
---
 eclass/savedconfig.eclass | 15 +--
 1 file changed, 1 insertion(+), 14 deletions(-)

diff --git a/eclass/savedconfig.eclass b/eclass/savedconfig.eclass
index c4fd0c492f4..c7aa8084ac8 100644
--- a/eclass/savedconfig.eclass
+++ b/eclass/savedconfig.eclass
@@ -39,13 +39,6 @@ case ${EAPI} in
*) die "EAPI=${EAPI:-0} is not supported" ;;
 esac
 
-# @ECLASS-VARIABLE: _SAVEDCONFIG_CONFIGURATION_FILE
-# @DEFAULT_UNSET
-# @INTERNAL
-# @DESCRIPTION:
-# Path of configuration file, relative to /etc/portage/savedconfig,
-# restored by restore_config() and saved by save_config().
-
 # @FUNCTION: save_config
 # @USAGE: 
 # @DESCRIPTION:
@@ -59,12 +52,7 @@ save_config() {
fi
[[ $# -eq 0 ]] && die "Usage: save_config "
 
-   local configfile
-   if [[ -n ${_SAVEDCONFIG_CONFIGURATION_FILE} ]] ; then
-   
configfile="/etc/portage/savedconfig/${_SAVEDCONFIG_CONFIGURATION_FILE}"
-   else
-   configfile="/etc/portage/savedconfig/${CATEGORY}/${PF}"
-   fi
+   local configfile"/etc/portage/savedconfig/${CATEGORY}/${PF}"
 
if [[ $# -eq 1 && -f $1 ]] ; then
# Just one file, so have the ${configfile} be that config file
@@ -125,7 +113,6 @@ restore_config() {
if [[ -r "${configfile}" ]] ; then
einfo "Found \"${configfile}\""
found=${configfile}
-   _SAVEDCONFIG_CONFIGURATION_FILE=${configfile#${base}/}
break
fi
 
-- 
2.33.1




Re: [gentoo-portage-dev] [PATCH] estrip: rework hard link logic in save_elf_debug

2021-10-28 Thread Mike Gilbert
On Wed, Oct 27, 2021 at 10:51 AM Alec Warner  wrote:
> Can we do better than X and Y here?

The patch has gone through several revisions on Github.

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



[gentoo-dev] Re: [PATCH] profiles: remove default ALSA_CARDS setting from arch profiles

2021-10-26 Thread Mike Gilbert
On Tue, Oct 26, 2021 at 2:38 PM Mike Gilbert  wrote:
> diff --git a/profiles/desc/.alsa_cards.desc.swp 
> b/profiles/desc/.alsa_cards.desc.swp
> new file mode 100644
> index 
> ..e96a7263d04461d069c3e6ecaf2730efc81dfbde
> GIT binary patch

Oops, I accidentally committed my vim swap file. I have fixed this locally.



[gentoo-dev] [PATCH] profiles: remove default ALSA_CARDS setting from arch profiles

2021-10-26 Thread Mike Gilbert
These have not been reviewed for several years and contain many
obsolete/invalid values.

Currently only two packages utilize these flags:

media-sound/alsa-tools optionally installs several card-specific
utilities. It is unlikely that anything will break if these are
uninstalled by accident.

sys-firmware/alsa-firmware installs firmware for niche hardware
and is probably needed by very few users.

It probably makes more sense for the user to set ALSA_CARDS explicitly.

Signed-off-by: Mike Gilbert 
---
 profiles/arch/alpha/make.defaults |   7 +--
 profiles/arch/amd64/make.defaults |   4 
 profiles/arch/ia64/make.defaults  |   6 +-
 profiles/arch/mips/make.defaults  |   6 +-
 profiles/arch/powerpc/ppc32/make.defaults |   4 
 profiles/arch/x86/make.defaults   |   4 
 profiles/desc/.alsa_cards.desc.swp| Bin 0 -> 12288 bytes
 7 files changed, 3 insertions(+), 28 deletions(-)
 create mode 100644 profiles/desc/.alsa_cards.desc.swp

diff --git a/profiles/arch/alpha/make.defaults 
b/profiles/arch/alpha/make.defaults
index 6749b9c0a44..0d2b90931c4 100644
--- a/profiles/arch/alpha/make.defaults
+++ b/profiles/arch/alpha/make.defaults
@@ -1,4 +1,4 @@
-# Copyright 1999-2020 Gentoo Authors
+# Copyright 1999-2021 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 ARCH="alpha"
@@ -23,11 +23,6 @@ LIBDIR_alpha="lib"
 # Defaults for video drivers
 VIDEO_CARDS="fbdev glint mga nv r128 radeon"
 
-# Chris Gianelloni  (2007-02-05)
-# Defaults for audio drivers. These are copied from x86 (minus modems), since
-# Alpha supports the same busses.
-ALSA_CARDS="ali5451 als4000 bt87x ca0106 cmipci emu10k1 ens1370 ens1371 es1938 
es1968 fm801 hda-intel intel8x0 maestro3 trident usb-audio via82xx ymfpci"
-
 # Tobias Klausmann  (2018-06-25)
 # Enable USE=libtirpc by default, to ease dependency resolution during
 # the stabilization of glibc-2.26. Bug 657148
diff --git a/profiles/arch/amd64/make.defaults 
b/profiles/arch/amd64/make.defaults
index 775103c63ac..0c05dec124e 100644
--- a/profiles/arch/amd64/make.defaults
+++ b/profiles/arch/amd64/make.defaults
@@ -50,10 +50,6 @@ ABI_X86="64"
 # Defaults for video drivers
 VIDEO_CARDS="amdgpu fbdev intel nouveau radeon radeonsi vesa"
 
-# Danny van Dyk  (2006-12-22)
-# Default for ALSA_CARDS USE_EXPAND variable.
-ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x 
ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 
trident usb-audio via82xx via82xx-modem ymfpci"
-
 # Michał Górny  (2013-01-26)
 # Unhide the x86-specific USE_EXPANDs.
 USE_EXPAND_HIDDEN="-ABI_X86 -CPU_FLAGS_X86"
diff --git a/profiles/arch/ia64/make.defaults b/profiles/arch/ia64/make.defaults
index c87d017b15e..4327e575707 100644
--- a/profiles/arch/ia64/make.defaults
+++ b/profiles/arch/ia64/make.defaults
@@ -1,4 +1,4 @@
-# Copyright 1999-2020 Gentoo Authors
+# Copyright 1999-2021 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 ARCH="ia64"
@@ -27,7 +27,3 @@ CHOST_ia64="${CHOST}"
 # Donnie Berkholz  (2006-08-18)
 # Defaults for video drivers
 VIDEO_CARDS="fbdev glint mga nv r128 radeon"
-
-# Diego Pettenò  (2006-12-23)
-# Defaults for audio drivers - Took from x86 profile
-ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x 
ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 
trident usb-audio via82xx via82xx-modem ymfpci"
diff --git a/profiles/arch/mips/make.defaults b/profiles/arch/mips/make.defaults
index cb1dead24e7..9d3d5a8a1bf 100644
--- a/profiles/arch/mips/make.defaults
+++ b/profiles/arch/mips/make.defaults
@@ -1,4 +1,4 @@
-# Copyright 2008-2019 Gentoo Authors
+# Copyright 2008-2021 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # Donnie Berkholz  (2006-08-18)
@@ -15,7 +15,3 @@ USE="-fortran -openmp"
 LIBDIR_o32="lib"
 LIBDIR_n32="lib32"
 LIBDIR_n64="lib64"
-
-# Matt Turner  (2010-12-06)
-# Probably missing a bunch for various SGI systems.
-ALSA_CARDS="au1x00"
diff --git a/profiles/arch/powerpc/ppc32/make.defaults 
b/profiles/arch/powerpc/ppc32/make.defaults
index 0332427d751..51f2ea0ad11 100644
--- a/profiles/arch/powerpc/ppc32/make.defaults
+++ b/profiles/arch/powerpc/ppc32/make.defaults
@@ -17,10 +17,6 @@ FCFLAGS="${CFLAGS}"
 # Defaults for video drivers
 VIDEO_CARDS="fbdev glint mga nv r128 radeon"
 
-# Diego Pettenò  (2006-12-06)
-# Defaults for PowerPC sound driver
-ALSA_CARDS="aoa aoa-fabric-layout aoa-onyx aoa-soundbus aoa-soundbus-i2s 
aoa-tas aoa-toonie powermac usb-audio via82xx"
-
 # Michał Górny  (2014-06-27)
 # Multilib-related setup for compatibility with future multilib.
 ABI="ppc"
diff --git a/profiles/arch/x86/make.d

[gentoo-portage-dev] [PATCH] estrip: rework hard link logic in save_elf_debug

2021-10-25 Thread Mike Gilbert
GDB loads debug files based on the file name given in the .gnu_debuglink
section, prepended with /usr/lib/debug/${dirname}, where dirname is the
absolute path to the parent directory of the binary being executed.

For each unique inode as input, we need a link to the debug file with
the GNU debuglink as its basename. A link to the debug file should exist
for each directory in which the input inode exists.

The debug link names should be based on the .gnu_debuglink value instead
of the name of the file we are processing as input.

The .gnu_debuglink value is based on the name of the first link
processed for each inode. We save this value as a symlink, and then read
it back as we process subsequent links.

For example, given the following input:

INODE PATH
1 /usr/bin/git
1 /usr/libexec/git-core/git-add
2 /usr/bin/git-shell
2 /usr/libexec/git-core/git-shell

We generate the following inodes for the debug files:

INODE DEBUGLINK
3 git.debug
4 git-shell.debug

We should generate the following links:

INODE PATH
3 /usr/lib/debug/usr/bin/git.debug
3 /usr/lib/debug/usr/libexec/git-core/git.debug
4 /usr/bin/debug/usr/bin/git-shell.debug
4 /usr/bin/debug/usr/libexec/git-core/git-shell.debug

The previous code would have generated this broken output:

INODE PATH
3 /usr/lib/debug/usr/bin/git.debug
3 /usr/lib/debug/usr/libexec/git-core/git-add.debug (*)
4 /usr/bin/debug/usr/bin/git-shell.debug
4 /usr/bin/debug/usr/libexec/git-core/git-shell.debug

(*) This link has the wrong name.

Bug: https://bugs.gentoo.org/820107
Signed-off-by: Mike Gilbert 
---
 bin/estrip | 31 ++-
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/bin/estrip b/bin/estrip
index abe523fff..8134020fd 100755
--- a/bin/estrip
+++ b/bin/estrip
@@ -201,17 +201,29 @@ save_elf_debug() {
local x=$1
local inode_debug=$2
local splitdebug=$3
-   local d_noslash=${D%/}
-   local y=${ED%/}/usr/lib/debug/${x:${#d_noslash}}.debug
+
+   local x_basename=${x##*/}
+   local x_dirname=${x%/*}
+   local y_dirname=${ED%/}/usr/lib/debug/${x_dirname#${D%/}/}
+   local y_basename y
 
# dont save debug info twice
[[ ${x} == *".debug" ]] && return 0
 
-   mkdir -p "${y%/*}"
+   mkdir -p "${y_dirname}" || die
+
+   if [[ -L ${inode_debug} ]] ; then
+   y_basename=$(readlink "${inode_debug}") || die
+   y_basename=${y_basename##*/}
+   y=${y_dirname}/${y_basename}
 
-   if [ -f "${inode_debug}" ] ; then
-   ln "${inode_debug}" "${y}" || die "ln failed unexpectedly"
+   if [[ ! -e ${y} ]]; then
+   ln -L "${inode_debug}" "${y}" || die
+   fi
else
+   y_basename=${x_basename}.debug
+   y=${y_dirname}/${y_basename}
+
if [[ -n ${splitdebug} ]] ; then
mv "${splitdebug}" "${y}"
else
@@ -222,11 +234,12 @@ save_elf_debug() {
fi
# Only do the following if the debug file was
# successfully created (see bug #446774).
-   if [ $? -eq 0 ] ; then
+   if [[ $? -eq 0 ]] ; then
local args="a-x,o-w"
[[ -g ${x} || -u ${x} ]] && args+=",go-r"
chmod ${args} "${y}"
-   ln "${y}" "${inode_debug}" || die "ln failed 
unexpectedly"
+   # symlink so we can read the name back.
+   ln -s "${y}" "${inode_debug}" || die
fi
fi
 
@@ -239,8 +252,8 @@ save_elf_debug() {
local 
buildid_dir="${ED%/}/usr/lib/debug/.build-id/${buildid:0:2}"
local buildid_file="${buildid_dir}/${buildid:2}"
mkdir -p "${buildid_dir}"
-   [ -L "${buildid_file}".debug ] || ln -s 
"../../${x:$((${#d_noslash} + 1))}.debug" "${buildid_file}.debug"
-   [ -L "${buildid_file}" ] || ln -s "/${x:$((${#d_noslash} + 
1))}" "${buildid_file}"
+   [[ -L "${buildid_file}".debug ]] || ln -s 
"../../${x#${D%/}/}.debug" "${buildid_file}.debug"
+   [[ -L "${buildid_file}" ]] || ln -s 
"../../../../../${x#${D%/}/}" "${buildid_file}"
fi
 }
 
-- 
2.33.1




[gentoo-dev] [PATCH] xdg-utils.eclass: disable fdatasync() in update-mime-database

2021-10-24 Thread Mike Gilbert
This speeds up installation dramatically on slow disks, and may reduce
wear on solid state storage.

Portage will call 'sync' after installation if FEATURES="merge-sync" is
enabled, so the risk should be small.

Closes: https://bugs.gentoo.org/819783
Signed-off-by: Mike Gilbert 
---
 eclass/xdg-utils.eclass | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/eclass/xdg-utils.eclass b/eclass/xdg-utils.eclass
index 35084fc8164..a834d5d3acc 100644
--- a/eclass/xdg-utils.eclass
+++ b/eclass/xdg-utils.eclass
@@ -125,6 +125,9 @@ xdg_mimeinfo_database_update() {
return
fi
 
+   # https://bugs.gentoo.org/819783
+   local -x PKGSYSTEM_ENABLE_FSYNC=0
+
ebegin "Updating shared mime info database"
update-mime-database "${EROOT%/}${MIMEINFO_DATABASE_DIR}"
eend $?
-- 
2.33.1




[gentoo-dev] [PATCH] 2021-10-24-netifrc-dhcp-client: add news item

2021-10-21 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 .../2021-10-24-netifrc-dhcp-client.en.txt | 21 +++
 1 file changed, 21 insertions(+)
 create mode 100644 
2021-10-24-netifrc-dhcp-client/2021-10-24-netifrc-dhcp-client.en.txt

diff --git 
a/2021-10-24-netifrc-dhcp-client/2021-10-24-netifrc-dhcp-client.en.txt 
b/2021-10-24-netifrc-dhcp-client/2021-10-24-netifrc-dhcp-client.en.txt
new file mode 100644
index 000..d97a454
--- /dev/null
+++ b/2021-10-24-netifrc-dhcp-client/2021-10-24-netifrc-dhcp-client.en.txt
@@ -0,0 +1,21 @@
+Title: netifrc DHCP client
+Author: Mike Gilbert 
+Posted: 2021-10-24
+Revision: 1
+News-Item-Format: 2.0
+Display-If-Installed: net-misc/netifrc
+Display-If-Profile: default/linux/*
+
+The sys-apps/busybox package was recently removed from the system set.
+Users of net-misc/netifrc may have unknowingly relied upon this package
+to provide a DHCP client.
+
+If you are using netifrc and use DHCP for network connectivity, please
+ensure you have a supported DHCP client installed/selected in the
+Portage world file.
+
+Supported clients include:
+
+dhcpcd provided by net-misc/dhcpcd
+dhclient provided by net-misc/dhcp
+udhcpc provided by sys-apps/busybox
-- 
2.33.1




[gentoo-dev] [PATCH] meson.eclass: add EMESON_BUILDTYPE variable

2021-10-21 Thread Mike Gilbert
This allows the buildtype option to be overridden or omitted.

This may be necessary if an ebuild makes use of the 'debug' built-in
option control project-specific debug functionality. meson emits a
warning if both buildtype and debug are specified, since the former
overrides the latter.

See discussion in https://github.com/gentoo/gentoo/pull/22574.

Signed-off-by: Mike Gilbert 
---
 eclass/meson.eclass | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 4ba364924e4..5fab2f8df6b 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -64,6 +64,11 @@ fi
 # Build directory, location where all generated files should be placed.
 # If this isn't set, it defaults to ${WORKDIR}/${P}-build.
 
+# @ECLASS-VARIABLE: EMESON_BUILDTYPE
+# @DESCRIPTION:
+# The buildtype value to pass to meson setup.
+: ${EMESON_BUILDTYPE=plain}
+
 # @ECLASS-VARIABLE: EMESON_SOURCE
 # @DEFAULT_UNSET
 # @DESCRIPTION:
@@ -310,7 +315,6 @@ meson_src_configure() {
 
local mesonargs=(
meson setup
-   --buildtype plain
--libdir "$(get_libdir)"
--localstatedir "${EPREFIX}/var/lib"
--prefix "${EPREFIX}/usr"
@@ -321,6 +325,10 @@ meson_src_configure() {
--native-file "$(_meson_create_native_file)"
)
 
+   if [[ -n ${EMESON_BUILDTYPE} ]]; then
+   mesonargs+=( --buildtype "${EMESON_BUILDTYPE}" )
+   fi
+
if tc-is-cross-compiler; then
mesonargs+=( --cross-file "$(_meson_create_cross_file)" )
fi
-- 
2.33.1




Re: [gentoo-dev] [RFC] Removing separate "security supported" arch list

2021-10-21 Thread Mike Gilbert
On Thu, Oct 21, 2021 at 4:05 AM Michał Górny  wrote:
> 4. In the end, Security team isn't really respecting this policy.
> In the end, this leads to absurdities like GLSA being released before
> a package is stable on amd64, and confusing the users [4].

This is certainly an absurd mistake, but I think it is unrelated to
the topic of your message. It looks like Whissi jumped the gun on
releasing a GLSA, which could happen regardless of the policy. Am I
missing some context?



Re: [gentoo-dev] [PATCH] 2021-10-08-openssh-rsa-sha1: add news item

2021-10-05 Thread Mike Gilbert
On Tue, Oct 5, 2021 at 4:22 PM Aaron W. Swenson  wrote:
>
>
> I think it may be helpful to include the specific file(s) those
> options
> need to be added and to clarify whether they need to be added to
> the
> server host or the clients.
>
> Perhaps like so:
>
> hashes may be re-enabled on the server by adding the following
> config
> options to the end of /etc/ssh/sshd_confg:

I considered something similar, but decided that I don't really want
to do that level of hand-holding.

Re-enabling ssh-rsa should be a seldom-used workaround. I feel like
people can read the manual if they really need to enable them. The
point of the news item is really to alert folks so they don't spend
hours scratching their heads over it.



Re: [gentoo-dev] [PATCH 1/1] glep-0068: Add notes element for package maintenance instructions

2021-10-05 Thread Mike Gilbert
On Tue, Oct 5, 2021 at 2:27 PM Sam James  wrote:
>
> This adds a new '' element to allow maintainers to describe
> package-specific quirks or other instructions on how to correctly
> maintain a package. This is intended to encourage developers to document
> knowledge and increase the bus-factor of packages which are delicate
> but must live beyond a maintainer.

Personally, I am much more likely to notice a comment at the top of
the ebuild than a new element in metadata.xml.



[gentoo-dev] [PATCH] 2021-10-08-openssh-rsa-sha1: add news item

2021-10-05 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 .../2021-10-08-openssh-rsa-sha1.en.txt| 26 +++
 1 file changed, 26 insertions(+)
 create mode 100644 
2021-10-08-openssh-rsa-sha1/2021-10-08-openssh-rsa-sha1.en.txt

diff --git a/2021-10-08-openssh-rsa-sha1/2021-10-08-openssh-rsa-sha1.en.txt 
b/2021-10-08-openssh-rsa-sha1/2021-10-08-openssh-rsa-sha1.en.txt
new file mode 100644
index 000..cfdcc4a
--- /dev/null
+++ b/2021-10-08-openssh-rsa-sha1/2021-10-08-openssh-rsa-sha1.en.txt
@@ -0,0 +1,26 @@
+Title: OpenSSH RSA SHA-1 signatures
+Author: Mike Gilbert 
+Posted: 2021-10-08
+Revision: 1
+News-Item-Format: 2.0
+Display-If-Installed: net-misc/openssh
+
+As of version 8.8, OpenSSH disables RSA signatures using the SHA-1
+hash algorithm by default. This change affects both the client and
+server components.
+
+After upgrading to this version, you may have trouble connecting to
+older SSH servers that do not support the newer RSA/SHA-256/SHA-512
+signatures. Support for these signatures was added in OpenSSH 7.2.
+
+As well, you may have trouble using older SSH clients to connect to a
+server running OpenSSH 8.8 or higher. Some older clients do not
+automatically utilize the newer hashes. For example, PuTTY before
+version 0.75 is affected.
+
+To resolve these problems, please upgrade your SSH client/server
+whereever possible. If this is not feasible, support for the SHA-1
+hashes may be re-enabled using the following config options:
+
+HostkeyAlgorithms +ssh-rsa
+PubkeyAcceptedAlgorithms +ssh-rsa
-- 
2.33.0




Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

2021-10-02 Thread Mike Gilbert
On Sat, Oct 2, 2021 at 1:25 PM A Schenck  wrote:
> Further discussion belongs on a different list, but the link provided by
> mgorny and repeated by you does not allow collaborating in compliance
> with the Gentoo Social Contract.

The patches were also posted for review on the gentoo-portage-dev mailing list.



[gentoo-dev] [PATCH 3/3] media-fonts/font-alias: pass --with-fontrootdir to configure

2021-10-01 Thread Mike Gilbert
Bug: https://bugs.gentoo.org/815520
Signed-off-by: Mike Gilbert 
---
 media-fonts/font-alias/font-alias-1.0.4.ebuild | 5 +
 1 file changed, 5 insertions(+)

diff --git a/media-fonts/font-alias/font-alias-1.0.4.ebuild 
b/media-fonts/font-alias/font-alias-1.0.4.ebuild
index 39335266b55..32c3a1c9fe7 100644
--- a/media-fonts/font-alias/font-alias-1.0.4.ebuild
+++ b/media-fonts/font-alias/font-alias-1.0.4.ebuild
@@ -10,3 +10,8 @@ KEYWORDS="~alpha amd64 arm arm64 ~hppa ~ia64 ~m68k ~mips ppc 
ppc64 ~riscv ~s390
 
 BDEPEND="x11-apps/mkfontscale
>=media-fonts/font-util-1.1.1-r1"
+
+XORG_CONFIGURE_OPTIONS=(
+   # https://bugs.gentoo.org/815520
+   --with-fontrootdir="${EPREFIX}"/usr/share/fonts
+)
-- 
2.33.0




[gentoo-dev] [PATCH 2/3] media-fonts/encodings: pass --with-fontrootdir to configure

2021-10-01 Thread Mike Gilbert
Bug: https://bugs.gentoo.org/815520
Signed-off-by: Mike Gilbert 
---
 media-fonts/encodings/encodings-1.0.5-r1.ebuild | 5 +
 1 file changed, 5 insertions(+)

diff --git a/media-fonts/encodings/encodings-1.0.5-r1.ebuild 
b/media-fonts/encodings/encodings-1.0.5-r1.ebuild
index 3e7bceb439a..5c0f196cd64 100644
--- a/media-fonts/encodings/encodings-1.0.5-r1.ebuild
+++ b/media-fonts/encodings/encodings-1.0.5-r1.ebuild
@@ -13,3 +13,8 @@ KEYWORDS="~alpha amd64 arm arm64 ~hppa ~ia64 ~m68k ~mips ppc 
ppc64 ~riscv ~s390
 
 BDEPEND="x11-apps/mkfontscale
>=media-fonts/font-util-1.1.1-r1"
+
+XORG_CONFIGURE_OPTIONS=(
+   # https://bugs.gentoo.org/815520
+   --with-fontrootdir="${EPREFIX}"/usr/share/fonts
+)
-- 
2.33.0




[gentoo-dev] [PATCH 1/3] xorg-3.eclass: pass --with-fontrootdir to configure

2021-10-01 Thread Mike Gilbert
The XORG_FONTROOTDIR autoconf macro calls pkg-config to obtain the
fontrootdir path defined in fontutil.pc.

pkgconf automatically prepends SYSROOT to variable values that start
with a "/". For installation paths, we don't want SYSROOT prepended.

Passing --with-fontrootdir bypasses the pkg-config call and avoids the
problem with SYSROOT.

Bug: https://bugs.gentoo.org/815520
Signed-off-by: Mike Gilbert 
---
 eclass/xorg-3.eclass | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/eclass/xorg-3.eclass b/eclass/xorg-3.eclass
index cfa679b766c..41732e289b9 100644
--- a/eclass/xorg-3.eclass
+++ b/eclass/xorg-3.eclass
@@ -275,7 +275,7 @@ xorg-3_src_unpack() {
unpack ${A}
fi
 
-   [[ -n ${FONT_OPTIONS} ]] && einfo "Detected font directory: ${FONT_DIR}"
+   [[ -n ${FONT} ]] && einfo "Detected font directory: ${FONT_DIR}"
 }
 
 # @FUNCTION: xorg-3_reconf_source
@@ -317,13 +317,17 @@ xorg-3_src_prepare() {
 xorg-3_font_configure() {
debug-print-function ${FUNCNAME} "$@"
 
+   # Pass --with-fontrootdir to override pkgconf SYSROOT behavior.
+   # https://bugs.gentoo.org/815520
+   if grep -q -s "with-fontrootdir" "${ECONF_SOURCE:-.}"/configure; then
+   FONT_OPTIONS+=( --with-fontrootdir="${EPREFIX}"/usr/share/fonts 
)
+   fi
+
if has nls ${IUSE//+} && ! use nls; then
if ! grep -q -s "disable-all-encodings" 
${ECONF_SOURCE:-.}/configure; then
die "--disable-all-encodings option not available in 
configure"
fi
-   FONT_OPTIONS+="
-   --disable-all-encodings
-   --enable-iso8859-1"
+   FONT_OPTIONS+=( --disable-all-encodings --enable-iso8859-1 )
fi
 }
 
@@ -365,6 +369,7 @@ xorg-3_src_configure() {
# @DEFAULT_UNSET
local xorgconfadd=("${XORG_CONFIGURE_OPTIONS[@]}")
 
+   local FONT_OPTIONS=()
[[ -n "${FONT}" ]] && xorg-3_font_configure
 
# Check if package supports disabling of dep tracking
@@ -388,7 +393,7 @@ xorg-3_src_configure() {
${dep_track}
${selective_werror}
${no_static}
-   ${FONT_OPTIONS}
+   "${FONT_OPTIONS[@]}"
"${xorgconfadd[@]}"
)
 
-- 
2.33.0




Re: [gentoo-portage-dev] [PATCH 0/4] Output rewrite for better clarify and greppability

2021-09-28 Thread Mike Gilbert
On Tue, Sep 28, 2021 at 10:20 AM Michał Górny  wrote:
>
> Hi,
>
> Ok, so it's more major than I originally intended but I think it's
> a good direction (once you get used to it). Roughly:
>
> 1. All bash color vars are now prefixed with `PORTAGE_COLOR_` to avoid
>accidental collisions with ebuild vars (e.g. ebuild setting
>`GOOD=foo` broke `elog` before).
> 2. There are specific color vars for all kinds of output functions,
>and now `einfo` messages use distinct color (dark green) from `elog`,
>and `eqawarn` (brown) from `ewarn`.
> 3. Messages are now prefixed by their kind, making it possible to
>distinguish them without colors and grep for specific kind of logs:
>- `[--]` for einfo & ebegin
>- `[II]` for elog
>- `[WW]` for ewarn
>- `[QA]` for eqawarn
>- `[EE]` for eerror
> 4. Finally, I've replaced most of `>>>` and `!!!` in Portage output with
>four `` and `` to align the output again.

I like it.

Maybe add a reference to this bug? https://bugs.gentoo.org/728046



Re: [gentoo-portage-dev] [PATCH] install-qa-check.d: Add a QA check for installing xattrs

2021-09-28 Thread Mike Gilbert
On Tue, Sep 28, 2021 at 2:25 AM Michał Górny  wrote:
>
> On Mon, 2021-09-27 at 21:09 -0400, Mike Gilbert wrote:
> > On Mon, Sep 27, 2021 at 1:20 PM Michał Górny  wrote:
> > > +   eqawarn
> > > +   eqawarn "It is impossible to reliably guarantee that the 
> > > extended attributes"
> > > +   eqawarn "will be reliably preserved while merging.  
> > > Please ensure that any"
> > > +   eqawarn "extended metadata necessary is applied in 
> > > pkg_postinst() phase,"
> > > +   eqawarn "and that the implementation includes a fallback 
> > > if necessary."
> >
> > This message suggests that applying xattrs in pkg_postinst is
> > acceptable. However, your patch offers no way to disable the QA
> > warning for ebuilds that do so.
>
> We'll cross that bridge when we get there.  Ideally, we wouldn't need to
> silence the check because no packages would do that.  If they do, then
> we'll probably want to work on an eclass like fcaps.eclas.

We need a way to silence this thing when false positives pop up and/or
ebuilds are adjusted. That needs to be there from day 1, not when we
cross some bridge later.

An immediate example: packages that call pax-mark in src_compile
because the need to disable MPROTECT on binary that is called a
compile time will end up with extended attributes in ${D} due to
install-xattr. We can adjust them to also call pax-mark in
pkg_postinst, but that won't magically make them go away in ${D}.



Re: [gentoo-portage-dev] [PATCH] install-qa-check.d: Add a QA check for installing xattrs

2021-09-27 Thread Mike Gilbert
On Mon, Sep 27, 2021 at 1:20 PM Michał Górny  wrote:
> +   eqawarn
> +   eqawarn "It is impossible to reliably guarantee that the 
> extended attributes"
> +   eqawarn "will be reliably preserved while merging.  Please 
> ensure that any"
> +   eqawarn "extended metadata necessary is applied in 
> pkg_postinst() phase,"
> +   eqawarn "and that the implementation includes a fallback if 
> necessary."

This message suggests that applying xattrs in pkg_postinst is
acceptable. However, your patch offers no way to disable the QA
warning for ebuilds that do so.



Re: [gentoo-portage-dev] [PATCH] install-qa-check.d: Add a QA check for installing xattrs

2021-09-27 Thread Mike Gilbert
On Mon, Sep 27, 2021 at 1:20 PM Michał Górny  wrote:
>
> Warn the developers if ebuilds install files with xattrs to ${ED}.
> The xattrs may or may not be preserved when installing the package,
> making them unreliable on one hand, and somewhat suprising in other
> cases (e.g. when they unintentionally leak from developer's system).
>
> This is the first step towards restoring PMS compliance and *not*
> preserving extended metadata.

How does preserving xattrs conflict with PMS?

Is there a bug report you could reference?



Re: [gentoo-dev] Guidance on adding kernel config checks to ebuilds

2021-09-27 Thread Mike Gilbert
On Mon, Sep 27, 2021 at 4:28 PM Jason A. Donenfeld  wrote:
>
> On Mon, Sep 27, 2021 at 11:44 AM Robin H. Johnson  wrote:
> > I think we need to strip out a lot of the crap about trying to detect
> > things in the stuff being built, and reduce the check to the simplest
> > possible form:
> > $ time zgrep -w CONFIG_PACKET /proc/config.gz
> > CONFIG_PACKET=y
>
> The results from our current method could of course be cached, and
> even cached between runs, by just relying on `/proc/version` changing
> for different kernels. This seems easy enough to do.
>
> Alternatively, sure, we could require that everyone has /proc/config
> in their kernel config. Many kernels don't have this (mine doesn't),
> but we could add it to the base requirements.

I think it would be reasonable to check a couple fallback locations:

/proc/config.gz
/lib/modules/$(uname -r)/build/.config
/boot/config-$(uname-r)

The slowness really comes from guessing the kernel build location and
invoking the kernel build system via make. Avoiding that is a big
improvement.



Re: [gentoo-dev] Guidance on adding kernel config checks to ebuilds

2021-09-27 Thread Mike Gilbert
On Mon, Sep 27, 2021 at 3:11 PM Peter Stuge  wrote:
>
> Mike Gilbert wrote:
> > It's a waste of time and effort to pepper random ebuilds with checks
> > for options that everyone should have enabled in the first place.
>
> It's not for you to say what everyone should have enabled in their kernel.

Do you not agree that there are some options that should always be
enabled, or at least that we can assume are enabled?

To use my earlier example, should every package that uses AF_INET
check for CONFIG_INET in the kernel?



Re: [gentoo-dev] Guidance on adding kernel config checks to ebuilds

2021-09-27 Thread Mike Gilbert
On Mon, Sep 27, 2021 at 1:56 PM Rich Freeman  wrote:
>
> On Mon, Sep 27, 2021 at 1:44 PM Robin H. Johnson  wrote:
> >
> > I think we need to strip out a lot of the crap about trying to detect
> > things in the stuff being built, and reduce the check to the simplest
> > possible form:
> > $ time zgrep -w CONFIG_PACKET /proc/config.gz
> > CONFIG_PACKET=y
> >
>
> Sure, just please don't strip out the part that actually does what you
> just did - check the running kernel.  I don't think we should assume
> that the user has the configured+prepared sources for a kernel just
> lying around all the time.  I don't build in /usr/src (which is
> apparently discouraged by upstream anyway), so /proc/config.gz is
> really the only reliable indication of how things are setup.  Well,
> that or a config file in /boot which I'm sure others don't use (but
> make install puts it there).

I like the idea of a stripped-down implementation that just checks the
running kernel config when packages get installed. I think that
probably means creating a new eclass though, or moving some of the
current complexity into linux-mod.eclass.



Re: [gentoo-dev] Guidance on adding kernel config checks to ebuilds

2021-09-27 Thread Mike Gilbert
On Mon, Sep 27, 2021 at 12:23 PM Mike Pagano  wrote:
>
> On 9/27/21 12:10 PM, Mike Gilbert wrote:
> > I'm looking to solicit opinions on when it is appropriate for an
> > ebuild to check for kernel config options using linux-info.eclass. I
> > don't think we have any guidelines documented, instead leaving it up
> > to the "common sense" of package maintainers.
> >
> > Adding linux-info calls to pkg_pretend or pkg_setup causes slowdowns
> > when running emerge, so we should do so only when there is a
> > compensating benefit. It doesn't make sense to check for kernel
> > options that are very commonly enabled. But what is "very common"?
> >
> > An obvious example would be CONFIG_INET, which controls IPv4 support
> > in the kernel. It does not make sense to check for that in every
> > package that uses AF_INET sockets.
> >
> > A less obvious example: a user filed a bug against net-misc/dhcpcd
> > today asking that we check for CONFIG_PACKET [1]. My first thought was
> > "why would you ever disable that?". The option description even says
> > "if unsure, say Y". However, I suppose it is technically possible to
> > run a Linux system with it disabled.
> >
> > I think a reasonable rule of thumb would be to assume we can rely on
> > options that are enabled by "make defconfig". If the user chooses to
> > disable them, they are responsible for anything that breaks.
> >
> > Thoughts?
> >
> > [1] https://bugs.gentoo.org/815064
> >
>
> The challenge I see is that these config checks head off bugs and issues 
> without our intervention.
>
> We as kernel maintainers depend on ebuild maintainers to check these things 
> so they don't become "kernel bugs" to figure out.

I guess I'm proposing that we set some minimal standard for kernel
configs. It's a waste of time and effort to pepper random ebuilds with
checks for options that everyone should have enabled in the first
place.



Re: [gentoo-dev] Guidance on adding kernel config checks to ebuilds

2021-09-27 Thread Mike Gilbert
On Mon, Sep 27, 2021 at 1:44 PM Robin H. Johnson  wrote:
>
> On Mon, Sep 27, 2021 at 01:15:10PM -0400, Mike Gilbert wrote:
> > On Mon, Sep 27, 2021 at 12:23 PM Mike Pagano  wrote:
> > > > Adding linux-info calls to pkg_pretend or pkg_setup causes slowdowns
> > > > when running emerge, so we should do so only when there is a
> > > > compensating benefit.
> > >
> > > Is this a significant slowdown? Do you have any numbers?
> >
> > Adding a check for CONFIG_PACKET to the dhcpcd ebuild adds around 7
> > seconds of delay time to the pkg_setup and/or pkg_pretend phase on my
> > system.
> >
> > That's ok if a small number of packages are doing it, but it would
> > become quite annoying if a significant number of them get queued up.
> 7 seconds is ridiculous.

I think the horribly slow performance is mainly due to this change in
how we detect the kernel version:

https://gitweb.gentoo.org/repo/gentoo.git/commit/eclass/linux-info.eclass?id=d1ea596f034285cd044006b107a60902ea059793

That causes "make" to be called 4 times, and each make invocation adds
a couple of seconds to the get_version call.



Re: [gentoo-dev] Guidance on adding kernel config checks to ebuilds

2021-09-27 Thread Mike Gilbert
On Mon, Sep 27, 2021 at 12:23 PM Mike Pagano  wrote:
> > Adding linux-info calls to pkg_pretend or pkg_setup causes slowdowns
> > when running emerge, so we should do so only when there is a
> > compensating benefit.
>
> Is this a significant slowdown? Do you have any numbers?

Adding a check for CONFIG_PACKET to the dhcpcd ebuild adds around 7
seconds of delay time to the pkg_setup and/or pkg_pretend phase on my
system.

That's ok if a small number of packages are doing it, but it would
become quite annoying if a significant number of them get queued up.



[gentoo-dev] Guidance on adding kernel config checks to ebuilds

2021-09-27 Thread Mike Gilbert
I'm looking to solicit opinions on when it is appropriate for an
ebuild to check for kernel config options using linux-info.eclass. I
don't think we have any guidelines documented, instead leaving it up
to the "common sense" of package maintainers.

Adding linux-info calls to pkg_pretend or pkg_setup causes slowdowns
when running emerge, so we should do so only when there is a
compensating benefit. It doesn't make sense to check for kernel
options that are very commonly enabled. But what is "very common"?

An obvious example would be CONFIG_INET, which controls IPv4 support
in the kernel. It does not make sense to check for that in every
package that uses AF_INET sockets.

A less obvious example: a user filed a bug against net-misc/dhcpcd
today asking that we check for CONFIG_PACKET [1]. My first thought was
"why would you ever disable that?". The option description even says
"if unsure, say Y". However, I suppose it is technically possible to
run a Linux system with it disabled.

I think a reasonable rule of thumb would be to assume we can rely on
options that are enabled by "make defconfig". If the user chooses to
disable them, they are responsible for anything that breaks.

Thoughts?

[1] https://bugs.gentoo.org/815064



[gentoo-dev] [PATCH] savedconfig.eclass: drop faulty permissions check

2021-09-26 Thread Mike Gilbert
This check was meant to test if the user has accidentally restricted
access to the /etc/portage/savedconfig directory. There are a few
problems:

1. We don't actually need read access on the directory. We really need
   the execute bit set so that we can access files within the directory.

2. There may be permissions issues on subdirectories, and we would fail
   to detect them.

3. There is no easy way to distingish between EACCES and ENOENT using
   shell commands. We get an exit status of 1 from [[ -r ${path} ]] if
   there is a permissions problem or if some component of the path does
   not exist. This makes resolving problem 2 difficult without using a
   more robust language with direct access to errno.

Instead of trying to detect a permissions problem, just output a warning
telling the user to check permissions if we cannot find a config file.

Bug: https://bugs.gentoo.org/289168
Bug: https://bugs.gentoo.org/814995
Signed-off-by: Mike Gilbert 
---
 eclass/savedconfig.eclass | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/eclass/savedconfig.eclass b/eclass/savedconfig.eclass
index e90a9b618d6..c4fd0c492f4 100644
--- a/eclass/savedconfig.eclass
+++ b/eclass/savedconfig.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2020 Gentoo Authors
+# Copyright 1999-2021 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: savedconfig.eclass
@@ -146,14 +146,10 @@ restore_config() {
treecopy . "${dest}" || die "Failed to restore ${found} to $1"
popd > /dev/null
else
-   # maybe the user is screwing around with perms they shouldnt 
#289168
-   if [[ ! -r ${base} ]] ; then
-   eerror "Unable to read ${base} -- please check its 
permissions."
-   die "Reading config files failed"
-   fi
ewarn "No saved config to restore - please remove 
USE=savedconfig or"
ewarn "provide a configuration file in 
${PORTAGE_CONFIGROOT%/}/etc/portage/savedconfig/${CATEGORY}/${PN}"
-   ewarn "Your config file(s) will not be used this time"
+   ewarn "and ensure the build process has permission to access 
it."
+   ewarn "Your config file(s) will not be used this time."
fi
 }
 
-- 
2.33.0




Re: [gentoo-dev] [PATCH] 2021-09-20-busybox-removal-from-system: add item

2021-09-20 Thread Mike Gilbert
On Mon, Sep 20, 2021 at 2:51 PM Ulrich Mueller  wrote:
>
> >>>>> On Mon, 20 Sep 2021, Mike Gilbert wrote:
>
> > +The sys-apps/busybox package has been removed from @system for Linux
>
> Maybe "from the system set" or "from the system set (@system)" would
> make this even clearer.

I updated the paragraph text to "from the system set (@system)", and
updated the title to read "system set" instead of "@system".



[gentoo-dev] [PATCH] 2021-09-20-busybox-removal-from-system: add item

2021-09-20 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 ...1-09-20-busybox-removal-from-system.en.txt | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 
2021-09-20-busybox-removal-from-system/2021-09-20-busybox-removal-from-system.en.txt

diff --git 
a/2021-09-20-busybox-removal-from-system/2021-09-20-busybox-removal-from-system.en.txt
 
b/2021-09-20-busybox-removal-from-system/2021-09-20-busybox-removal-from-system.en.txt
new file mode 100644
index 000..27917d8
--- /dev/null
+++ 
b/2021-09-20-busybox-removal-from-system/2021-09-20-busybox-removal-from-system.en.txt
@@ -0,0 +1,19 @@
+Title: busybox removal from @system
+Author: Mike Gilbert 
+Posted: -mm-dd
+Revision: 1
+News-Item-Format: 2.0
+Display-If-Installed: sys-apps/busybox
+Display-If-Profile: default/linux/*
+
+The sys-apps/busybox package has been removed from @system for Linux
+profiles. It was decided that this package is not necessary for a basic
+system install.
+
+If you would like to keep this package installed, please ensure it is
+present in your Portage world file.
+
+  emerge --select --noreplace sys-apps/busybox
+
+As well, the "static" USE flag has been disabled by default. It may be
+re-enabled locally via package.use if so desired.
-- 
2.33.0




[gentoo-dev] [PATCH 5/5] sys-apps/dbus: pass systemduserunitdir to configure

2021-09-18 Thread Mike Gilbert
Closes: https://bugs.gentoo.org/813639
Signed-off-by: Mike Gilbert 
---
 sys-apps/dbus/dbus-1.12.20-r3.ebuild | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sys-apps/dbus/dbus-1.12.20-r3.ebuild 
b/sys-apps/dbus/dbus-1.12.20-r3.ebuild
index f175a20c1ae..d108b73feed 100644
--- a/sys-apps/dbus/dbus-1.12.20-r3.ebuild
+++ b/sys-apps/dbus/dbus-1.12.20-r3.ebuild
@@ -135,6 +135,7 @@ multilib_src_configure() {
--with-system-pid-file="${EPREFIX}${rundir}"/dbus.pid

--with-system-socket="${EPREFIX}${rundir}"/dbus/system_bus_socket
--with-systemdsystemunitdir="$(systemd_get_systemunitdir)"
+   --with-systemduserunitdir="$(systemd_get_userunitdir)"
--with-dbus-user=messagebus
$(use_with X x)
)
-- 
2.33.0




[gentoo-dev] [PATCH 4/5] sys-apps/gentoo-systemd-integration: pass systemd dirs to configure

2021-09-18 Thread Mike Gilbert
This prevents install paths from being prefixed with SYSROOT by
pkg-config.

Bug: https://bugs.gentoo.org/813639
Signed-off-by: Mike Gilbert 
---
 .../gentoo-systemd-integration-8.ebuild  | 10 ++
 .../gentoo-systemd-integration-9.ebuild  | 12 +++-
 .../gentoo-systemd-integration-.ebuild   | 12 +++-
 3 files changed, 32 insertions(+), 2 deletions(-)

diff --git 
a/sys-apps/gentoo-systemd-integration/gentoo-systemd-integration-8.ebuild 
b/sys-apps/gentoo-systemd-integration/gentoo-systemd-integration-8.ebuild
index d6fa26516aa..c5acec8fc6d 100644
--- a/sys-apps/gentoo-systemd-integration/gentoo-systemd-integration-8.ebuild
+++ b/sys-apps/gentoo-systemd-integration/gentoo-systemd-integration-8.ebuild
@@ -3,6 +3,8 @@
 
 EAPI=7
 
+inherit systemd
+
 if [[ ${PV} ==  ]]; then

EGIT_REPO_URI="https://anongit.gentoo.org/git/proj/gentoo-systemd-integration.git;
inherit autotools git-r3
@@ -30,3 +32,11 @@ src_prepare() {
default
[[ ${PV} !=  ]] || eautoreconf
 }
+
+src_configure() {
+   local myconf=(
+   
--with-systemdsystemgeneratordir="$(systemd_get_systemgeneratordir)"
+   --with-systemdsystempresetdir="$(systemd_get_systempresetdir)"
+   )
+   econf "${myconf[@]}"
+}
diff --git 
a/sys-apps/gentoo-systemd-integration/gentoo-systemd-integration-9.ebuild 
b/sys-apps/gentoo-systemd-integration/gentoo-systemd-integration-9.ebuild
index 7983540e726..0d5b07883d9 100644
--- a/sys-apps/gentoo-systemd-integration/gentoo-systemd-integration-9.ebuild
+++ b/sys-apps/gentoo-systemd-integration/gentoo-systemd-integration-9.ebuild
@@ -1,8 +1,10 @@
-# Copyright 1999-2020 Gentoo Authors
+# Copyright 1999-2021 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=7
 
+inherit systemd
+
 if [[ ${PV} ==  ]]; then

EGIT_REPO_URI="https://anongit.gentoo.org/git/proj/gentoo-systemd-integration.git;
inherit autotools git-r3
@@ -28,3 +30,11 @@ src_prepare() {
default
[[ ${PV} !=  ]] || eautoreconf
 }
+
+src_configure() {
+   local myconf=(
+   
--with-systemdsystemgeneratordir="$(systemd_get_systemgeneratordir)"
+   --with-systemdsystempresetdir="$(systemd_get_systempresetdir)"
+   )
+   econf "${myconf[@]}"
+}
diff --git 
a/sys-apps/gentoo-systemd-integration/gentoo-systemd-integration-.ebuild 
b/sys-apps/gentoo-systemd-integration/gentoo-systemd-integration-.ebuild
index 7983540e726..0d5b07883d9 100644
--- a/sys-apps/gentoo-systemd-integration/gentoo-systemd-integration-.ebuild
+++ b/sys-apps/gentoo-systemd-integration/gentoo-systemd-integration-.ebuild
@@ -1,8 +1,10 @@
-# Copyright 1999-2020 Gentoo Authors
+# Copyright 1999-2021 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=7
 
+inherit systemd
+
 if [[ ${PV} ==  ]]; then

EGIT_REPO_URI="https://anongit.gentoo.org/git/proj/gentoo-systemd-integration.git;
inherit autotools git-r3
@@ -28,3 +30,11 @@ src_prepare() {
default
[[ ${PV} !=  ]] || eautoreconf
 }
+
+src_configure() {
+   local myconf=(
+   
--with-systemdsystemgeneratordir="$(systemd_get_systemgeneratordir)"
+   --with-systemdsystempresetdir="$(systemd_get_systempresetdir)"
+   )
+   econf "${myconf[@]}"
+}
-- 
2.33.0




[gentoo-dev] [PATCH 3/5] systemd.eclass: introduce systemd_get_systempresetdir

2021-09-18 Thread Mike Gilbert
Bug: https://bugs.gentoo.org/813639
Signed-off-by: Mike Gilbert 
---
 eclass/systemd.eclass | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
index c80c4c43f31..7731bede094 100644
--- a/eclass/systemd.eclass
+++ b/eclass/systemd.eclass
@@ -145,6 +145,24 @@ systemd_get_systemgeneratordir() {
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
+}
+
+# @FUNCTION: systemd_get_systempresetdir
+# @DESCRIPTION:
+# Output the path for the systemd system preset directory (not including
+# ${D}). This function always succeeds, even if systemd is not installed.
+systemd_get_systempresetdir() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   echo "${EPREFIX}$(_systemd_get_systempresetdir)"
+}
+
 # @FUNCTION: systemd_dounit
 # @USAGE: ...
 # @DESCRIPTION:
-- 
2.33.0




[gentoo-dev] [PATCH 2/5] udev.eclass: set PKG_CONFIG_FDO_SYSROOT_RULES

2021-09-18 Thread Mike Gilbert
This prevents pkgconf from prepending install paths with SYSROOT.

Bug: https://bugs.gentoo.org/813639
Signed-off-by: Mike Gilbert 
---
 eclass/udev.eclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/eclass/udev.eclass b/eclass/udev.eclass
index 7f9415914cd..073e5d8acbc 100644
--- a/eclass/udev.eclass
+++ b/eclass/udev.eclass
@@ -49,6 +49,8 @@ fi
 # @DESCRIPTION:
 # Get unprefixed udevdir.
 _udev_get_udevdir() {
+   # https://github.com/pkgconf/pkgconf/issues/205
+   local -x PKG_CONFIG_FDO_SYSROOT_RULES=1
if $($(tc-getPKG_CONFIG) --exists udev); then
local udevdir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)"
echo "${udevdir#${EPREFIX%/}}"
-- 
2.33.0




[gentoo-dev] [PATCH 1/5] systemd.eclass: set PKG_CONFIG_FDO_SYSROOT_RULES

2021-09-18 Thread Mike Gilbert
This prevents pkgconf from prepending install paths with SYSROOT.

Bug: https://bugs.gentoo.org/813639
Signed-off-by: Mike Gilbert 
---
 eclass/systemd.eclass | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
index 27e4dcae1ff..c80c4c43f31 100644
--- a/eclass/systemd.eclass
+++ b/eclass/systemd.eclass
@@ -48,6 +48,9 @@ _systemd_get_dir() {
[[ ${#} -eq 2 ]] || die "Usage: ${FUNCNAME}  
"
local variable=${1} fallback=${2} d
 
+   # https://github.com/pkgconf/pkgconf/issues/205
+   local -x PKG_CONFIG_FDO_SYSROOT_RULES=1
+
if $(tc-getPKG_CONFIG) --exists systemd; then
d=$($(tc-getPKG_CONFIG) --variable="${variable}" systemd) || die
d=${d#${EPREFIX}}
-- 
2.33.0




[gentoo-dev] [PATCH 2/2] linux-info.eclass: getfilevar: pass dot-config=0 to make

2021-09-13 Thread Mike Gilbert
This disables the kernel config check for versions prior to 5.4.

Bug: https://bugs.gentoo.org/811726
Signed-off-by: Mike Gilbert 
---
 eclass/linux-info.eclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
index 97f7b5c06a9..9eae5ad589b 100644
--- a/eclass/linux-info.eclass
+++ b/eclass/linux-info.eclass
@@ -205,9 +205,10 @@ getfilevar() {
 
# We use nonfatal because we want the caller to take care of 
things #373151
# Pass need-config= to make to avoid config check in kernel 
Makefile.
+   # 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}" M="${T}" need-config= 
${BUILD_FIXES} -s -f - 2>/dev/null
+   nonfatal emake -C "${basedname}" M="${T}" dot-config=0 
need-config= ${BUILD_FIXES} -s -f - 2>/dev/null
 
ARCH=${myARCH}
fi
-- 
2.33.0




[gentoo-dev] [PATCH 1/2] linux-info.eclass: rework get_running_version

2021-09-13 Thread Mike Gilbert
This function may fail if the version cannot be parsed from a Makefile
found by following the /lib/modules/${KV_FULL}/{source,build} symlinks.
Instead of failing, we should just split KV_FULL as a fallback.

Also, simplify the existance checks for the kernel Makefile; if we can't
find the kernel source directory, there is really no point in checking
for the kernel build directory. The latter will probably contain a
Makefile with no version information.

Bug: https://bugs.gentoo.org/811726
Signed-off-by: Mike Gilbert 
---
 eclass/linux-info.eclass | 47 +---
 1 file changed, 20 insertions(+), 27 deletions(-)

diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
index 4e08949a385..97f7b5c06a9 100644
--- a/eclass/linux-info.eclass
+++ b/eclass/linux-info.eclass
@@ -629,34 +629,27 @@ get_running_version() {
die "${FUNCNAME}() called on non-Linux system, please fix the 
ebuild"
fi
 
-   KV_FULL=$(uname -r)
-
-   if [[ -f ${ROOT%/}/lib/modules/${KV_FULL}/source/Makefile && -f 
${ROOT%/}/lib/modules/${KV_FULL}/build/Makefile ]]; then
-   KERNEL_DIR=$(readlink -f 
${ROOT%/}/lib/modules/${KV_FULL}/source)
-   KBUILD_OUTPUT=$(readlink -f 
${ROOT%/}/lib/modules/${KV_FULL}/build)
-   unset KV_FULL
-   get_version
-   return $?
-   elif [[ -f ${ROOT%/}/lib/modules/${KV_FULL}/source/Makefile ]]; then
-   KERNEL_DIR=$(readlink -f 
${ROOT%/}/lib/modules/${KV_FULL}/source)
-   unset KV_FULL
-   get_version
-   return $?
-   elif [[ -f ${ROOT%/}/lib/modules/${KV_FULL}/build/Makefile ]]; then
-   KERNEL_DIR=$(readlink -f ${ROOT%/}/lib/modules/${KV_FULL}/build)
-   unset KV_FULL
-   get_version
-   return $?
-   else
-   # This handles a variety of weird kernel versions.  Make sure 
to update
-   # tests/linux-info_get_running_version.sh if you want to change 
this.
-   local kv_full=${KV_FULL//[-+_]*}
-   KV_MAJOR=$(ver_cut 1 ${kv_full})
-   KV_MINOR=$(ver_cut 2 ${kv_full})
-   KV_PATCH=$(ver_cut 3 ${kv_full})
-   
KV_EXTRA="${KV_FULL#${KV_MAJOR}.${KV_MINOR}${KV_PATCH:+.${KV_PATCH}}}"
-   : ${KV_PATCH:=0}
+   local kv=$(uname -r)
+
+   if [[ -f ${ROOT%/}/lib/modules/${kv}/source/Makefile ]]; then
+   KERNEL_DIR=$(readlink -f "${ROOT%/}/lib/modules/${kv}/source")
+   if [[ -f ${ROOT%/}/lib/modules/${kv}/build/Makefile ]]; then
+   KBUILD_OUTPUT=$(readlink -f 
"${ROOT%/}/lib/modules/${kv}/build")
+   fi
+   get_version && return 0
fi
+
+   KV_FULL=${kv}
+
+   # This handles a variety of weird kernel versions.  Make sure to update
+   # tests/linux-info_get_running_version.sh if you want to change this.
+   local kv_full=${KV_FULL//[-+_]*}
+   KV_MAJOR=$(ver_cut 1 ${kv_full})
+   KV_MINOR=$(ver_cut 2 ${kv_full})
+   KV_PATCH=$(ver_cut 3 ${kv_full})
+   KV_EXTRA="${KV_FULL#${KV_MAJOR}.${KV_MINOR}${KV_PATCH:+.${KV_PATCH}}}"
+   : ${KV_PATCH:=0}
+
return 0
 }
 
-- 
2.33.0




[gentoo-dev] [PATCH 5/5] sys-libs/libxcrypt: disable static-libs by default

2021-09-09 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 sys-libs/libxcrypt/libxcrypt-4.4.20.ebuild | 2 +-
 sys-libs/libxcrypt/libxcrypt-4.4.25.ebuild | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/sys-libs/libxcrypt/libxcrypt-4.4.20.ebuild 
b/sys-libs/libxcrypt/libxcrypt-4.4.20.ebuild
index f75a2a57824..f31e856bc88 100644
--- a/sys-libs/libxcrypt/libxcrypt-4.4.20.ebuild
+++ b/sys-libs/libxcrypt/libxcrypt-4.4.20.ebuild
@@ -21,7 +21,7 @@ fi
 LICENSE="LGPL-2.1+ public-domain BSD BSD-2"
 SLOT="0/1"
 KEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~mips ppc ppc64 ~riscv ~s390 sparc 
x86"
-IUSE="+compat split-usr +static-libs system test"
+IUSE="+compat split-usr static-libs system test"
 REQUIRED_USE="split-usr? ( system )"
 RESTRICT="!test? ( test )"
 
diff --git a/sys-libs/libxcrypt/libxcrypt-4.4.25.ebuild 
b/sys-libs/libxcrypt/libxcrypt-4.4.25.ebuild
index 0124869d552..dca937cb958 100644
--- a/sys-libs/libxcrypt/libxcrypt-4.4.25.ebuild
+++ b/sys-libs/libxcrypt/libxcrypt-4.4.25.ebuild
@@ -21,7 +21,7 @@ fi
 LICENSE="LGPL-2.1+ public-domain BSD BSD-2"
 SLOT="0/1"
 KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~riscv 
~s390 ~sparc ~x86"
-IUSE="+compat split-usr +static-libs system test"
+IUSE="+compat split-usr static-libs system test"
 REQUIRED_USE="split-usr? ( system )"
 RESTRICT="!test? ( test )"
 
-- 
2.33.0




[gentoo-dev] [PATCH 3/5] profiles/embedded: enable libcrypt[static-libs] by default

2021-09-09 Thread Mike Gilbert
Needed for busybox[static].

Signed-off-by: Mike Gilbert 
---
 profiles/embedded/package.use | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/profiles/embedded/package.use b/profiles/embedded/package.use
index 7dda9d81fe0..526095b3877 100644
--- a/profiles/embedded/package.use
+++ b/profiles/embedded/package.use
@@ -1 +1,3 @@
 sys-apps/busybox make-symlinks static
+virtual/libcrypt static-libs
+sys-libs/libxcrypt static-libs
-- 
2.33.0




[gentoo-dev] [PATCH 1/5] profiles/default/linux: remove busybox from @system

2021-09-09 Thread Mike Gilbert
busybox[static] was added to @system as a system recovery tool.

If the system is in such a state that a static shell is needed for
recovery, it is likely that remote access is also broken, and the
sysadmin will need to log into a console. At that point, they could boot
from recovery media anyway.

Also, stage3 tarballs are often used to build containers, where having
a recovery tool installed is completely pointless.

Signed-off-by: Mike Gilbert 
---
 profiles/default/linux/packages | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/profiles/default/linux/packages b/profiles/default/linux/packages
index d0b8745d044..6d35bf72e20 100644
--- a/profiles/default/linux/packages
+++ b/profiles/default/linux/packages
@@ -1,4 +1,4 @@
-# Copyright 2004-2015 Gentoo Foundation.
+# Copyright 2004-2021 Gentoo Authors.
 # Distributed under the terms of the GNU General Public License v2
 
 # This file extends the base packages file for the default profile that all
@@ -6,7 +6,6 @@
 # will have.  Some will have an selinux profile (see 
${PORTDIR}/profiles/selinux).
 # The idea is to only create a new family of profiles when absolutely 
necessary.
 
-*sys-apps/busybox
 *sys-apps/iproute2
 *sys-apps/man-pages
 *sys-apps/net-tools
-- 
2.33.0




[gentoo-dev] [PATCH 2/5] profiles/default/linux: remove busybox from package.use

2021-09-09 Thread Mike Gilbert
With busybox no longer in @system, there is no reason to make it static
by default.

Signed-off-by: Mike Gilbert 
---
 profiles/default/linux/package.use | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/profiles/default/linux/package.use 
b/profiles/default/linux/package.use
index e45526319f5..a283c16b146 100644
--- a/profiles/default/linux/package.use
+++ b/profiles/default/linux/package.use
@@ -1,15 +1,10 @@
-# Copyright 1999-2011 Gentoo Foundation
+# Copyright 1999-2021 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # Mike Gilbert  (2017-10-29)
 # Override default from make.defaults, bug 635822.
 net-libs/mbedtls -zlib
 
-# Mike Frysinger  (2015-11-12)
-# We want busybox statically linked by default as it is the system rescue 
shell.
-# But we cannot statically link pam, so turn that off by default. #468580
-sys-apps/busybox -pam static
-
 # Arfrever Frehtes Taifersar Arahesis  (2011-02-13)
 # Disable deprecated bsddb module of Python 2 by default.
 =dev-lang/python-2* -berkdb
-- 
2.33.0




[gentoo-dev] [PATCH 4/5] virtual/libcrypt: disable static-libs by default

2021-09-09 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 virtual/libcrypt/libcrypt-1-r1.ebuild | 2 +-
 virtual/libcrypt/libcrypt-2.ebuild| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/virtual/libcrypt/libcrypt-1-r1.ebuild 
b/virtual/libcrypt/libcrypt-1-r1.ebuild
index fc93d79bc4c..d239f1b834e 100644
--- a/virtual/libcrypt/libcrypt-1-r1.ebuild
+++ b/virtual/libcrypt/libcrypt-1-r1.ebuild
@@ -9,7 +9,7 @@ DESCRIPTION="Virtual for libcrypt.so"
 
 SLOT="0/1"
 KEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~m68k ~mips ppc ppc64 ~riscv ~s390 
sparc x86 ~x64-cygwin ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos 
~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris"
-IUSE="+static-libs"
+IUSE="static-libs"
 
 RDEPEND="
!prefix-guest? (
diff --git a/virtual/libcrypt/libcrypt-2.ebuild 
b/virtual/libcrypt/libcrypt-2.ebuild
index a27d98da245..f9bf2af6231 100644
--- a/virtual/libcrypt/libcrypt-2.ebuild
+++ b/virtual/libcrypt/libcrypt-2.ebuild
@@ -9,7 +9,7 @@ DESCRIPTION="Virtual for libcrypt.so"
 
 SLOT="0/2"
 KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~riscv 
~s390 ~sparc ~x86 ~x64-cygwin ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos 
~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris"
-IUSE="+static-libs"
+IUSE="static-libs"
 
 RDEPEND="
!prefix-guest? (
-- 
2.33.0




Re: [gentoo-dev] [PATCH] Support Makefiles that set variables to a non-static value

2021-09-09 Thread Mike Gilbert
On Thu, Sep 9, 2021 at 1:21 PM Robin H. Johnson  wrote:
>
> On Wed, Sep 01, 2021 at 02:44:11PM -0400, Mike Pagano wrote:
> > Previously, the kernel Makefile had to define version variables
> > as static string literals to be read.
> > This change will allow varibles defined as non-static values
> > to be read.
> Hi,
>
> This change has broken infra systems where /usr/src/ is empty because
> they use a binary kernel. /proc/config.gz does exist on those systems for this
> use case.
>
> Specifically, any package that uses linux-info to issues warnings via the '~'
> syntax now fails because "getfilevar_noexec VERSION ..." returns empty string.
>
>  * Determining the location of the kernel source code
>  * Unable to find kernel sources at /usr/src/linux
>  * Please make sure that /usr/src/linux points at your running kernel,
>  * (or the kernel you wish to build against).
>  * Alternatively, set the KERNEL_DIR environment variable to the kernel 
> sources location
>  * Unable to calculate Linux Kernel version for build, attempting to use 
> running version
>  * ERROR: app-emulation/docker-20.10.7::gentoo failed (setup phase):
>  *   Unable to determine any Linux Kernel version, please report a bug
>  *
>  * Call stack:
>  *   ebuild.sh, line 127:  Called pkg_setup
>  *   docker-20.10.7.ebuild, line 110:  Called kernel_is 'lt' '4' '5'
>  *   linux-info.eclass, line 405:  Called linux-info_get_any_version
>  *   linux-info.eclass, line 678:  Called die
>  * The specific snippet of code:
>  *  die "Unable to determine any Linux Kernel version, 
> please report a bug"
>
> I'd like to propose that we revert the original CVS change that supported the 
> fallback to getfilevar_noexec:
> https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/eclass/linux-info.eclass?id=ab160a941f5f52c95b47129d3243c693b05401e5

I cannot reproduce this with /proc/config.gz present.

% sudo ebuild docker-20.10.8.ebuild clean setup
 * docker-20.10.8.tar.gz BLAKE2B SHA512 size ;-) ...
  [ ok ]
 * Determining the location of the kernel source code
 * Unable to find kernel sources at /usr/src/linux
 * Please make sure that /usr/src/linux points at your running kernel,
 * (or the kernel you wish to build against).
 * Alternatively, set the KERNEL_DIR environment variable to the
kernel sources location
 * Unable to calculate Linux Kernel version for build, attempting to
use running version
 * Checking for suitable kernel configuration options...
 *   CONFIG_BRIDGE_NETFILTER:is not set when it should be.
 *   CONFIG_IP_NF_TARGET_MASQUERADE: is not set when it should be.
 *   CONFIG_NETFILTER_XT_MATCH_IPVS: is not set when it should be.
 *   CONFIG_IP_VS:   is not set when it should be.
 *   CONFIG_IP_VS_PROTO_TCP: is not set when it should be.
 *   CONFIG_IP_VS_PROTO_UDP: is not set when it should be.
 *   CONFIG_IP_VS_NFCT:  is not set when it should be.
 *   CONFIG_IP_VS_RR:is not set when it should be.
 *   CONFIG_OVERLAY_FS:  is not set when it should be.
 * Please check to make sure these options are set correctly.
 * Failure to do so may cause unexpected problems.



[gentoo-dev] [PATCH] profiles/arch/amd64/x32: set KERNEL_ABI="amd64"

2021-09-06 Thread Mike Gilbert
Closes: https://bugs.gentoo.org/427052
Signed-off-by: Mike Gilbert 
---
 profiles/arch/amd64/x32/make.defaults | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/profiles/arch/amd64/x32/make.defaults 
b/profiles/arch/amd64/x32/make.defaults
index b509b305b00..0c9b008c9fd 100644
--- a/profiles/arch/amd64/x32/make.defaults
+++ b/profiles/arch/amd64/x32/make.defaults
@@ -1,10 +1,14 @@
-# Copyright 1999-2017 Gentoo Foundation
+# Copyright 1999-2021 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 DEFAULT_ABI="x32"
 ABI="x32"
 MULTILIB_ABIS="amd64 x86 x32"
 
+# Mike Gilbert  (2021-09-06)
+# x32 userspace runs on amd64 kernels.
+KERNEL_ABI="amd64"
+
 # Michał Górny  (2014-07-01)
 # Default to abi_x86_x32 for packages that don't have it forced.
 ABI_X86="x32"
-- 
2.33.0




Re: [gentoo-dev] [PATCH 29/44] meson.eclass: Set @PROVIDES

2021-09-02 Thread Mike Gilbert
On Thu, Sep 2, 2021 at 6:47 AM Michał Górny  wrote:
>
> Signed-off-by: Michał Górny 
> ---
>  eclass/meson.eclass | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> index eaff26709a75..c5e3b91f9a15 100644
> --- a/eclass/meson.eclass
> +++ b/eclass/meson.eclass
> @@ -6,6 +6,7 @@
>  # William Hubbs 
>  # Mike Gilbert 
>  # @SUPPORTED_EAPIS: 6 7 8
> +# @PROVIDES: ninja-utils
>  # @BLURB: common ebuild functions for meson-based packages
>  # @DESCRIPTION:
>  # This eclass contains the default phase functions for packages which
> --
> 2.33.0

Please drop this patch. meson.eclass does not use ninja-utils since
5974284d8cb3c2b6d3dab3ad83c2f270db3b0798, and we certainly don't want
to implicitly provide it to consumers.

We should probably remove the ninja-utils inherit from meson.eclass instead.



[gentoo-dev] [PATCH 3/3] meson-multilib.eclass: fix MAINTAINER and AUTHOR tags

2021-08-27 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 eclass/meson-multilib.eclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/eclass/meson-multilib.eclass b/eclass/meson-multilib.eclass
index 83c5202d069..1ed95f99fa1 100644
--- a/eclass/meson-multilib.eclass
+++ b/eclass/meson-multilib.eclass
@@ -3,10 +3,10 @@
 
 # @ECLASS: meson-multilib.eclass
 # @MAINTAINER:
-# Author: Matt Turner 
+# Matt Turner 
 # @AUTHOR:
-# Author: Michał Górny 
-# Author: Matt Turner 
+# Michał Górny 
+# Matt Turner 
 # @SUPPORTED_EAPIS: 7 8
 # @BLURB: meson wrapper for multilib builds
 # @DESCRIPTION:
-- 
2.33.0




[gentoo-dev] [PATCH 2/3] meson-multilib.eclass: use meson_install helper function

2021-08-27 Thread Mike Gilbert
Use meson_install to avoid calling einstalldocs more than once.
multilib-minimal_src_install already handles it.

Signed-off-by: Mike Gilbert 
---
 eclass/meson-multilib.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/meson-multilib.eclass b/eclass/meson-multilib.eclass
index fc1ef5802f9..83c5202d069 100644
--- a/eclass/meson-multilib.eclass
+++ b/eclass/meson-multilib.eclass
@@ -125,7 +125,7 @@ meson-multilib_src_install() {
 }
 
 multilib_src_install() {
-   meson_src_install "${_meson_args[@]}"
+   meson_install "${_meson_args[@]}"
 }
 
 fi
-- 
2.33.0




[gentoo-dev] [PATCH 1/3] meson.eclass: introduce meson_install helper function

2021-08-27 Thread Mike Gilbert
This will be called from meson.eclass and meson-multilib.eclass.

Signed-off-by: Mike Gilbert 
---
 eclass/meson.eclass | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 8b22797da71..a3cf8740b26 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -404,11 +404,11 @@ meson_src_test() {
"$@" || die "tests failed"
 }
 
-# @FUNCTION: meson_src_install
+# @FUNCTION: meson_install
 # @USAGE: [extra meson install arguments]
 # @DESCRIPTION:
-# This is the meson_src_install function.
-meson_src_install() {
+# Calls meson install with suitable arguments
+meson_install() {
debug-print-function ${FUNCNAME} "$@"
 
local mesoninstallargs=(
@@ -420,10 +420,17 @@ meson_src_install() {
set -- meson install "${mesoninstallargs[@]}"
echo "$@" >&2
"$@" || die "install failed"
+}
+
+# @FUNCTION: meson_src_install
+# @USAGE: [extra meson install arguments]
+# @DESCRIPTION:
+# This is the meson_src_install function.
+meson_src_install() {
+   debug-print-function ${FUNCNAME} "$@"
 
-   pushd "${S}" > /dev/null || die
+   meson_install "$@"
einstalldocs
-   popd > /dev/null || die
 }
 
 fi
-- 
2.33.0




Re: [gentoo-dev] [PATCH] unpacker.eclass: enable EAPI 8

2021-08-26 Thread Mike Gilbert
On Thu, Aug 26, 2021 at 7:40 AM Ulrich Mueller  wrote:
>
> > On Thu, 26 Aug 2021, Stephan Hartmann wrote:
>
> > --- a/eclass/unpacker.eclass
> > +++ b/eclass/unpacker.eclass
> > @@ -4,7 +4,7 @@
> >  # @ECLASS: unpacker.eclass
> >  # @MAINTAINER:
> >  # base-sys...@gentoo.org
> > -# @SUPPORTED_EAPIS: 5 6 7
> > +# @SUPPORTED_EAPIS: 5 6 7 8
> >  # @BLURB: helpers for extraneous file formats and consistent behavior 
> > across EAPIs
> >  # @DESCRIPTION:
> >  # Some extraneous file formats are not part of PMS, or are only in certain
> > @@ -16,7 +16,7 @@
> >  #  - support partial unpacks?
> >
> >  case ${EAPI:-0} in
> > - [567]) ;;
> > + [5678]) ;;
> >   *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
> >  esac
> >
>
> I think for EAPI 8 you'll need additional cases in _unpacker() for
> 7z, .rar, and .lha/.lzh, because package manager support for these
> extensions has been dropped:
> https://projects.gentoo.org/pms/8/pms.html#x1-135002r24

That would be a nice enhancement for the eclass, but I don't think it
needs to be implemented before EAPI 8 is allowed. It could wait until
some EAPI 8 ebuild actually needs to unpack one of these obscure
formats.



Re: [gentoo-dev] [PATCH] meson.eclass: stop calling ninja

2021-08-24 Thread Mike Gilbert
On Tue, Aug 24, 2021 at 1:35 AM William Hubbs  wrote:
>
> Use the compile and install subcommands of meson instead of calling
> ninja. This allows for the possibility of a different back end.
>
> Signed-off-by: William Hubbs 
> ---
>  eclass/meson.eclass | 24 +---
>  1 file changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> index 2a563e367c6..e9c9b155096 100644
> --- a/eclass/meson.eclass
> +++ b/eclass/meson.eclass
> @@ -379,7 +379,21 @@ meson_src_configure() {
>  meson_src_compile() {
> debug-print-function ${FUNCNAME} "$@"
>
> -   eninja -C "${BUILD_DIR}" "$@"
> +   local mesoncompileargs=(
> +   -C "${BUILD_DIR}"
> +   )
> +   if [[ -n ${NINJAOPTS} ]]; then
> +   mesoncompileargs+=(
> +   --jobs "$(makeopts_jobs ${NINJAOPTS})"
> +   --load-average "$(makeopts_loadavg ${NINJAOPTS})"
> +   )
> +   elif [[ -n ${MAKEOPTS} ]]; then
> +   mesoncompileargs+=(
> +   --jobs "$(makeopts_jobs ${MAKEOPTS})"
> +   --load-average "$(makeopts_loadavg ${MAKEOPTS})"

${MAKEOPTS} should be quoted on the above 2 lines.

makeopts_loadavg outputs 999 by default if the load average is not
specified. Please override this as "0" by passing it as the second
argument.

> +   )
> +
> +   meson compile "${mesoncompileargs[@]}" "$@" || die "compile failed"
>  }
>
>  # @FUNCTION: meson_src_test
> @@ -406,13 +420,17 @@ meson_src_test() {
>  }
>
>  # @FUNCTION: meson_src_install
> -# @USAGE: [extra ninja install arguments]
> +# @USAGE: [extra meson install arguments]
>  # @DESCRIPTION:
>  # This is the meson_src_install function.
>  meson_src_install() {
> debug-print-function ${FUNCNAME} "$@"
>
> -   DESTDIR="${D}" eninja -C "${BUILD_DIR}" install "$@"
> +   local mesoninstallargs=(
> +   -C "${BUILD_DIR}" "$@"
> +   --destdir "${D}"
> +   )
> +   meson install "${mesoninstallargs[@]}" "$@"

You are including "$@" twice: once in mesoninstallargs, and once on
the above line. Please remove it from mesoninstallargs.



Re: [gentoo-dev] [PATCH] meson.eclass: stop calling ninja

2021-08-24 Thread Mike Gilbert
On Tue, Aug 24, 2021 at 3:59 AM Florian Schmaus  wrote:
>
> On 24/08/2021 07.35, William Hubbs wrote:
> > Use the compile and install subcommands of meson instead of calling
> > ninja. This allows for the possibility of a different back end.
> >
> > Signed-off-by: William Hubbs 
> > ---
> >   eclass/meson.eclass | 24 +---
> >   1 file changed, 21 insertions(+), 3 deletions(-)
> >
> > diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> > index 2a563e367c6..e9c9b155096 100644
> > --- a/eclass/meson.eclass
> > +++ b/eclass/meson.eclass
> > @@ -379,7 +379,21 @@ meson_src_configure() {
> >   meson_src_compile() {
> >   debug-print-function ${FUNCNAME} "$@"
> >
> > - eninja -C "${BUILD_DIR}" "$@"
> > + local mesoncompileargs=(
> > + -C "${BUILD_DIR}"
> > + )
> > + if [[ -n ${NINJAOPTS} ]]; then
> > + mesoncompileargs+=(
> > + --jobs "$(makeopts_jobs ${NINJAOPTS})"
> > + --load-average "$(makeopts_loadavg ${NINJAOPTS})"
> > + )
> > + elif [[ -n ${MAKEOPTS} ]]; then
> > + mesoncompileargs+=(
> > + --jobs "$(makeopts_jobs ${MAKEOPTS})"
> > + --load-average "$(makeopts_loadavg ${MAKEOPTS})"
> > + )
> > +
> > + meson compile "${mesoncompileargs[@]}" "$@" || die "compile failed"
> >   }
> >
> >   # @FUNCTION: meson_src_test
>
> Missing 'fi'?
>
> I'd probably drop NINJAOPTS and simply have MAKEOPTS the one place where
> users can specify --jobs and --load values.

I agree: drop NINJAOPTS.



Re: [gentoo-dev] News Item for uClibc-ng deprecation

2021-08-17 Thread Mike Gilbert
On Tue, Aug 17, 2021 at 7:40 AM Anthony G. Basile  wrote:
>
> Hi everyone,
>
> Can I get feedback on the following news item?  (BTW, thanks soap)
>
> Title: uClibc-ng retirement on 2023/01/01
> Author: Anthony G. Basile 
> Posted: 2021-08-15
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Profile: default/linux/uclibc/*
>
> uClibc-ng is mostly abandoned upstream, and since my RFC in Jan 2021,
> noone has volunteered to step up maintenance or expressed interest in
> the uClibc-ng profiles. With this announcement we last-rite the "uclibc"
> profiles, which will be removed on 2023/01/01. For parties interested in
> an alternative libc, consider moving to musl, which is supported.

2023? That seems like a pretty long time to wait to remove something
that isn't very well supported right now.



Re: [gentoo-dev] [PATCH] readme.gentoo-r1.eclass: Use fixed location for README.gentoo

2021-08-16 Thread Mike Gilbert
On Sun, Aug 15, 2021 at 6:55 AM Ulrich Müller  wrote:
>
> Eclass documentation and the elog message indicate that the expected
> location to install the file is /usr/share/doc/${PF}/README.gentoo,
> not the location of the ebuild's last docinto call.
>
> Signed-off-by: Ulrich Müller 
> ---
>  eclass/readme.gentoo-r1.eclass | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/eclass/readme.gentoo-r1.eclass b/eclass/readme.gentoo-r1.eclass
> index 69d0e1c5c6b4..bebdba5b705a 100644
> --- a/eclass/readme.gentoo-r1.eclass
> +++ b/eclass/readme.gentoo-r1.eclass
> @@ -76,7 +76,10 @@ readme.gentoo_create_doc() {
> die "You are not specifying README.gentoo contents!"
> fi
>
> -   dodoc "${T}"/README.gentoo
> +   ( # subshell to avoid pollution of calling environment
> +   docinto .
> +   dodoc "${T}"/README.gentoo
> +   )

I believe the current handling "die" in subshells terminates execution
at the end of the current phase.

Maybe add "|| die" after the subshell so that execution stops
immediately if dodoc fails.



[gentoo-dev] Package up for grabs: app-text/bdf2psf (nt)

2021-08-14 Thread Mike Gilbert




Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check

2021-08-01 Thread Mike Gilbert
On Sun, Aug 1, 2021 at 1:24 PM Sam James  wrote:
>
>
>
> > On 1 Aug 2021, at 17:42, Mike Gilbert  wrote:
> >
> > On Sat, Jul 31, 2021 at 7:56 PM Sam James  wrote:
> >>
> >> This adds two tmpfiles related QA checks:
> >> 1) Verify packages don't install tmpfiles to /etc/tmpfiles.d, which
> >> is a deprecated location;
> >
> > sys-apps/systemd calls keepdir /etc/tmpfiles.d so that users don't get
> > confused by a missing directory.
> >
> > How would you suggest I avoid this QA warning?
>
> We can change the check to be for installing files within the directory?

Works for me. Note that keepdir actually installs a dotfile,
(.keep-${CATEGORY}_${PN}-${SLOT}), so we would want to exclude that.
Also, systemd-tmpfiles looks for *.conf and ignores other files, so we
could probably ignore them too.

Maybe something like this:

files=( "${ED}"/etc/tmpfiles.d/*.conf )
if [[ ${#files[@]} -gt 0 ]]; then
...

> >
> >> 2) Check whether packages inherit tmpfiles.eclass if they're
> >> installing files to /usr/lib/tmpfiles.d.
> >>
> >> (This helps to catch packages not calling tmpfiles_process
> >> in pkg_postinst).
> >
> > sys-apps/systemd installs many files in /usr/lib/tmpfiles.d, but
> > calling tmpfiles_process would probably not make much sense.
> >
> > How would you suggest I avoid this QA warning?
> >
>
> We'll probably hardcode a list of folks who need to do this:
> - sys-libs/pam
> - sys-apps/systemd
> (I'll check for any others, but I don't believe there are any now).
>
> How about that?

I'm not crazy about hard-coding package names inside a QA check.
Personally, I would prefer a magic variable I could set to disable the
check from the ebuild side.



Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check

2021-08-01 Thread Mike Gilbert
On Sat, Jul 31, 2021 at 7:56 PM Sam James  wrote:
>
> This adds two tmpfiles related QA checks:
> 1) Verify packages don't install tmpfiles to /etc/tmpfiles.d, which
> is a deprecated location;

sys-apps/systemd calls keepdir /etc/tmpfiles.d so that users don't get
confused by a missing directory.

How would you suggest I avoid this QA warning?

> 2) Check whether packages inherit tmpfiles.eclass if they're
> installing files to /usr/lib/tmpfiles.d.
>
> (This helps to catch packages not calling tmpfiles_process
> in pkg_postinst).

sys-apps/systemd installs many files in /usr/lib/tmpfiles.d, but
calling tmpfiles_process would probably not make much sense.

How would you suggest I avoid this QA warning?



Re: [gentoo-dev] [PATCH] xdg.eclass: add EAPI 8 support

2021-07-15 Thread Mike Gilbert
On Thu, Jul 15, 2021 at 9:29 AM Ionen Wolkens  wrote:
>
> On Thu, Jul 15, 2021 at 03:23:04PM +0200, Ulrich Mueller wrote:
> > > On Thu, 15 Jul 2021, Ionen Wolkens wrote:
> >
> > > Old DEPEND should be kept as-is not to risk breaking packages with odd
> > > checks that need it present at build time. I'd rather no RDEPEND switch
> > > either as it'll just complicate things with revbumps and tools don't
> > > really need to be in RDEPEND given the above.
> >
> > Well, if the challenge was to pick the _worst_ match out of
> > {,B,R,I}DEPEND then DEPEND would be the correct answer. :)
>
> Well, if really must improve it, I think BDEPEND is the better choice.
>
> Some packages use desktop-file-validate for their tests and the like.

If ebuilds are using these programs directly (like for testing), they
should really declare the dependency explicitly instead of relying on
an implicit dependency in xdg.eclass. The eclass deps should be
limited to functionality utilized by its exported phase functions.

However, I realize older ebuilds were not written with that reasoning
in mind, so I understand the "don't mess with older EAPIs" request
from leio.

Regarding BDEPEND/RDEPEND/IDEPEND, here's what we did with fcaps.eclass:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=789ec15b80a0ad2902d59be5bdb7c5fa6fcd0092

Quoting the commit message:

This defines the native install-time libcap dependency as:

  - EAPI < 7: RDEPEND
Only regular ROOT=/ builds can be expected to work.

  - EAPI = 7: RDEPEND + BDEPEND
Also install the native setcap at built time, so cross-
compiling will work, but not installing binpkgs in ROOTs.

  - EAPI > 7: IDEPEND
Install native setcap at install-time; it works everywhere.



Re: [gentoo-dev] Lua eclasses: support EAPI 8

2021-06-29 Thread Mike Gilbert
On Tue, Jun 29, 2021 at 2:55 PM William Hubbs  wrote:
>
> On Wed, Jun 16, 2021 at 10:34:18AM +0100, Marek Szuba wrote:
> > Nothing special here. RESTRICT manipulation in lua-utils still uses +=
> > on purpose, for consistency with how other variables are handled there
> > as well as in order to avoid wasting CPU cycles on an EAPI version
> > check for something that ultimately achieves the same.
>
> I was on vacation for a number of days so didn't have a chance to check
> on this.
>
> Is portage stable already supporting eapi 8? if so when did that happen?
> If not we can't support it in eclasses yet.

That's not true at all. You can't stabilize ebuilds with EAPI=8, but
there is no reason to hold off on merging eclass changes.



Re: [gentoo-dev] 'pax_kernel' USE flag

2021-06-22 Thread Mike Gilbert
On Tue, Jun 22, 2021 at 12:06 PM Ulrich Mueller  wrote:
>
> > On Tue, 22 Jun 2021, Marek Szuba wrote:
>
> > Seeing as in the end this USE flag is not going anywhere in spite of
> > Gentoo no longer providing PaX-capable kernel sources, could we please
> > rename it (e.g. to 'pax-kernel') so that it no longer contains a
> > disallowed character. I understand the main reason this hasn't been
> > done yet is that we expected it might disappear altogether.
>
> +1 for renaming to pax-kernel.
>
> A related question, the pax_kernel flag is still used by these packages:
>
>app-emulation/virtualbox
>app-emulation/virtualbox-modules
>dev-java/icedtea
>dev-lang/mlton
>dev-lang/mono
>dev-lang/smlnj
>dev-libs/libffi
>dev-libs/libffi-compat
>media-sound/spotify
>net-libs/nodejs
>
> From my past experience with PaX support in Emacs, things used to break
> on a regular basis [1]. So I wonder, how is the status of PaX support in
> the packages listed above? Do their maintainers actually test them with
> a PaX kernel (which would be a third-party kernel, I suppose)? If not,
> maybe the flag should be removed from these untested packages?

ebuild maintainers are rarely responsible for the PaX-related
workarounds that end up in ebuilds. A better question would be if
*anybody* is using these packages with a PaX-enabled kernel, and
that's more difficult to answer.



[gentoo-dev] Last rites: sys-apps/rescan-scsi-bus

2021-06-18 Thread Mike Gilbert
# Mike Gilbert  (2021-06-17)
# rescan-scsi-bus.sh is installed by >=sys-apps/sg3_utils-1.44, rendering
# this package redundant.
# Removal on 2021-07-17.
sys-apps/rescan-scsi-bus



Re: [gentoo-portage-dev] KeyError: 'ED' ?

2021-06-09 Thread Mike Gilbert
On Thu, May 6, 2021 at 6:54 AM Joakim Tjernlund
 wrote:
>
> On Wed, 2021-05-05 at 16:47 +, Joakim Tjernlund wrote:
> > I am upgrading an old portage(2.3.76) to 3.0.18 using qmerge(binary pkg) 
> > and I get this:
> >  qmerge -OK sys-apps/portage
> > [R] sys-apps/portage-3.0.18
> >  * Checking for suitable kernel configuration options...
> >  [ ok ]
> >  * Using python3.8 in global scope
> > FEATURES variable contains unknown value(s): disabled
> > Traceback (most recent call last):
> >   File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main
> > return _run_code(code, main_globals, None,
> >   File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
> > exec(code, run_globals)
> >   File 
> > "/var/tmp/qmerge/sys-apps/portage-3.0.18/image/usr/lib/python3.8/site-packages/portage/_compat_upgrade/default_locations.py",
> >  line 93, in 
> > main()
> >   File 
> > "/var/tmp/qmerge/sys-apps/portage-3.0.18/image/usr/lib/python3.8/site-packages/portage/_compat_upgrade/default_locations.py",
> >  line 63, in main
> > config_path = os.path.join(os.environ['ED'], 
> > GLOBAL_CONFIG_PATH.lstrip(os.sep), 'make.globals')
> >   File "/usr/lib/python3.8/os.py", line 675, in __getitem__
> > raise KeyError(key) from None
> > KeyError: 'ED'
> >
> > so portage fails to install properly, I am guessin this is becuse I have an 
> > old portage to begin with?
> > Can it be fixed?
>
> The error goes away when I do: ED=/ qmerge -OK sys-apps/portage
> Does that mean that it is qmerge(aka portage-utils) that needs to set ED 
> during merge? which PHASES ?

According to PMS, a package manager must define ED in src_install,
pkg_preinst, and pkg_postinst.



[gentoo-dev] Package up for grabs: sys-boot/lilo

2021-06-01 Thread Mike Gilbert
The base system project is dropping LILO: it really needs to be
maintained by someone who actually uses it.



[gentoo-dev] Maintainer needed on a few packages

2021-04-05 Thread Mike Gilbert
I recently dropped base-system as a maintainer on the following
packages. Feel free to pick them up.

dev-util/makepp
sys-apps/ucspi-proxy
sys-devel/dev86
sys-devel/bin86



Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-21 Thread Mike Gilbert
On Sun, Mar 21, 2021 at 11:06 PM Thomas Deutschmann  wrote:
>
> On 2021-03-22 03:06, Mike Gilbert wrote:
> > Based on that commit message, it looks systemd switched to looking at
> > the symlink target instead of /etc/timezone well *after* some major
> > distro started using a symlink for /etc/localtime. I suspect Kay
> > Sievers noticed that the content of /etc/timezone and /etc/localtime
> > were redundant on his development machine, and added a TODO entry to
> > eliminate the redundant /etc/timezone file.
> >
> > In other words, this isn't a case of systemd forcing distros to
> > symlink /etc/localtime; they were already doing that anyway.
>
> I just downloaded and tested some old distributions:
>
> Debian 9 was the first Debian release with systemd. Because of systemd,
> /etc/localtime became a symlink. In Debian 8 or when you install Debian
> 9 without systemd, it is a regular file.
>
> Ubuntu 12.04.5 is the same: No systemd, /etc/localtime is a regular
> file. Once they moved to systemd it became a symlink.
>
> In Fedora 17, which is already using systemd but a version before linked
> commit, /etc/localtime is also a regular file. But once Fedora upgraded
> to >=systemd-190 it became a symlink.

Thanks for looking into it. I wonder how Kay's system ended up that
way then. Just a curiosity.

> That's why from my P.O.V. this is clearly caused by systemd. But does
> this matter?

You're the one who brought it up; I'm not sure what the point of that
was, other than to complain about systemd.



Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-21 Thread Mike Gilbert
On Sat, Mar 20, 2021 at 11:37 AM Andreas K. Huettel
 wrote:
>
> Hi all,
>
> why do we *copy* the timezone file to /etc/localtime, instead of symlinking 
> it like everyone else?
>
> 1) Our handbook recommends:
>
> echo "Europe/Brussels" > /etc/timezone
> emerge --config sys-libs/timezone-data
>
> which is effectively doing
>
> echo "Europe/Brussels" > /etc/timezone
> cp -f /usr/share/zoneinfo/Europe/Brussels /etc/localtime
>
> 2) Most other distros seem to just do
>
> ln -sf /usr/share/zoneinfo/Europe/Brussels /etc/localtime
>
> and use the link content as timezone name (this is also what is required by 
> systemd).
>
> Does anyone remember the reason for 1) ? Or is that lost in history?

I think the most obvious reason would be to support late-mounting of
/usr, after the system clock has been reset with a UTC offset on boot.
To make this work, the /etc/localtime file would need to be available
when the hwclock init script runs.

These days, I suspect there are not many users running systems with a
hardware clock in local time, and a separate /usr filesystem, and no
initramfs to mount /usr early.

I created a PR to adjust the logic in timezone-data to promote
symlinks for new installs, while keeping regular files in place for
existing users.

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

If we added some logic to detect if /usr is a separate filesystem, we
could possibly be even more aggressive about this. But I'm not sure I
want to rock the boat that much in one commit.



Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-21 Thread Mike Gilbert
On Sun, Mar 21, 2021 at 7:58 PM Thomas Deutschmann  wrote:
>
> On 2021-03-20 16:37, Andreas K. Huettel wrote:
> > 2) Most other distros seem to just do
>
> No, not most distros are doing that. systemd is forcing that downstream
> (the result is the same)!
>
> It was added via
> https://github.com/systemd/systemd/commit/92c4ef2d357baeef78b6f82f119b92f7ed12ac77
> without mentioning a reason.

Based on that commit message, it looks systemd switched to looking at
the symlink target instead of /etc/timezone well *after* some major
distro started using a symlink for /etc/localtime. I suspect Kay
Sievers noticed that the content of /etc/timezone and /etc/localtime
were redundant on his development machine, and added a TODO entry to
eliminate the redundant /etc/timezone file.

In other words, this isn't a case of systemd forcing distros to
symlink /etc/localtime; they were already doing that anyway.



[gentoo-dev] [PATCH] tmpfiles.eclass: introduce TMPFILES_OPTIONAL variable

2021-03-08 Thread Mike Gilbert
This allows the automatic dependency on virtual/tmpfiles to be disabled.

Bug: https://bugs.gentoo.org/774855
Signed-off-by: Mike Gilbert 
---
 eclass/tmpfiles.eclass | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/eclass/tmpfiles.eclass b/eclass/tmpfiles.eclass
index 360c5e3b816f..632343821648 100644
--- a/eclass/tmpfiles.eclass
+++ b/eclass/tmpfiles.eclass
@@ -60,7 +60,15 @@ case "${EAPI}" in
 *) die "API is undefined for EAPI ${EAPI}" ;;
 esac
 
-RDEPEND="virtual/tmpfiles"
+# @ECLASS-VARIABLE: TMPFILES_OPTIONAL
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# When not empty, disables the dependency on virtual/tmpfiles.
+# Ebuilds that call tmpfiles_process conditionally should declare a
+# conditional dependency themselves.
+if [[ -z ${TMPFILES_OPTIONAL} ]]; then
+   RDEPEND="virtual/tmpfiles"
+fi
 
 # @FUNCTION: dotmpfiles
 # @USAGE:  ...
-- 
2.31.0.rc1




Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390

2021-02-10 Thread Mike Gilbert
On Wed, Feb 10, 2021 at 4:57 PM Peter Stuge  wrote:
> > The first big blocker we're going to hit is trustme [3] package that
> > relies on cryptography API pretty heavily to generate TLS certs for
> > testing.
>
> For which testing? Could it be changed to generate certs differently?

He is probably referring to the test suite in dev-python/urllib3,
which uses the python "trustme" package in several places.

https://github.com/urllib3/urllib3/search?q=trustme

Someone would need to convince the urllib3 developers to use something
else to manage certificates in their unit tests.



Re: [gentoo-dev] A script to pick next free UID/GID for your acct-* packages

2021-02-09 Thread Mike Gilbert
On Tue, Feb 9, 2021 at 2:23 PM Ulrich Mueller  wrote:
>
> >>>>> On Tue, 09 Feb 2021, Mike Gilbert wrote:
>
> >> Mh - so the obvious first feature request for the script is to also
> >> output Free UID+GID pairs. Counting them manually in your screenshot
> >> I get 36.
> >>
> >> That's not a whole lot; just 7% of 500.
>
> > The output was abbreviated. Here is the full output for entries where
> > both ids are FREE.
>
> Still, it's not an infinite resource, and maybe we shouldn't waste a
> pair if only one of UID or GID is needed?

It's possible that a package might require both a UID and a GID at
some point in the future.

If we actually start running out of low-numbered ids, we could start
mixing them at that point; having them match is really just a cosmetic
thing.

Or we could always just expand the permissible range.



Re: [gentoo-dev] A script to pick next free UID/GID for your acct-* packages

2021-02-09 Thread Mike Gilbert
On Tue, Feb 9, 2021 at 12:51 PM Peter Stuge  wrote:
>
> Joonas Niilola wrote:
> > There's a script by jkroon in data/api.git
> > (https://gitweb.gentoo.org/data/api.git/) that prints the next available
> > UID/GID pair for new acct-* packages.
>
> This is super nice! Thanks a lot jkroon!
>
>
> > It is not forbidden to mix and mash UID/GID between different packages,
> > but I'd still suggest to find a new "pair" even if you push just an UID
> > or GID. Since we don't seem to be in danger of running out any time soon.
>
> Mh - so the obvious first feature request for the script is to also output
> Free UID+GID pairs. Counting them manually in your screenshot I get 36.
>
> That's not a whole lot; just 7% of 500.

The output was abbreviated. Here is the full output for entries where
both ids are FREE.

% bin/used_free_uidgids.sh | grep "FREE  FREE"
23..24   FREE  FREE
29..30   FREE  FREE
34   FREE  FREE
37..39   FREE  FREE
41..42   FREE  FREE
44   FREE  FREE
49..52   FREE  FREE
54..58   FREE  FREE
67   FREE  FREE
71..73   FREE  FREE
83   FREE  FREE
86..87   FREE  FREE
90   FREE  FREE
92..94   FREE  FREE
96   FREE  FREE
98   FREE  FREE
104..105 FREE  FREE
107..110 FREE  FREE
112  FREE  FREE
116  FREE  FREE
118..121 FREE  FREE
125..132 FREE  FREE
134..138 FREE  FREE
140..149 FREE  FREE
151..152 FREE  FREE
154..155 FREE  FREE
159..166 FREE  FREE
168  FREE  FREE
170  FREE  FREE
173..176 FREE  FREE
179..182 FREE  FREE
185  FREE  FREE
187  FREE  FREE
189  FREE  FREE
210..211 FREE  FREE
213..218 FREE  FREE
224..229 FREE  FREE
231  FREE  FREE
233..234 FREE  FREE
238  FREE  FREE
244  FREE  FREE
246..249 FREE  FREE
251  FREE  FREE
253..264 FREE  FREE
266  FREE  FREE
279..289 FREE  FREE
293..298 FREE  FREE
311..314 FREE  FREE
317..320 FREE  FREE
322..326 FREE  FREE



Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390

2021-02-08 Thread Mike Gilbert
On Mon, Feb 8, 2021 at 1:35 PM Brian Evans  wrote:
>
> On 2/8/2021 12:53 PM, Brian Evans wrote:
> > On 2/8/2021 6:19 AM, Michał Górny wrote:
> >> Hi,
> >>
> >> FYI the developers of dev-python/cryptography decided that Rust is going
> >> to be mandatory for 1.5+ versions.  It's unlikely that they're going to
> >> provide LTS support or security fixes for the old versions.
> >>
> >> Since cryptography is a very important package in the Python ecosystem,
> >> and it is an indirect dependency of Portage, this means that we will
> >> probably have to entirely drop support for architectures that are not
> >> supported by Rust.
> >>
> >
> > For the portage indirect dependency, can it be swapped for pycurl?
> >
> > AFAICT, it is just used to pull GPG sigs in gemato via dev-python/requests.
> >
> > This at least would at least keep the arches in question with some
> > support but not necessarily all of python world until a clearer plan can
> > be made.
> >
> > Brian
> >
>
> After discussion in #gentoo-dev and simple chroot testing, it seems like
> dev-python/requests nor dev-python/urlllib3 needs
> dev-python/cryptography at all (when run with stable Python, tested with
> 3.8).   So unless there's a really good reason outside of gemato sync,
> this looks to be a non-issue for portage and more of a dependency fix.

I created a PR to drop this and related deps from dev-python/urllib3
and dev-python/requests. Please review.

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



Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: new function tc-ld-force-bfd()

2021-01-20 Thread Mike Gilbert
On Wed, Jan 20, 2021 at 9:41 PM Manoj Gupta  wrote:
>
>
>
> On Wed, Jan 20, 2021 at 1:01 PM Theo Anderson  wrote:
>>
>> Hello, please see the below patch to support disabling ld.lld like
>> ld.gold. This has not been split into a separate function
>> such as tc-ld-disable-lld(), as I do not believe there is a use case
>> where ld.gold is supported and ld.lld is not.
>>
>> Thanks.
>>
>> Pull-request: https://github.com/gentoo/gentoo/pull/19116
>>
>
> I am not a Gentoo maintainer but this forces bfd linker for the ebuilds when 
> gold is not even used e.g. lld is default linker. I am curious how many 
> places where gold is disabled do not work with lld.
> In my experience, LLD is far more compatible with bfd than gold e.g. it can 
> link Linux kernels. So, imo we should not disable lld as a side effect when 
> the compatibility problem is with gold only.
> i.e. It is ok to add a function to force bfd but disabling gold needs to have 
> a check if gold is the current linker.
>
> My preference us to add 2 functions:
> tc-ld-force-bfd
> tc-ld-disable-lld
>
> And tc-ld-disable-gold should check if gold is the current linker. If not, 
> only then force bfd.
>
> What do the maintainers think?

Please see bug 729510 for an example where gold and lld do not work,
but bfd does. That bug precipitated this change in the first place.

I don't think there are any cases where we want to disable lld without
disabling gold. Maybe it would suffice to un-deprecate
tc-ld-disable-gold and only have it call tc-ld-force-bfd if the
default linker is gold. I don't think a separate tc-ld-disable-lld
function is necessary at this time, and it could be easily added
later.



Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-08 Thread Mike Gilbert
On Fri, Jan 8, 2021 at 1:31 PM Michał Górny  wrote:
> Again, I don't understand why you continue escalating this.  I have
> already indicated that I'm fine with adding an option to disable this,
> given that 1) the current behavior remains the default, and 2) people
> are given big fat warning that they are now responsible for updating
> their users (and ideally 3) the eclass tells user how to update
> the user).  I've just asked for the option to override values via
> make.conf goes first since that is the preferred solution that doesn't
> destroy the foundations of GLEP 81.
>
> floppym has indicated an interest in this, so I've presumed he's going
> to submit an updated patch to the ml.

Sorry, I didn't mean to give that impression. I do not have any plans
to submit patches myself. I asked if you would accept a similar patch
to clarify your position for others (including Whissi) who may want to
contribute.



Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-08 Thread Mike Gilbert
On Fri, Jan 8, 2021 at 11:29 AM Thomas Deutschmann  wrote:
> This is a technical mailing list. Currently, acct-* stuff is breaking
> stuff. Nobody has challenged this yet.
>
> Now I proposed a way how to unbreak stuff.
>
> Please tell me why we should keep broken stuff for non-technical reason
> and cause harm for those who are affected?

I disagree with your premise: I argue that the eclass is not "broken",
and the code works as designed. You just don't like aspects of its
design.

If you want to change the design, you need buy-in from the maintainer,
or you need to override him.



Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-08 Thread Mike Gilbert
On Fri, Jan 8, 2021 at 11:29 AM Thomas Deutschmann  wrote:
>
> On 2021-01-08 17:03, Mike Gilbert wrote:
> > I strongly object to you pushing this patch as-is. There have been
> > plenty of non-technical objections, including from the eclass
> > maintainer.
>
> The eclass maintainer has disqualified himself going into a technical
> debate with saying
>
> > So, over my dead commit access.
>
> in his first posting.
>
> This is a technical mailing list. Currently, acct-* stuff is breaking
> stuff. Nobody has challenged this yet.
>
> Now I proposed a way how to unbreak stuff.
>
> Please tell me why we should keep broken stuff for non-technical reason
> and cause harm for those who are affected?
>
> It's not like we cannot address the other stuff later. It's about
> getting the fix down to users who are currently affected by this. So why
> take hostage when some user(s) ignore the problem for more than a year
> and show that they are not interested in collaboration to find a
> solution for a technical problem they created despite warnings before
> this went live?
>
> Of course, if you are not affected by this problem it is very easy to
> relax and sit back. You have all the time in the world... but when you
> are affected by this at large scale it is not that funny anymore.

Let me put it this way: if you push this without agreement from the
maintainer, QA, or council, you can probably expect a swift revert.



Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-08 Thread Mike Gilbert
On Fri, Jan 8, 2021 at 10:48 AM Thomas Deutschmann  wrote:
>
> Hi,
>
> since nobody posted any technical objections, I am going to push the
> proposed patch on Saturday to address the current issue and allow any
> professional Gentoo user relying on usermod/configuration management
> tool to move on.

I strongly object to you pushing this patch as-is. There have been
plenty of non-technical objections, including from the eclass
maintainer.



Re: [gentoo-dev] [PATCH] systemd.eclass: remove SYSROOT from pkg-config output

2021-01-06 Thread Mike Gilbert
On Wed, Jan 6, 2021 at 5:47 PM James Le Cuirot  wrote:
>
> On Mon, 4 Jan 2021 19:28:37 -0500
> Mike Gilbert  wrote:
>
> > On Mon, Jan 4, 2021 at 6:45 PM Mike Gilbert  wrote:
> > >
> > > On Mon, Jan 4, 2021 at 6:18 PM James Le Cuirot  wrote:
> > > > $ PKG_CONFIG_SYSROOT_DIR=/foo pkg-config --variable=udevdir udev
> > > > /lib/udev
> > > >
> > > > The udevdir variable is not affected by PKG_CONFIG_SYSROOT_DIR at all.
> > > > And why would it be? The man page says that this variable is only
> > > > applied to -I and -L flags. I don't know for sure but I suspect that
> > > > pkg-config just sees this as some arbitrary variable with no special
> > > > path handling at all. I wonder what led you to think that this fix was
> > > > necessary?
> > >
> > > Interesting!
> > >
> > > pkg-config behaves differently on my system:
> > >
> > > % PKG_CONFIG_SYSROOT_DIR=/foo pkg-config --variable=udevdir udev
> > > /foo/lib/udev
> > >
> > > This appears to be a difference in behavior between dev-util/pkgconfig
> > > and dev-util/pkgconf. I am using pkgconf, and I would guess you are
> > > using pkgconfig.
> > >
> > > I guess I will ask pkgconf upstream for help on this; it seems like
> > > this is probably an unintended behavior.
> >
> > It seems that the pkgconf behavior is intentional.
> >
> > https://github.com/pkgconf/pkgconf/issues/69
> >
> > I opened an issue to see if we can get some kind of opt-out.
> >
> > https://github.com/pkgconf/pkgconf/issues/205
>
> Hmmm. At this point, I'm thinking maybe we should just address this in
> cross-pkg-config. It seems unfair to ask upstream to accommodate this
> when the tool is just doing what we asked it to. Perhaps it could
> respect PKG_CONFIG_SYSROOT_DIR if it is already set, even when empty.
> It wouldn't allow to you set this differently for the build host but
> you shouldn't ever have to. I think I'd prefer this over adding yet
> another confusing variable. The same could be applied to
> PKG_CONFIG_LIBDIR and PKG_CONFIG_SYSTEM_LIBRARY_PATH for consistency.
> What do you think?

I like the idea of having cross-pkg-config respect
PKG_CONFIG_SYSROOT_DIR from the calling environment (even if it is
empty). That's just a more flexible design overall.

However, I think there's a fundamental design conflict here. Prefixing
all pkgconfig variables that happen to start with a slash is
problematic, and the desired result depends on the context in which it
will be used.

If the result is going to be used to find some existing file in
SYSROOT (like the SDK example included in issue 69 from above), then
we want it to be prefixed with SYSROOT.

If the result is going to be used to install new files, we don't want
SYSROOT in the result. The package manager is responsible for
prefixing the paths with ROOT when merging the files.

We could apply workarounds in ebuilds/eclasses to make this
distinction in Gentoo by setting PKG_CONFIG_SYSROOT_DIR selectively.
However, I wonder if there is a workable solution to this that could
be applied in upstream projects.



Re: [gentoo-dev] [PATCH] systemd.eclass: remove SYSROOT from pkg-config output

2021-01-04 Thread Mike Gilbert
On Mon, Jan 4, 2021 at 6:45 PM Mike Gilbert  wrote:
>
> On Mon, Jan 4, 2021 at 6:18 PM James Le Cuirot  wrote:
> > $ PKG_CONFIG_SYSROOT_DIR=/foo pkg-config --variable=udevdir udev
> > /lib/udev
> >
> > The udevdir variable is not affected by PKG_CONFIG_SYSROOT_DIR at all.
> > And why would it be? The man page says that this variable is only
> > applied to -I and -L flags. I don't know for sure but I suspect that
> > pkg-config just sees this as some arbitrary variable with no special
> > path handling at all. I wonder what led you to think that this fix was
> > necessary?
>
> Interesting!
>
> pkg-config behaves differently on my system:
>
> % PKG_CONFIG_SYSROOT_DIR=/foo pkg-config --variable=udevdir udev
> /foo/lib/udev
>
> This appears to be a difference in behavior between dev-util/pkgconfig
> and dev-util/pkgconf. I am using pkgconf, and I would guess you are
> using pkgconfig.
>
> I guess I will ask pkgconf upstream for help on this; it seems like
> this is probably an unintended behavior.

It seems that the pkgconf behavior is intentional.

https://github.com/pkgconf/pkgconf/issues/69

I opened an issue to see if we can get some kind of opt-out.

https://github.com/pkgconf/pkgconf/issues/205



Re: [gentoo-dev] [PATCH] systemd.eclass: remove SYSROOT from pkg-config output

2021-01-04 Thread Mike Gilbert
On Mon, Jan 4, 2021 at 6:18 PM James Le Cuirot  wrote:
> $ PKG_CONFIG_SYSROOT_DIR=/foo pkg-config --variable=udevdir udev
> /lib/udev
>
> The udevdir variable is not affected by PKG_CONFIG_SYSROOT_DIR at all.
> And why would it be? The man page says that this variable is only
> applied to -I and -L flags. I don't know for sure but I suspect that
> pkg-config just sees this as some arbitrary variable with no special
> path handling at all. I wonder what led you to think that this fix was
> necessary?

Interesting!

pkg-config behaves differently on my system:

% PKG_CONFIG_SYSROOT_DIR=/foo pkg-config --variable=udevdir udev
/foo/lib/udev

This appears to be a difference in behavior between dev-util/pkgconfig
and dev-util/pkgconf. I am using pkgconf, and I would guess you are
using pkgconfig.

I guess I will ask pkgconf upstream for help on this; it seems like
this is probably an unintended behavior.

> One last question. Why is this dynamic at all? Shouldn't it just be
> hardcoded to /lib/udev? Sure, a user could patch udev to make it
> something different if they really wanted but there are plenty of other
> paths we just assume. What makes this one special?

sys-apps/systemd has a USE flag called "split-usr". This is meant to
allow users to perform a /usr merge if desired. When split-usr is
disabled, udevdir becomes /usr/lib/udev instead of /lib/udev.



Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-04 Thread Mike Gilbert
On Mon, Jan 4, 2021 at 11:50 AM Thomas Deutschmann  wrote:
>
> On 2021-01-04 17:38, Michał Górny wrote:
> > You've actually added 'portage' to group 'thomas'.
>
> Yes, I know that.
>
> Well, I understand why this might be confusing for you. Like I was using
> portage as example for the described example when you give another
> service access to a socket like shown in my memcached/redis example.

That's a really weird example, but if that was your intent please
disregard my last message.



Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-04 Thread Mike Gilbert
On Mon, Jan 4, 2021 at 11:34 AM Thomas Deutschmann  wrote:
>
> On 2021-01-04 17:30, Thomas Deutschmann wrote:
> > On 2021-01-04 17:28, Michał Górny wrote:
> >> It must be a bug in your version of the eclass.  I've just reemerged
> >> acct-group/wheel and to*my great surprise*  I'm still there.  How
> >> unexpected!
> >
> > That's why I wrote
> >
> >  >  (luckily groups like wheel don't have users...)
> >
> > I meant that there is no acct-user/wheel because otherwise this group
> > would get cleaned (reset), too.
>
> Best example is portage. Follow handbook. Add your user to portage's group:
>
>  > usermod -aG  portage

I don't see any mention of usermod in the handbook, so I'm not sure
where this came from.

As mgorny pointed out, you are invoking usermod incorrectly. You want
this instead:

usermod -aG portage 

Don't use "id" to list group members. That lists groups of which a
user is a member. Use getent instead:

getent group portage



Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-04 Thread Mike Gilbert
On Mon, Jan 4, 2021 at 4:23 AM Michał Górny  wrote:
>
> On Mon, 2021-01-04 at 02:35 +0100, Thomas Deutschmann wrote:
> > Modifying an existing user is a bad default and makes Gentoo
> > special because it is common for system administrators to make
> > modifications to user (i.e. putting an user into another service's
> > group to allow that user to access service in question) and it
> > would be unexpected to see these changes reverted during normal
> > world upgrade (which could break services).
>
> Not modifying an existing user is a horrible default that has already
> bricked one system (by removing /dev/null).  So, over my dead commit
> access.

As the eclass maintainer, would you be willing to merge a similar
patch that enables user modifications by default, but provides
sysadmins a way to disable it?

I have a feeling that there will not be a consensus on the default
behavior, and I could see that getting escalated to council. However,
it might be nice to provide people with the option in the meantime.



Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-03 Thread Mike Gilbert
On Sun, Jan 3, 2021 at 8:35 PM Thomas Deutschmann  wrote:
>
> Modifying an existing user is a bad default and makes Gentoo
> special because it is common for system administrators to make
> modifications to user (i.e. putting an user into another service's
> group to allow that user to access service in question) and it
> would be unexpected to see these changes reverted during normal
> world upgrade (which could break services).
>
> This commit will make Gentoo behave like any other Linux distribution
> by respecting any user modifications by default. However, we will retain
> the functionality to reset system user and groups and users interested
> in this feature can opt-in by setting
> ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED to a non-zero value in
> their make.conf.

So the main problem I see with doing this is that it becomes
impossible to reliably make changes to a user in later ebuild
revisions. Developers may want/need to deploy changes to user
attributes. Changing group memberships seems like the best example,
but I could foresee a want/need to change DESCRIPTION, HOME, or SHELL
as well.

Because of this, I think the new behavior should be opt-in, and people
who use it should be aware that they will need to pay attention if any
account changes are rolled out in new ebuild versions.

> diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
> index 22b0038fbff7..d60b1e53b4bb 100644
> --- a/eclass/acct-user.eclass
> +++ b/eclass/acct-user.eclass
> @@ -309,6 +321,20 @@ acct-user_pkg_pretend() {
> fi
>  }
>
> +# @FUNCTION: acct-user_pkg_setup
> +# @DESCRIPTION:
> +# Initialize internal environment variable(s).
> +acct-user_pkg_setup() {
> +   debug-print-function ${FUNCNAME} "${@}"
> +
> +   # check if user already exists
> +   ACCT_USER_ALREADY_EXISTS=
> +   if [[ -n $(egetent passwd "${ACCT_USER_NAME}") ]]; then
> +   ACCT_USER_ALREADY_EXISTS=yes
> +   fi
> +   readonly ACCT_USER_ALREADY_EXISTS
> +}

I don't think this pkg_setup function is necessary; you could do this
in pkg_preinst instead, before enewuser gets called.



[gentoo-dev] [PATCH 3/3] udev.eclass: copy sysroot/prefix logic from systemd.eclass

2021-01-03 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 eclass/udev.eclass | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/eclass/udev.eclass b/eclass/udev.eclass
index 9a65b080f171..8e256385f8ef 100644
--- a/eclass/udev.eclass
+++ b/eclass/udev.eclass
@@ -50,11 +50,25 @@ fi
 # @DESCRIPTION:
 # Get unprefixed udevdir.
 _udev_get_udevdir() {
-   local udevdir="/lib/udev"
+   local udevdir="/lib/udev" eprefix
+
+   if [[ ${EAPI:-0} == [0123456] ]]; then
+   eprefix=${EPREFIX}
+   else
+   # Derive from ESYSROOT due to weird PMS logic.
+   eprefix=${ESYSROOT#${SYSROOT}}
+   fi
+
if $(tc-getPKG_CONFIG) --exists udev; then
udevdir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)" || die
-   udevdir="${udevdir#${EPREFIX}}"
+
+   # Remove SYSROOT in case PKG_CONFIG_SYSROOT_DIR is set by 
cross-pkg-config.
+   d=${udevdir#${SYSROOT}}
+
+   # Remove any offset prefix.
+   d=${udevdir#${eprefix}}
fi
+
echo "${udevdir}"
 }
 
-- 
2.30.0




[gentoo-dev] [PATCH 2/3] systemd.eclass: rework prefix logic for EAPI 7

2021-01-03 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 eclass/systemd.eclass | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
index f6d1fa2d92d6..9f439238fe6c 100644
--- a/eclass/systemd.eclass
+++ b/eclass/systemd.eclass
@@ -46,12 +46,23 @@ fi
 # instead.
 _systemd_get_dir() {
[[ ${#} -eq 2 ]] || die "Usage: ${FUNCNAME}  
"
-   local variable=${1} fallback=${2} d
+   local variable=${1} fallback=${2} d eprefix
+
+   if [[ ${EAPI:-0} == [0123456] ]]; then
+   eprefix=${EPREFIX}
+   else
+   # Derive from ESYSROOT due to weird PMS logic.
+   eprefix=${ESYSROOT#${SYSROOT}}
+   fi
 
if $(tc-getPKG_CONFIG) --exists systemd; then
d=$($(tc-getPKG_CONFIG) --variable="${variable}" systemd) || die
+
+   # Remove SYSROOT in case PKG_CONFIG_SYSROOT_DIR is set by 
cross-pkg-config.
d=${d#${SYSROOT}}
-   d=${d#${EPREFIX}}
+
+   # Remove any offset prefix.
+   d=${d#${eprefix}}
else
d=${fallback}
fi
-- 
2.30.0




[gentoo-dev] [PATCH 1/3] udev.eclass: rework _udev_get_udevdir

2021-01-03 Thread Mike Gilbert
Rewrite logic to resemble _systemd_get_dir from systemd.eclass.

Remove incorrect command substitution: pkg-config --exists does not
write to stdout.

Die when pkg-config --variable fails.

Signed-off-by: Mike Gilbert 
---
 eclass/udev.eclass | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/eclass/udev.eclass b/eclass/udev.eclass
index 2873ae9a92c3..9a65b080f171 100644
--- a/eclass/udev.eclass
+++ b/eclass/udev.eclass
@@ -50,12 +50,12 @@ fi
 # @DESCRIPTION:
 # Get unprefixed udevdir.
 _udev_get_udevdir() {
-   if $($(tc-getPKG_CONFIG) --exists udev); then
-   local udevdir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)"
-   echo "${udevdir#${EPREFIX%/}}"
-   else
-   echo /lib/udev
+   local udevdir="/lib/udev"
+   if $(tc-getPKG_CONFIG) --exists udev; then
+   udevdir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)" || die
+   udevdir="${udevdir#${EPREFIX}}"
fi
+   echo "${udevdir}"
 }
 
 # @FUNCTION: udev_get_udevdir
-- 
2.30.0




Re: [gentoo-dev] [PATCH] systemd.eclass: remove SYSROOT from pkg-config output

2021-01-03 Thread Mike Gilbert
On Sun, Jan 3, 2021 at 7:52 AM James Le Cuirot  wrote:
>
> On Sat,  2 Jan 2021 20:09:04 -0500
> Mike Gilbert  wrote:
>
> > When cross-compiling, users will typically have
> > PKG_CONFIG_SYSROOT=${SYSROOT} defined via pkg-config wrapper.
> >
> > When PKG_CONFIG_SYSROOT is set, all paths included in pkg-config
> > output get prefixed with this value.
> >
> > Signed-off-by: Mike Gilbert 
> > ---
> >
> > This patch has already been pushed, but I figured I would send it for
> > review in case someone else can think of a failure case, or has a better
> > solution.
> >
> >  eclass/systemd.eclass | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
> > index 81065a0af79a..f6d1fa2d92d6 100644
> > --- a/eclass/systemd.eclass
> > +++ b/eclass/systemd.eclass
> > @@ -50,6 +50,7 @@ _systemd_get_dir() {
> >
> >   if $(tc-getPKG_CONFIG) --exists systemd; then
> >   d=$($(tc-getPKG_CONFIG) --variable="${variable}" systemd) || 
> > die
> > + d=${d#${SYSROOT}}
> >   d=${d#${EPREFIX}}
> >   else
> >   d=${fallback}
>
> I was going to say this is not the best approach as it would be better
> to tell pkg-config to not add the SYSROOT in the first place. I now
> realise we have shot ourselves in the foot with cross-pkg-config as it
> uses SYSROOT to set both PKG_CONFIG_SYSROOT_DIR to control the output
> and PKG_CONFIG_LIBDIR to find the .pc files in the first place. I have
> had prefix-related fixes for cross-pkg-config lined up for over a year
> but unfortunately they do not address this. Trying to accommodate this
> use case would probably just make it more confusing though so maybe
> your approach is best after all.

It would be cleaner overall if we could prevent SYSROOT from being
added to the paths in the first place.

> The EPREFIX line is (sometimes) wrong in EAPI 7 though and the same goes
> for udev.eclass. It took a while to get this agreed and corrected in
> PMS but if SYSROOT points to / then the effective prefix is BROOT, not
> EPREFIX; they may not be the same.

Ugh, that "corrected" logic in PMS head is nasty.

> If you just strip ESYSROOT then
> it will always do the right thing but you'll need this fall back for
> older EAPIs. I'm not sure why you didn't do it in one line?

I was trying to accommodate older EAPIs that do not define ESYSROOT.
This seemed like the simplest approach. It also allows for the case
where someone is not using cross-pkg-config, and
PKG_CONFIG_SYSROOT_DIR is unset. Since SYSROOT and EPREFIX are removed
separately, if one of them is already missing, it will just be
skipped.

> I forget if EPREFIX is normalised to be / rather thank blank.
>
> d=${d#${SYSROOT%/}/${EPREFIX#/}}

SYSROOT never ends with a / in modern versions of portage (regardless
of EAPI), so there's currently no need to remove a trailing slash.

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

I have never seen EPREFIX equal to "/", or end with a trailing slash.
Given it is most commonly used as "${EPREFIX}/usr", this would result
in double-slashes everywhere.



[gentoo-dev] [PATCH] udev.eclass: rework _udev_get_udevdir

2021-01-02 Thread Mike Gilbert
Rewrite logic to resemble _systemd_get_dir from systemd.eclass.

Remove incorrect command substitution: pkg-config --exists does not
write to stdout.

Die when pkg-config --variable fails.

Remove SYSROOT from pkg-config output in case the user is cross-
compiling with a pkg-config wrapper that sets PKG_CONFIG_SYSROOT_DIR.

Signed-off-by: Mike Gilbert 
---
 eclass/udev.eclass | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/eclass/udev.eclass b/eclass/udev.eclass
index 2873ae9a92c3..82af1ea7788b 100644
--- a/eclass/udev.eclass
+++ b/eclass/udev.eclass
@@ -50,12 +50,13 @@ fi
 # @DESCRIPTION:
 # Get unprefixed udevdir.
 _udev_get_udevdir() {
-   if $($(tc-getPKG_CONFIG) --exists udev); then
-   local udevdir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)"
-   echo "${udevdir#${EPREFIX%/}}"
-   else
-   echo /lib/udev
+   local udevdir="/lib/udev"
+   if $(tc-getPKG_CONFIG) --exists udev; then
+   udevdir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)" || die
+   udevdir="${udevdir#${SYSROOT}}"
+   udevdir="${udevdir#${EPREFIX}}"
fi
+   echo "${udevdir}"
 }
 
 # @FUNCTION: udev_get_udevdir
-- 
2.30.0




[gentoo-dev] [PATCH] systemd.eclass: remove SYSROOT from pkg-config output

2021-01-02 Thread Mike Gilbert
When cross-compiling, users will typically have
PKG_CONFIG_SYSROOT=${SYSROOT} defined via pkg-config wrapper.

When PKG_CONFIG_SYSROOT is set, all paths included in pkg-config
output get prefixed with this value.

Signed-off-by: Mike Gilbert 
---

This patch has already been pushed, but I figured I would send it for
review in case someone else can think of a failure case, or has a better
solution.

 eclass/systemd.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
index 81065a0af79a..f6d1fa2d92d6 100644
--- a/eclass/systemd.eclass
+++ b/eclass/systemd.eclass
@@ -50,6 +50,7 @@ _systemd_get_dir() {
 
if $(tc-getPKG_CONFIG) --exists systemd; then
d=$($(tc-getPKG_CONFIG) --variable="${variable}" systemd) || die
+   d=${d#${SYSROOT}}
d=${d#${EPREFIX}}
else
d=${fallback}
-- 
2.30.0




Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?

2020-12-30 Thread Mike Gilbert
On Wed, Dec 30, 2020 at 9:50 PM Peter Stuge  wrote:
>
> Michał Górny wrote:
> > > > I think the three main ways forward from here would be to either:
> > > >
> > > > 1. Keep LibreSSL for indefinite time (possibly masked)
> > > > 2. Eventually move LibreSSL to libressl overlay.
> > > > 3. Eventually remove LibreSSL.
> > >
> > > 4. A libressl or libressl-libtls ebuild installs only libtls.
> >
> > dev-libs/libretls already does that.
>
> dev-libs/libretls doesn't install a libressl libtls.
>
> This thread is obviously about how the libressl implementation remains
> in use.
>
> It's clear now that you want to hinder that in Gentoo at any cost to
> the community, but that's not useful, so please take a step back unless
> you are actually going to be constructive.
>
> My proposition 4. (which I suggested already earlier - you shouldn't
> have ignored it) is obviously not about having any libtls provider in
> the tree, but to model reality accurately and ensure that libretls is
> the primary and prefered libtls provider, since it is literally the
> libtls upstream.
>
> It is important to me that you can choose dev-libs/libretls instead of
> having any libretls code on your systems, but I reject you forcing that
> choice of yours on everyone else.

I'm having trouble making sense of this sentence. Did you mean to
write "libressl" instead of "libretls" somewhere?

Anyway, it seems like the people maintaining libressl in Gentoo are
really not interested in keeping it going. A libtls wrapper around
openssl seems much more manageable to me, and that should probably be
the default option for people.



  1   2   3   4   5   6   7   8   9   10   >