Re: [gentoo-dev] default php-ext status

[Michael Orlitzky]

On Mon, 2024-04-22 at 16:46 +0200, Jaco Kroon wrote:
> 
> Which in my *opinion* is not desirable behaviour, but I'm open for 
> discussion.
> 
> xdebug.mode = off by default, but the extension still gets loaded.
> 
> Not sure if there is a sensible "solution", further expanding USE flags 
> certainly is not a desirable option, so perhaps INSTALL_MASK 
> (per-package env) is the best solution ... ?

You can replace the symlinks with empty files. The package manager
should then refuse to overwrite them. It _looks_ wrong (why are these
non-active extensions in ext-active?), but it's the easiest solution.

I think the default should be for the extensions to be per-SAPI
disabled and for users to enable them by creating the symlinks. (The
"ext" and "ext-active" design screams this.) That would be an easy
change to php-ext-source-r3.eclass but risks breaking everyone's web
servers if we do it without news items and/or ewarnings.

There's nobody in the PHP project at the moment. If you want to make an
-r4 of the eclass and handle the paperwork, by all means...

Re: [gentoo-dev] Update on the 23.0 profiles

[Michael Orlitzky]

On Sun, 2024-04-07 at 15:07 +0200, Andreas K. Huettel wrote:
> > tl;dr can we turn them back off in the profile? In any scenario where
> > they are beneficial, there's a better place to put them.
> 
> Easily doable with lzma, if there is consensus for it.
> 
> Slightly more complex for zstd since this affects gcc and binutils.
> Still doable though.
> 

Thanks:

* https://bugs.gentoo.org/928932
* https://bugs.gentoo.org/928933

Re: [gentoo-dev] Update on the 23.0 profiles

[Michael Orlitzky]

On Sun, 2024-04-07 at 16:48 +0200, Michał Górny wrote:
> 
> So, what you're basically saying, is that the best Gentoo response right
> now would be to frantically remove LZMA support everywhere?  I'm sure
> that would be so much better than our response of masking vulnerable
> versions and issuing a statement.
> 

Only in the sense that people who park their cars in the bike lane are
basically Hitler. This really has nothing to do with the xz thing. The
timing was funny, that's all.

What I am saying is that I want the freedom to not have things
pointlessly enabled on my systems, because similar problems (and worse)
happen all day every day. The less exposure I have, the better. The
liblzma backdoor was timely because it will prevent most people from
telling me I'm being paranoid, but it could have been USE=anything on
any other day. Moving the defaults out of the high-level profiles will
give control back to the user, hence my complaint about it.

Re: [gentoo-dev] Update on the 23.0 profiles

[Michael Orlitzky]

On Sun, 2024-04-07 at 14:35 +0200, Andreas K. Huettel wrote:
> 
> Uhh, I dont really remember, I think some Chinese-sounding guy asked
> me for it... (j/k) 

It is remarkably bad timing. How it looks: Gentoo's response to the xz
incident is to have me rebuild my entire system with everything that
could possibly be linked to liblzma, linked to liblzma. Even on the
hardened profiles, and with no easy way to prevent it.



> Jokes aside, we did have bz2 in the default useflags for ages, and 
> at the time this made a lot of sense since xz/lzma and zstd were
> steadily becoming the most prevalent compression algorithms.

The flags that predate IUSE defaults can of course be forgiven.

What is improved by having these flags in every profile, vs only (say)
the desktop profiles, or in IUSE defaults?

Here's what is made worse: I can't undo it. To maintain the status quo
(I was quite happy to not have 100 packages pointlessly linked to
liblzma last week), what I want to do is set USE="-lzma -zstd". But if
I do that, then it overrides the IUSE defaults for the few packages
whose maintainers are doing the right thing, and setting IUSE="+lzma
+zstd" where it is important. For example, sys-apps/kmod, where the
defaults ensure that your system isn't made unbootable by accident.

The other option is for me to perpetually maintain a list of everything
that uses lzma/zstd inside my package.use. And to avoid the problem
above, I now have to read the ebuilds to see which ones have defaults
and which ones don't. This is also not a great way to spend my time.

tl;dr can we turn them back off in the profile? In any scenario where
they are beneficial, there's a better place to put them.

Re: [gentoo-dev] Update on the 23.0 profiles

[Michael Orlitzky]

On Sat, 2024-04-06 at 17:06 +0200, Andreas K. Huettel wrote:
> Hi all, 
> 
> so here's a small update on the state of the 23.0 profiles:
> 

Why was this silently added to make.defaults for all 23.0 profiles?

> # This just makes sense nowadays, if only for distfiles...  
> USE="lzma zstd"

It doesn't help with distfiles in any way, wasn't discussed here,
doesn't belong there, and creates a mess on systems where they should
be disabled. Use per-package defaults if they're important for certain
packages.

[gentoo-dev] Package up for grabs: net-dns/djbdns

[Michael Orlitzky]

We finally had to migrate to a new nameserver, so net-dns/djbdns is up
for grabs. No open bugs, but you've been warned, it's a monster.
Unmaintained for roughly 20 years, weird init, lots of big patches that
conflict with one another, bit-rotting C code, etc.

Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo

[Michael Orlitzky]

On Wed, 2024-04-03 at 16:30 +0100, Eddie Chapman wrote:
> It does involve a
> relatively small hack and functionality previously provided by xz-utils is
> replaced by app-arch/p7zip.

I did the same thing with app-arch/unzip a long time ago. You caught a
lot of shit for your post, but I don't think it was out of line.

Worst case? You spent a lot of time building a fragile solution to a
non-problem that everyone said you were crazy for wanting in the first
place. Hi, this is Gentoo, glad to have you.

Re: [gentoo-dev] arb has been merged into flint

[Michael Orlitzky]

On Thu, 2024-03-21 at 16:44 +, Andrey Grozin wrote:
> sci-mathematics/arb has been merged into sci-mathematics/flint, see
> https://github.com/flintlib/arb
> Is it time to last-rite sci-mathematics/arb?
> 

Yeah, I was waiting for flint-3.x to go stable first since arb is
stable. But until recently flint-3.x was broken by a missing pkg-config
file. It should be fixed in flint-3.1.0 added ~11 days ago.

Re: [gentoo-dev] Re: [PATCH 1/3] texlive-module.eclass: implicitly set TL_PV if not explicitly set

[Michael Orlitzky]

On Thu, 2024-02-29 at 15:21 +0100, Florian Schmaus wrote:
> > 
> > The eclass only supports EAPIs {7,8,...} so it should suffice to
> > blacklist EAPI=7.
> 
> Fair point, but that would mean to remember to adjust this line once the 
> eclass gets support for EAPI 9.
> 

It should do the right thing automatically when EAPI=9 is added, no? If
the goal of "-gt 8" is to match EAPI=8 and newer, then rejecting (only)
the one EAPI that's older than 8 should be equivalent without involving
a numerical comparison.

Re: [gentoo-dev] Re: [PATCH 1/3] texlive-module.eclass: implicitly set TL_PV if not explicitly set

[Michael Orlitzky]

On Thu, 2024-02-29 at 14:47 +0100, Florian Schmaus wrote:
> >   
> > +if [[ -z ${TL_PV} ]] \
> > +  && [[ ${EAPI} -ge 8 ]] \
> 
> I am skeptical of this construct, as in the past we had non-numeric 
> EAPIs. So I may have to go with EAPI == 8 for now. Input appreciated.
> 


The eclass only supports EAPIs {7,8,...} so it should suffice to
blacklist EAPI=7.

Re: [gentoo-dev] RFC: Setting default HOME_MODE in /etc/login.defs

[Michael Orlitzky]

On Sat, 2024-02-10 at 17:57 +0100, Daniel Simionato wrote:
> Hello,
>  I'd like to start a discussion regarding setting HOME_MODE by default in
> the /etc/login.defs file (owned by sys-apps/shadow package).
> 
> Upstream keeps HOME_MODE commented:
> https://github.com/shadow-maint/shadow/blob/3e59e9613ec40c51c19c7bb5c28468e33a4529d5/etc/login.defs#L207
> 
> HOME_MODE affects only useradd and newuser commands: if HOME_MODE is set,
> they will use the specified permission when creating a user home directory,
> otherwise the default UMASK will be used.
> Since the default umask is 022, keeping HOME_MODE unset will result in home
> readable home direct

umask 022 is also egregious, changing it to 027 would kill two birds.
But in lieu of that, yes.

Re: [gentoo-dev] special small-files USE flag without effect on dependencies: [ unicode ]

[Michael Orlitzky]

On Fri, 2024-02-09 at 16:04 -0500, Eli Schwartz wrote:
> 
> Counterpoint: some PHP program out there is probably vulnerable because
> it tried to validate an ipv6 address and could not distinguish between
> "it's okay" and "idk if it's okay, the function you called does not
> exist" (because php is really that terrible of a language).
> 
> I'm confused why you think compiling or not compiling in support for
> part of a programming language is supposed to make CVEs *less* likely to
> happen, rather than more likely?

This is the part where you try to convince me that the things I want
are stupid. OK. I don't care. I want it off. Leave me alone :)

Re: [gentoo-dev] special small-files USE flag without effect on dependencies: [ unicode ]

[Michael Orlitzky]

On Fri, 2024-02-09 at 14:09 -0500, Eli Schwartz wrote:
> 
> Asking out of genuine ignorance: what kind of direct behavioral changes
> occur as a result of setting or unsetting USE=ipv6.

One example I know off the top of my head is dev-lang/php where
USE=ipv6 isn't entirely about ipv6 connectivity (although it does do
that). It also augments some of the user-facing PHP language functions
with ipv6 support. Having them enabled is not a big deal, and PHP is a
programming language so you may say that it's atypical, but... for a
package that gets a new CVE every week and sits on the public web, I'd
just rather have it off?

Unicode support is similar in my mind. Adding "unicode support" to a
package might be easy (at the cost of some extra memory), but dealing
with the consequences of unicode is harder. Maybe I don't want to worry
about homoglyphs and bidirectional text when I'm validating a hostname?
Life is just simpler without it, if you know you don't need it. Things
also tend to be more space and memory efficient with features compiled
out; not to mention that the compile times themselves are improved.
You're still pulling in "extra dependencies," in a sense, even if
they're in the same tarball.

I really don't want to fall into a trap where I make up reasons why
other people might want to do things and everyone says my reasons are
stupid. Everyone is going to have different reasons, and we have a lot
of users who are our users because they're edge cases.

It's not unfathomably stupid to build a package without ipv6 or unicode
support (whatever that means), and there are no small files to worry
about, so I don't think they deserve the special negative treatment.

Re: [gentoo-dev] special small-files USE flag without effect on dependencies: [ unicode ]

[Michael Orlitzky]

On Fri, 2024-02-09 at 11:57 -0500, Mike Gilbert wrote:
> 
> Based on this pkgcheck issue, this originates from a decision from by
> Gentoo QA team.
> 
> https://github.com/pkgcore/pkgcheck/issues/414#issuecomment-1213057268
> 

Thanks for the dig. I agree with the reasoning for things like
USE=bash-completion and USE=vim-syntax, where the added complexity of a
flag is not justified to avoid installing small files. In those cases,
the additional files simply don't do anything if you don't (for
example) use vim.

USE=unicode and USE=ipv6 are different beasts. In many cases they
directly and immediately change the behavior of the package. I think
that there are good reasons to want those two disabled, but the user's
reasoning shouldn't really matter. The only "problem" in this case is
the pkgcheck warning. Upstream supports it, the maintainer supports it,
it works, users might want it, and it's one of our selling points.
Given all of that, I'm leery of treating it like some kind of mistake.

Re: [gentoo-dev] special small-files USE flag without effect on dependencies: [ unicode ]

[Michael Orlitzky]

On Fri, 2024-02-09 at 10:54 -0500, Ionen Wolkens wrote:
> 
> Is there even any reason to ever disable unicode support? Point is that
> why have USE for it? Or does it introduce additional dependencies?

Being able to disable things like this is one of the few reasons why
people choose Gentoo.

Re: [gentoo-dev] [PATCH 1/2] profiles/thirdpartymirrors: add 'ctan' mirror

[Michael Orlitzky]

On Tue, 2024-01-16 at 10:26 +0100, Florian Schmaus wrote:
> +ctan https://mirrors.ctan.org/ https://ftp.fau.de/ctan/ 
> https://mirror.physik.tu-berlin.de/pub/CTAN/ https://ftp.sun.ac.za/ftp/CTAN/ 
> https://mirror.math.princeton.edu/pub/CTAN/ 
> https://mirrors.sjtug.sjtu.edu.cn/ctan/ https://mirrors.mit.edu/CTAN/ 
> https://tug.ctan.org/

Are any of these packages mirror-restricted? If you visit ctan in a
browser, the download links it presents are via mirrors.ctan.org. I
think that would be considered the "primary download location" in
satisfaction of

https://devmanual.gentoo.org/ebuild-writing/variables/index.html#third-party-mirrors

We already mirror everything onto Gentoo infrastructure (unless it's
mirror-restricted!), so I think it would be simpler to avoid the
indirection here and simply use mirrors.ctan.org.

Anyway, thanks you for this usually thankless work on TeX.

[gentoo-dev] New eclass: gap-pkg

[Michael Orlitzky]

A new eclass for the GAP system and its packages,

  * https://www.gap-system.org/
  * https://www.gap-system.org/Packages/packages.html
  * https://bugs.gentoo.org/49282

A pull request is open with a category full of examples:

  * https://github.com/gentoo/gentoo/pull/34472

Comments, suggestions, and complaints are appreciated.

--

# Copyright 2024 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

# @ECLASS: gap-pkg.eclass
# @MAINTAINER:
# François Bissey 
# Michael Orlitzky 
# Gentoo Mathematics Project 
# @AUTHOR:
# François Bissey 
# Michael Orlitzky 
# @SUPPORTED_EAPIS: 8
# @BLURB: Simplify the installation of GAP packages.
# @DESCRIPTION:
# The main purpose of this eclass is to build and install GAP packages
# that typically occupy the dev-gap category. Most GAP packages do not
# support an install target out of the box, so the default installation
# is "by hand," with attention paid to those directories that are part
# of the recommended layout. The prepare, configure, and compile phases
# do however try to support packages having a real build system.
#
# GAP itself has four "required" packages that are packaged separately,
# making dependencies between them somewhat weird. The four required
# packages are,
#
#   * dev-gap/gapdoc
#   * dev-gap/primgrp
#   * dev-gap/smallgrp
#   * dev-gap/transgrp
#
# Those four packages will have only sci-mathematics/gap added to
# RDEPEND. All other packages will have the four required packages above
# added to RDEPEND in addition to sci-mathematics/gap. In theory it
# would be better to list all dependencies explicitly rather than
# grouping together the "required" four, but this is how upstream GAP
# works, and is what all GAP packages expect; for example, most test
# suites fail without the required packages but make no attempt to load
# them.
#
# If you need a version constraint on sci-mathematics/gap, you'll have
# to specify it yourself. Compiled packages will likely need
# sci-mathematics/gap in DEPEND as well, and may also want a subslot
# dependency.

case ${EAPI} in
8) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac

# For eshopts_push and eshopts_pop
inherit estack

# Some packages have additional homepages, but pretty much every GAP
# package can be found at this URL.
HOMEPAGE="https://www.gap-system.org/Packages/${PN}.html;

# _GAP_PKG_IS_REQUIRED is an internal variable that indicates whether or
# not $PN is one of the four "required" GAP packages that are always
# loaded, even when GAP is started with the "-A" flag. We treat this
# four somewhat differently since they are implicit dependencies of
# everything else in the GAP ecosystem.
_GAP_PKG_IS_REQUIRED=no
case ${CATEGORY}/${PN} in
 dev-gap/gapdoc|dev-gap/smallgrp|dev-gap/primgrp|dev-gap/transgrp)
_GAP_PKG_IS_REQUIRED=yes
;;
 *)
;;
esac

# _GAP_PKG_RDEPEND is an internal variable to hold the RDEPEND entries
# added by this eclass. We use a separate variable for this because we
# need its contents later in gap-pkg_enable_tests, and that function is
# called from an ebuild context where the list of RDEPEND is maintained
# separately. Basically: the values we add to RDEPEND here do not appear
# in RDEPEND when gap-pkg_enable_tests is called.
_GAP_PKG_RDEPEND="sci-mathematics/gap"

# The four "required" packages depend only on GAP itself, while every
# other package depends (also) on the four required ones.
if [[ "${_GAP_PKG_IS_REQUIRED}" = "no" ]]; then
_GAP_PKG_RDEPEND+="
dev-gap/gapdoc
dev-gap/smallgrp
dev-gap/primgrp
dev-gap/transgrp"
fi
RDEPEND="${_GAP_PKG_RDEPEND}"

# @FUNCTION: gap-pkg_dir
# @DESCRIPTION:
# The directory into which the gap package should be installed. The
# accepted current location is /usr/$(get_libdir)/gap/pkg, but
# technically this depends on the econf call in sci-mathematics/gap.
gap-pkg_dir() {
echo "/usr/$(get_libdir)/gap/pkg/${PN}"
}

# @FUNCTION: _gap-pkg_gaproot
# @INTERNAL
# @DESCRIPTION:
# The directory containing sysinfo.gap. This is frequently passed to GAP
# packages via ./configure --with-gaproot or as a positional argument to
# hand-written configure scripts. We also use it to find the value of
# $GAParch, which is contained in sysinfo.gap. The "gaproot" is
# implicitly determined by the econf call in sci-mathematics/gap. As a
# result, calling this function requires sci-mathematics/gap at
# build-time.
_gap-pkg_gaproot() {
echo "${ESYSROOT}/usr/$(get_libdir)/gap"
}

# @FUNCTION: gap-pkg_econf
# @USAGE: [extra econf args]
# @DESCRIPTION:
# Call econf, passing the value of _gap-pkg_gaproot to --with-gaproot.
# All arguments to gap-pkg_econf are passed through to econf.
#
# @EXAMPLE
# src_configu

[gentoo-dev] RFC: new dev-gap category

[Michael Orlitzky]

In https://github.com/gentoo/gentoo/pull/34472 I'd like to add 61
packages under a new dev-gap category. GAP has its own package
ecosystem,

  https://www.gap-system.org/Packages/packages.html

and a reasonably standard build/install process. Since most GAP
packages are written in its own GAP language, I think dev-gap is
appropriate.

Feel free to take an advance peek at the new eclass as well if you
don't mind doing it on Github.

[gentoo-dev] [PATCH 2/3] sys-auth/pam_smb: inline mirror://samba/ into SRC_URI

[Michael Orlitzky]

Bug: https://bugs.gentoo.org/916556
Signed-off-by: Michael Orlitzky 
---
 sys-auth/pam_smb/pam_smb-2.0.0_rc6-r3.ebuild | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sys-auth/pam_smb/pam_smb-2.0.0_rc6-r3.ebuild 
b/sys-auth/pam_smb/pam_smb-2.0.0_rc6-r3.ebuild
index e62a1829a687..2b61b73610f9 100644
--- a/sys-auth/pam_smb/pam_smb-2.0.0_rc6-r3.ebuild
+++ b/sys-auth/pam_smb/pam_smb-2.0.0_rc6-r3.ebuild
@@ -1,4 +1,4 @@
-# Copyright 1999-2021 Gentoo Authors
+# Copyright 1999-2023 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=7
@@ -10,7 +10,7 @@ MY_P=${P/_rc/-rc}
 DESCRIPTION="PAM module for authenticating against an SMB (such as the Win_x 
families) server"
 HOMEPAGE="http://www.csn.ul.ie/~airlied/pam_smb/;
 SRC_URI="
-   mirror://samba/pam_smb/v2/${MY_P}.tar.gz
+   https://download.samba.org/pub/samba/pam_smb/v2/${MY_P}.tar.gz
http://www.csn.ul.ie/~airlied/pam_smb/v2/${MY_P}.tar.gz;
 S="${WORKDIR}"/${MY_P}
 
-- 
2.41.0

[gentoo-dev] [PATCH 1/3] net-fs/samba: inline mirror://samba/ into SRC_URI

[Michael Orlitzky]

Bug: https://bugs.gentoo.org/916556
Signed-off-by: Michael Orlitzky 
---
 net-fs/samba/samba-4.18.4-r1.ebuild | 4 ++--
 net-fs/samba/samba-4.18.5-r1.ebuild | 4 ++--
 net-fs/samba/samba-4.18.6-r1.ebuild | 4 ++--
 net-fs/samba/samba-4.18.7.ebuild| 4 ++--
 net-fs/samba/samba-4.18.8.ebuild| 4 ++--
 net-fs/samba/samba-4.19.0-r1.ebuild | 4 ++--
 net-fs/samba/samba-4.19.1.ebuild| 4 ++--
 net-fs/samba/samba-4.19.2.ebuild| 4 ++--
 8 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/net-fs/samba/samba-4.18.4-r1.ebuild 
b/net-fs/samba/samba-4.18.4-r1.ebuild
index 7be674c8b658..50bd8a8ba337 100644
--- a/net-fs/samba/samba-4.18.4-r1.ebuild
+++ b/net-fs/samba/samba-4.18.4-r1.ebuild
@@ -13,9 +13,9 @@ HOMEPAGE="https://samba.org/;
 MY_PV="${PV/_rc/rc}"
 MY_P="${PN}-${MY_PV}"
 if [[ ${PV} == *_rc* ]]; then
-   SRC_URI="mirror://samba/rc/${MY_P}.tar.gz"
+   SRC_URI="https://download.samba.org/pub/samba/rc/${MY_P}.tar.gz;
 else
-   SRC_URI="mirror://samba/stable/${MY_P}.tar.gz"
+   SRC_URI="https://download.samba.org/pub/samba/stable/${MY_P}.tar.gz;
KEYWORDS="~alpha amd64 arm arm64 ~hppa ~ia64 ~loong ppc ppc64 ~riscv 
sparc x86"
 fi
 S="${WORKDIR}/${MY_P}"
diff --git a/net-fs/samba/samba-4.18.5-r1.ebuild 
b/net-fs/samba/samba-4.18.5-r1.ebuild
index cea5c8d53ad5..62e458b0c89d 100644
--- a/net-fs/samba/samba-4.18.5-r1.ebuild
+++ b/net-fs/samba/samba-4.18.5-r1.ebuild
@@ -13,9 +13,9 @@ HOMEPAGE="https://samba.org/;
 MY_PV="${PV/_rc/rc}"
 MY_P="${PN}-${MY_PV}"
 if [[ ${PV} == *_rc* ]]; then
-   SRC_URI="mirror://samba/rc/${MY_P}.tar.gz"
+   SRC_URI="https://download.samba.org/pub/samba/rc/${MY_P}.tar.gz;
 else
-   SRC_URI="mirror://samba/stable/${MY_P}.tar.gz"
+   SRC_URI="https://download.samba.org/pub/samba/stable/${MY_P}.tar.gz;
KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~loong ~ppc ~ppc64 
~riscv ~sparc ~x86"
 fi
 S="${WORKDIR}/${MY_P}"
diff --git a/net-fs/samba/samba-4.18.6-r1.ebuild 
b/net-fs/samba/samba-4.18.6-r1.ebuild
index cea5c8d53ad5..62e458b0c89d 100644
--- a/net-fs/samba/samba-4.18.6-r1.ebuild
+++ b/net-fs/samba/samba-4.18.6-r1.ebuild
@@ -13,9 +13,9 @@ HOMEPAGE="https://samba.org/;
 MY_PV="${PV/_rc/rc}"
 MY_P="${PN}-${MY_PV}"
 if [[ ${PV} == *_rc* ]]; then
-   SRC_URI="mirror://samba/rc/${MY_P}.tar.gz"
+   SRC_URI="https://download.samba.org/pub/samba/rc/${MY_P}.tar.gz;
 else
-   SRC_URI="mirror://samba/stable/${MY_P}.tar.gz"
+   SRC_URI="https://download.samba.org/pub/samba/stable/${MY_P}.tar.gz;
KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~loong ~ppc ~ppc64 
~riscv ~sparc ~x86"
 fi
 S="${WORKDIR}/${MY_P}"
diff --git a/net-fs/samba/samba-4.18.7.ebuild b/net-fs/samba/samba-4.18.7.ebuild
index cea5c8d53ad5..62e458b0c89d 100644
--- a/net-fs/samba/samba-4.18.7.ebuild
+++ b/net-fs/samba/samba-4.18.7.ebuild
@@ -13,9 +13,9 @@ HOMEPAGE="https://samba.org/;
 MY_PV="${PV/_rc/rc}"
 MY_P="${PN}-${MY_PV}"
 if [[ ${PV} == *_rc* ]]; then
-   SRC_URI="mirror://samba/rc/${MY_P}.tar.gz"
+   SRC_URI="https://download.samba.org/pub/samba/rc/${MY_P}.tar.gz;
 else
-   SRC_URI="mirror://samba/stable/${MY_P}.tar.gz"
+   SRC_URI="https://download.samba.org/pub/samba/stable/${MY_P}.tar.gz;
KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~loong ~ppc ~ppc64 
~riscv ~sparc ~x86"
 fi
 S="${WORKDIR}/${MY_P}"
diff --git a/net-fs/samba/samba-4.18.8.ebuild b/net-fs/samba/samba-4.18.8.ebuild
index c91b4ea77582..8135362ec56e 100644
--- a/net-fs/samba/samba-4.18.8.ebuild
+++ b/net-fs/samba/samba-4.18.8.ebuild
@@ -13,9 +13,9 @@ HOMEPAGE="https://samba.org/;
 MY_PV="${PV/_rc/rc}"
 MY_P="${PN}-${MY_PV}"
 if [[ ${PV} == *_rc* ]]; then
-   SRC_URI="mirror://samba/rc/${MY_P}.tar.gz"
+   SRC_URI="https://download.samba.org/pub/samba/rc/${MY_P}.tar.gz;
 else
-   SRC_URI="mirror://samba/stable/${MY_P}.tar.gz"
+   SRC_URI="https://download.samba.org/pub/samba/stable/${MY_P}.tar.gz;
KEYWORDS="~alpha amd64 arm arm64 ~hppa ~ia64 ~loong ppc ppc64 ~riscv 
sparc x86"
 fi
 S="${WORKDIR}/${MY_P}"
diff --git a/net-fs/samba/samba-4.19.0-r1.ebuild 
b/net-fs/samba/samba-4.19.0-r1.ebuild
index 38134f5ff67e..60a4f1bf20bd 100644
--- a/net-fs/samba/samba-4.19.0-r1.ebuild
+++ b/net-fs/samba/samba-4.19.0-r1.ebuild
@@ -13,9 +13,9 @@ HOMEPAGE="https://samba.org/;
 MY_PV="${PV/_rc/rc}"
 MY_P="${PN}-${MY_PV}"
 if [[ ${PV} == *_rc* ]]; then
-   SRC_URI="mirror://samba/rc/${MY_P}.tar.gz"
+   SRC_URI="https://download.samba.org/pub/samba/rc/${MY_P}.tar.gz;
 else
-   SRC_URI="mirror://samba/stable/${MY

[gentoo-dev] [PATCH 0/3] inline the samba mirror

[Michael Orlitzky]

Close https://bugs.gentoo.org/916556 by inlining the samba mirror into
net-fs/samba and sys-auth/pam_smb and then dropping the entry from
thirdpartymirrors.

Michael Orlitzky (3):
  net-fs/samba: inline mirror://samba/ into SRC_URI
  sys-auth/pam_smb: inline mirror://samba/ into SRC_URI
  profiles/thirdpartymirrors: drop mirror://samba/

 net-fs/samba/samba-4.18.4-r1.ebuild  | 4 ++--
 net-fs/samba/samba-4.18.5-r1.ebuild  | 4 ++--
 net-fs/samba/samba-4.18.6-r1.ebuild  | 4 ++--
 net-fs/samba/samba-4.18.7.ebuild | 4 ++--
 net-fs/samba/samba-4.18.8.ebuild | 4 ++--
 net-fs/samba/samba-4.19.0-r1.ebuild  | 4 ++--
 net-fs/samba/samba-4.19.1.ebuild | 4 ++--
 net-fs/samba/samba-4.19.2.ebuild | 4 ++--
 profiles/thirdpartymirrors   | 1 -
 sys-auth/pam_smb/pam_smb-2.0.0_rc6-r3.ebuild | 4 ++--
 10 files changed, 18 insertions(+), 19 deletions(-)

-- 
2.41.0

[gentoo-dev] [PATCH 1/1] profiles/thirdpartymirrors: drop dead ubuntu mirrors

[Michael Orlitzky]

Drop the following mirrors from the "ubuntu" list:

 * https://mirror.tcc.wa.edu.au/   (doesn't resolve)
 * http://ubuntu.uni-sofia.bg/ (nothing hosted here)
 * http://mirror.amsiohosting.net/ (no route to host)
 * https://ftp.yzu.edu.tw/ (doesn't resolve)
 * http://mirror.cc.columbia.edu/  (timed out)

To confirm that these are in fact dead, the list at

  http://mirrors.ubuntu.com/mirrors.txt

can be cross-referenced.

Signed-off-by: Michael Orlitzky 
---
 profiles/thirdpartymirrors | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/profiles/thirdpartymirrors b/profiles/thirdpartymirrors
index 034485cccab1..b28145aeac1f 100644
--- a/profiles/thirdpartymirrors
+++ b/profiles/thirdpartymirrors
@@ -22,5 +22,5 @@ samba https://download.samba.org/pub/samba/
 sabayonhttp://sabayon.c3sl.ufpr.br/distfiles 
https://ftp.nluug.nl/pub/os/Linux/distr/sabayonlinux/distfiles 
https://ftp.rnl.tecnico.ulisboa.pt/pub/sabayon/distfiles 
https://ftp.fsn.hu/pub/linux/distributions/sabayon/distfiles 
http://cross-lfs.sabayonlinux.org/distfiles 
https://mirror.dkm.cz/sabayon/distfiles 
http://mirror.internode.on.net/pub/sabayon/distfiles 
https://na.mirror.garr.it/mirrors/sabayonlinux/distfiles 
http://distfiles.sabayon.org
 sourceforgehttps://downloads.sourceforge.net
 sourceforge.jp http://iij.dl.sourceforge.jp https://osdn.dl.sourceforge.jp 
https://jaist.dl.sourceforge.jp
-ubuntu http://mirror.internode.on.net/pub/ubuntu/ubuntu/ 
https://mirror.tcc.wa.edu.au/ubuntu/ http://ubuntu.uni-klu.ac.at/ubuntu/ 
http://mirror.dhakacom.com/ubuntu-archive/ http://ubuntu.c3sl.ufpr.br/ubuntu/ 
http://ubuntu.uni-sofia.bg/ubuntu/ http://hr.archive.ubuntu.com/ubuntu/ 
http://cz.archive.ubuntu.com/ubuntu/ https://mirror.dkm.cz/ubuntu 
http://ftp.cvut.cz/ubuntu/ http://ftp.stw-bonn.de/ubuntu/ 
https://ftp-stud.hs-esslingen.de/ubuntu/ https://mirror.netcologne.de/ubuntu/ 
https://mirror.unej.ac.id/ubuntu/ http://kr.archive.ubuntu.com/ubuntu/ 
https://mirror.nforce.com/pub/linux/ubuntu/ 
http://mirror.amsiohosting.net/archive.ubuntu.com/ 
http://nl3.archive.ubuntu.com/ubuntu/ https://mirror.timeweb.ru/ubuntu/ 
http://ubuntu.mirror.su.se/ubuntu/ https://ftp.yzu.edu.tw/ubuntu/ 
https://ubuntu.volia.net/ubuntu-archive/ https://mirror.pnl.gov/ubuntu/ 
http://mirror.cc.columbia.edu/pub/linux/ubuntu/archive/ 
https://mirrors.namecheap.com/ubuntu/
+ubuntu http://mirror.internode.on.net/pub/ubuntu/ubuntu/ 
http://ubuntu.uni-klu.ac.at/ubuntu/ http://mirror.dhakacom.com/ubuntu-archive/ 
http://ubuntu.c3sl.ufpr.br/ubuntu/ http://hr.archive.ubuntu.com/ubuntu/ 
http://cz.archive.ubuntu.com/ubuntu/ https://mirror.dkm.cz/ubuntu 
http://ftp.cvut.cz/ubuntu/ http://ftp.stw-bonn.de/ubuntu/ 
https://ftp-stud.hs-esslingen.de/ubuntu/ https://mirror.netcologne.de/ubuntu/ 
https://mirror.unej.ac.id/ubuntu/ http://kr.archive.ubuntu.com/ubuntu/ 
https://mirror.nforce.com/pub/linux/ubuntu/ 
http://nl3.archive.ubuntu.com/ubuntu/ https://mirror.timeweb.ru/ubuntu/ 
http://ubuntu.mirror.su.se/ubuntu/ https://ubuntu.volia.net/ubuntu-archive/ 
https://mirror.pnl.gov/ubuntu/ https://mirrors.namecheap.com/ubuntu/
 vdr-developerorg http://projects.vdr-developer.org/attachments/download
-- 
2.41.0

[gentoo-dev] [PATCH 1/1] profiles/thirdpartymirrors: drop "gmt" mirrorlist

[Michael Orlitzky]

This is no longer used anywhere in ::gentoo. It was needed once upon a
time for sci-geosciences/gmt but that project is now hosted on Github.
---
 profiles/thirdpartymirrors | 1 -
 1 file changed, 1 deletion(-)

diff --git a/profiles/thirdpartymirrors b/profiles/thirdpartymirrors
index 97d3f261bc5b..034485cccab1 100644
--- a/profiles/thirdpartymirrors
+++ b/profiles/thirdpartymirrors
@@ -4,7 +4,6 @@ debian  https://deb.debian.org/debian/ 
http://ftp.au.debian.org/debian/ http://f
 gentoo https://distfiles.gentoo.org/distfiles 
https://gentoo.osuosl.org/distfiles 
https://ftp.halifax.rwth-aachen.de/gentoo/distfiles 
https://ftp.fau.de/gentoo/distfiles
 gcchttps://gcc.gnu.org/pub/gcc/ 
http://mirrors.concertpass.com/gcc/ 
https://mirrorservice.org/sites/sourceware.org/pub/gcc/ 
https://ftp.mpi-inf.mpg.de/mirrors/gnu/mirror/gcc.gnu.org/pub/gcc/ 
https://bigsearcher.com/mirrors/gcc/
 gimp   https://ftp.fau.de/gimp/gimp/ ftp://ftp.fau.de/gimp/gimp/ 
https://artfiles.org/gimp.org/pub/gimp/ 
https://www.mirrorservice.org/sites/ftp.gimp.org/pub/gimp/ 
ftp://ftp.mirrorservice.org/sites/ftp.gimp.org/pub/gimp/
-gmthttp://ftp.iris.washington.edu/pub/gmt/ 
ftp://ftp.soest.hawaii.edu/gmt/ ftp://ftp.iris.washington.edu/pub/gmt/ 
ftp://ftp.star.nesdis.noaa.gov/pub/sod/lsa/gmt
 gnome  https://download.gnome.org/
 gnuhttps://ftp.gnu.org/gnu/ https://artfiles.org/gnu.org/ 
https://www.mirrorservice.org/sites/ftp.gnu.org/gnu/
 gnupg  https://www.mirrorservice.org/sites/ftp.gnupg.org/gcrypt/ 
https://ftp.heanet.ie/mirrors/ftp.gnupg.org/gcrypt/ 
https://mirrors.dotsrc.org/gcrypt/ https://gnupg.org/ftp/gcrypt/ 
ftp://ftp.gnupg.org/gcrypt/
-- 
2.41.0

[gentoo-dev] [PATCH 1/1] profiles/thirdpartymirrors: drop cran mirrorlist

[Michael Orlitzky]

The "cran" mirrorlist contained exactly one working mirror and was used
by exactly one ebuild. The working mirror has been inlined into the
ebuild's SRC_URI.

Signed-off-by: Michael Orlitzky 
---
 profiles/thirdpartymirrors | 1 -
 1 file changed, 1 deletion(-)

diff --git a/profiles/thirdpartymirrors b/profiles/thirdpartymirrors
index e1c355086b6e..97d3f261bc5b 100644
--- a/profiles/thirdpartymirrors
+++ b/profiles/thirdpartymirrors
@@ -1,6 +1,5 @@
 apache https://dlcdn.apache.org/ https://apache.mirror.iphh.net/ 
https://artfiles.org/apache.org/ 
https://ftp-stud.hs-esslingen.de/pub/Mirrors/ftp.apache.org/dist/ 
https://ftp.fau.de/apache/ https://apache.osuosl.org/
 cpan   https://cpan.metacpan.org https://www.cpan.org
-cran   https://cran.r-project.org https://cran.us.r-project.org
 debian https://deb.debian.org/debian/ http://ftp.au.debian.org/debian/ 
http://ftp.at.debian.org/debian/ http://ftp.by.debian.org/debian/ 
http://ftp.be.debian.org/debian/ http://ftp.br.debian.org/debian/ 
http://ftp.bg.debian.org/debian/ http://ftp.ca.debian.org/debian/ 
http://ftp2.cn.debian.org/debian/ http://ftp.cn.debian.org/debian/ 
http://ftp.hr.debian.org/debian/ http://ftp.cz.debian.org/debian/ 
http://ftp.dk.debian.org/debian/ http://ftp.sv.debian.org/debian/ 
http://ftp.ee.debian.org/debian/ http://ftp.fi.debian.org/debian/ 
http://ftp.fr.debian.org/debian/ http://ftp2.de.debian.org/debian/ 
http://ftp.de.debian.org/debian/ http://ftp.gr.debian.org/debian/ 
http://ftp.hu.debian.org/debian/ http://ftp.is.debian.org/debian/ 
http://ftp.ie.debian.org/debian/ http://ftp.it.debian.org/debian/ 
http://ftp.jp.debian.org/debian/ http://ftp.lt.debian.org/debian/ 
http://ftp.mx.debian.org/debian/ http://ftp.md.debian.org/debian/ 
http://ftp.nl.debian.org/debian/ http://ftp.nc.debian.org/debian/ 
http://ftp.nz.debian.org/debian/ http://ftp.no.debian.org/debian/ 
http://ftp.pl.debian.org/debian/ http://ftp.pt.debian.org/debian/ 
http://ftp.ro.debian.org/debian/ http://ftp.ru.debian.org/debian/ 
http://ftp.sg.debian.org/debian/ http://ftp.sk.debian.org/debian/ 
http://ftp.si.debian.org/debian/ http://ftp.es.debian.org/debian/ 
http://ftp.se.debian.org/debian/ http://ftp.ch.debian.org/debian/ 
http://ftp.tw.debian.org/debian/ http://ftp.tr.debian.org/debian/ 
http://ftp.ua.debian.org/debian/ http://ftp.uk.debian.org/debian/ 
http://ftp.us.debian.org/debian/
 gentoo https://distfiles.gentoo.org/distfiles 
https://gentoo.osuosl.org/distfiles 
https://ftp.halifax.rwth-aachen.de/gentoo/distfiles 
https://ftp.fau.de/gentoo/distfiles
 gcchttps://gcc.gnu.org/pub/gcc/ 
http://mirrors.concertpass.com/gcc/ 
https://mirrorservice.org/sites/sourceware.org/pub/gcc/ 
https://ftp.mpi-inf.mpg.de/mirrors/gnu/mirror/gcc.gnu.org/pub/gcc/ 
https://bigsearcher.com/mirrors/gcc/
-- 
2.41.0

Re: [gentoo-dev] Proposal for a Universal Remote-ID File

[Michael Orlitzky]

On Sun, 2023-09-24 at 23:14 +0530, Siddhanth Rathod wrote:
> How does modifying the DTD with a git hook sound ?

That could work if we put the DTD, XML schema, and RELAX NG schema all
in the repo metadata. The remaining projects are programs and (given
access to ::gentoo) can probably parse the list themselves.

We're all sufficiently clever here to imagine some solution; it just
occurred to me that without a concrete proposal, it's hard to say
whether the end result would actually be simpler than copy/paste.

Re: [gentoo-dev] Proposal for a Universal Remote-ID File

[Michael Orlitzky]

On Sat, 2023-09-23 at 15:39 +0100, Sam James wrote:
> 
> At the moment, we bundle the DTD in pkgcore. If we just shoved it in
> metadata/ instead in the main repo, we don't have that kind of problem.
> 

I might be missing something obvious, but what I mean is, suppose we
have this plain-text mapping of remote-id names to URLs. How do we get
the list of keys (valid remote-id names) into the DTD? Even if both
files are inside metadata/, there's another step that needs to happen.

Re: [gentoo-dev] Proposal for a Universal Remote-ID File

[Michael Orlitzky]

On Sat, 2023-09-23 at 00:10 +0530, Siddhanth Rathod wrote:
> 
> By establishing a universal remote-ID file, we can streamline this 
> process. Your thoughts and feedback on this proposal would be greatly 
> appreciated.Also, Any preferences on format?

Building the wiki page isn't too hard, but what's the plan to propagate
changes into those seven other repositories? If we're still
copy/pasting the output of some tool, then we haven't really saved a
step, we've only changed what we're copy/pasting.

Re: [gentoo-dev] Re: [gentoo-dev-announce] last rites (kinda, long masked): sys-apps/opentmpfiles

[Michael Orlitzky]

On 2023-09-17 20:28:49, Alexe Stefan wrote:
> 
> There are 2 open pr's on the opentmpfiles github. One removes the
> security vulnerability, but is non-compliant with the spec, the other
> is (at least is a start of) a rewrite in c.

The PR is still vulnerable. These checks,

  _chown() {
local path=$2 uid=$1
if ! owned_by_root "${path}" ; then
...

are insufficient to fix the vulnerability, because it's the parent
path(s) that are the problem. If any parent path is writable by a
non-root user, that non-root user can swap it out from under you,
even if the thing you're operating on is root:root.

AFAIK it's impossible to fix that in shell. In C, you can do a little
openat() dance ensuring that each component of your path is safe from
the root upwards -- that's why one of the suggestions is to rewrite
opentmpfiles in C.

> >As a result, opentmpfiles never should have tried to implement it, but
> >its authors didn't know about those problems either. And while
> >implementing tmpfiles in C has certain unavoidable race conditions,
> >ho boy is the shell version swiss cheese. There's no safe way
> >to run chown and chmod (the shell commands) as root in a directory you
> >don't control, and that's a big part of what opentmpfiles does. The
> >exploits for the shell version are kindergaren stuff.
> 
> Is it really so easy to exploit it?
> How would you do that?
> 

The daemon runs "ln" or "ln -s", basically at its leisure, and
waits for opentmpfiles to run again.

Re: [gentoo-dev] Re: [gentoo-dev-announce] last rites (kinda, long masked): sys-apps/opentmpfiles

[Michael Orlitzky]

On 2023-09-17 15:32:46, Marc Joliet wrote:
> I just want to say how amazed I am that you (and Arsen, too) still have the
> patience to try and explain the realities of the situation like this,
> especially after the eudev thread.

I'm a founding member of the systemd haters club so I'm sympathetic,
but in this case there are only a few realistic paths forward and none
of them involve opentmpfiles.

Re: [gentoo-dev] Re: [gentoo-dev-announce] last rites (kinda, long masked): sys-apps/opentmpfiles

[Michael Orlitzky]

On 2023-09-17 08:26:50, Alexe Stefan wrote:
> One is written in shell, the other is written in c.(no problems here)
> One is not part of systemd, the other is.
> How are they identical.

The big picture is that the tmpfiles.d specification is impossible to
implement securely on a POSIX system. The systemd devs wrote a
specification to appease the people who complained, but that doesn't
change the fact that the spec is fundamentally flawed unless you
happen to be implementing it on a new linux system. (The authors
didn't know this at the time, so it was not a dirty trick.)

As a result, opentmpfiles never should have tried to implement it, but
its authors didn't know about those problems either. And while
implementing tmpfiles in C has certain unavoidable race conditions,
ho boy is the shell version swiss cheese. There's no safe way
to run chown and chmod (the shell commands) as root in a directory you
don't control, and that's a big part of what opentmpfiles does. The
exploits for the shell version are kindergaren stuff.

The systemd folks put in a lot of work to make sure that the race
window is a small as possible in systemd-tmpfiles. And on linux with
kernel hardening, you're safe. Given that no one is working towards
replacing tmpfiles completely, here's where that leaves us.

We have the systemd utility that is as secure as possible, and
opentmpfiles that tries to mimic it but is unmaintained and much less
secure. At best, the insecure version could be rewritten in C to make
it basically identical to the systemd version? Which has no real
problems aside from the fact that it has systemd in the name. And no
one is volunteering to do that rewrite in the first place. Newer linux
systems are well supported by systemd-tmpfiles, and that's the only
place tmpfiles is safe to begin with.

It sucks that we're all stuck with tmpfiles now but you're only
shooting yourself in the foot if you insist on using the worst
possible implementation of it.

Re: [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options

[Michael Orlitzky]

On Tue, 2023-09-12 at 22:52 -0400, Eli Schwartz wrote:
> 
> Is portage generally expected to successfully complete (including
> internal metadata write stages) when its workdir drive runs out of space
> partway through?
> 

No, but I think what everyone else is forgetting to mention is that if
it's going to fail, we want it to fail as soon as possible, i.e. as
close to the thing that actually went wrong. If we proceed past ENOSPC
or whatever, we could get five or six lines further in the ebuild, and
then some other command will fail but possibly with a crazy unrelated
error message.

Re: [gentoo-dev] Massive Github PR Queue

[Michael Orlitzky]

On Fri, 2023-08-11 at 18:37 -0500, Gordon Pettey wrote:
> 
> "Not using GitHub" is not an excuse for a PR to sit ignored when it has a
> bug attachment. Anyone can view a PR anonymously and clone the remote from
> the read-only https URL. There's no "using github" required for that beyond
> clicking the link in the attached bug to see the PR and the remote
> repository name.

We went years with one developer refusing to fix tinderbox bugs because
the build logs were hosted on AWS instead of bugzilla.

These are Gentoo Linux developers. People who chose a corner case
operating system and then chose a corner case distribution of it and
then became a corner case of its userbase. As a result, you're going to
see some corner-case moral and technical principles. Telling someone
that those principles aren't an excuse just isn't going to get them to
help you any faster.

Re: [gentoo-dev] Massive Github PR Queue

[Michael Orlitzky]

On Fri, 2023-08-11 at 10:35 -0700, orbea wrote:
> 
> Perhaps the correct answer would be neither Bugzilla or Github?

A mailing list (whose archives work :o) with git-send-email threads
would be an improvement over both.

Re: [gentoo-dev] Massive Github PR Queue

[Michael Orlitzky]

On Fri, 2023-08-11 at 07:46 -0700, orbea wrote:
> 
> Understandable, but I still don't get how 1 or 2 people can take care
> of SBo every week while Gentoo the process stagnates.

Probably due to compartmentalization. In Gentoo you're often waiting
for one maintainer. Or worse, waiting for one "project" consisting of
several people none of whom actually care about the package the PR
touches.


> > 
> > But also, Github sucks. Open bugs.
> > 
> 
> No disagreements and personally I wouldn't use Github if not for it
> being beyond my control, but there are still 235 open PRs with bugs
> assigned.
> 
> https://github.com/gentoo/gentoo/pulls?q=is%3Apr+is%3Aopen+label%3A%22bug+linked%22
> 

Linking a bug was a half-hearted attempt to appease the folks who think
that Gentoo development shouldn't depend on proprietary software (per
our social contract). But if the bug just points me to Github, it
doesn't really change anything.

I of course have a comprehensive list of Github complaints in mind 24
hours a day, but they're not especially relevant. What is relevant is
that some other developers have their own list, and sometimes you're
waiting on one developer who doesn't like to use Github for whatever
reason. My personal PR queue is of length zero, so I'm not making
excuses, but when you want something done for free it's in your best
interest to make it easy for the person who has to do it.

Re: [gentoo-dev] Massive Github PR Queue

[Michael Orlitzky]

On Fri, 2023-08-11 at 07:07 -0700, orbea wrote:
> 
> Why does Gentoo lets PRs indefinitely sit around and collect dust? Its
> extremely discouraging for contributors if their work just gets ignored.
> With some extra work I imagine its possible to get the PR queue to a
> much more manageable size where work doesn't get lost.
> 

Reviewing a PR takes longer than doing it yourself would, and if you
had time to do it yourself there wouldn't be a PR in the first place.

But also, Github sucks. Open bugs.

Re: [gentoo-dev] Packages up for grabs per grknight's retirement

[Michael Orlitzky]

On Sun, 2023-06-25 at 16:58 +0300, Joonas Niilola wrote:
> Hey,
> 
> these packages are up for grabs:
> 

Brian was the last member of the PHP project, so most of those packages
are now unmaintained too. I'm co-maintainer on a few of them but Brian
did most of the work.

Re: [gentoo-dev] [PATCH] savedconfig.eclass: do not preserve symlink in restore_config

[Michael Orlitzky]

On Sun, 2023-06-04 at 20:46 +0200, Arsen Arsenović wrote:
> 
> I believe that the target directory of this cp can be considered
> equivalent in terms of access to any superuser-only directory, so I'm
> not sure I see the problem with this change.

It silently changes something that was safe (but stupid) to something
unsafe (but still stupid).

Re: [gentoo-dev] [PATCH] savedconfig.eclass: do not preserve symlink in restore_config

[Michael Orlitzky]

On Sun, 2023-06-04 at 13:31 -0400, Mike Gilbert wrote:
> This allows users to maintain the saved config file in some other
> location.
> 

If so, the symlink should point to a superuser-only location to avoid
creating any new vulnerabilities. We can't fix the general problem, but
we could at least mention in the docs that symlinks will (now) be
followed and that users should be careful if they want to maintain the
files elsewhere.

[gentoo-dev] Re: [gentoo-dev-announce] Gentoo metastructure update (GLEP 39) voting now open - 7 days left

[Michael Orlitzky]

On Sun, 2023-04-30 at 16:30 +, Jorge Manuel B. S. Vicetto wrote:
> 
> This is a friendly reminder that we're nearing (at the end of the day) 
> the half-period for this election voting.
> 

My options are "yes" and "no" but there's no indication of what I'm
saying yes/no to.

I'd wager that "yes" means update the GLEP but I'd really rather have
it in writing before voting.

Re: [gentoo-dev] QA PG 0305 (manpages must always be installed) discussion

[Michael Orlitzky]

On Thu, 2023-01-19 at 13:25 +0200, Cedric Sodhi wrote:
> 
> In this case, the expectation to compile manpages does not come free
> of cost and protects noone. By the above formulation, the cost
> "should" not come in the form of additional (heavy! dev-python/sphinx
> and deps are 75M) dependencies, but instead in the form of additional
> work for the maintainer. One way to annoy less-enthusiastic (proxy-)
> maintainers, in my opinion.
> 

I think "protects noone" is overstating it. If your network is broken,
the man pages might be your only troubleshooting resource. It would
suck to find that (say) net-wireless/iwd introduced a new USE=man flag
a few weeks ago and now you can't get connected to some weird
conference wifi and are unable to google for help.

Something like USE=noman would be nicer for users, but IIRC we have a
policy against them (flags with a "no" prefix). Setting a global
USE="+man" default also creates some headaches in our "user interface."

OTOH I do agree it would be nice if we had a way to disable them if you
very explicitly ask for it. Sphinx (the example in bug 890589) is
obnoxious, and if you're going to strip the man pages with something
like FEATURES=noman on an embedded system -- or if you just don't care
about those particular man pages -- then it would be great if you could
not build them in the first place.

The best of both worlds would be if someone could convince upstream to
generate them during their "make dist" process.

Re: [gentoo-dev] Defining TZ in the base system profile?

[Michael Orlitzky]

On Wed, 2023-01-18 at 20:48 -0500, Joshua Kinard wrote:
> 
> So is adding a default definition of TZ to our base system
> /etc/profile something we want to look at?  I 
> haven't tried any other methods of benchmarking to see if not making
> those additional syscalls is just placebo 
> or if there are actual impacts.  Given how long this oddity has been
> around, I can't tell if it's a genuine 
> bug in glibc, an unoptimized corner case, or just a big
> nothingburger.
> 

I thought about doing this on my laptop, and talked myself out of it.
The main counter-arguments are,

  1. ICU doesn't handle the :/etc/localtime format at the moment,

   * https://unicode-org.atlassian.net/browse/ICU-13694
   * https://github.com/nodejs/node/issues/37271

 You could readlink() it or whatever at boot, but that will cause
 changes to /etc/localtime to be mysteriously ignored.

  2. The stats are there for a "good" reason, namely to let glibc
 know if the timezone has changed on the fly.

The first one is only a temporary deal-breaker, but the second is a
tradeoff involving how often your timezone changes (user-dependent) and
what the real performance impact is (probably not much).

Re: [gentoo-dev] Gentoo LTS or: proper backward compatibility?

[Michael Orlitzky]

On Mon, 2023-01-02 at 12:48 +, m1027 wrote:
> Hi and happy new year.
> 
> When we create apps on Gentoo they become easily incompatible for
> older Gentoo systems in production where unattended remote world
> updates are risky. This is due to new glibc, openssl-3 etc.
> 

Just update them. YOLO.

Seriously though, most of us run Gentoo in some sort of production
setting. Updating often is your best bet as it keeps the list of
suspects short when things do break.

OTOH I'm only about 15km from our servers when I set them on fire, so
keep that in mind if yours are on another continent. If updating
frequently is truly out of the question, a rolling release probably
isn't the best deployment target for you.

Re: [gentoo-dev] Packages up for grabs: apache-2.eclass

[Michael Orlitzky]

On 2022-12-26 10:11:18, Hans de Graaff wrote:
> 
> It would be great if you could dust these off and post them here so we
> can get these improvements merged. You mention in the bug that you'd
> rather wait for a dedicated maintainer to review them, but I'm (in
> name) that maintainer and I think you probably know these eclasses
> better than I do. With some joint effort we may get things moving here.

I'm trying to avoid becoming the de facto maintainer of the thirty or
so apache modules that I care nothing about. The eclasses I posted to
the bug are a proof-of-concept for www-apache/mpm_itk, but even that
has a workaround allowing it to use EAPI=7 now. I haven't tested them
with any other packages.

Updating apache-module-r1.eclass to EAPI=8 still requires some work,
and then the whole thing needs to be tested by migrating a
representative chunk of apache-module packages to determine if the
idea is feasible as-is, or if the approach needs to be tweaked. Until
then we'd just be wasting reviewers' time.

I may eventually get bored enough to do all that testing, but right
now I have a lot of things that are actually enjoyable and/or make me
money in front of it on my list.

Re: [gentoo-dev] Packages up for grabs: apache-2.eclass

[Michael Orlitzky]

On 2022-12-25 13:09:46, David Seifert wrote:
> Back when polynomial-c was retired, we forgot to send up for grabs for
> eclasses he maintained:
> 
>   apache-2.eclass
> 
> is up for grabs, and is in general need of a revamp, it hasn't aged
> well.

If anyone is interested, I posted updates/replacements for the other
two apache eclasses on https://bugs.gentoo.org/616612. Merging those
should ideally be accompanied by an update to apache-2.eclass, making
it use the paths from the new apache-paths.eclass, so that everyone is
getting the paths from the same place.

Re: [gentoo-dev] Last rites: dev-python/* using nose, with no revdeps

[Michael Orlitzky]

On Fri, 2022-12-23 at 15:35 +0100, Michał Górny wrote:
> # Michał Górny  (2022-12-23)
> # Packages that still use dev-python/nose and have no revdeps.
> #
> ...
> dev-python/python-redmine

I'm the (only) maintainer for this, and I didn't even know there was a
problem. I have at least filed an upstream issue now.

I suppose it suffices to RESTRICT the tests for now?

Re: [gentoo-dev] Missing inside metadata.xmls

[Michael Orlitzky]

On Mon, 2022-12-19 at 22:05 +0100, mscard...@icloud.com wrote:
> 
> I know it’s not actually imperative to add it but actually strongly
> suggested to maintain things consistent. What do you think about
> that? Is something You find important to stick?
> 

The problem is that the name is redundant for Gentoo developers. It's
often helpful to have it for other types (e.g. proxy) developers, but I
find it a bit pointless to copy/paste "Michael Orlitzky" into hundreds
of ebuilds when it can easily be deduced from "m...@gentoo.org."

Re: [gentoo-dev] musl, sbcl, and ros

[Michael Orlitzky]

On Sat, 2022-12-03 at 02:59 +0100, Haelwenn (lanodan) Monnier wrote:
> [2022-12-02 05:11:15+] Andrey Grozin:
> > In principle, one can try a workaround: use some other lisp (say, clisp or
> > ecl) as the bootstrap lisp. This way is at best brittle: there is no
> > guarantee that these external lisps will compile the sbcl sources
> > successfully. People say that sometimes this works.
> 
> Well Alpine is using the ecl route: 
> https://git.alpinelinux.org/aports/tree/community/sbcl/APKBUILD

ECL is a good choice. Upstream is active and friendly. but:

The current and only version of ECL in the tree has a bug that makes it
unusable for compiling SBCL:

  * https://bugs.launchpad.net/sbcl/+bug/1956852
  * https://gitlab.com/embeddable-common-lisp/ecl/-/issues/667

A fix was committed, but there hasn't been a new release yet.

Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)

[Michael Orlitzky]

On Wed, 2022-11-23 at 08:38 +0100, Michał Górny wrote:
> 
> What are the advantages of proposed solution over eselect?
> ==

I think it's also worth mentioning the advantages over the usual
virtual approach, where we have a virtual pull in one implementation
and the implementations be responsible for the symlink. Because
otherwise that would tick the same boxes.

Here's one: the sys-meta approach allows you to switch the
implementation quickly without rebuilding an entire package. For
example, if I meet a package that's broken with /bin/sh -> /bin/dash, I
don't want to have to emerge bash to get past that.

Maybe there are others.

Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)

[Michael Orlitzky]

On Wed, 2022-11-23 at 15:37 +0100, Michał Górny wrote:

> 
> 
> PMS doesn't say anything about (new-style) virtuals.  It's a Gentoo
> policy entirely.

This is listed as a retroactive change,

  Note: A ‘new-style virtual’ is a normal package that installs no 
  files and uses its dependency requirements to pull in a ‘provider’.


> Do you have any specific concerns about having an extra category?
> I'm not aware of any real costs involved, or real reasons to use
> categories scarcely.
>  
> ...
> 
> I don't really care how it's named.  I've chosen "sys-" because in my
> PoC it happens to control tools that are part of the base system.
> I suppose we could also want it for less important stuff like notify-
> send (though I guess I'll lastrite that eselect anyway).  I think we
> should just use one category for all of them, and I'm open to a
> better name.

The main reason the new category is distasteful to me is because it's
*so close* to being a virtual. For one, having these packages be
virtuals would make them somewhat self-explanatory to end users. If
we're collectively willing to overlook the "no files" bit, are there
any other reasons to avoid using virtual/ ?

Regardless, since I specifically called out the "meta" suffix, let me
put forward sys-alternatives as an alternative.

Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)

[Michael Orlitzky]

On Wed, 2022-11-23 at 08:38 +0100, Michał Górny wrote:
> Hello, everyone.
> 
> TL;DR: I'd like to add sys-meta/{cpio,sh,tar} to install and control
> (via USE flags) /bin/{cpio,sh,tar} symlinks.
> 
> Draft PR: https://github.com/gentoo/gentoo/pull/28390
> 

I generally favor using the package manager in these situations, but
there's a lot of user-facing documentation (and user configurations)
that will need updating. We should probably have a GLEP -- and
eventually a news item -- for this.

A few comments:

  * The new category is a bit annoying. I know the PMS says that  
virtuals can't install files, but having an entirely separate 
category for virtuals that install a symlink feels excessive.
Not that I have a better idea.

  * The name also suggests to me that it will control sys-* 
implementations, but the victims so far are all app-*. Obviously,
we don't want twenty *-meta categories though.

  * The -meta prefix is already used in a bunch of ebuilds to mean
something different. The packages in sys-meta won't be 
"metapackages" in the same sense.

  * Should we replace app-arch/tar with sys-meta/tar in @system?

  * Having to specify the relationship twice (once in the sys-meta 
package and once in each implementation) is also a bit ugly, as is 
having to account for the symlink not being installed (yet) in 
each implementation's pkg_postinst. This made me wonder, could 
the RDEPEND/PDEPEND be reversed? In other words, could (say) GNU 
tar require that the symlink be present immediately, but the 
metapackage only require that some implementation be merged 
eventually?

To answer my own question, the PMS says that PDEPENDs "must be 
installed at some point before the package manager finishes the 
batch of installs," which would be problematic if some later 
package in the batch actually needed a tar implementation 
available to build. We can't change the PMS, so installing a 
symlink in the implementation ebuilds avoids the issue, but still 
    eventually cedes control to the sys-meta package.

I guess you already thought through all of that? If so, it would be
nice to have the rationale written down somewhere that we can refer
back to.

  * Is it worth thinking about improvements to EAPI=? that could help 
us here? By e.g. allowing virtuals to install symlinks, or by 
making PDEPEND kick in sooner (after this package, but before the 
rest of the batch)?

Despite all the skeptical-sounding feedback, I think this is a good
idea, and an improvement over eselect.

Re: [gentoo-dev] [PATCH] git-r3.eclass: Add checkout dirs as "safe" directories

[Michael Orlitzky]

On Sun, 2022-11-06 at 12:19 +0100, Florian Schmaus wrote:
> 
> I guess there is no way we can avoid the --global and use --local instead?
> 

The setting is only respected if it's in the global ($HOME) or system
(/etc) configs. There's no explanation for that in the man page, but
it's probably because you can't let $repo/.git/config be in charge of
safety if $repo is untrustworthy.

Re: [gentoo-dev] Clang 16 is coming - and it'll break your packages!

[Michael Orlitzky]

On Sun, 2022-10-09 at 22:25 +0100, Sam James wrote:
> 
> * Some bugs simply need an `eautoreconf` because older
>   autoconf-generated configure files had issues.
> 

Vanilla autoconf still emits busted tests for e.g. AC_CHECK_FUNC, so
you'll want the ~arch autoconf with sam's backported patches in the
meantime. (Surely they'll be stable before clang-16 is available.)

Re: [gentoo-dev] Last rites: various more revdep-less Haskell packages

[Michael Orlitzky]

On Sun, 2022-08-21 at 15:10 -0400, matoro wrote:
> Hey mjo, sorry about this - we were somewhat aggressive when building 
> this list because much of the ecosystem has a tendency to do things like 
> put strict upper bounds in their cabal files, leading to lots of 
> blockers and manual patching whenever dependencies get bumped.
> 
> Do any of your packages pull in deps that are in the last-rited list?  
> If not I don't see an issue with keeping them.
> 

These are the recently-masked first-level dependencies that they need,
but there may be more transitively:

  dev-haskell/configurator
  dev-haskell/dns
  dev-haskell/filemanip
  dev-haskell/hdbc
  dev-haskell/hdbc-postgresql
  dev-haskell/hdbc-sqlite3
  dev-haskell/missingh
  dev-haskell/parallel-io

All of the bounds in my four packages are >= bounds -- even in the
cabal file -- to avoid the problem you mentioned. I'd guess that they
build fine against whatever the latest versions of those dependencies
are; if not, the dependencies could be updated (can't hurt worse than
masking, right?)

Re: [gentoo-dev] Last rites: various more revdep-less Haskell packages

[Michael Orlitzky]

On Sun, 2022-08-21 at 03:23 +0100, Sam James wrote:
> # hololeap  (2022-08-21)
> # Monolithic mask for dev-haskell/* packages which have no reverse 
> dependencies,
> # are broken, or severely out of date
> net-mail/list-remote-forwards
> net-mail/mailbox-count
> net-misc/haeredes
> net-misc/hath
> 

Two of these have haskell@ as a backup maintainer, but the other two
list only myself.

What's wrong with them? They're essentially feature complete with no
bugs and don't bother anyone AFAIK.

Re: [gentoo-dev] [PATCH] elisp-common.eclass: fix for Emacs 29 (explicitly require autoload)

[Michael Orlitzky]

On Thu, 2022-08-18 at 20:18 +0100, Sam James wrote:
> Emacs 29's NEWS says: "The autoload.el library is now obsolete."
> 
> ...
>  
>   ${EMACS} ${EMACSFLAGS} \
> + --eval "(require 'autoload)" \
>   --eval "(setq make-backup-files nil)" \
>   --eval "(setq generated-autoload-file (expand-file-name 
> \"${f}\"))" \
>   -f batch-update-autoloads "${@-.}"

The batch-update-autoloads docstring says that it "calls 'update-
directory-autoloads' on the command line arguments." The function
update-directory-autoloads is, in turn, obsoleted in favor of loaddefs-
generate from loaddefs-gen.el (which replaces autoload.el).

Can we bypass the obsolete autoload.el entirely here, instead calling
loaddefs-generate directly?

Re: [gentoo-dev] Last rites: large amount of unmaintained dev-haskell/* package

[Michael Orlitzky]

On 2022-07-23 23:23:38, Sam James wrote:
> 
> The two people you refer to (solpeth and hololeap) both warmly
> welcomed this move and endorse it. It'd be great to have them as developers
> and I've offered to help mentor them, as have others.

Ok, awesome. Thank you both.

Re: [gentoo-dev] Last rites: large amount of unmaintained dev-haskell/* package

[Michael Orlitzky]

On Sat, 2022-07-23 at 02:49 +0100, Sam James wrote:
> # Sam James  (2022-07-22)
> # Monolithic mask for dev-haskell/* packages which have no reverse 
> dependencies,
> # are broken, or severely out of date. The aim is to have the Haskell overlay
> # (::haskell) be the place for development packages and only have packages
> # needed for end-user applications in ::gentoo, as the status who has
> # proven to be unsustainable. More up-to-date versions of these packages
> # are available in ::haskell.
> # Removal on 2022-08-22.
> ...
> dev-haskell/hakyll
> ...
> sci-mathematics/agda
> 

Those two are (relatively) popular end-user applications.

I'm sure this came up already, but just in case it didn't: we largely
have two non-developers maintaining the ::haskell overlay, and they've
been doing so since slyfox's retirement. Since there's an ongoing
thread about recruitment... has anyone thought about letting them do
their work in ::gentoo instead?

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

[Michael Orlitzky]

On Fri, 2022-05-13 at 11:44 -0400, Mike Gilbert wrote:
> 
> "which" is a built-in command in bash, but not in dash. For most
> users, /bin/sh points at bash and I don't expect to see much breakage
> when /usr/bin/which is removed. The bug reports will come from people
> who like pain and run their systems with /bin/sh pointed at dash.
> 

Debian did that first, too. If your oldest and most boring friend jumps
off a bridge, it's fine. And it makes each ./configure run like 15%
faster!

Who is Gentoo for if not for people who would sacrifice essential
stability for a little temporary performance, and deserve neither?

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

[Michael Orlitzky]

On Fri, 2022-05-13 at 09:11 +0200, Ulrich Mueller wrote:
> 
> So, should we join the "which hunt", with the goal of removing
> sys-apps/which from the system set and from stage1?

Yes, although I would suggest "command -v" as a POSIX replacement that
can be sent upstream. The "type" utility is also standard, but the "-p"
flag is not, so "type -p" creates some pointless bashisms. Both are
built-in to bash so there's no performance penalty in ebuilds either
way.

Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60libtool-la (check for unnecessary .la files)

[Michael Orlitzky]

On Fri, 2022-04-15 at 09:40 +0100, Sam James wrote:
> +
> +   if grep -q "dev-libs/libltdl" <<<${RDEPEND}; then
> +   # Nothing to do here
> +   return
> +   fi

We should probably have delimiters around that atom to future-proof it
against (say) dev-libs/libltdl2. Would "has" suffice?

Re: [gentoo-dev] Feature request: auto-CC for bugs modified via commit tags

[Michael Orlitzky]

On Tue, 2022-01-25 at 21:59 +0100, Agostino Sarubbo wrote:
> 
> - If you are CC'ed by the hook and you are part of the alias that is the 
> assignee of the bug, 
> you will receive two emails unless the hook integrates the alias.
> 
> - Based on the previous point, I'd suggest to use a wrapper if you want to be 
> cc'ed on the 
> bug you are resolving:
> 

I don't have enough information about the environment to know if it's
possible, but obviously it would be nice if the implementation could
avoid double emails. A pass through projects.xml might suffice, since
non-devs can't commit directly. It might take an extra HTTP request
though.

An alias or wrapper isn't much better than checking the box on the
webpage, at least for me personally:

  * I still have to remember to use the wrapper and not the "repoman 
commit" I've typed thousands of times.

  * I need two wrappers; one for repoman and one for pkgdev.

  * I only want to be CCed if I actually modify the bug (not merely by 
committing), since that's what prompts follow-up comments.

  * A few other people have said they would like the feature, and 
we'd all need to reimplement the same thing on a bunch of machines.

  * It needs www-client/pybugz installed =)

Re: [gentoo-dev] Feature request: auto-CC for bugs modified via commit tags

[Michael Orlitzky]

On Tue, 2022-01-25 at 11:29 -0800, Alec Warner wrote:
> 
> Just to clarify here:
> For your own commits (e.g. fixing a package you own) you are already
> typically on the bug..right?

Right.


> I assume the major use case here is proxying commits for others (where
> they are on the bug, but you are not, either directly, or via an
> alias?)
> 
> 

Take maintainer-needed packages for example. No one else is maintaining
them, and I don't want to add myself to the alias or take full
responsibility for the package. But if I have ten free minutes I might
pick an open bug from the 24h recent list on bugzilla and do a drive-by
commit to fix a simple build failure. I'd like to be CCed on the
relevant bug in case someone comments on my fix.

[gentoo-dev] Feature request: auto-CC for bugs modified via commit tags

[Michael Orlitzky]

Can I request that Bug: and Closes: tags in our commits automatically
CC the committer on the bug that is modified?

Use case: I often fix (sci-*) bugs that I'm not CCed on, and a user
will leave a comment like "it still crashes on x86" that I never see.
Of course, I could manually CC myself on every bug. But that will send
everyone an extra email, and is forgettable. Plus, avoiding the manual
step is kind of the point of the automation, right?

One potential downside is that the commit author could wind up CCed
twice via an alias, but that could be solved with a sufficiently clever
implementation. Or disregarded if it's not too much of a problem in
practice; the bugs will usually be closed, after all.

Re: [gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust

[Michael Orlitzky]

On 2022-01-20 16:32:30, Brian Evans wrote:
> 
> GNOME and Mozilla products still pull in spidermonkey but other users 
> will have a much reduced requirement for rust.
> 

Avoiding librsvg used to be difficult because it's required by our GTK
icon packages to render PNGs from SVGs. Luckily dilfridge's binrepo
now makes it easy to download pre-rendered icons, and there's no
security/performance/legal concerns with pre-rendered PNGs, so using
them shouldn't present any moral dilemmata. You mainly just have to
replace Firefox, Thunderbird, and GIMP.

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

[Michael Orlitzky]

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

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

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

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

[Michael Orlitzky]

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

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

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

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

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

[Michael Orlitzky]

On Tue, 2022-01-04 at 03:38 +, Sam James wrote:
> 
> ACL is kind of similar to what Ionen said for PAM, i.e. sometimes
> people may want to turn it off and it makes sense to expose
> this option for those who do, but we don't need to try support it.
> 

This is another important one. It has security implications, is highly
confusing, requires kernel support, and is nonstandard as a USE flag
and as an implementation. Most people should have it off to avoid
surprises, but disabling it in the kernel can make the userland
software complain when explicitly built with ACL support.

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

[Michael Orlitzky]

On Mon, 2022-01-03 at 16:51 -0800, Alec Warner wrote:
> > 
> > 
> > Many packages need their ipv6 code disabled if the kernel has no ipv6
> > support, and enabling ipv6 in the kernel is a pointless security risk
> > for pretty much anyone in the United States.
> 
> https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption
> 
> Go troll somewhere else?
> 

Anyway, leave the USE flag please.

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

[Michael Orlitzky]

On Mon, 2022-01-03 at 21:29 +0100, Piotr Karbowski wrote:
> 
> Perhaps the 'pam' example was extreme, but ipv6, or threads as Sam 
> shared, does not make sense to be togglable.
> 

Many packages need their ipv6 code disabled if the kernel has no ipv6
support, and enabling ipv6 in the kernel is a pointless security risk
for pretty much anyone in the United States.

Re: [gentoo-portage-dev] [PATCH] portage.output: Replace darkblue colors with teal

[Michael Orlitzky]

On Sat, 2021-12-04 at 10:47 +0100, Fabian Groffen wrote:
> 
> Now, if you would make a supported claim that all terminals we install
> use a black background by default, your change becomes more valid.
> 
> 

For one, when you're working through the handbook to install Gentoo,
you're doing it on a black background.

Or if you have any physical servers. The dark-blue-on-black is even
more fun to read from three feet away on the CRT monitor from 1995 in
the back of a poorly lit server room.

Re: [gentoo-dev] Common options missed in OpenRC declarative scripts and how to improve them

[Michael Orlitzky]

On 2021-12-02 08:12:55, Alec Warner wrote:
> 
> Can we automate any of it? Emit QA warnings? etc.
> 

I would love to be proven wrong, but I don't think so. We have two
main problems. First, The service scripts are POSIX sh, which is
better than bash, but still can't easily be parsed for semantic
information.

Second, if the daemon is "special," then the service script is
justified in being similarly unconventional. Unusual runtime behavior
can't be statically detected, and I doubt that the well-behaved
portion of daemons in the tree is large enough that we can warn about
every script that smells a little bit fishy.

Re: [gentoo-dev] Common options missed in OpenRC declarative scripts and how to improve them

[Michael Orlitzky]

On 2021-12-01 21:02:20, Brian Evans wrote:
> After a cursory scan of the Gentoo repository, I've noticed an
> overabundance of start_stop_daemon_args being declared in scripts committed.
> 
> I would like to draw attention and see if we can clean these up together.

A lot of this is covered in the service script guide:

  https://github.com/OpenRC/openrc/blob/master/service-script-guide.md

There's a 2.5-year old bug to mention it in the devmanual:

  https://bugs.gentoo.org/684354

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

[Michael Orlitzky]

On Tue, 2021-11-30 at 22:45 -0800, Alec Warner wrote:
> 
> So questions from my side are:
> Does your cluster not have human users?
> Do the userids for the human users also not have to match between
> hosts in the cluster?
> 
> 

You can easily create ebuilds for the human users who access the
system, and sets like @admins or @developers, so that all important
user information is ultimately recorded by the package manager.

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

[Michael Orlitzky]

On Tue, 2021-11-30 at 19:32 -0600, William Hubbs wrote:
> 
> This is the part of this that I don't understand. If we aren't enforcing
> an ID, why do we care which ID to try first? It seems to be an
> unnecessary step since users can pick the IDs they want by putting
> settings in make.conf.
> 

This way, all new installs have consistent IDs by default. Users having
to manually specify every ID on every system to have them be consistent
is exactly what we are trying to avoid.

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

[Michael Orlitzky]

On Mon, 2021-11-29 at 05:05 +, Sam James wrote:
> 
> What I wish we had done (and there's still time to do, albeit belated --
> it's still useful for the remaining big bits like Apache and nginx) is
> write a news item explaining the implications and linked to a page
> like https://wiki.gentoo.org/wiki/Practical_guide_to_the_GLEP_81_migration 
> 
> (which ConiKost created after we discussed how to inform users better)
> that explains how to work around/express their preferences/give their own 
> hints.
> 

I agree, and there's still room to improve the user interface as well.
For example, I run postfix on all of my machines. A few of them also
need to run OpenDKIM, and need the postfix user to be a member of a
group that is shared with OpenDKIM, to access a socket.

To best integrate with the PM, the solution to this problem is to
override acct-user/postfix in an overlay. Ok, no problem. But since the
additional group should be optional, it needs to be controlled by a USE
flag if you want to use the same ebuild across your entire
organization. The implementation details make this a bit ugly:

  RDEPEND+=" dkimsocket? ( acct-group/dkimsocket )"

  pkg_setup() {
if use dkimsocket; then
  ACCT_USER_GROUPS+=( dkimsocket )
fi
  }

The extra noise is necessary because "dkimsocket" needs to be added to
two arrays, and that can't be done declaratively at the moment. It
would be a nice UI improvement if the best solution was less of a
headache.



> Sorry, I should've been explicit. The main thing I'd like to understand better
> from your POV is:
> 
> this isn't new, but you're quite clear you feel that the UID/GID range 
> limitations
> are completely arbitrary and without merit(?).
> 
> Whissi essentially says the opposite: 
> https://archives.gentoo.org/gentoo-dev/message/17a22877f5f18dae44a2f0859d807450
>  
> .
> 
> I'd like to understand if this is just a result of beliefs about what the PM 
> should/shouldn't do
> or if there's genuine problems with continuing to extend the range?

Using the rest of the system range (500-999) should pose no problems
for anyone, since that's exactly what the old user.eclass will do. I
also see no problem with 60001+. I'm skeptical that any daemons have
those ranges hard-coded; and even if they do, they're buggy and we
shouldn't handicap the distribution over it.

More fundamentally, the "user" and "system" limits themselves not
written in stone: they are written in login.defs, and are only hints
for a few standard tools. Software should not be guessing at them. I
think we should try to keep things as consistent as possible with other
distributions, operating systems, and standards -- but if it comes down
to it, the numbers in the acct-* ebuilds are only suggestions, and it
doesn't hurt anything in the long run to suggest a number that might
already be taken because login.defs allowed useradd to take it in the
past.

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

[Michael Orlitzky]

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

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

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

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

[Michael Orlitzky]

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

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


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

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

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


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

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


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

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

Is there an actual problem?

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

[Michael Orlitzky]

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

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

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

Re: [gentoo-dev] Common Lisp project is empty

[Michael Orlitzky]

On Wed, 2021-11-03 at 16:25 +0100, Max Zettlmeißl wrote:
> On Wed, 3 Nov 2021 at 14:15, Michael Orlitzky  wrote:
> > If no one intends to join, we should drop the following to maintainer-
> > needed:
> 
> I use some of those packets daily. Is there a way to join the Common
> Lisp project without currently having maintainer status or is that not
> intended?

I don't think you can join the project, but you could still be added as
an additional proxy maintainer for those packages you care about. That
would let you take care of them using pull requests once everyone is
made aware that common-lisp@ isn't going to respond to RFCs.

Then if the common lisp project is ever disbanded, you would remain as
the sole maintainer of those packages rather than having them go to
maintainer-needed.

[gentoo-dev] Common Lisp project is empty

[Michael Orlitzky]

If no one intends to join, we should drop the following to maintainer-
needed:
 
app-misc/rlwrap
dev-libs/ffcall
dev-libs/libsigsegv
dev-lisp/alexandria
dev-lisp/asdf
dev-lisp/cl-ppcre
dev-lisp/cl-ppcre-unicode
dev-lisp/clisp
dev-lisp/clozurecl
dev-lisp/clx
dev-lisp/cmucl
dev-lisp/ecls
dev-lisp/flexi-streams
dev-lisp/gcl
dev-lisp/hyperspec
dev-lisp/sbcl
dev-lisp/trivial-gray-streams
dev-lisp/uiop
virtual/commonlisp

The full package list is available at p.g.o but those above have no
other maintainer.

Re: [gentoo-portage-dev] [RFC] LTS branch of Portage

[Michael Orlitzky]

On Tue, 2021-10-05 at 17:13 +0200, Michał Górny wrote:
> 
> >   2. What happens to the LTS branch when the next EAPI is released?
> > 
> 
> I haven't really thought about it.  Are you suggesting that we could
> bump 'master' Portage to newer EAPI earlier or...?
> 

I just mean that, a priori, the LTS branch won't be able to install
ebuilds that use the next EAPI. Backporting an entire EAPI doesn't seem
appropriate for a stable series; but maintaining an increasingly-
obsolete branch at that point doesn't make much sense either.

Re: [gentoo-portage-dev] [RFC] LTS branch of Portage

[Michael Orlitzky]

On Tue, 2021-10-05 at 10:31 +0200, Michał Górny wrote:
> Hi, everyone.
> 
> I've been thinking about this for some time already, and the recent
> FILESDIR mess seems to confirm it: I'd like to start a more stable LTS
> branch of Portage.
> 

I think this is healthy for most software projects, but two things
stand out to me for portage specifically:

  1. Most portage users can fake this already by telling portage to 
 accept only stable keywords for sys-apps/portage. I know it's not 
 exactly the same, but it provides many of the same benefits.

  2. What happens to the LTS branch when the next EAPI is released?

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

[Michael Orlitzky]

On Mon, 2021-09-27 at 15:44 -0400, Mike Gilbert wrote:
> 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?
> 

There is a distro/Kconfig in gentoo-sources with,

  config GENTOO_LINUX
bool "Gentoo Linux support"
...

that could be extended to include a set of assumed features; otherwise
a sub-setting (default enabled) could be added.

Re: [gentoo-dev] [PATCH 02/44] apache-module.eclass: Set @PROVIDES

[Michael Orlitzky]

On Thu, 2021-09-02 at 14:58 +0200, Michał Górny wrote:
> > 
> Apparently, need_apache* is the problem.  Most of the ebuilds in www-
> apache/* are calling it:
> 

The apache-module eclass tells you to do that because it needs some of
those APACHE_* paths. It should really be figuring them out itself
rather than telling the user to call a function that does it in global
scope. It's an easy fix:

  APXS=apxs
  APACHE_MODULESDIR=$(apxs -q libexecdir)
  APACHE_MODULES_CONFDIR=$(apxs -q sysconfdir)/modules.d
  APACHE_VHOSTS_CONFDIR=$(apxs -q sysconfdir)/vhosts.d

On the one hand, we probably don't want ebuild maintainers trying to
solve that themselves when the eclass could do it. But for whatever
such a promise is worth, it also feels wrong to promise that apache-
module will provide all of depend.apache -- what if we someday apply
the fix above to apache-module and want to drop the depend.apache
inherit?

If we do ever update apache-module, updating ebuilds and retiring
depend.apache would be a lot easier if you could find the candidates
with `git grep depend.apache`, rather than having to look through all
consumers of apache-module for implicit uses of depend.apache.

Re: [gentoo-dev] [PATCH 02/44] apache-module.eclass: Set @PROVIDES

[Michael Orlitzky]

On Thu, 2021-09-02 at 12:46 +0200, Michał Górny wrote:
> Signed-off-by: Michał Górny 
> ---
>  eclass/apache-module.eclass | 1 +
>  1 file changed, 1 insertion(+)
> ...
>  # @SUPPORTED_EAPIS: 5 6 7
> +# @PROVIDES: depend.apache

I'm not sure about this one. The depend.apache eclass is junk and we
should be encouraging people to move away from it (bug 616612):

  * If you want to depend on apache, depend on apache.

  * If you need paths like APACHE_MODULESDIR, the "apxs" tool is now
in PATH so you can get it from $(apxs -q libexecdir)

  * If you need paths like APACHE_MODULES_CONFDIR, the eclass doesn't 
work anyway. You can hard-code those paths yourself (relative to
apxs -q sysconfdir), or if anyone feels up to the task, they could
write a greatly simplified apache-paths.eclass that provides these
paths via functions that are to be called outside of global scope.

If people are using anything in depend.apache, I think a warning is
appropriate. Making a promise that apache-module (which is not junk)
provides depend.apache will moreover make it harder to disentangle them
in the future if anyone decides to fix things.

Disclaimer: I'm not the apache maintainer.

[gentoo-dev] Infra support for mail submission with implicit TLS on port 465

[Michael Orlitzky]

There have been some attacks on STARTTLS lately, so I'm finally getting
around to using implicit TLS for mail submission on port 465.

I tried this on dev.gentoo.org, and it seems to work. For example: I
just switched Evolution to port 465, with always-on TLS, and am sending
this message.

Is this supported? I don't see it in the infra docs anywhere.

Re: [gentoo-dev] [PATCH 2/3] qmail.eclass: remove magic to query root group

[Michael Orlitzky]

On Thu, 2021-08-12 at 17:22 +0200, Rolf Eike Beer wrote:
> The default owner is root:root anyway.
> 

This is only true of you don't call insopts earlier with some other
value. I see "insopts -o root -g qmail -m 700" in there so you might
want to double check.

Re: [gentoo-dev] [PATCH] eclass/postgres.eclass: migrate to GLEP 81

[Michael Orlitzky]

On Fri, 2021-07-23 at 00:20 +0200, Conrad Kostecki wrote:
> This update drops the function 'postgres_new_user', which was used to
> create the 'postgres' user and group.
> 
> ...
> 
> Since many other packages depend on the 'postgres' and 'postgres-multi'
> eclass, adding the core acct-*/postgres packages here to [R]DEPEND.

Not all packages using the eclass necessarily need the "postgres"
user/group to build/run. You should only add (R)DEPEND in the packages
that actually call postgres_new_user, I think?


> 
> Before merging this eclass patch, acct-* packages will be added to
> the tree.

Before doing this, please double-check that SHELL=/bin/bash and
HOME=/var/lib/postgres are needed. It's likely that the default HOME
can be used, and that dev-db/postgresql (which actually *uses*
/var/lib/postgres) should control its permissions.

You should also get an ACK from titanofold, since he's been maintaining
postgresql essentially by himself forever (and may have some insight
into the SHELL/HOME items).

Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

[Michael Orlitzky]

On Mon, 2021-07-12 at 10:46 -0500, Ben Kohler wrote:
> 
> Nobody is "disabling choice" here, a change in defaults doesn't remove 
> your ability to choose something else.

I think what you're suggesting is that default-on is not any worse for
choice than default-off, since both can be changed?

Consider the one legitimate example given: sys-apps/kmod. How can we
disable lzma for everything except packages that have +lzma defaulted?
(Ignoring the open pull request, that is usually done for a good
reason.) In other words, how do people undo this patch, without
potentially breaking their systems?

I hesitate to speak for anyone else, but all I personally want is to be
reasonably sure what my configurations are going to do without having
to list every individual package and USE flag explicitly. I don't think
it's written in stone anywhere, but the repo relies on the fact that
USE flags are disabled by default. As a result, it's much easier for
users to add things to USE than it is to remove them.

If we assume that most IUSE default-ons exist for a good reason
(roughly true), then you can imagine two groups of people.

Person 1: wants everything enabled by default.
Person 2: wants only important things (determined by chosen profile and
IUSE defaults) enabled by default.

Before the patch,

Person 1: adds USE="bzip2 lzma zstd" to make.conf. Requires no ongoing
maintenance.
Person 2: does nothing.

After the patch,

Person 1: does nothing.
Person 2: lists a hundred different packages in all of his package.use
files, after checking each of them to see which ones have important
IUSE defaults. Requires ongoing maintenance as new packages are added.

We've kept things the same level of difficulty for one group of people,
but made them much harder for another. In no situation can anyone who
wants everything enabled have a harder time than 'adds USE="bzip2 lzma
zstd" to make.conf', but everyone else suffers to some degree. That's
discouraging choice overall.

Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item

[Michael Orlitzky]

On Sun, 2021-07-11 at 15:53 +0200, Thomas Deutschmann wrote:
> 
> Furthermore, tmpfiles.d settings are only supposed for creation, 
> deletion and cleaning of volatile and temporary files. Any package which
> will install tmpfiles.d settings which will create files in persistent 
> locations should be treated like a bug in the package itself (for Gentoo
> packagers for example we have keepdir [3] function).

Not crucial to your main point, but packages that use keepdir under
/var/cache (which is persistent) get prodded to use tmpfiles instead:

  https://bugs.gentoo.org/692736

Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

[Michael Orlitzky]

On Fri, 2021-07-09 at 12:05 +0200, Ulrich Mueller wrote:
> > > > > > 
> 
> Sorry, but that doesn't make sense. These are global USE flags, and
> the aim here is to set a _global_ default for them, based on the fact
> that these libraries are present on every Gentoo system.
> 
> So if we agree that e.g. zlib should be on by default, then this
> belongs
> in profiles.

We don't agree that it belongs on by default. And I never said they
shouldn't be enabled in a profile. I said they shouldn't be enabled in
the BASE profile. If you enable them in, say, the desktop profile that
I have the option of not using, I'm fine with that.

Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

[Michael Orlitzky]

On Thu, 2021-07-08 at 13:17 -0700, Matt Turner wrote:
> 
> I hear you, and I appreciate the theoretical concerns.
> 
> I could maybe even support this position if you were actively working
> towards this new and glorious future, but the only time I hear
> anything about it is when you're arguing that someone else should do
> something the way you want.

I've spent a great deal of time in the past moving flags from the base
profiles into package defaults. Not that I see what that has to do with
anything. I'm not arguing that you should do things the way I want
except insofar as I'd prefer you to choose the way of doing things that
has all of the benefits for you and none of the downsides for the rest
of us.


> > 
> > I don't have them enabled for any packages where they're not IUSE-
> > defaulted, and haven't noticed any problems. Not not having a reason to
> > do something isn't a good justification to do it. If it ain't broke and
> > all that. If anyone wants them set, it's as easy as USE="lzma bzip2
> > zstd", and we are apparently all okay without them.
> 
> Well, you're okay without them until you need them: E.g., enable
> CONFIG_MODULE_COMPRESS / MODULE_COMPRESS_XZ without knowing that you
> need sys-apps/kmod[lzma] and your system becomes unbootable.
> 
> But you're of course right that some die-hards might rather accept
> this risk and save the 8 KiB of disk space (424 KiB → 436 KiB) they'd
> lose out on by enabling USE=lzma for the package. But the good news
> is.. they still can!

No, this is a great case for the package default. Save some people a
headache, and include the batteries for kmod. I'll disable that one
manually if I know what I'm doing. But, the kmod situation is not a
good reason to enable lzma support in FFmpeg.

Given the above, it is maybe not surprising that sys-apps/kmod already
has IUSE="+lzma +zlib".


> 
> > But, if you really look, I think you'll find that most of these flags
> > do completely useless things. Do you REALLY need libpcre to build and
> > install you a special executable called "pcregrep-libbz2" that just
> > pipes bunzip2 to pcregrep? No, nobody does. And most other uses are
> > comparably stupid.
> 
> I mean, you could make that argument for bzless or any other version
> of these tools. I don't find that compelling.

You don't find it compelling that changing the default globally has no
additional benefits but a bunch of negative side effects? I *am* making
that argument about all of the other tools. The bzip2/lzma/zstd support
is mostly junk and should not be enabled by default, especially not
globally. (If individual maintainers want to enable junk features by
default, there's not much I can do except point out how unusually
difficult it is to override.)




> Maybe you'd like to audit the compression USE flags and make
> recommendations for which you think do completely useless things? I
> can pretty easily replace this patch with a set of
> automatically-generated patches that enable these USE flags by default
> for all packages but on a per-package basis.

You're the one trying to do something here but you haven't really said
what yet. No, I don't want to spend hours reverse engineering what
you're trying to accomplish when you could just tell us. Which packages
do you think need these flags on by default, and why? If their
maintainers agree, you don't need anyone else's approval.

Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

[Michael Orlitzky]

On Thu, 2021-07-08 at 11:15 -0700, Matt Turner wrote:
> 
> So, the thing about running a minimal system is... you already have
> these dependencies installed. This doesn't change that...
> 
> I could of course change the default of every bzip2/lzma/zstd in IUSE
> (and might as well handle zlib too so we can remove it from
> make.defaults!) but what practical advantage does that bring?

There's more to being a dependency than just being installed. Not all
of these packages have e.g. USE=zstd so that they can run
/usr/bin/zstd. Some link against libzstd, which now bloats them to use
a tiny bit more space and memory, as well as exposing you to any
security problems in the library. Your dependency tree gets a little
bit more complicated, and your package manager has to figure out how to
do subslot rebuilds for everything when libzstd gets upgraded.

Per-package defaults are easier to override, since I don't have to undo
everything before setting the USE-flags that I wanted to enable in the
first place.

Per-package defaults are easier to revert if we change our collective
minds later, since we don't have to test the entire tree for breakage
first.

Global flags have essentially undefined behaviour, since e.g. USE=bzip2
does different things for each package. As an extreme example, global
flags affect packages that aren't even in the tree yet and that may use
USE=bzip2 in a way you don't expect. As a less extreme example,
USE=bzip2 may open your crypto library up to compression attacks. It
definitely makes your dev-lang/php more vulnerable. (The same goes for
USE=zlib, which should be removed in favor of per-package defaults.)

Global flag settings increase complexity because they all interact with
each other, creating a combinatorial explosion of interaction points.
Figuring out how to turn a global flag off for a subset of packages can
be a nightmare. Do you change the file where it's enabled? Or the arch
profile where the enabling is reverted? Or the arch/desktop profile
where the disabling is disabled? Or the hardened profile where the
disabled disabling is disabled? Any argument against global variables
in a program is an argument against global profile changes.


> I doubt there's a sensible reason to build without any of these USE
> flags enabled. I think the claim that most people will want them
> enabled is not really a question. So we should enable them by default.
> I think that logic is pretty straightforward. If someone wants to
> disable the flags for some reason, they of course still have that
> option.
> 
> If you can find a case where you wouldn't want to enable one of these
> USE flags, please let me know and I'll reconsider my position.
> 

I don't have them enabled for any packages where they're not IUSE-
defaulted, and haven't noticed any problems. Not not having a reason to
do something isn't a good justification to do it. If it ain't broke and
all that. If anyone wants them set, it's as easy as USE="lzma bzip2
zstd", and we are apparently all okay without them.

If you have a good reason to do it for certain packages, setting per-
package defaults is the way to do it. The base profile defaults are
only there because we didn't always have per-package defaults.

But, if you really look, I think you'll find that most of these flags
do completely useless things. Do you REALLY need libpcre to build and
install you a special executable called "pcregrep-libbz2" that just
pipes bunzip2 to pcregrep? No, nobody does. And most other uses are
comparably stupid.

Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

[Michael Orlitzky]

On Thu, 2021-07-08 at 07:19 -0500, Ben Kohler wrote:
> On 7/8/21 6:54 AM, Michael Orlitzky wrote:
> > On Wed, 2021-07-07 at 22:01 -0700, Matt Turner wrote:
> > > Enable these flags by default, since they effectively add no additional
> > > dependencies:
> > Why? This list should be getting smaller, not larger.
> 
> That's a valid opinion/viewpoint, but it's not a fact.
> 
> 

It is a fact. If you want to enable these features by default in some
packages (WHY?), there are better ways to do that now. Adding global
defaults into the profiles is sloppy and should be avoided.

Re: [gentoo-dev] Declare the type of source

[Michael Orlitzky]

On Mon, 2021-06-28 at 16:52 +0200, Michał Górny wrote:
> > 
> > This is long overdue, for many reasons, but in particular it would
> > force us to declare a dependency on a C compiler if one is needed and
> > allow you to re-test only those packages that use a C compiler.
> > 
> 
> Which C compiler?  The one I have in CC for the package in question, or
> the one selected via gcc-config, or any random C compiler that might not
> be used at all?  Does that mean that if clang is pulled via depgraph,
> Portage will insist on depcleaning gcc by default?
> 

If the package declares a dependency on e.g. virtual/c-compiler, ago
would want to re-test it whenever a new version of any compiler is
released that satisfies virtual/c-compiler. Conversely, if the package
doesn't require virtual/c-compiler, we may assume that it doesn't
compile C code, and is not affected by the new version.

I know switching toolchains is a mess at the moment, but independently
adding (correct) dependency information should make many things easier
without harming anything else. The precise nature of the dependencies
would of course need some thought.

Re: [gentoo-dev] Declare the type of source

[Michael Orlitzky]

On Mon, 2021-06-28 at 16:31 +0200, Gerion Entrup wrote:
> 
> This should only build, if _all_ build dependencies are present
> (including every compiler and base system tool). Of course, it needs a
> bigger rework of the portage build process.

We had a GSoC project that aimed to do something like this back in
2011:

  https://gitweb.gentoo.org/proj/autodep.git/

At this point, we'd be starting over from scratch, but in short: it's a
good idea. Filling out the list of dependencies should be boring and
fool-proof.

Re: [gentoo-dev] Declare the type of source

[Michael Orlitzky]

On Mon, 2021-06-28 at 15:00 +0200, Agostino Sarubbo wrote:
> 
> Instead, imagine that each ebuild declares a variable called SOURCETYPE ( or 
> similar, or in metadata.xml if you prefer ) and with a tool like equery/eix 
> we 
> are able to get the list of all packages that compiles C code.
> 

I think all you are really asking for is that we stop omitting a random
subset of @system from *DEPEND.

This is long overdue, for many reasons, but in particular it would
force us to declare a dependency on a C compiler if one is needed and
allow you to re-test only those packages that use a C compiler.

Re: [gentoo-dev] [PATCH] qmail.eclass: simplify is_prime()

[Michael Orlitzky]

> 
> This depends on the actual domain of numbers. If the primes involved
> have 20 digits as in your example, then factor should be used of course.
> 
> I suspect though that we're talking about small numbers (below 100?)
> here, in which case a solution in pure bash would be preferable.
> 

If so, we could just list them all.

Re: [gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)

[Michael Orlitzky]

On Sat, 2021-04-10 at 00:32 +0100, Sam James wrote:
> 
> 
> Yes, this is the part I find difficult too. The important
> distinction here was *bootstrapping* (which I missed)
> but I think at least we should make a list of packages generally considered
> critical for bootstrap.
> 

What is a bootstrap package?

There is some chicken-and-egg problem to be solved, but I don't think
that we should be assuming that e.g. GNU grep is always present just
because, during the base case of some recursive process, POSIX grep
must be available temporarily.

Anyway, https://bugs.gentoo.org/485356 awaits reopening if you make any
progress on this.

Re: [gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)

[Michael Orlitzky]

On Tue, 2021-04-06 at 20:32 +0100, Sam James wrote:
> 
> > 
> > We usually don't add basic tools like grep to dependencies.
> 
> Few points:
> 
> ...

5) There are no clear rules about what @system packages can be left out
of *DEPEND and when, so their presence is wildly inconsistent.