[gentoo-dev] [PATCH v2] 2022-05-14-apache-nginx-glep-81: add news
Signed-off-by: Conrad Kostecki --- .../2022-05-14-apache-nginx-glep-81.en.txt| 36 +++ 1 file changed, 36 insertions(+) create mode 100644 2022-05-14-apache-nginx-glep-81/2022-05-14-apache-nginx-glep-81.en.txt diff --git a/2022-05-14-apache-nginx-glep-81/2022-05-14-apache-nginx-glep-81.en.txt b/2022-05-14-apache-nginx-glep-81/2022-05-14-apache-nginx-glep-81.en.txt new file mode 100644 index 000..34b2e63 --- /dev/null +++ b/2022-05-14-apache-nginx-glep-81/2022-05-14-apache-nginx-glep-81.en.txt @@ -0,0 +1,36 @@ +Title: Migration to GLEP-81 enabled webservers +Author: Conrad Kostecki +Posted: 2022-05-14 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: www-servers/apache +Display-If-Installed: www-servers/nginx + +In future, in order to complete the whole GLEP-81 migration, +the packages www-servers/apache and www-servers/nginx +will be migrated to GLEP-81. + +If changes have been made to the default created user and group +by one of the both packages, the configuration needs to be updated, +as otherwise it will be overwritten. + +The following configuration settings can be set +in make.conf or per package in package.env: + +1. ACCT_USER__GROUPS + for overriding all default groups. + +2. ACCT_USER__GROUPS_ADD + for adding additional groups to default groups. + +** Package www-servers/apache will use username/group 'apache'. +-> ACCT_USER_APACHE_GROUPS=".." +-> ACCT_USER_APACHE_GROUPS_ADD=".." + +** Package www-servers/nginx will use username/group 'nginx'. +-> ACCT_USER_NGINX_GROUPS=".." +-> ACCT_USER_NGINX_GROUPS_ADD=".." + +Please update configuration parameters before emerging +both GLEP-81 enabled ebuilds, as otherwise configuration +will be overwritten to default. -- 2.35.1
[gentoo-dev] [PATCH] 2022-05-14-apache-nginx-glep-81: add news
Signed-off-by: Conrad Kostecki --- .../2022-05-14-apache-nginx-glep-81.en.txt| 36 +++ 1 file changed, 36 insertions(+) create mode 100644 2022-05-14-apache-nginx-glep-81/2022-05-14-apache-nginx-glep-81.en.txt diff --git a/2022-05-14-apache-nginx-glep-81/2022-05-14-apache-nginx-glep-81.en.txt b/2022-05-14-apache-nginx-glep-81/2022-05-14-apache-nginx-glep-81.en.txt new file mode 100644 index 000..f6222ed --- /dev/null +++ b/2022-05-14-apache-nginx-glep-81/2022-05-14-apache-nginx-glep-81.en.txt @@ -0,0 +1,36 @@ +Title: Migration to sys-apps/systemd-utils +Author: Conrad Kostecki +Posted: 2022-05-14 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: www-servers/apache +Display-If-Installed: www-servers/nginx + +In future, in order to complete the whole GLEP-81 migration, +the packages www-servers/apache and www-servers/nginx +will be migrated to GLEP-81. + +If changes have been made to the default created user and group +by one of the both packages, the configuration needs to be updated, +as otherwise it will be overwritten. + +The following configuration settings can be set +in make.conf or per package in package.env: + +1. ACCT_USER__GROUPS + for overriding all default groups. + +2. ACCT_USER__GROUPS_ADD + for adding additional groups to default groups. + +** Package www-servers/apache will use username/group 'apache'. +-> ACCT_USER_APACHE_GROUPS=".." +-> ACCT_USER_APACHE_GROUPS_ADD=".." + +** Package www-servers/nginx will use username/group 'nginx'. +-> ACCT_USER_NGINX_GROUPS=".." +-> ACCT_USER_NGINX_GROUPS_ADD=".." + +Please update configuration parameters before emerging +both GLEP-81 enabled ebuilds, as otherwise configuration +will be overwritten to default. -- 2.35.1
Re: [gentoo-dev] Should we join the which hunt?
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?
On Fri, May 13, 2022 at 11:44 AM Mike Gilbert wrote: > > On Fri, May 13, 2022 at 3:11 AM Ulrich Mueller wrote: > > > > Recently Debian has started to transition away from the "which" command. > > [1] > > > > which is a non-POSIX command which prints out the location of specified > > executables that are in your path. Unfortunately, there are several > > versions of the program around which are not compatible with each other. > > We package the GNU version as sys-apps/which, which is in the system set > > since 2004. > > > > Already in 2007, vapier asked developers to avoid which in ebuilds. [2] > > The replacement in most circumstances is "type -p" which is a bash > > builtin command. > > > > So, should we join the "which hunt", with the goal of removing > > sys-apps/which from the system set and from stage1? I think the first > > step would be to identify which packages use which, and add it as an > > explicit dependency. (Maybe the tinderbox could help there?) A bug for > > this [3] has already been filed by mgorny some time ago. > > > > Unfortunately, the command pops up in unexpected places, e.g. it appears > > to be an (indirect) build-time dependency of systemd. [4] > > "which" is a built-in command in bash, but not in dash. For most > users, /bin/sh points at bash and I don't expect to see much breakage > when /usr/bin/which is removed. The bug reports will come from people > who like pain and run their systems with /bin/sh pointed at dash. Oops, turns out I tested with zsh, not bash. Disregard the above.
[gentoo-dev] Python 3.11 is ready to enter PYTHON_COMPAT (and other Python news)
Hi, everyone.
TL;DR:
1. Gentoo eclasses now support Python 3.11 in ~arch. Please start
testing your packages. (It's going to be stabilized once it leaves
beta, i.e. sometime Nov-Dec.)
2. We're switching to Python 3.10 in the beginning of June, so if you
haven't ported your packages yet, please hurry.
3. While updating your packages, please switch to DISTUTILS_USE_PEP517
build.
For help, please consult our docs:
https://projects.gentoo.org/python/guide/
===
Python 3.11 now supported in Gentoo
===
Python 3.11.0b1 has been released recently. This means upstream feature
freeze (i.e. technically no breaking changes, unless they do some last-
minute reverts like with 3.10.0 final). This in turn we can start
testing packages and marking them as 3.11 happy.
We've already have ported some initial packages (which nowadays means
tons of packages). My experience so far is that Python 3.11 is rather
painless, compared to previous releases. What usually breaks are gross
hacks or deprecations ignored for years (both common in Python ecosystem
but not that common).
Bad news is that for one useful package, you may end up having to deal
with half a dozen unmaintained, broken NIH dependencies. Good news is
that we're not alone with this, and neither we're the first ones to
fight Python 3.11. So if something's broken, then there's a good chance
that either it's already fixed in the upstream VCS repository or someone
has made a pull request/patch for it.
My usual recommendation is to prefer fixing problems over skipping
tests. However, if something is important enough and the test failures
are minor compared to the package's functionality, you can use
EPYTEST_IGNORE and EPYTEST_DESELECT to skip broken tests conditionally
to Python version. Sometimes it also makes sense to skip some
dependency (python_gen_cond_dep) and possibly tests depending on it
(using has_version). You can find some examples in the Guide, as well
as by grepping the existing ebuilds.
One package we haven't ported yet (and that we would really prefer not
to port) is dev-python/nose. It's unmaintained for years, we're already
carrying a ton of patches to keep it working and with Python 3.11, it's
once again a mess. Plus, the code itself is a mess full of hacks. Good
news is: 3.11 broke it completely, so upstreams can't just ignore
the problem ("it works in my virtualenv"), so there's some hope they
will be for switching to another test runner. That is, unless you're
dealing with yet another unmaintained NIH dependency of an unmaintained
NIH dependency. But there's some chance that you should be able to get
it running with pytest easily or with a reasonably small patch.
I'd also like to ask you to update your packages to EAPI 8 (if possible)
and DISTUTILS_USE_PEP517 while touching them. Setuptools has deprecated
`setup.py install` that the legacy builds are using long time ago. It
doesn't look like it's going to stop working anytime soon but it's
better to avoid running into last minute porting.
The new flags are currently stable-masked on all profiles. Python
3.11.0 final release is planned for October 2022. We're probably going
to stabilize it sometime after, then work on unmasking the flags.
=
Python 3.10 coming as the default interpreter
=
As announced before, we're going to be switching to Python 3.10
in the beginning of June 2022. There shouldn't be any unplanned delay,
and all the most important packages are ready.
If you haven't ported your packages, please do so ASAP.
If something isn't suitable for Python 3.10, it's probably a good idea
to give the users an early warning that it's likely to be lastrited
at some point.
If you need help, please don't hesitate to ask on #gentoo-python.
We can help, point you at the right docs or good examples of ebuilds.
TIA for all you help and have fun with new Pythons!
--
Best regards,
Michał Górny
Re: [gentoo-dev] Should we join the which hunt?
On Fri, May 13, 2022 at 3:11 AM Ulrich Mueller wrote: > > Recently Debian has started to transition away from the "which" command. > [1] > > which is a non-POSIX command which prints out the location of specified > executables that are in your path. Unfortunately, there are several > versions of the program around which are not compatible with each other. > We package the GNU version as sys-apps/which, which is in the system set > since 2004. > > Already in 2007, vapier asked developers to avoid which in ebuilds. [2] > The replacement in most circumstances is "type -p" which is a bash > builtin command. > > So, should we join the "which hunt", with the goal of removing > sys-apps/which from the system set and from stage1? I think the first > step would be to identify which packages use which, and add it as an > explicit dependency. (Maybe the tinderbox could help there?) A bug for > this [3] has already been filed by mgorny some time ago. > > Unfortunately, the command pops up in unexpected places, e.g. it appears > to be an (indirect) build-time dependency of systemd. [4] "which" is a built-in command in bash, but not in dash. For most users, /bin/sh points at bash and I don't expect to see much breakage when /usr/bin/which is removed. The bug reports will come from people who like pain and run their systems with /bin/sh pointed at dash.
[gentoo-dev] Re: [PATCH] linux-info.eclass: Remove local function.Calling code removed on Aug 3,2010
On 5/12/22 14:29, Mike Pagano wrote:
This function was only called locally and the last use was almost 12
years ago
See: https://gitlab.com/rindeal/gentoo-cvs-history-archive/-/commit/1715ad
cd9e404075340e5a5ed82f88928feeffd9
Signed-off-by: Mike Pagano
---
eclass/linux-info.eclass | 20
1 file changed, 20 deletions(-)
diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
index 8c502812f8f..d2003874da0 100644
--- a/eclass/linux-info.eclass
+++ b/eclass/linux-info.eclass
@@ -438,26 +438,6 @@ kernel_is() {
"${1:-${KV_MAJOR:-0}}.${2:-${KV_MINOR:-0}}.${3:-${KV_PATCH:-0}}"
}
-get_localversion() {
- local lv_list i x
-
- local shopt_save=$(shopt -p nullglob)
- shopt -s nullglob
- local files=( ${1}/localversion* )
- ${shopt_save}
-
- # ignore files with ~ in it.
- for i in "${files[@]}"; do
- [[ -n ${i//*~*} ]] && lv_list="${lv_list} ${i}"
- done
-
- for i in ${lv_list}; do
- x="${x}$(<${i})"
- done
- x=${x/ /}
- echo ${x}
-}
-
# Check if the Makefile is valid for direct parsing.
# Check status results:
# - PASS, use 'getfilevar' to extract values
Committed
OpenPGP_0x92A6DBEC81F2B137.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [gentoo-dev] Should we join the which hunt?
> On Fri, 13 May 2022, Philip Webb wrote: >> Recently Debian has started to transition away from the "which" command. >> [1] > Do we take Debian as a role model ? No, but it is additional input. Note that our own activities [2,3] started earlier than that. >> 'which' is a non-POSIX command which prints out the location of specified >> executables that are in your path. Unfortunately, there are several >> versions of the program around which are not compatible with each other. >> We package the GNU version as sys-apps/which, >> which is in the system set since 2004. > If there is a GNU version, that would seem to be somewhat "official". > Also, it's been around a long time. It's been around at least since the 1980s but in spite of this it was never standardised. The GNU version exists since 1999 and had its last release in 2015. >> Already in 2007, vapier asked developers to avoid which in ebuilds. [2] > There well mb good reasons for the devs to do that, > but users may have different needs or preferences. Nobody is asking to drop the sys-apps/which package, so users can install it if they like the command. Gentoo is about choice, so we shouldn't force installation for everybody if the package isn't needed in @system. (The same applies to sys-apps/less BTW, but that's a different story.) Ulrich >> [1] https://lwn.net/Articles/874049/ >> [2] >> https://archives.gentoo.org/gentoo-dev/message/e04d4db72572dd5fec48e87c6b18c525 >> [3] https://bugs.gentoo.org/646588 >> [4] https://bugs.gentoo.org/502084 signature.asc Description: PGP signature
Re: [gentoo-dev] Should we join the which hunt?
On Fri, May 13, 2022 at 05:02:25AM -0400, Michael Orlitzky wrote:
> 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.
fwiw both command -v and type -p aren't analogous to which given they
check shell functions too, requiring to pay attention to namespace.
e.g. if have /bin/ftest and ftest() { :; }, with bash:
which ftest: /bin/ftest
command -v ftest: ftest
type -p ftest: (nothing)
type -P ftest: /bin/ftest
If the function is unset they all return /bin/ftest though. In bash
/ ebuilds I don't see much reason to use command -v, but if swapping
which for command -v with POSIX sh should check if the script doesn't
have simple function names everywhere.
--
ionen
signature.asc
Description: PGP signature
Re: [gentoo-dev] Should we join the which hunt?
On 13/05/2022 09.11, 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, please. If there is a equally powerful bash builtin, and even a POSIX shell function, that performs the same task as the external command, than the shell builtins should be used. Since ebuilds are bash, it seems safe to use "type -p" in them. Would it be possible to add a QA check to portage that detects invalid usages of 'which' and flags them to be replaced with "type -p"? I think that would be a good first step. - Flow
Re: [gentoo-dev] Should we join the which hunt?
> On Fri, 13 May 2022, Michael Orlitzky 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. This depends on context. I think with bash "type -p" is the better choice, because it simply prints the path which is machine readable without any postprocessing. In other posixly-correct contexts "command -v" may be the best alternative available, indeed. > Both are built-in to bash so there's no performance penalty in ebuilds > either way. signature.asc Description: PGP signature
Re: [gentoo-dev] Should we join the which hunt?
220513 Ulrich Mueller wrote: > Recently Debian has started to transition away from the "which" command. > [1] Do we take Debian as a role model ? > 'which' is a non-POSIX command which prints out the location of specified > executables that are in your path. Unfortunately, there are several > versions of the program around which are not compatible with each other. > We package the GNU version as sys-apps/which, > which is in the system set since 2004. If there is a GNU version, that would seem to be somewhat "official". Also, it's been around a long time. > Already in 2007, vapier asked developers to avoid which in ebuilds. [2] There well mb good reasons for the devs to do that, but users may have different needs or preferences. > The replacement in most circumstances is "type -p" > which is a bash builtin command. It does appear to do the same job, but it's more difficult to remember. Yes, anyone could make 'which' an alias for 'type -p'. > So, should we join the "which hunt", with the goal > of removing sys-apps/which from the system set and from stage1 ? > The first step would be to identify which packages use 'which' > and add it as an explicit dependency. > Maybe the tinderbox could help there ? > A bug for this [3] has already been filed by mgorny some time ago. > Unfortunately, the command pops up in unexpected places, > e.g. it appears to be an (indirect) build-time dependency of systemd. [4] > [1] https://lwn.net/Articles/874049/ > [2] > https://archives.gentoo.org/gentoo-dev/message/e04d4db72572dd5fec48e87c6b18c525 > [3] https://bugs.gentoo.org/646588 > [4] https://bugs.gentoo.org/502084 Those are a user's reactions. I trust the devs to do something sensible. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] Should we join the which hunt?
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.
[gentoo-dev] Should we join the which hunt?
Recently Debian has started to transition away from the "which" command. [1] which is a non-POSIX command which prints out the location of specified executables that are in your path. Unfortunately, there are several versions of the program around which are not compatible with each other. We package the GNU version as sys-apps/which, which is in the system set since 2004. Already in 2007, vapier asked developers to avoid which in ebuilds. [2] The replacement in most circumstances is "type -p" which is a bash builtin command. So, should we join the "which hunt", with the goal of removing sys-apps/which from the system set and from stage1? I think the first step would be to identify which packages use which, and add it as an explicit dependency. (Maybe the tinderbox could help there?) A bug for this [3] has already been filed by mgorny some time ago. Unfortunately, the command pops up in unexpected places, e.g. it appears to be an (indirect) build-time dependency of systemd. [4] Ulrich [1] https://lwn.net/Articles/874049/ [2] https://archives.gentoo.org/gentoo-dev/message/e04d4db72572dd5fec48e87c6b18c525 [3] https://bugs.gentoo.org/646588 [4] https://bugs.gentoo.org/502084 signature.asc Description: PGP signature
