Re: [gentoo-dev] [PATCH v3] mount-boot.eclass: Check if /boot is sane, but don't try to mount it.
> On Sat, 07 Dec 2019, Sergei Trofimovich wrote:
>> # The user wants us to leave things be.
>> -if [[ -n ${DONT_MOUNT_BOOT} ]] ; then
>> +if [[ -n ${I_KNOW_WHAT_I_AM_DOING} ]] ; then
>> return 0
>> fi
> The rest of patch looks ok but I find I_KNOW_WHAT_I_AM_DOING
> proliferation worrying. Having enough eclasses guard things on it I
> don't really know what I am doing :)
> For example developer profile sets it on by default and disables perl
> error checks. I don't think it's intentional.
Oh, I forgot that it is set globally in the developer profile (and I
think that's a stupid idea). Indeed we should use a different variable
then.
> I suggest giving this variable a unique specific name.
Would it be acceptable to leave DONT_MOUNT_BOOT in place? It would have
the advantage that users won't have to update their config.
> And phase out ${I_KNOW_WHAT_I_AM_DOING} uses from tree completely.
That's a separate discussion.
Ulrich
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] cargo.eclass: use verbose cargo invocations
On Friday, December 6, 2019 3:44:38 PM PST Sergei Trofimovich wrote:
> On Fri, 6 Dec 2019 12:09:31 -0800
>
> Georgy Yakovlev wrote:
> > Default output just prints crate name.
> > With -vv we can see all cargo options and rustc args.
> >
> > Signed-off-by: Georgy Yakovlev
> > ---
>
> Looks good!
>
> I had to do an equivalent locally at least a few times.
Pushed!
>
> While at it I also suggest adding equivalent of
> econf's/emake's ${EXTRA_ECONF} and ${EXTRA_EMAKE}
> to allow users to inject arbitrary stuff. For example
> to sneak in '-Z' options globally.
>
> Say, ${CARGO_BUILD_EXTRA}, ${CARGO_INSTALL_EXTRA},
> ${CARGO_TEST_EXTRA}.
>
Yeah, it's on my to-do list for this eclass.
1 question tho, should it come after "$@" or before? Do you use it?
I know cargo can be picky about order and some ebuilds rely on passing params
in phase funcs.
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH v3] mount-boot.eclass: Check if /boot is sane, but don't try to mount it.
On Fri, 06 Dec 2019 16:35:53 +0100
Ulrich Müller wrote:
> # The user wants us to leave things be.
> - if [[ -n ${DONT_MOUNT_BOOT} ]] ; then
> + if [[ -n ${I_KNOW_WHAT_I_AM_DOING} ]] ; then
> return 0
> fi
The rest of patch looks ok but I find I_KNOW_WHAT_I_AM_DOING
proliferation worrying. Having enough eclasses guard things on it I don't
really know what I am doing :)
For example developer profile sets it on by default and disables perl error
checks. I don't think it's intentional.
I suggest giving this variable a unique specific name. And phase out
${I_KNOW_WHAT_I_AM_DOING} uses from tree completely.
--
Sergei
Re: [gentoo-dev] [PATCH] cargo.eclass: use verbose cargo invocations
On Fri, 6 Dec 2019 12:09:31 -0800
Georgy Yakovlev wrote:
> Default output just prints crate name.
> With -vv we can see all cargo options and rustc args.
>
> Signed-off-by: Georgy Yakovlev
> ---
Looks good!
I had to do an equivalent locally at least a few times.
While at it I also suggest adding equivalent of
econf's/emake's ${EXTRA_ECONF} and ${EXTRA_EMAKE}
to allow users to inject arbitrary stuff. For example
to sneak in '-Z' options globally.
Say, ${CARGO_BUILD_EXTRA}, ${CARGO_INSTALL_EXTRA},
${CARGO_TEST_EXTRA}.
> eclass/cargo.eclass | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
> index 5b6d1f050f1..13dd5c355fb 100644
> --- a/eclass/cargo.eclass
> +++ b/eclass/cargo.eclass
> @@ -146,7 +146,7 @@ cargo_src_compile() {
>
> export CARGO_HOME="${ECARGO_HOME}"
>
> - cargo build -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
> + cargo build -vv -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
> || die "cargo build failed"
> }
>
> @@ -156,7 +156,7 @@ cargo_src_compile() {
> cargo_src_install() {
> debug-print-function ${FUNCNAME} "$@"
>
> - cargo install -j $(makeopts_jobs) --root="${ED}/usr" $(usex debug
> --debug "") "$@" \
> + cargo install -vv -j $(makeopts_jobs) --root="${ED}/usr" $(usex debug
> --debug "") "$@" \
> || die "cargo install failed"
> rm -f "${ED}/usr/.crates.toml"
>
> @@ -169,7 +169,7 @@ cargo_src_install() {
> cargo_src_test() {
> debug-print-function ${FUNCNAME} "$@"
>
> - cargo test -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
> + cargo test -vv -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
> || die "cargo test failed"
> }
>
> --
> 2.23.0
>
>
--
Sergei
[gentoo-dev] RFC: UID/GID assignment for net-analyzer/suricata
Hello, I hereby order... no, wait. Let me start over. Seeing as I am now in the process of reviving net-analyzer/suricata in the tree (5.0.0 builds and tests fine for me, there are however a few installation-time QA issues I'd like to take care of before pushing this), I would like to request UID/GID 477 for the Suricata user/group. There is no such user in either Arch or Fedora. Let me know if you have any questions or comments. -- Marecki signature.asc Description: OpenPGP digital signature
[gentoo-portage-dev] [PATCH] emerge: drop FEATURES=distcc-pump support, bug #702146
'distcc' dustributes code generation for preprocessed files.
'pump' distributes preprocessing and code generation of files
and imposes very strict requirement:
"""
Note that distcc's pump-mode assumes that sources files will
not be modified during the lifetime of the include server, so
modifying source files during a build may cause inconsistent
results.
"""
`src_configure()` (where we used to start include server before
this change) almost always violates that requirement.
It is not uncommon to generate more intermediate source files
as a package builds (`bison`, `flex`, child `./configure` calls
from `make`) and thus quite unsafe to use `pump`.
This change drops `FEATURES=distcc-pump` and leaves only
FEATURES=distcc. This way all the proprocessing happens as expected
and only code generation is offloaded.
Closes: https://bugs.gentoo.org/702146
Signed-off-by: Sergei Trofimovich
---
bin/phase-functions.sh | 17 -
lib/_emerge/EbuildPhase.py | 2 +-
lib/portage/const.py | 1 -
3 files changed, 1 insertion(+), 19 deletions(-)
diff --git a/bin/phase-functions.sh b/bin/phase-functions.sh
index 92fcd3929..73f8cee9b 100644
--- a/bin/phase-functions.sh
+++ b/bin/phase-functions.sh
@@ -403,19 +403,6 @@ __dyn_prepare() {
trap - SIGINT SIGQUIT
}
-# @FUNCTION: __start_distcc
-# @DESCRIPTION:
-# Start distcc-pump if necessary.
-__start_distcc() {
- if has distcc $FEATURES && has distcc-pump $FEATURES ; then
- if [[ -z $INCLUDE_SERVER_PORT ]] || [[ ! -w
$INCLUDE_SERVER_PORT ]] ; then
- # adding distcc to PATH repeatedly results in fatal
distcc recursion :)
- eval $(pump --startup | grep -v PATH)
- trap "pump --shutdown >/dev/null" EXIT
- fi
- fi
-}
-
__dyn_configure() {
if [[ -e $PORTAGE_BUILDDIR/.configured ]] ; then
@@ -435,7 +422,6 @@ __dyn_configure() {
fi
trap __abort_configure SIGINT SIGQUIT
- __start_distcc
__ebuild_phase pre_src_configure
@@ -469,7 +455,6 @@ __dyn_compile() {
fi
trap __abort_compile SIGINT SIGQUIT
- __start_distcc
__ebuild_phase pre_src_compile
@@ -493,7 +478,6 @@ __dyn_test() {
fi
trap "__abort_test" SIGINT SIGQUIT
- __start_distcc
if [[ -d ${S} ]]; then
cd "${S}"
@@ -541,7 +525,6 @@ __dyn_install() {
return 0
fi
trap "__abort_install" SIGINT SIGQUIT
- __start_distcc
# Handle setting QA_* based on QA_PREBUILT
# Those variables shouldn't be needed before src_install()
diff --git a/lib/_emerge/EbuildPhase.py b/lib/_emerge/EbuildPhase.py
index 4104cefa7..50e3dd1f4 100644
--- a/lib/_emerge/EbuildPhase.py
+++ b/lib/_emerge/EbuildPhase.py
@@ -49,7 +49,7 @@ class EbuildPhase(CompositeTask):
# FEATURES displayed prior to setup phase
_features_display = (
- "ccache", "compressdebug", "distcc", "distcc-pump", "fakeroot",
+ "ccache", "compressdebug", "distcc", "fakeroot",
"installsources", "keeptemp", "keepwork", "network-sandbox",
"network-sandbox-proxy", "nostrip", "preserve-libs", "sandbox",
"selinux", "sesandbox", "splitdebug", "suidctl", "test",
diff --git a/lib/portage/const.py b/lib/portage/const.py
index 36b33af92..e95039fd5 100644
--- a/lib/portage/const.py
+++ b/lib/portage/const.py
@@ -142,7 +142,6 @@ SUPPORTED_FEATURES = frozenset([
"config-protect-if-modified",
"digest",
"distcc",
- "distcc-pump",
"distlocks",
"downgrade-backup",
"ebuild-locks",
--
2.24.0
Re: [gentoo-dev] unsanctioned python 2.7 crusade
On 06/12/19 20:10, Andreas Sturmlechner wrote: > On Friday, 6 December 2019 20:47:31 CET Thomas Deutschmann wrote: >> On 2019-12-06 17:44, Mike Gilbert wrote: >>> 1. Keep the old version installed. >>> 2. Emit a confusing error message to the user since the use-dependency >>> on dev-python/example[python_targets_python2_7] cannot be resolved >>> with the latest visible version. >> I don't fully understand #2 to be honest but yes, you will be cut off >> from latest version at some point. Same in PHP. > Considering that above statement, I would expect a bit more humility than the > following: > >> Maybe someday one of those responsible will admit that this step was not >> a thoughtful and good decision and promise not to do it that way again >> and I'll get over it. Who knows. :) > Just so we're on the same page, a recent example of what some people > suggesting to keep py27 ad nauseam are asking users to deal with: > > > > # emerge -uDpv @world > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > > Total: 0 packages, Size of downloads: 0 KiB > > WARNING: One or more updates/rebuilds have been skipped due to a dependency > conflict: > > dev-python/sphinx:0 > > (dev-python/sphinx-2.0.1:0/0::gentoo, ebuild scheduled for merge) conflicts > with > >=dev-python/ > sphinx-1.5.3[python_targets_python2_7(-),python_targets_python3_6(-),- > python_single_target_pypy(-),-python_single_target_pypy3(-),- > python_single_target_python2_7(-),-python_single_target_python3_5(-),- > python_single_target_python3_6(-),-python_single_target_python3_7(-)] > required > by (dev-python/sphinxcontrib-websupport-1.1.0:0/0::gentoo, installed) > > > > > dev-python/ > sphinx[python_targets_python2_7(-),python_targets_python3_6(-),- > python_single_target_python2_7(-),-python_single_target_python3_5(-),- > python_single_target_python3_6(-),-python_single_target_python3_7(-)] > required > by (dev-python/cython-0.29.4:0/0::gentoo, installed) > > > > dev-python/ > sphinx[python_targets_python2_7(-),python_targets_python3_6(-),- > python_single_target_python2_7(-),-python_single_target_python3_5(-),- > python_single_target_python3_6(-),-python_single_target_python3_7(-)] > required > by (dev-python/flask-babelex-0.9.3:0/0::gentoo, installed) > > > > dev-python/ > sphinx[python_targets_python2_7(-),python_targets_python3_6(-),- > python_single_target_pypy(-),-python_single_target_pypy3(-),- > python_single_target_python2_7(-),-python_single_target_python3_5(-),- > python_single_target_python3_6(-),-python_single_target_python3_7(-)] > required > by (dev-python/testtools-2.3.0:0/0::gentoo, installed) > > > > > dev-python/ > sphinx[python_targets_python2_7(-),python_targets_python3_6(-),- > python_single_target_pypy(-),-python_single_target_pypy3(-),- > python_single_target_python2_7(-),-python_single_target_python3_5(-),- > python_single_target_python3_6(-),-python_single_target_python3_7(-)] > required > by (dev-python/pytest-runner-4.2:0/0::gentoo, installed) > > > > > dev-python/ > sphinx[python_targets_python2_7(-),python_targets_python3_6(-),- > python_single_target_pypy(-),-python_single_target_pypy3(-),- > python_single_target_python2_7(-),-python_single_target_python3_5(-),- > python_single_target_python3_6(-),-python_single_target_python3_7(-)] > required > by (dev-python/flask-babel-0.11.2-r2:0/0::gentoo, installed) > > > >
Re: [gentoo-dev] unsanctioned python 2.7 crusade
On 2019-12-06 21:10, Andreas Sturmlechner wrote: > Just so we're on the same page, a recent example of what some people > suggesting to keep py27 ad nauseam are asking users to deal with: > [...] > WARNING: One or more updates/rebuilds have been skipped due to a dependency > conflict: Yes, like said, at some point you cannot prevent that. Remember when I bumped libvpx to v1.8.0 and people yelled at me because they are now seeing that message all the time (If you are using gnome you probably know the same msg which triggers for unicode stuff which I am also responsible for) because I bumped that package but not everything supports that version yet? It's just a hint. Not a problem. If you don't understand that hint I can't help. It doesn't force user interaction like a mask do. If you understand the problem, you will locally mask >=libvpx-1.8 and message will go away. And again: If this will really solve problems, why is anyone allowed to take over those package like I did for sabnzbd? If you are right and this is really a problem for Gentoo I shouldn't be allowed to do that. And *then* we would also have a reason to mask :-) -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] unsanctioned python 2.7 crusade
On Friday, 6 December 2019 20:47:31 CET Thomas Deutschmann wrote: > On 2019-12-06 17:44, Mike Gilbert wrote: > > 1. Keep the old version installed. > > 2. Emit a confusing error message to the user since the use-dependency > > on dev-python/example[python_targets_python2_7] cannot be resolved > > with the latest visible version. > > I don't fully understand #2 to be honest but yes, you will be cut off > from latest version at some point. Same in PHP. Considering that above statement, I would expect a bit more humility than the following: > Maybe someday one of those responsible will admit that this step was not > a thoughtful and good decision and promise not to do it that way again > and I'll get over it. Who knows. :) Just so we're on the same page, a recent example of what some people suggesting to keep py27 ad nauseam are asking users to deal with: # emerge -uDpv @world These are the packages that would be merged, in order: Calculating dependencies... done! Total: 0 packages, Size of downloads: 0 KiB WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict: dev-python/sphinx:0 (dev-python/sphinx-2.0.1:0/0::gentoo, ebuild scheduled for merge) conflicts with >=dev-python/ sphinx-1.5.3[python_targets_python2_7(-),python_targets_python3_6(-),- python_single_target_pypy(-),-python_single_target_pypy3(-),- python_single_target_python2_7(-),-python_single_target_python3_5(-),- python_single_target_python3_6(-),-python_single_target_python3_7(-)] required by (dev-python/sphinxcontrib-websupport-1.1.0:0/0::gentoo, installed) dev-python/ sphinx[python_targets_python2_7(-),python_targets_python3_6(-),- python_single_target_python2_7(-),-python_single_target_python3_5(-),- python_single_target_python3_6(-),-python_single_target_python3_7(-)] required by (dev-python/cython-0.29.4:0/0::gentoo, installed) dev-python/ sphinx[python_targets_python2_7(-),python_targets_python3_6(-),- python_single_target_python2_7(-),-python_single_target_python3_5(-),- python_single_target_python3_6(-),-python_single_target_python3_7(-)] required by (dev-python/flask-babelex-0.9.3:0/0::gentoo, installed) dev-python/ sphinx[python_targets_python2_7(-),python_targets_python3_6(-),- python_single_target_pypy(-),-python_single_target_pypy3(-),- python_single_target_python2_7(-),-python_single_target_python3_5(-),- python_single_target_python3_6(-),-python_single_target_python3_7(-)] required by (dev-python/testtools-2.3.0:0/0::gentoo, installed) dev-python/ sphinx[python_targets_python2_7(-),python_targets_python3_6(-),- python_single_target_pypy(-),-python_single_target_pypy3(-),- python_single_target_python2_7(-),-python_single_target_python3_5(-),- python_single_target_python3_6(-),-python_single_target_python3_7(-)] required by (dev-python/pytest-runner-4.2:0/0::gentoo, installed) dev-python/ sphinx[python_targets_python2_7(-),python_targets_python3_6(-),- python_single_target_pypy(-),-python_single_target_pypy3(-),- python_single_target_python2_7(-),-python_single_target_python3_5(-),- python_single_target_python3_6(-),-python_single_target_python3_7(-)] required by (dev-python/flask-babel-0.11.2-r2:0/0::gentoo, installed) >=dev-python/ sphinx-1.3.1[python_targets_python2_7(-),python_targets_python3_6(-),- python_single_target_python2_7(-),-python_single_target_python3_5(-),-
[gentoo-dev] [PATCH] cargo.eclass: use verbose cargo invocations
Default output just prints crate name.
With -vv we can see all cargo options and rustc args.
Signed-off-by: Georgy Yakovlev
---
eclass/cargo.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 5b6d1f050f1..13dd5c355fb 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -146,7 +146,7 @@ cargo_src_compile() {
export CARGO_HOME="${ECARGO_HOME}"
- cargo build -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
+ cargo build -vv -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
|| die "cargo build failed"
}
@@ -156,7 +156,7 @@ cargo_src_compile() {
cargo_src_install() {
debug-print-function ${FUNCNAME} "$@"
- cargo install -j $(makeopts_jobs) --root="${ED}/usr" $(usex debug
--debug "") "$@" \
+ cargo install -vv -j $(makeopts_jobs) --root="${ED}/usr" $(usex debug
--debug "") "$@" \
|| die "cargo install failed"
rm -f "${ED}/usr/.crates.toml"
@@ -169,7 +169,7 @@ cargo_src_install() {
cargo_src_test() {
debug-print-function ${FUNCNAME} "$@"
- cargo test -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
+ cargo test -vv -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
|| die "cargo test failed"
}
--
2.23.0
Re: [gentoo-dev] unsanctioned python 2.7 crusade
On 2019-12-06 17:44, Mike Gilbert wrote:
> That's going to cause a very confusing user-experience due to
> conflicting PYTHON_TARGETS values on the various packages. It's also
> going to cause users to have old/unsupported/buggy versions of various
> random python packages depending on what set of reverse dependencies
> they happen to have installed.
>
> For example, lets say the next release of dev-python/example drops
> support for python2, and also adds some new features and fixes some
> bugs.
>
> If the user has python2_7 enabled for any reverse dependency of
> dev-python/example, Portage will be forced to do one of two things:
>
> 1. Keep the old version installed.
> 2. Emit a confusing error message to the user since the use-dependency
> on dev-python/example[python_targets_python2_7] cannot be resolved
> with the latest visible version.
I don't fully understand #2 to be honest but yes, you will be cut off
from latest version at some point. Same in PHP.
But from my POV you are trying to find a solution for a non-existent
problem: Keep in mind that *user* is in control of PYTHON_TARGETS
(PHP_TARGETS).
If we expect that our users should simply remove that mask locally
("OMG! It's just a package.mask!") we can assume that same user
understand consequences when sticking to targets not supported by newer
versions anymore.
Also, problem will automatically go away when time passes assuming more
and more packages will no longer have python_targets_python2_7. I.e.
user will automatically migrate to Py3 over time.
I still have no words for this decision breaking working Py 2 *only*
packages 150+ days in advance which don't cause any problems (and aside
USE=test case will never cause problems -- if pytest for example will
become a problem, dropping tests but keeping the package itself is also
an option, just saying).
Especially now that I adopted that package, no problem was really solved
and at some point we will have to discuss test dependencies for example.
So yeah, even after 24h I still think this was a bad decision which
wasn't thought through to the end. An easy solution for a not yet
existing problem. Purely activism in a bad way. :/
> It's also a giant pain in the butt for python maintainers since it
> makes cleaning up old versions very error-prone. This may also be a
> problem if the security team demands we remove it.
We would never do that and you know that. The only thing we would ask
you to do is masking to inform user in case user isn't aware that
package is vulnerable. But more important: In that case you would have
your reason to mask affected dependencies (like PHP project did with PHP
5.6 and consumers).
Maybe someday one of those responsible will admit that this step was not
a thoughtful and good decision and promise not to do it that way again
and I'll get over it. Who knows. :)
--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template
On 12/6/19 11:29 AM, Alexis Ballier wrote: > > Without good integration from the checker it is probably a PITA to > figure out that 23 too If you're reading through your commit log and if you see something wrong, you can $ git rebase -i to do a rebase starting at the one you'd like to fix.
Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template
On 06/12/19 16:28, Mike Gilbert wrote: > On Fri, Dec 6, 2019 at 10:46 AM Michael 'veremitz' Everitt > wrote: >> I hope you're not suggesting a rebase of any sort in gentoo.git, Matt ;) > He's talking about rebasing local commits that haven't yet been > pushed. That's perfectly normal. > Fair .. it was a very tongue-in-cheek remark .. fwiw. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] unsanctioned python 2.7 crusade
On Fri, Dec 6, 2019 at 11:12 AM Thomas Deutschmann wrote: > > On 2019-12-06 16:48, Mike Gilbert wrote: > > It's not quite so simple as you make it sound. There really isn't a > > viable way to defer removal of python2-only packages until we remove > > dev-lang/python:2.7. > > > > An increasing number of python packages are dropping support for > > python2 when upstream releases new versions. When this happens, we > > really need to drop python2 support from all reverse dependencies as > > well. Alternative strategies like slotting or compatibility packages > > are a stopgap at best, and become a problem as soon as bugs are > > reported or security issues pop up. > > > > Ripping out python2 support for all reverse dependencies of a core > > package is rather daunting, and is likely to cause much more of an > > uproar than the recent mask. Aaron is really tackling the low-hanging > > fruit at this point: leaves on the depgraph. > > But what's the problem here? Why do you need to rip out Py2 support? PHP > project is facing a similar situation with PHP 5.6, 7.0 and now 7.1 > becoming EOL. Sure, there are way more Python packages but could you > explain why you can't do the same like we did? I.e. new versions of PHP > PECL extension also dropped support for PHP versions which are EOL. When > we bump these packages we just drop PHP versions which are no longer > able to run these extensions. But we keep at least last version still > supporting PHP version which is/become EOL until we finally get rid of > this PHP version as a whole. For example, a lot of packages are now > masked *with* dev-lang/php:5.6 because Gentoo will finally get rid of > PHP 5.6 which is EOL since 2018-12-31. But we didn't break PHP 5.6 users > by starting to remove PECL extension for this version while > dev-lang/php:5.6 was still a thing... That's going to cause a very confusing user-experience due to conflicting PYTHON_TARGETS values on the various packages. It's also going to cause users to have old/unsupported/buggy versions of various random python packages depending on what set of reverse dependencies they happen to have installed. For example, lets say the next release of dev-python/example drops support for python2, and also adds some new features and fixes some bugs. If the user has python2_7 enabled for any reverse dependency of dev-python/example, Portage will be forced to do one of two things: 1. Keep the old version installed. 2. Emit a confusing error message to the user since the use-dependency on dev-python/example[python_targets_python2_7] cannot be resolved with the latest visible version. Option 1 is bad because the user will be missing out on bug fixes and new features. Option 2 will probably generate some bug reports that we will have to close as CANTFIX. It's also a giant pain in the butt for python maintainers since it makes cleaning up old versions very error-prone. This may also be a problem if the security team demands we remove it.
Re: [gentoo-dev] unsanctioned python 2.7 crusade
On 2019-12-06 17:35, Mart Raudsepp wrote: > I don't see anything wrong with the idea of p.masking it in case it > could be causing problems for others (such as py2). Sure, in *case* it *is* causing problems. ACK. But so far nobody was able to provide any reasons. That's the thing which drives me nuts... -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] unsanctioned python 2.7 crusade
Ühel kenal päeval, R, 06.12.2019 kell 14:06, kirjutas Thomas Deutschmann: > Since when is it acceptable for anyone to remove packages (the > package.mask entry clearly says that this package is scheduled for > removal and suspecting that any *user* will step and contact p-m for > example is naive) without any need? I assume the p.mask entry text wasn't optimal then. For this specific case, sabnzbd had been in maintainer-needed for 3 months already. Unfortunately no "package up for grabs" had been sent for this one when it was dropped to that (previous maintainer dropped maintenance himself). I don't see anything wrong with the idea of p.masking it in case it could be causing problems for others (such as py2). Of course the p.mask entry could apparently have been better, it's sad that no "package up for grabs" happened back then months ago, and it's not nice it was all in a big lump of maintainer-needed packages, python@ packages and packages maintained by completely unaware maintainers with no notification period. Mart signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template
On Fri, Dec 6, 2019 at 10:46 AM Michael 'veremitz' Everitt wrote: > I hope you're not suggesting a rebase of any sort in gentoo.git, Matt ;) He's talking about rebasing local commits that haven't yet been pushed. That's perfectly normal.
Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template
On Fri, 6 Dec 2019 10:41:56 -0500 Matt Turner wrote: > On Fri, Dec 6, 2019 at 5:51 AM Alexis Ballier > wrote: > > > > On Fri, 6 Dec 2019 04:33:36 -0500 > > Tim Harder wrote: > > > > > On 2019-12-06 Fri 04:03, Alexis Ballier wrote: > > > > it's not just like repoman and cvs since repoman commit did > > > > push ;) it will never be perfect but i really like repoman > > > > commit to refuse to even commit if there's something obviously > > > > wrong > > > > > > I'm more of the opinion (and am working towards that practicality > > > in terms of runtime speed) that a subset of QA checks should be > > > run as a git hook which would cause push failures on certain > > > classes of bad commits. > > > > > > There should be both. Amending the 23rd commit message because one > > mistyped a semicolon is kind of a PITA. > > It is? > > git rebase -i HEAD~23 > > Is that what you think is a pain in the ass, or do you not know about > interactive rebase? :) You made me look at the doc and I indeed had never used the reword option ;) got stuck at pick/squash/edit somehow and that's the edit I did consider a PITA yes Without good integration from the checker it is probably a PITA to figure out that 23 too and also still doesn't help for broken commits (not messages) that may or may not trigger later conflicts (unless we decide we don't care about working commits, just working pushes, which WFM)
Re: [gentoo-dev] stable-bot is down. Temporary? Forever? Can we have a contacts page for it?
stable-bot appears to be down again. I've been unsuccessful in reaching kensington on IRC. I think stable-bot has become an integral part of the workflow and as such (1) we should have the code available and (2) we should run it on some hardware that others are able to administer. Can we please?
Re: [gentoo-dev] unsanctioned python 2.7 crusade
On 2019-12-06 16:48, Mike Gilbert wrote: > It's not quite so simple as you make it sound. There really isn't a > viable way to defer removal of python2-only packages until we remove > dev-lang/python:2.7. > > An increasing number of python packages are dropping support for > python2 when upstream releases new versions. When this happens, we > really need to drop python2 support from all reverse dependencies as > well. Alternative strategies like slotting or compatibility packages > are a stopgap at best, and become a problem as soon as bugs are > reported or security issues pop up. > > Ripping out python2 support for all reverse dependencies of a core > package is rather daunting, and is likely to cause much more of an > uproar than the recent mask. Aaron is really tackling the low-hanging > fruit at this point: leaves on the depgraph. But what's the problem here? Why do you need to rip out Py2 support? PHP project is facing a similar situation with PHP 5.6, 7.0 and now 7.1 becoming EOL. Sure, there are way more Python packages but could you explain why you can't do the same like we did? I.e. new versions of PHP PECL extension also dropped support for PHP versions which are EOL. When we bump these packages we just drop PHP versions which are no longer able to run these extensions. But we keep at least last version still supporting PHP version which is/become EOL until we finally get rid of this PHP version as a whole. For example, a lot of packages are now masked *with* dev-lang/php:5.6 because Gentoo will finally get rid of PHP 5.6 which is EOL since 2018-12-31. But we didn't break PHP 5.6 users by starting to remove PECL extension for this version while dev-lang/php:5.6 was still a thing... -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] unsanctioned python 2.7 crusade
On Fri, Dec 6, 2019 at 8:52 AM Rich Freeman wrote: > > On Fri, Dec 6, 2019 at 8:06 AM Thomas Deutschmann wrote: > > > > Sure, if packages don't work anymore or are blocking something, we will > > start last-rite process. But for the sabnzbd example (I haven't looked > > closely on any other package from that list) there isn't anything > > blocking and it's a working piece of software. The only thing which > > stands out is: It's a Py2-only package. > > > > Well, that's simple enough. If the python maintainers intend to > remove python2 then they need to remove anything that depends on it at > the same time. Otherwise all those packages are going to break anyway > and users just end up with a mess of error messages due to a broken > depgraph. > > That said, as I've already commented I think it makes more sense to > mask the reverse dependencies at the same time as masking python2 > itself. It's not quite so simple as you make it sound. There really isn't a viable way to defer removal of python2-only packages until we remove dev-lang/python:2.7. An increasing number of python packages are dropping support for python2 when upstream releases new versions. When this happens, we really need to drop python2 support from all reverse dependencies as well. Alternative strategies like slotting or compatibility packages are a stopgap at best, and become a problem as soon as bugs are reported or security issues pop up. Ripping out python2 support for all reverse dependencies of a core package is rather daunting, and is likely to cause much more of an uproar than the recent mask. Aaron is really tackling the low-hanging fruit at this point: leaves on the depgraph.
Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template
On 06/12/19 15:41, Matt Turner wrote: > On Fri, Dec 6, 2019 at 5:51 AM Alexis Ballier wrote: >> On Fri, 6 Dec 2019 04:33:36 -0500 >> Tim Harder wrote: >> >>> On 2019-12-06 Fri 04:03, Alexis Ballier wrote: it's not just like repoman and cvs since repoman commit did push ;) it will never be perfect but i really like repoman commit to refuse to even commit if there's something obviously wrong >>> I'm more of the opinion (and am working towards that practicality in >>> terms of runtime speed) that a subset of QA checks should be run as a >>> git hook which would cause push failures on certain classes of bad >>> commits. >> >> There should be both. Amending the 23rd commit message because one >> mistyped a semicolon is kind of a PITA. > It is? > > git rebase -i HEAD~23 > > Is that what you think is a pain in the ass, or do you not know about > interactive rebase? :) > I hope you're not suggesting a rebase of any sort in gentoo.git, Matt ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template
On Fri, Dec 6, 2019 at 5:51 AM Alexis Ballier wrote: > > On Fri, 6 Dec 2019 04:33:36 -0500 > Tim Harder wrote: > > > On 2019-12-06 Fri 04:03, Alexis Ballier wrote: > > > it's not just like repoman and cvs since repoman commit did push ;) > > > it will never be perfect but i really like repoman commit to refuse > > > to even commit if there's something obviously wrong > > > > I'm more of the opinion (and am working towards that practicality in > > terms of runtime speed) that a subset of QA checks should be run as a > > git hook which would cause push failures on certain classes of bad > > commits. > > > There should be both. Amending the 23rd commit message because one > mistyped a semicolon is kind of a PITA. It is? git rebase -i HEAD~23 Is that what you think is a pain in the ass, or do you not know about interactive rebase? :)
[gentoo-dev] [PATCH v3] mount-boot.eclass: Check if /boot is sane, but don't try to mount it.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The eclass failed to remount a read-only mounted /boot, because package
collision sanity checks in recent Portage versions prevented it from
reaching pkg_preinst() at all. Furthermore, with the "mount-sandbox"
feature enabled, the mount won't be propagated past pkg_preinst() and
installed files would end up under the (shadowed) mount point.
Therefore don't even attempt to mount /boot ourselves, but error out
if it isn't mounted read/write and ask the user to mount /boot.
Also clean up and simplify. (For example, awk is a grown-up program
which doesn't need any help from egrep or sed. :-)
Closes: https://bugs.gentoo.org/532264
See-also: https://bugs.gentoo.org/274130#c5
Signed-off-by: Ulrich Müller
---
v3: Exit awk commands on first match.
eclass/mount-boot.eclass | 144 +--
1 file changed, 48 insertions(+), 96 deletions(-)
diff --git a/eclass/mount-boot.eclass b/eclass/mount-boot.eclass
index 938df6732f4..a7d8851aa6e 100644
--- a/eclass/mount-boot.eclass
+++ b/eclass/mount-boot.eclass
@@ -1,156 +1,108 @@
-# Copyright 1999-2015 Gentoo Foundation
+# Copyright 1999-2019 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: mount-boot.eclass
# @MAINTAINER:
# base-sys...@gentoo.org
# @BLURB: functions for packages that install files into /boot
# @DESCRIPTION:
# This eclass is really only useful for bootloaders.
#
# If the live system has a separate /boot partition configured, then this
# function tries to ensure that it's mounted in rw mode, exiting with an
-# error if it can't. It does nothing if /boot isn't a separate partition.
+# error if it can't. It does nothing if /boot isn't a separate partition.
+
+case ${EAPI:-0} in
+ 4|5|6|7) ;;
+ *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
+esac
EXPORT_FUNCTIONS pkg_pretend pkg_preinst pkg_postinst pkg_prerm pkg_postrm
# @FUNCTION: mount-boot_disabled
# @INTERNAL
# @DESCRIPTION:
# Detect whether the current environment/build settings are such that we do not
# want to mess with any mounts.
mount-boot_is_disabled() {
- # Since this eclass only deals with /boot, skip things when ROOT is
active.
- if [[ "${ROOT:-/}" != "/" ]] ; then
+ # Since this eclass only deals with /boot, skip things when EROOT is
active.
+ if [[ ${EROOT:-/} != / ]] ; then
return 0
fi
# If we're only building a package, then there's no need to check
things.
- if [[ "${MERGE_TYPE}" == "buildonly" ]] ; then
+ if [[ ${MERGE_TYPE} == buildonly ]] ; then
return 0
fi
# The user wants us to leave things be.
- if [[ -n ${DONT_MOUNT_BOOT} ]] ; then
+ if [[ -n ${I_KNOW_WHAT_I_AM_DOING} ]] ; then
return 0
fi
# OK, we want to handle things ourselves.
return 1
}
# @FUNCTION: mount-boot_check_status
# @INTERNAL
# @DESCRIPTION:
-# Figure out what kind of work we need to do in order to have /boot be sane.
-# Return values are:
-# 0 - Do nothing at all!
-# 1 - It's mounted, but is currently ro, so need to remount rw.
-# 2 - It's not mounted, so need to mount it rw.
+# Check if /boot is sane, i.e., mounted read/write if on a separate
+# partition. Die if conditions are not fulfilled.
mount-boot_check_status() {
# Get out fast if possible.
- mount-boot_is_disabled && return 0
+ mount-boot_is_disabled && return
# note that /dev/BOOT is in the Gentoo default /etc/fstab file
- local fstabstate=$(awk '!/^#|^[[:blank:]]+#|^\/dev\/BOOT/ {print $2}'
/etc/fstab | egrep "^/boot$" )
- local procstate=$(awk '$2 ~ /^\/boot$/ {print $2}' /proc/mounts)
- local proc_ro=$(awk '{ print $2 " ," $4 "," }' /proc/mounts | sed -n
'/^\/boot .*,ro,/p')
-
- if [ -n "${fstabstate}" ] && [ -n "${procstate}" ] ; then
- if [ -n "${proc_ro}" ] ; then
- echo
- einfo "Your boot partition, detected as being mounted
at /boot, is read-only."
- einfo "It will be remounted in read-write mode
temporarily."
- return 1
- else
- echo
- einfo "Your boot partition was detected as being
mounted at /boot."
- einfo "Files will be installed there for ${PN} to
function correctly."
- return 0
- fi
- elif [ -n "${fstabstate}" ] && [ -z "${procstate}" ] ; then
- echo
- einfo "Your boot partition was not mounted at /boot, so it will
be automounted for you."
- einfo "Files will be installed there for ${PN} to function
correctly."
- return 2
- else
- echo
+ local fstabstate=$(awk '!/^[[:blank:]]*#|^\/dev\/BOOT/ && $2 == "/boot"
Re: [gentoo-dev] [PATCH] mount-boot.eclass: Check if /boot is sane, but don't try to mount it.
On Fri, 2019-12-06 at 15:45 +0100, Ulrich Mueller wrote:
> > > + local fstabstate=$(awk '!/^[[:blank:]]*#|^\/dev\/BOOT/ && $2 == "/boot"
> > > \
> > > + {print $2}' /etc/fstab)
> > The 'print' here is used as a boolean... why not use a boolean output
> > instead?
>
> Changed, it's printing a 1 now.
Well, I actually meant using exit status ;-). Would be also have the
benefit of terminating early.
>
> > > + local procstate=$(awk '$2 == "/boot" \
> > > + {print gensub(/^(.*,)?(ro|rw)(,.*)?$/, "\\2", 1, $4)}'
> > > /proc/mounts)
> > Shouldn't this use /proc/self/mounts?
>
> I haven't actually changed this, it was /proc/mounts before (which is a
> symlink to self/mounts). Maybe we should keep it as-is for backwards
> compatibility? (But TBH, I have no idea with which kernel version
> /proc/self/mounts appeared.)
Ok.
>
> > > + mount-boot_check_status
> > > + if ! ( shopt -s failglob; : "${ROOT}"/boot/.keep* ) 2>/dev/null ; then
> > EROOT?
>
> Hm, we mount /boot, not ${EROOT}/boot. I've added an additional test for
> [[ ${EROOT:-/} == / ]] before touching the file.
>
> Patch v2 will follow.
>
Thanks.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH v2] mount-boot.eclass: Check if /boot is sane, but don't try to mount it.
The eclass failed to remount a read-only mounted /boot, because package
collision sanity checks in recent Portage versions prevented it from
reaching pkg_preinst() at all. Furthermore, with the "mount-sandbox"
feature enabled, the mount won't be propagated past pkg_preinst() and
installed files would end up under the (shadowed) mount point.
Therefore don't even attempt to mount /boot ourselves, but error out
if it isn't mounted read/write and ask the user to mount /boot.
Also clean up and simplify. (For example, awk is a grown-up program
which doesn't need any help from egrep or sed. :-)
Closes: https://bugs.gentoo.org/532264
See-also: https://bugs.gentoo.org/274130#c5
Signed-off-by: Ulrich Müller
---
eclass/mount-boot.eclass | 144 +--
1 file changed, 47 insertions(+), 97 deletions(-)
diff --git a/eclass/mount-boot.eclass b/eclass/mount-boot.eclass
index 938df6732f4..8994cf1aa42 100644
--- a/eclass/mount-boot.eclass
+++ b/eclass/mount-boot.eclass
@@ -1,156 +1,106 @@
-# Copyright 1999-2015 Gentoo Foundation
+# Copyright 1999-2019 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: mount-boot.eclass
# @MAINTAINER:
# base-sys...@gentoo.org
# @BLURB: functions for packages that install files into /boot
# @DESCRIPTION:
# This eclass is really only useful for bootloaders.
#
# If the live system has a separate /boot partition configured, then this
# function tries to ensure that it's mounted in rw mode, exiting with an
-# error if it can't. It does nothing if /boot isn't a separate partition.
+# error if it can't. It does nothing if /boot isn't a separate partition.
+
+case ${EAPI:-0} in
+ 4|5|6|7) ;;
+ *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
+esac
EXPORT_FUNCTIONS pkg_pretend pkg_preinst pkg_postinst pkg_prerm pkg_postrm
# @FUNCTION: mount-boot_disabled
# @INTERNAL
# @DESCRIPTION:
# Detect whether the current environment/build settings are such that we do not
# want to mess with any mounts.
mount-boot_is_disabled() {
- # Since this eclass only deals with /boot, skip things when ROOT is
active.
- if [[ "${ROOT:-/}" != "/" ]] ; then
+ # Since this eclass only deals with /boot, skip things when EROOT is
active.
+ if [[ ${EROOT:-/} != / ]] ; then
return 0
fi
# If we're only building a package, then there's no need to check
things.
- if [[ "${MERGE_TYPE}" == "buildonly" ]] ; then
+ if [[ ${MERGE_TYPE} == buildonly ]] ; then
return 0
fi
# The user wants us to leave things be.
- if [[ -n ${DONT_MOUNT_BOOT} ]] ; then
+ if [[ -n ${I_KNOW_WHAT_I_AM_DOING} ]] ; then
return 0
fi
# OK, we want to handle things ourselves.
return 1
}
# @FUNCTION: mount-boot_check_status
# @INTERNAL
# @DESCRIPTION:
-# Figure out what kind of work we need to do in order to have /boot be sane.
-# Return values are:
-# 0 - Do nothing at all!
-# 1 - It's mounted, but is currently ro, so need to remount rw.
-# 2 - It's not mounted, so need to mount it rw.
+# Check if /boot is sane, i.e., mounted read/write if on a separate
+# partition. Die if conditions are not fulfilled.
mount-boot_check_status() {
# Get out fast if possible.
- mount-boot_is_disabled && return 0
+ mount-boot_is_disabled && return
# note that /dev/BOOT is in the Gentoo default /etc/fstab file
- local fstabstate=$(awk '!/^#|^[[:blank:]]+#|^\/dev\/BOOT/ {print $2}'
/etc/fstab | egrep "^/boot$" )
- local procstate=$(awk '$2 ~ /^\/boot$/ {print $2}' /proc/mounts)
- local proc_ro=$(awk '{ print $2 " ," $4 "," }' /proc/mounts | sed -n
'/^\/boot .*,ro,/p')
-
- if [ -n "${fstabstate}" ] && [ -n "${procstate}" ] ; then
- if [ -n "${proc_ro}" ] ; then
- echo
- einfo "Your boot partition, detected as being mounted
at /boot, is read-only."
- einfo "It will be remounted in read-write mode
temporarily."
- return 1
- else
- echo
- einfo "Your boot partition was detected as being
mounted at /boot."
- einfo "Files will be installed there for ${PN} to
function correctly."
- return 0
- fi
- elif [ -n "${fstabstate}" ] && [ -z "${procstate}" ] ; then
- echo
- einfo "Your boot partition was not mounted at /boot, so it will
be automounted for you."
- einfo "Files will be installed there for ${PN} to function
correctly."
- return 2
- else
- echo
+ local fstabstate=$(awk '!/^[[:blank:]]*#|^\/dev\/BOOT/ && $2 == "/boot"
\
+ { print 1 }' /etc/fstab)
+
+ if [[ -z ${fstabstate} ]] ; then
einfo "Assuming you do not
Re: [gentoo-dev] [PATCH] mount-boot.eclass: Check if /boot is sane, but don't try to mount it.
> On Fri, 06 Dec 2019, Michał Górny wrote:
>> reaching pkg_pretend() at all. Furthermore, with the "mount-sandbox"
> Did you mean: pkg_preinst?
Of course.
>> -if [[ "${ROOT:-/}" != "/" ]] ; then
>> +if [[ ${ROOT:-/} != "/" ]] ; then
> I suppose you can unquote RHS too since it doesn't contain any pattern
> characters, if you are already touching quoting.
Quotes dropped (globally).
>> +# Check if /boot is sane, i.e., mounted read/write if on a separate
>> +# partition. Return 0 if conditions are fulfilled, otherwise die.
> I don't think there's a point in explicitly defining the return value
> if there is no alternative.
Fixed.
>> +local fstabstate=$(awk '!/^[[:blank:]]*#|^\/dev\/BOOT/ && $2 == "/boot"
>> \
>> +{print $2}' /etc/fstab)
> The 'print' here is used as a boolean... why not use a boolean output
> instead?
Changed, it's printing a 1 now.
>> +local procstate=$(awk '$2 == "/boot" \
>> +{print gensub(/^(.*,)?(ro|rw)(,.*)?$/, "\\2", 1, $4)}'
>> /proc/mounts)
> Shouldn't this use /proc/self/mounts?
I haven't actually changed this, it was /proc/mounts before (which is a
symlink to self/mounts). Maybe we should keep it as-is for backwards
compatibility? (But TBH, I have no idea with which kernel version
/proc/self/mounts appeared.)
>> +mount-boot_check_status
>> +if ! ( shopt -s failglob; : "${ROOT}"/boot/.keep* ) 2>/dev/null ; then
> EROOT?
Hm, we mount /boot, not ${EROOT}/boot. I've added an additional test for
[[ ${EROOT:-/} == / ]] before touching the file.
Patch v2 will follow.
Ulrich
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] mount-boot.eclass: Check if /boot is sane, but don't try to mount it.
On Fri, 2019-12-06 at 14:11 +0100, Ulrich Müller wrote:
> The eclass failed to remount a read-only mounted /boot, because package
> collision sanity checks in recent Portage versions prevented it from
> reaching pkg_pretend() at all. Furthermore, with the "mount-sandbox"
Did you mean: pkg_preinst?
> feature enabled, the mount won't be propagated past pkg_preinst() and
> installed files would end up under the (shadowed) mount point.
>
> Therefore don't even attempt to mount /boot ourselves, but error out
> if it isn't mounted read/write and ask the user to mount /boot.
>
> Also clean up and simplify. (For example, awk is a grown-up program
> which doesn't need any help from egrep or sed. :-)
>
> Closes: https://bugs.gentoo.org/532264
> Signed-off-by: Ulrich Müller
> ---
> eclass/mount-boot.eclass | 137 ---
> 1 file changed, 43 insertions(+), 94 deletions(-)
>
> diff --git a/eclass/mount-boot.eclass b/eclass/mount-boot.eclass
> index 938df6732f4..1d7eb8bfc29 100644
> --- a/eclass/mount-boot.eclass
> +++ b/eclass/mount-boot.eclass
> @@ -1,156 +1,105 @@
> -# Copyright 1999-2015 Gentoo Foundation
> +# Copyright 1999-2019 Gentoo Authors
> # Distributed under the terms of the GNU General Public License v2
>
> # @ECLASS: mount-boot.eclass
> # @MAINTAINER:
> # base-sys...@gentoo.org
> # @BLURB: functions for packages that install files into /boot
> # @DESCRIPTION:
> # This eclass is really only useful for bootloaders.
> #
> # If the live system has a separate /boot partition configured, then this
> # function tries to ensure that it's mounted in rw mode, exiting with an
> -# error if it can't. It does nothing if /boot isn't a separate partition.
> +# error if it can't. It does nothing if /boot isn't a separate partition.
> +
> +case ${EAPI:-0} in
> + 4|5|6|7) ;;
> + *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
> +esac
>
> EXPORT_FUNCTIONS pkg_pretend pkg_preinst pkg_postinst pkg_prerm pkg_postrm
>
> # @FUNCTION: mount-boot_disabled
> # @INTERNAL
> # @DESCRIPTION:
> # Detect whether the current environment/build settings are such that we do
> not
> # want to mess with any mounts.
> mount-boot_is_disabled() {
> # Since this eclass only deals with /boot, skip things when ROOT is
> active.
> - if [[ "${ROOT:-/}" != "/" ]] ; then
> + if [[ ${ROOT:-/} != "/" ]] ; then
I suppose you can unquote RHS too since it doesn't contain any pattern
characters, if you are already touching quoting.
> return 0
> fi
>
> # If we're only building a package, then there's no need to check
> things.
> - if [[ "${MERGE_TYPE}" == "buildonly" ]] ; then
> + if [[ ${MERGE_TYPE} == "buildonly" ]] ; then
> return 0
> fi
>
> # The user wants us to leave things be.
> - if [[ -n ${DONT_MOUNT_BOOT} ]] ; then
> + if [[ -n ${I_KNOW_WHAT_I_AM_DOING} ]] ; then
> return 0
> fi
>
> # OK, we want to handle things ourselves.
> return 1
> }
>
> # @FUNCTION: mount-boot_check_status
> # @INTERNAL
> # @DESCRIPTION:
> -# Figure out what kind of work we need to do in order to have /boot be sane.
> -# Return values are:
> -# 0 - Do nothing at all!
> -# 1 - It's mounted, but is currently ro, so need to remount rw.
> -# 2 - It's not mounted, so need to mount it rw.
> +# Check if /boot is sane, i.e., mounted read/write if on a separate
> +# partition. Return 0 if conditions are fulfilled, otherwise die.
I don't think there's a point in explicitly defining the return value
if there is no alternative.
> mount-boot_check_status() {
> # Get out fast if possible.
> mount-boot_is_disabled && return 0
>
> # note that /dev/BOOT is in the Gentoo default /etc/fstab file
> - local fstabstate=$(awk '!/^#|^[[:blank:]]+#|^\/dev\/BOOT/ {print $2}'
> /etc/fstab | egrep "^/boot$" )
> - local procstate=$(awk '$2 ~ /^\/boot$/ {print $2}' /proc/mounts)
> - local proc_ro=$(awk '{ print $2 " ," $4 "," }' /proc/mounts | sed -n
> '/^\/boot .*,ro,/p')
> -
> - if [ -n "${fstabstate}" ] && [ -n "${procstate}" ] ; then
> - if [ -n "${proc_ro}" ] ; then
> - echo
> - einfo "Your boot partition, detected as being mounted
> at /boot, is read-only."
> - einfo "It will be remounted in read-write mode
> temporarily."
> - return 1
> - else
> - echo
> - einfo "Your boot partition was detected as being
> mounted at /boot."
> - einfo "Files will be installed there for ${PN} to
> function correctly."
> - return 0
> - fi
> - elif [ -n "${fstabstate}" ] && [ -z "${procstate}" ] ; then
> - echo
> - einfo "Your boot partition was not mounted at /boot, so it will
> be automounted for you."
> - einfo "Files will be
Re: [gentoo-dev] unsanctioned python 2.7 crusade
On Fri, Dec 6, 2019 at 8:06 AM Thomas Deutschmann wrote: > > Sure, if packages don't work anymore or are blocking something, we will > start last-rite process. But for the sabnzbd example (I haven't looked > closely on any other package from that list) there isn't anything > blocking and it's a working piece of software. The only thing which > stands out is: It's a Py2-only package. > Well, that's simple enough. If the python maintainers intend to remove python2 then they need to remove anything that depends on it at the same time. Otherwise all those packages are going to break anyway and users just end up with a mess of error messages due to a broken depgraph. That said, as I've already commented I think it makes more sense to mask the reverse dependencies at the same time as masking python2 itself. And of course for something this big it wouldn't have hurt to announce the plans and what was going to get masked so that mistakes could get caught. Even though it is just a mask it is still a bit disruptive to have packages masked/unmasked because of incorrect identification of reverse/optional deps. Ultimately though it is up to the python2 maintainers to decide when they want to remove it. If others want to step up and replace them as python2 maintainers and they have a reasonable plan for keeping it working that would seem like the approach that would make the most people happy. We can't force people to maintain python2 if they don't want to. -- Rich
[gentoo-dev] [PATCH] mount-boot.eclass: Check if /boot is sane, but don't try to mount it.
The eclass failed to remount a read-only mounted /boot, because package
collision sanity checks in recent Portage versions prevented it from
reaching pkg_pretend() at all. Furthermore, with the "mount-sandbox"
feature enabled, the mount won't be propagated past pkg_preinst() and
installed files would end up under the (shadowed) mount point.
Therefore don't even attempt to mount /boot ourselves, but error out
if it isn't mounted read/write and ask the user to mount /boot.
Also clean up and simplify. (For example, awk is a grown-up program
which doesn't need any help from egrep or sed. :-)
Closes: https://bugs.gentoo.org/532264
Signed-off-by: Ulrich Müller
---
eclass/mount-boot.eclass | 137 ---
1 file changed, 43 insertions(+), 94 deletions(-)
diff --git a/eclass/mount-boot.eclass b/eclass/mount-boot.eclass
index 938df6732f4..1d7eb8bfc29 100644
--- a/eclass/mount-boot.eclass
+++ b/eclass/mount-boot.eclass
@@ -1,156 +1,105 @@
-# Copyright 1999-2015 Gentoo Foundation
+# Copyright 1999-2019 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: mount-boot.eclass
# @MAINTAINER:
# base-sys...@gentoo.org
# @BLURB: functions for packages that install files into /boot
# @DESCRIPTION:
# This eclass is really only useful for bootloaders.
#
# If the live system has a separate /boot partition configured, then this
# function tries to ensure that it's mounted in rw mode, exiting with an
-# error if it can't. It does nothing if /boot isn't a separate partition.
+# error if it can't. It does nothing if /boot isn't a separate partition.
+
+case ${EAPI:-0} in
+ 4|5|6|7) ;;
+ *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
+esac
EXPORT_FUNCTIONS pkg_pretend pkg_preinst pkg_postinst pkg_prerm pkg_postrm
# @FUNCTION: mount-boot_disabled
# @INTERNAL
# @DESCRIPTION:
# Detect whether the current environment/build settings are such that we do not
# want to mess with any mounts.
mount-boot_is_disabled() {
# Since this eclass only deals with /boot, skip things when ROOT is
active.
- if [[ "${ROOT:-/}" != "/" ]] ; then
+ if [[ ${ROOT:-/} != "/" ]] ; then
return 0
fi
# If we're only building a package, then there's no need to check
things.
- if [[ "${MERGE_TYPE}" == "buildonly" ]] ; then
+ if [[ ${MERGE_TYPE} == "buildonly" ]] ; then
return 0
fi
# The user wants us to leave things be.
- if [[ -n ${DONT_MOUNT_BOOT} ]] ; then
+ if [[ -n ${I_KNOW_WHAT_I_AM_DOING} ]] ; then
return 0
fi
# OK, we want to handle things ourselves.
return 1
}
# @FUNCTION: mount-boot_check_status
# @INTERNAL
# @DESCRIPTION:
-# Figure out what kind of work we need to do in order to have /boot be sane.
-# Return values are:
-# 0 - Do nothing at all!
-# 1 - It's mounted, but is currently ro, so need to remount rw.
-# 2 - It's not mounted, so need to mount it rw.
+# Check if /boot is sane, i.e., mounted read/write if on a separate
+# partition. Return 0 if conditions are fulfilled, otherwise die.
mount-boot_check_status() {
# Get out fast if possible.
mount-boot_is_disabled && return 0
# note that /dev/BOOT is in the Gentoo default /etc/fstab file
- local fstabstate=$(awk '!/^#|^[[:blank:]]+#|^\/dev\/BOOT/ {print $2}'
/etc/fstab | egrep "^/boot$" )
- local procstate=$(awk '$2 ~ /^\/boot$/ {print $2}' /proc/mounts)
- local proc_ro=$(awk '{ print $2 " ," $4 "," }' /proc/mounts | sed -n
'/^\/boot .*,ro,/p')
-
- if [ -n "${fstabstate}" ] && [ -n "${procstate}" ] ; then
- if [ -n "${proc_ro}" ] ; then
- echo
- einfo "Your boot partition, detected as being mounted
at /boot, is read-only."
- einfo "It will be remounted in read-write mode
temporarily."
- return 1
- else
- echo
- einfo "Your boot partition was detected as being
mounted at /boot."
- einfo "Files will be installed there for ${PN} to
function correctly."
- return 0
- fi
- elif [ -n "${fstabstate}" ] && [ -z "${procstate}" ] ; then
- echo
- einfo "Your boot partition was not mounted at /boot, so it will
be automounted for you."
- einfo "Files will be installed there for ${PN} to function
correctly."
- return 2
- else
- echo
+ local fstabstate=$(awk '!/^[[:blank:]]*#|^\/dev\/BOOT/ && $2 == "/boot"
\
+ {print $2}' /etc/fstab)
+
+ if [[ -z ${fstabstate} ]] ; then
einfo "Assuming you do not have a separate /boot partition."
return 0
fi
-}
-mount-boot_pkg_pretend() {
- # Get out fast if possible.
-
Re: [gentoo-dev] unsanctioned python 2.7 crusade
Hi, On 2019-12-06 09:11, Mart Raudsepp wrote: > I don't think anyone can have a valid problem with package.mask of some > of the things mentioned (sabnzbd, abcde, etc), because they were indeed > maintainer-needed or sound@ (which David is part of, and is known > crickets territory) or whatnot. I agree with your mail in general but I don't understand this part: Since when is it acceptable for anyone to remove packages (the package.mask entry clearly says that this package is scheduled for removal and suspecting that any *user* will step and contact p-m for example is naive) without any need? Sure, if packages don't work anymore or are blocking something, we will start last-rite process. But for the sabnzbd example (I haven't looked closely on any other package from that list) there isn't anything blocking and it's a working piece of software. The only thing which stands out is: It's a Py2-only package. I am also curious about the maintainer-needed aspect: I understand that Python project doesn't *want* and is also *unable* to maintain all packages dumped to their project just because like everything in Gentoo, the project is understaffed for the amount of work. But what's the solution here? The message everyone saying this is acceptable sends out can be summarized as: In future, when you see a package which you are just using will lose its maintainer, take it before anyone decides 'I have not *any* reason and there is no need but I'll remove it just because I can'. Face it, no single maintainer can keep up with maintaining 30+ packages in good quality. So there's a high chance that package will rot the same way like they are already rotting in former herds (projects). Therefore I appreciate packages *without* set maintainer. Because these packages are sending an important signal: Because they are maintainer-needed, it's OK for anyone to touch them. Assuming we still have the rule "If you touch it and it will break, you have to fix it" that's at least something which *can* work because we still have no system to declare "Yes, I am the maintainer of this package but I am fine with you touching it". -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template
On 2019-12-06 Fri 06:33, Michał Górny wrote: > If you need something convenient to commit, app-portage/mgorny-dev- > scripts has pkgcommit tool which does the only useful part of what > repoman did -- that is, prepends package name to the commit message. > For pre-push checks, I use the following oneliner: > $ pkgcheck scan $(git diff origin --name-only $( | cut -d/ -f1-2 | sort -u); echo $? If you want to shorten that, `pkgcheck scan --commits` internalizes most of that and at some point will be extended to enable profile/eclass checks if it notices any related changes. Tim
Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template
On Fri, 2019-12-06 at 03:23 -0500, Tim Harder wrote: > On 2019-12-05 Thu 17:00, Alexis Ballier wrote: > > > > pkgcheck is mostly used by your CI checks for > > > > producing huge reports, which is nice but addresses a different > > > > problem > > > There is nothing stopping you from running pkgcheck locally. In > > > fact, > > > it should work out of the box these days. If you have any problems, > > > please report them and I'm sure they will be addressed promptly. > > Sure I did that to get reports like what CI does for me now but that's > > always been a different usecase; I wasn't aware pkgcheck had the > > equivalent of repoman commit > > While I dislike contributing more to this off-topic tangent, since I've > fielded this question/request in IRC a few times in the past I figure I > might as well address it again here for the IRC-averse. > > Personally I use pkgcheck as a QA tool and *git* (or another vcs tool) > as a commit tool, just like how I used to use repoman and cvs a long > time ago. I generally dislike when cli tools amalgamate disparate > features that they weren't designed for so no one has been able to > convince me why a tool designed to verify ebuilds and their related > repos should support commit capabilities internally. > > Furthermore, pkgcheck was designed to scale towards scanning multiple > pkgs, custom restrictions, or entire repos while I assume the majority > of repoman usage is run against singular pkgs. In many cases, a > multi-pkg scan doesn't map to a single commit so that functionality > would be pretty useless in those situations. > Exactly. Building a workflow on 'repoman commit' is a horrible waste of time. This in turn causes developers to make worse commits (e.g. by combining a lot of irrelevant changes just to workaround the workflow). It might have been necessary in times of CVS when we had to jump through hoops to commit. It doesn't fit git world anymore. A much better workflow is to commit first, then run pkgcheck on everything affected, then push. It's faster, usually more correct (as it checks the final state of all packages), and more flexible (fixups, anyone?). If you need something convenient to commit, app-portage/mgorny-dev- scripts has pkgcommit tool which does the only useful part of what repoman did -- that is, prepends package name to the commit message. For pre-push checks, I use the following oneliner: $ pkgcheck scan $(git diff origin --name-only $( takes care of it. If people want, I can add it to mgorny-dev-scripts under some fancy name. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template
On Fri, 6 Dec 2019 04:33:36 -0500 Tim Harder wrote: > On 2019-12-06 Fri 04:03, Alexis Ballier wrote: > > it's not just like repoman and cvs since repoman commit did push ;) > > it will never be perfect but i really like repoman commit to refuse > > to even commit if there's something obviously wrong > > I'm more of the opinion (and am working towards that practicality in > terms of runtime speed) that a subset of QA checks should be run as a > git hook which would cause push failures on certain classes of bad > commits. There should be both. Amending the 23rd commit message because one mistyped a semicolon is kind of a PITA. > > as you write below, it's just a matter of checking exit status and > > using git, which can be done by scripting, but the script is > > standard (*) and mandated to be part of the workflow > > > it also allows to check or templatize commit messages to follow > > policy > > Technically pkgcheck supports more git-related checks than repoman > last I checked, i.e. result keywords including BadCommitSummary, > DirectStableKeywords, DroppedUnstableKeywords, DroppedStableKeywords, > DirectNoMaintainer, and MissingSignOff; with possible future additions > such as warning when modifying deps in an ebuild without revbumping. > > Futhermore, one can scan against all commits in parallel via `pkgcheck > scan --commits` which will enable potential commit results that are > otherwise skipped. All this seems post-commit, not pre-commit. > Anyway, my main point is that if someone really wants commit > functionality it's semi-trivial to script something similar to what > repoman does (assuming exit status/api support exists) and if it's > decent enough quality (including tests) I'd probably consider adding > it to the pkgcheck repo. It doesn't necessarily have to live in the pkgcheck repo, but it should definitely not be "meh, script it yourself, it's trivial" since that will probably lead to several scripts with varying degrees of quality and brokeness.
Re: [gentoo-dev] unsanctioned python 2.7 crusade
On Fri, 2019-12-06 at 10:11 +0200, Mart Raudsepp wrote: > Ühel kenal päeval, N, 05.12.2019 kell 23:23, kirjutas David Seifert: > > When we started removing Qt4, tons of code still used it. To put > > things > > in perspective: > > > > grep -rl 'IUSE.*python_targets_python2_7' > > /usr/portage/metadata/md5- > > cache/ | wc -l > > > > gives me 7070 ebuilds currently. 7070 is easily more than one and > > closer to two orders of magnitude more ebuilds using python 2 than > > Qt4 > > back in the days. > > You are dramatizing things too much on purpose here. That gives you a > list of almost all PYTHON_COMPAT packages, the majority of which > support python3 already, and will happily continue working after the > user drops python2_7 from PYTHON_TARGETS or it gets dropped from the > _PYTHON_ALL_IMPLS list in python-utils-r1.eclass. Dramatizing that a significant portion of those need to be checked? Are you going to be doing that work? Are you going to check that the depgraph is valid? This is unlike py3.6 -> py3.7, where you just disable the impl in python-utils and stuff keeps working. This is going to trigger an avalanche. > > > Removing maintainer-needed and other semi-dead > > packages is part of a proactive strategy in continuously removing > > and > > treecleaning stale stuff from the tree. > > That's the problem right here. The mask included packages that are > not > maintainer-needed, nor maintained by python@ or other projects you or > Aaron are active members of. And it was a careless mask, masking even > some things that aren't even affected, merely had python2 mentioned > in > some commented out stuff, afaiu. > > I don't think there would be such a huge outcry if this was done > right > - involving the actual maintainers of these packages, not just going > ahead and package.masking them from under them 150+ days ahead of > time > of actual upstream python2 last release. Presumably most of these > maintainers would already know whether the package is in the progress > of being ported upstream (and just needs probably less than 120 days > to > complete that work and make a release), or know that it's dead and go > away. Or they don't respond, and you can p.mask them on a maintainer > honoring timeout. All the examples people name (abcde, eyeD3) are either maintained by sound, for which I gave Aaron an explicit sign-off, or they're m-n. This really boils down to what Rich called "somebody should maintain it, but it's not going to be me". The best example is probably sabnzbd, which people want, but don't want to maintain. > > As this was done is completely unacceptable. Honor your fellow > maintainers and don't trample over them like this. We already are in > a > lack of manpower, don't chase more away by trying to take the easy > route and doing stuff like this without involving them via a tracker > bug or other proper ways. > If you don't maintain a package, you get to work with the maintainer, > not do as you please without involving them at all. I am not aware of > QA having such blanket authority either for such a case. > > > I don't think anyone can have a valid problem with package.mask of > some > of the things mentioned (sabnzbd, abcde, etc), because they were > indeed > maintainer-needed or sound@ (which David is part of, and is known > crickets territory) or whatnot. It seems to have found interested > maintainers, as is normal with last-rite type of package.masks. > But by including things that are actually maintained, without any > apparent involvement of those maintainers, you allow for such outcry > even for things that shouldn't be a problem, because you display ill > intent and dishonoring towards your fellow maintainers. > > Honor your fellow Gentoo maintainers. Period. > > > Mart
Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template
On 2019-12-06 Fri 04:03, Alexis Ballier wrote: > it's not just like repoman and cvs since repoman commit did push ;) > it will never be perfect but i really like repoman commit to refuse to > even commit if there's something obviously wrong I'm more of the opinion (and am working towards that practicality in terms of runtime speed) that a subset of QA checks should be run as a git hook which would cause push failures on certain classes of bad commits. > as you write below, it's just a matter of checking exit status and > using git, which can be done by scripting, but the script is standard > (*) and mandated to be part of the workflow > it also allows to check or templatize commit messages to follow policy Technically pkgcheck supports more git-related checks than repoman last I checked, i.e. result keywords including BadCommitSummary, DirectStableKeywords, DroppedUnstableKeywords, DroppedStableKeywords, DirectNoMaintainer, and MissingSignOff; with possible future additions such as warning when modifying deps in an ebuild without revbumping. Futhermore, one can scan against all commits in parallel via `pkgcheck scan --commits` which will enable potential commit results that are otherwise skipped. Anyway, my main point is that if someone really wants commit functionality it's semi-trivial to script something similar to what repoman does (assuming exit status/api support exists) and if it's decent enough quality (including tests) I'd probably consider adding it to the pkgcheck repo. Tim
Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template
On Fri, 2019-12-06 at 03:23 -0500, Tim Harder wrote: > On 2019-12-05 Thu 17:00, Alexis Ballier wrote: > > > > pkgcheck is mostly used by your CI checks for > > > > producing huge reports, which is nice but addresses a different > > > > problem > > > There is nothing stopping you from running pkgcheck locally. In > > > fact, > > > it should work out of the box these days. If you have any > > > problems, > > > please report them and I'm sure they will be addressed promptly. > > Sure I did that to get reports like what CI does for me now but > > that's > > always been a different usecase; I wasn't aware pkgcheck had the > > equivalent of repoman commit > > While I dislike contributing more to this off-topic tangent, since > I've > fielded this question/request in IRC a few times in the past I figure > I > might as well address it again here for the IRC-averse. > > Personally I use pkgcheck as a QA tool and *git* (or another vcs > tool) > as a commit tool, just like how I used to use repoman and cvs a long > time ago. I generally dislike when cli tools amalgamate disparate > features that they weren't designed for so no one has been able to > convince me why a tool designed to verify ebuilds and their related > repos should support commit capabilities internally. it's not just like repoman and cvs since repoman commit did push ;) it will never be perfect but i really like repoman commit to refuse to even commit if there's something obviously wrong as you write below, it's just a matter of checking exit status and using git, which can be done by scripting, but the script is standard (*) and mandated to be part of the workflow it also allows to check or templatize commit messages to follow policy (*) and force the use of some handy git options like only commit paths starting from cwd even if other files had been git added, which i never remember what is the git cli option for this Alexis.
Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template
On 2019-12-05 Thu 17:00, Alexis Ballier wrote: > > > pkgcheck is mostly used by your CI checks for > > > producing huge reports, which is nice but addresses a different > > > problem > > There is nothing stopping you from running pkgcheck locally. In > > fact, > > it should work out of the box these days. If you have any problems, > > please report them and I'm sure they will be addressed promptly. > Sure I did that to get reports like what CI does for me now but that's > always been a different usecase; I wasn't aware pkgcheck had the > equivalent of repoman commit While I dislike contributing more to this off-topic tangent, since I've fielded this question/request in IRC a few times in the past I figure I might as well address it again here for the IRC-averse. Personally I use pkgcheck as a QA tool and *git* (or another vcs tool) as a commit tool, just like how I used to use repoman and cvs a long time ago. I generally dislike when cli tools amalgamate disparate features that they weren't designed for so no one has been able to convince me why a tool designed to verify ebuilds and their related repos should support commit capabilities internally. Furthermore, pkgcheck was designed to scale towards scanning multiple pkgs, custom restrictions, or entire repos while I assume the majority of repoman usage is run against singular pkgs. In many cases, a multi-pkg scan doesn't map to a single commit so that functionality would be pretty useless in those situations. To aid those who believe this commit functionality necessary, I've mentioned I would support improving API access and/or configurable exit status settings allowing for easier pkgcheck scripting or other types of external usage. Tim
Re: [gentoo-dev] unsanctioned python 2.7 crusade
Ühel kenal päeval, N, 05.12.2019 kell 23:23, kirjutas David Seifert: > When we started removing Qt4, tons of code still used it. To put > things > in perspective: > > grep -rl 'IUSE.*python_targets_python2_7' /usr/portage/metadata/md5- > cache/ | wc -l > > gives me 7070 ebuilds currently. 7070 is easily more than one and > closer to two orders of magnitude more ebuilds using python 2 than > Qt4 > back in the days. You are dramatizing things too much on purpose here. That gives you a list of almost all PYTHON_COMPAT packages, the majority of which support python3 already, and will happily continue working after the user drops python2_7 from PYTHON_TARGETS or it gets dropped from the _PYTHON_ALL_IMPLS list in python-utils-r1.eclass. > Removing maintainer-needed and other semi-dead > packages is part of a proactive strategy in continuously removing and > treecleaning stale stuff from the tree. That's the problem right here. The mask included packages that are not maintainer-needed, nor maintained by python@ or other projects you or Aaron are active members of. And it was a careless mask, masking even some things that aren't even affected, merely had python2 mentioned in some commented out stuff, afaiu. I don't think there would be such a huge outcry if this was done right - involving the actual maintainers of these packages, not just going ahead and package.masking them from under them 150+ days ahead of time of actual upstream python2 last release. Presumably most of these maintainers would already know whether the package is in the progress of being ported upstream (and just needs probably less than 120 days to complete that work and make a release), or know that it's dead and go away. Or they don't respond, and you can p.mask them on a maintainer honoring timeout. As this was done is completely unacceptable. Honor your fellow maintainers and don't trample over them like this. We already are in a lack of manpower, don't chase more away by trying to take the easy route and doing stuff like this without involving them via a tracker bug or other proper ways. If you don't maintain a package, you get to work with the maintainer, not do as you please without involving them at all. I am not aware of QA having such blanket authority either for such a case. I don't think anyone can have a valid problem with package.mask of some of the things mentioned (sabnzbd, abcde, etc), because they were indeed maintainer-needed or sound@ (which David is part of, and is known crickets territory) or whatnot. It seems to have found interested maintainers, as is normal with last-rite type of package.masks. But by including things that are actually maintained, without any apparent involvement of those maintainers, you allow for such outcry even for things that shouldn't be a problem, because you display ill intent and dishonoring towards your fellow maintainers. Honor your fellow Gentoo maintainers. Period. Mart signature.asc Description: This is a digitally signed message part
