[gentoo-dev] Last rites: dev-python/aiohttp-cors, net-misc/gns3*
# Michał Górny (2020-03-26)
# dev-python/aiohttp-cors is dead upstream and does not support
# Python 3.7 and newer.
#
# net-misc/gns3-* are effectively unmaintained and stuck with py3.6.
# gns3-server is the only revdep of aiohttp-cors, as well as the only
# blocker for removal of old dev-python/{aiohttp,async_timeout}
# (bug #714840). Some of those issues might be fixed by a version bump
# that's pending for a long time (bug #688016) but not aiohttp-cors dep.
#
# Removal in 30 days. Bug #712964.
dev-python/aiohttp-cors
net-misc/gns3-converter
net-misc/gns3-gui
net-misc/gns3-server
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] autotools
Dear all, I send this email to ask you for your help for the better approach to translate the following autoreconf command to an ebuild: > |autoreconf -i -f ./configure \ --prefix=/usr \ > --libexecdir=/usr/lib/snapd \ > --with-snap-mount-dir=/var/lib/snapd/snap \ --enable-apparmor \ > --enable-nvidia-biarch \ --enable-merged-usr| I realise that eautoreconf from autotools.eclass doesn't accept any parameters, so how would you advise me to reproduce it inside an ebuild using the available functions and eclasses? My goal is to create an ebuild from latest snapd pkgbuild: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=snapd Thank you, Samuel signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: autotools
On 26. 3. 2020 18:47, Samuel Bernardo wrote: > Dear all, > > I send this email to ask you for your help for the better approach to > translate the following autoreconf command to an ebuild: > >> |autoreconf -i -f ./configure \ --prefix=/usr \ >> --libexecdir=/usr/lib/snapd \ >> --with-snap-mount-dir=/var/lib/snapd/snap \ --enable-apparmor \ >> --enable-nvidia-biarch \ --enable-merged-usr| > I realise that eautoreconf from autotools.eclass doesn't accept any > parameters, so how would you advise me to reproduce it inside an ebuild > using the available functions and eclasses? > > My goal is to create an ebuild from latest snapd pkgbuild: > > https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=snapd > > Thank you, > > Samuel > I guess you are not really after autoreconf arguments rather than ./configure ones. You want to focus on src_configure() in the ebuild. I suggest starting here: https://devmanual.gentoo.org/ebuild-writing/functions/src_configure/configuring/index.html and there are plenty of examples existing in the portage. You will need to define USE flags for your ebuild though so that users can enable/disable parts of functionality. Happy hacking! Michal
Re: [gentoo-dev] autotools
[2020-03-26 17:47:35+] Samuel Bernardo:
> I send this email to ask you for your help for the better approach to
> translate the following autoreconf command to an ebuild:
>
> > |autoreconf -i -f ./configure \ --prefix=/usr \
> > --libexecdir=/usr/lib/snapd \
> > --with-snap-mount-dir=/var/lib/snapd/snap \ --enable-apparmor \
> > --enable-nvidia-biarch \ --enable-merged-usr|
> I realise that eautoreconf from autotools.eclass doesn't accept any
> parameters, so how would you advise me to reproduce it inside an ebuild
> using the available functions and eclasses?
>
> My goal is to create an ebuild from latest snapd pkgbuild:
> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=snapd
Not sure if this would work out-of-the-box but this is how it is usually done:
src_prepare() {
default
eautoreconf
}
src_configure() {
econf \
--with-snap-mount-dir=/var/lib/snapd/snap \
--enable-nvidia-biarch \
--enable-merged-usr \
$(use_enable apparmor)
}
But as AUR has basically no quality requirement also consider that maybe it
doesn't need eautoreconf at all, which can be nice to avoid.
[gentoo-dev] Re: autotools
Thank you Michal and Haelwenn for your advises.
I'm taking as reference the documentation about functions syntax in
devmanual[1] (very useful for a quickly review).
In the source code where autoreconf is being called I found a
configure.ac and Makefile.am.
Looking into autogen.sh[2] script prvided by the maintainer I confirm
that he runs the following commands:
- autoreconf -i -f
- for each supported distribution defines variable extra_opts
- "${SRC_DIR}/configure" --enable-maintainer-mode --prefix=/usr
$extra_opts "$@"
So it seems that the best approach would be the way you suggested in
your example Haelwenn.
[1] https://devmanual.gentoo.org/eclass-reference/ebuild/index.html
[2] https://github.com/snapcore/snapd/blob/master/cmd/autogen.sh
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] [PATCH 0/1] allow extra implementations of python
There are situations in which downstream overlays need to have versions of python which Gentoo no longer supports in the tree. Currently, the only way to do this is for the overlay author to fork python-utils-r1.eclass. This is highly undesirable since it creates a very significant maintenance burden for the overlay author. There are a couple of things we can do upstream to make this easier, and I think we should do one of them. The simplest way would be to apply the following patch. In this situation, all the overlay author would have to do is adjust the PYTHON_COMPAT_ALLOW_EXTRA_IMPLS variable. The other option would be to move _PYTHON_ALL_IMPLS and the implementation of _python_impl_supported to a separate eclass, e.g. python-impls-r1.eclass. This eclass could be forked freely downstream without worrying about the other python eclasses. I will volunteer to do the legwork for this option if we do not like the first one. I would advocate the first option however since no one has to fork anything. Thoughts? William William Hubbs (1): python.eclass: add PYTHON_COMPAT_ALLOW_EXTRA_IMPLS eclass/python-utils-r1.eclass | 2 ++ 1 file changed, 2 insertions(+) -- 2.24.1
[gentoo-dev] [PATCH 1/1] python.eclass: add PYTHON_COMPAT_ALLOW_EXTRA_IMPLS
This variable is meant to be set in downstream overlays when they need python
implementations other than the ones we support in the tree.
It should be a space-separated list of extra implementations.
Signed-off-by: William Hubbs
---
eclass/python-utils-r1.eclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index aacee5ac35a..4370c7a825f 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -43,6 +43,8 @@ _PYTHON_ALL_IMPLS=(
python2_7
python3_6 python3_7 python3_8
)
+[[ -n ${PYTHON_COMPAT_ALLOW_EXTRA_IMPLS[*]} ]] &&
+ _PYTHON_ALL_IMPLS+=( ${PYTHON_COMPAT_ALLOW_EXTRA_IMPLS} )
readonly _PYTHON_ALL_IMPLS
# @ECLASS-VARIABLE: PYTHON_COMPAT_NO_STRICT
--
2.24.1
Re: [gentoo-dev] [PATCH 1/1] python.eclass: add PYTHON_COMPAT_ALLOW_EXTRA_IMPLS
> +[[ -n ${PYTHON_COMPAT_ALLOW_EXTRA_IMPLS[*]} ]] &&
Without string check:
[[ ${#PYTHON_COMPAT_ALLOW_EXTRA_IMPLS[@]} -gt 0 ]]
> + _PYTHON_ALL_IMPLS+=( ${PYTHON_COMPAT_ALLOW_EXTRA_IMPLS} )
> readonly _PYTHON_ALL_IMPLS
Once array, always array:
_PYTHON_ALL_IMPLS+=( ${PYTHON_COMPAT_ALLOW_EXTRA_IMPLS[@]} )
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH 1/1] python.eclass: add PYTHON_COMPAT_ALLOW_EXTRA_IMPLS
On Thu, Mar 26, 2020 at 3:13 PM William Hubbs wrote: > > This variable is meant to be set in downstream overlays when they need python > implementations other than the ones we support in the tree. > It should be a space-separated list of extra implementations. This new variable should be documented in the eclass, along with a note that its use is unsupported for general use. Do you intend this variable to be set in profiles or make.conf? In either case, I don't think you can use bash arrays. Also, you're mixing scalar and array variable syntax in your patch.
Re: [gentoo-dev] [PATCH 0/1] allow extra implementations of python
On Thu, 2020-03-26 at 14:13 -0500, William Hubbs wrote: > There are situations in which downstream overlays need to have versions > of python which Gentoo no longer supports in the tree. > > Currently, the only way to do this is for the overlay author to fork > python-utils-r1.eclass. This is highly undesirable since it creates a > very significant maintenance burden for the overlay author. > > There are a couple of things we can do upstream to make this easier, and > I think we should do one of them. > > The simplest way would be to apply the following patch. > In this situation, all the overlay author > would have to do is adjust the PYTHON_COMPAT_ALLOW_EXTRA_IMPLS variable. > > The other option would be to move _PYTHON_ALL_IMPLS and the > implementation of _python_impl_supported to a separate eclass, e.g. > python-impls-r1.eclass. This eclass could be forked freely downstream > without worrying about the other python eclasses. > I will volunteer to do the legwork for this option if we do not like the > first one. > > I would advocate the first option however since no one has to fork > anything. > > Thoughts? > > William > > William Hubbs (1): > python.eclass: add PYTHON_COMPAT_ALLOW_EXTRA_IMPLS > > eclass/python-utils-r1.eclass | 2 ++ > 1 file changed, 2 insertions(+) > How do you prevent some extra clever Gentoo developer from doing the following in ::gentoo dev-python/foo/foo-1.ebuild: # don't have the time to port this right now, patches welcome PYTHON_COMPAT_ALLOW_EXTRA_IMPLS=( python3_4 ) PYTHON_COMPAT=( python3_4 ) inherit distutils-r1 Furthermore, defining PYTHON_COMPAT_ALLOW_EXTRA_IMPLS is going to break metadata invariance, causing tons of cache mis-hits. How do you prevent that? In addition, this will very quickly cause whatever overlay this is being used in to become invalid. Imagine I have dev-python/foo::gentoo that supports python 3.4 and 3.5 and have dev-python/bar::sony supporting 3.4 and 3.5 sitting in a hypothetical overlay, which depends on dev-python/foo::gentoo. Now we remove python 3.4 from ::gentoo in python-utils-r1, and one week later we remove python3.4 from dev-python/foo::gentoo's PYTHON_COMPAT. Now your dev- python/bar::sony in conjunction with PYTHON_COMPAT_ALLOW_EXTRA_IMPLS has an invalid depgraph. How do you wish to resolve this? I feel like keeping up with ::gentoo is ultimately the better strategy than trying to add backdoors to eclasses because some overlays are somewhat behind. Regards David
Re: [gentoo-dev] [PATCH 1/1] python.eclass: add PYTHON_COMPAT_ALLOW_EXTRA_IMPLS
On Thu, Mar 26, 2020 at 03:37:48PM -0400, Mike Gilbert wrote: > On Thu, Mar 26, 2020 at 3:13 PM William Hubbs wrote: > > > > This variable is meant to be set in downstream overlays when they need > > python > > implementations other than the ones we support in the tree. > > It should be a space-separated list of extra implementations. > > This new variable should be documented in the eclass, along with a > note that its use is unsupported for general use. > > Do you intend this variable to be set in profiles or make.conf? In > either case, I don't think you can use bash arrays. Also, you're > mixing scalar and array variable syntax in your patch. Sure, I can do that. I'll fix up the syntax and add the documentation. Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 1/1] python.eclass: add PYTHON_COMPAT_ALLOW_EXTRA_IMPLS
On Thu, 2020-03-26 at 14:13 -0500, William Hubbs wrote:
> This variable is meant to be set in downstream overlays when they need python
> implementations other than the ones we support in the tree.
> It should be a space-separated list of extra implementations.
>
> Signed-off-by: William Hubbs
> ---
> eclass/python-utils-r1.eclass | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> index aacee5ac35a..4370c7a825f 100644
> --- a/eclass/python-utils-r1.eclass
> +++ b/eclass/python-utils-r1.eclass
> @@ -43,6 +43,8 @@ _PYTHON_ALL_IMPLS=(
> python2_7
> python3_6 python3_7 python3_8
> )
> +[[ -n ${PYTHON_COMPAT_ALLOW_EXTRA_IMPLS[*]} ]] &&
> + _PYTHON_ALL_IMPLS+=( ${PYTHON_COMPAT_ALLOW_EXTRA_IMPLS} )
> readonly _PYTHON_ALL_IMPLS
>
> # @ECLASS-VARIABLE: PYTHON_COMPAT_NO_STRICT
How is this supposed to work, exactly? If you scroll to the next
function you'd realize that after this change this 'extra
implementation' will most likely be simultaneously considered supported
and unsupported.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 0/1] allow extra implementations of python
On Thu, 2020-03-26 at 14:13 -0500, William Hubbs wrote: > There are situations in which downstream overlays need to have versions > of python which Gentoo no longer supports in the tree. > > Currently, the only way to do this is for the overlay author to fork > python-utils-r1.eclass. This is highly undesirable since it creates a > very significant maintenance burden for the overlay author. Is it preferable to create the maintenance burden on Gentoo developers instead? Is it fair that paid company developers shift the burden on people who work on Gentoo in their free time, and already have their plate full? > The simplest way would be to apply the following patch. > In this situation, all the overlay author > would have to do is adjust the PYTHON_COMPAT_ALLOW_EXTRA_IMPLS variable. ...which solves exactly zero problems because the eclass still doesn't support the implementation in question. The best it could do is sweep part of the problem under the carpet. Even if it miraculously works right now at all, it will probably fail or misbehave randomly. Any eclass change might break it. Then one cheap hack will serve as an excuse to add one more, and another. > The other option would be to move _PYTHON_ALL_IMPLS and the > implementation of _python_impl_supported to a separate eclass, e.g. > python-impls-r1.eclass. This eclass could be forked freely downstream > without worrying about the other python eclasses. Again, this doesn't solve the problem. It just moves the problem elsewhere. > Thoughts? I've already told you that if you want to fork, fork all eclasses. Then you wouldn't have to worry about internal API going out of sync. Or don't autoupdate ::gentoo when eclasses change. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 0/1] allow extra implementations of python
On Thu, Mar 26, 2020 at 09:11:11PM +0100, Michał Górny wrote: > I've already told you that if you want to fork, fork all eclasses. Then > you wouldn't have to worry about internal API going out of sync. > > Or don't autoupdate ::gentoo when eclasses change. I also suggested something that is a corollary of this: If you effectively freeze ::gentoo to different points for different systems, then you ALSO need for generate frozen releases for your overlay and backport critical changes to those releases. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 0/1] allow extra implementations of python
On Thu, Mar 26, 2020 at 08:37:17PM +0100, David Seifert wrote: *snip* > How do you prevent some extra clever Gentoo developer from doing the following > in ::gentoo > > dev-python/foo/foo-1.ebuild: > > # don't have the time to port this right now, patches welcome > PYTHON_COMPAT_ALLOW_EXTRA_IMPLS=( python3_4 ) > PYTHON_COMPAT=( python3_4 ) > inherit distutils-r1 If there's a way inside an eclass to check that the ebuild inheriting it is in ::gentoo, I will use it to die if the ebuild is in ::gentoo and this variable is set. > Furthermore, defining PYTHON_COMPAT_ALLOW_EXTRA_IMPLS is going to break > metadata > invariance, causing tons of cache mis-hits. How do you prevent that? > > In addition, this will very quickly cause whatever overlay this is being used > in > to become invalid. Imagine I have dev-python/foo::gentoo that supports python > 3.4 and 3.5 and have dev-python/bar::sony supporting 3.4 and 3.5 sitting in a > hypothetical overlay, which depends on dev-python/foo::gentoo. Now we remove > python 3.4 from ::gentoo in python-utils-r1, and one week later we remove > python3.4 from dev-python/foo::gentoo's PYTHON_COMPAT. Now your dev- > python/bar::sony in conjunction with PYTHON_COMPAT_ALLOW_EXTRA_IMPLS has an > invalid depgraph. How do you wish to resolve this? These are both overlay maintenance questions that wouldn't affect ::gentoo, but the answer to the first one is we regenerate the metadata very often so it wouldn't be an issue, and the second one is resolved by grabbing packages and putting them in another overlay until we don't need them. > I feel like keeping up with ::gentoo is ultimately the better strategy than > trying to add backdoors to eclasses because some overlays are somewhat behind. I agree with you. However, sometimes in the real world it doesn't work that way, or it can take longer to move than Gentoo. If we can do something minimal to allow downstream overlays to do what they need to do to catch up, I think we should, especially if someone from downstream is offering to do the work. William signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 0/1] allow extra implementations of python
On Thu, 26 Mar 2020 21:11:11 +0100 Michał Górny wrote: > On Thu, 2020-03-26 at 14:13 -0500, William Hubbs wrote: > > There are situations in which downstream overlays need to have versions > > of python which Gentoo no longer supports in the tree. > > > > Currently, the only way to do this is for the overlay author to fork > > python-utils-r1.eclass. This is highly undesirable since it creates a > > very significant maintenance burden for the overlay author. > > Is it preferable to create the maintenance burden on Gentoo developers > instead? Is it fair that paid company developers shift the burden > on people who work on Gentoo in their free time, and already have their > plate full? We have no intention of shifting maintenance burdens anywhere, we want to make minor changes to make it easier for us to keep up. It's the same as a Gentoo developer asking an upstream project to make minor changes to their build system to support DESTDIR or a sandbox fix. > > > The simplest way would be to apply the following patch. > > In this situation, all the overlay author > > would have to do is adjust the PYTHON_COMPAT_ALLOW_EXTRA_IMPLS variable. > > ...which solves exactly zero problems because the eclass still doesn't > support the implementation in question. The best it could do is sweep > part of the problem under the carpet. We don't care if it *actually* supports it, the ebuilds in question aren't going to be installed on modern machines. We just want it to not blow up in the global scope. > Even if it miraculously works right now at all, it will probably fail or > misbehave randomly. Any eclass change might break it. Then one cheap > hack will serve as an excuse to add one more, and another.\ > > > The other option would be to move _PYTHON_ALL_IMPLS and the > > implementation of _python_impl_supported to a separate eclass, e.g. > > python-impls-r1.eclass. This eclass could be forked freely downstream > > without worrying about the other python eclasses. > > Again, this doesn't solve the problem. It just moves the problem > elsewhere. > How does this not solve the problem? Overlays could trivially support different implementations, without maintaining a lot of forks. We are quite happy to do the work to split it out to a separate eclass. > > Thoughts? > > I've already told you that if you want to fork, fork all eclasses. Then > you wouldn't have to worry about internal API going out of sync. > > Or don't autoupdate ::gentoo when eclasses change. >
Re: [gentoo-dev] [PATCH 0/1] allow extra implementations of python
On Thu, 2020-03-26 at 13:47 -0700, Patrick McLean wrote: > On Thu, 26 Mar 2020 21:11:11 +0100 > Michał Górny wrote: > > > On Thu, 2020-03-26 at 14:13 -0500, William Hubbs wrote: > > > There are situations in which downstream overlays need to have versions > > > of python which Gentoo no longer supports in the tree. > > > > > > Currently, the only way to do this is for the overlay author to fork > > > python-utils-r1.eclass. This is highly undesirable since it creates a > > > very significant maintenance burden for the overlay author. > > > > Is it preferable to create the maintenance burden on Gentoo developers > > instead? Is it fair that paid company developers shift the burden > > on people who work on Gentoo in their free time, and already have their > > plate full? > > We have no intention of shifting maintenance burdens anywhere, we want > to make minor changes to make it easier for us to keep up. It's the > same as a Gentoo developer asking an upstream project to make minor > changes to their build system to support DESTDIR or a sandbox fix. No, that's the exact opposite of it. Supporting DESTDIR is the correct course of action that benefits a lot of people. Adding hacks to make a broken thing to pretend to work is the exact opposite of that. > > > > The simplest way would be to apply the following patch. > > > In this situation, all the overlay author > > > would have to do is adjust the PYTHON_COMPAT_ALLOW_EXTRA_IMPLS variable. > > > > ...which solves exactly zero problems because the eclass still doesn't > > support the implementation in question. The best it could do is sweep > > part of the problem under the carpet. > > We don't care if it *actually* supports it, the ebuilds in question > aren't going to be installed on modern machines. We just want it to not > blow up in the global scope. Which makes literally zero sense. If you don't want them to work, remove them. Don't ask ::gentoo to provide special support to keep ebuilds that are 100% broken. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages up for grabs: app-office/magicpoint, sys-apps/flashrom
On 2020-03-23 20:33, Jonas Stein wrote: > sys-apps/flashrom I'll take this one, I still use it from time to time. -- MS signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH] Split python implementations definition to separate eclass
This patch splits the definition of _PYTHON_ALL_IMPLS and
_python_impl_supported to a separate eclass, this allows overlays
to easily support a different set of python implementations than
::gentoo without having to fork the entire suite of eclasses.
diff --git a/eclass/python-impls-r1.eclass b/eclass/python-impls-r1.eclass
new file mode 100644
index 000..0ae6e4e84a1
--- /dev/null
+++ b/eclass/python-impls-r1.eclass
@@ -0,0 +1,90 @@
+# Copyright 1999-2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: python-impls-r1.eclass
+# @MAINTAINER:
+# Python team
+# @AUTHOR:
+# Author: MichaŠGórny
+# Split to separate eclass by: Patrick McLean
+# Based on work of: Krzysztof Pawlik
+# @SUPPORTED_EAPIS: 5 6 7
+# @BLURB: Definitions of supported eclasses for python-utils-r1
+# @DESCRIPTION:
+# A helper eclass defining the supported python implementations for
+# the python-r1 suite of eclasses.
+#
+# This eclass is meant to be inherited by python-utils-r1, inheriting
+# it separately is very unlikely to be useful.
+#
+# For more information, please see the Python Guide:
+# https://dev.gentoo.org/~mgorny/python-guide/
+
+case "${EAPI:-0}" in
+ [0-4]) die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}" ;;
+ [5-7]) ;;
+ *) die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}" ;;
+esac
+
+if [[ ${_PYTHON_ECLASS_INHERITED} ]]; then
+ die 'python-r1 suite eclasses can not be used with python.eclass.'
+fi
+
+if [[ ! ${_PYTHON_IMPLS_R1} ]]; then
+
+# @ECLASS-VARIABLE: _PYTHON_ALL_IMPLS
+# @INTERNAL
+# @DESCRIPTION:
+# All supported Python implementations, most preferred last.
+_PYTHON_ALL_IMPLS=(
+ pypy3
+ python2_7
+ python3_6 python3_7 python3_8
+)
+readonly _PYTHON_ALL_IMPLS
+
+# @ECLASS-VARIABLE: PYTHON_COMPAT_NO_STRICT
+# @INTERNAL
+# @DESCRIPTION:
+# Set to a non-empty value in order to make eclass tolerate (ignore)
+# unknown implementations in PYTHON_COMPAT.
+#
+# This is intended to be set by the user when using ebuilds that may
+# have unknown (newer) implementations in PYTHON_COMPAT. The assumption
+# is that the ebuilds are intended to be used within multiple contexts
+# which can involve revisions of this eclass that support a different
+# set of Python implementations.
+
+# @FUNCTION: _python_impl_supported
+# @USAGE:
+# @INTERNAL
+# @DESCRIPTION:
+# Check whether the implementation (PYTHON_COMPAT-form)
+# is still supported.
+#
+# Returns 0 if the implementation is valid and supported. If it is
+# unsupported, returns 1 -- and the caller should ignore the entry.
+# If it is invalid, dies with an appopriate error messages.
+_python_impl_supported() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ [[ ${#} -eq 1 ]] || die "${FUNCNAME}: takes exactly 1 argument (impl)."
+
+ local impl=${1}
+
+ # keep in sync with _PYTHON_ALL_IMPLS!
+ # (not using that list because inline patterns shall be faster)
+ case "${impl}" in
+ python2_7|python3_[678]|pypy3)
+ return 0
+ ;;
+ jython2_7|pypy|pypy1_[89]|pypy2_0|python2_[56]|python3_[12345])
+ return 1
+ ;;
+ *)
+ [[ ${PYTHON_COMPAT_NO_STRICT} ]] && return 1
+ die "Invalid implementation in PYTHON_COMPAT: ${impl}"
+ esac
+}
+_PYTHON_IMPLS_R1=1
+fi
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index aacee5ac35a..28df410d5a1 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -32,62 +32,7 @@ fi
if [[ ! ${_PYTHON_UTILS_R1} ]]; then
[[ ${EAPI} == 5 ]] && inherit eutils multilib
-inherit toolchain-funcs
-
-# @ECLASS-VARIABLE: _PYTHON_ALL_IMPLS
-# @INTERNAL
-# @DESCRIPTION:
-# All supported Python implementations, most preferred last.
-_PYTHON_ALL_IMPLS=(
- pypy3
- python2_7
- python3_6 python3_7 python3_8
-)
-readonly _PYTHON_ALL_IMPLS
-
-# @ECLASS-VARIABLE: PYTHON_COMPAT_NO_STRICT
-# @INTERNAL
-# @DESCRIPTION:
-# Set to a non-empty value in order to make eclass tolerate (ignore)
-# unknown implementations in PYTHON_COMPAT.
-#
-# This is intended to be set by the user when using ebuilds that may
-# have unknown (newer) implementations in PYTHON_COMPAT. The assumption
-# is that the ebuilds are intended to be used within multiple contexts
-# which can involve revisions of this eclass that support a different
-# set of Python implementations.
-
-# @FUNCTION: _python_impl_supported
-# @USAGE:
-# @INTERNAL
-# @DESCRIPTION:
-# Check whether the implementation (PYTHON_COMPAT-form)
-# is still supported.
-#
-# Returns 0 if the implementation is valid and supported. If it is
-# unsupported, returns 1 -- and the caller should ignore the entry.
-# If it is invalid, dies with an appopriate error messages.
-_python_impl_supported() {
- debug-print-function ${FUNCNAME} "${@}"
-
- [[ ${#} -eq 1 ]] || die "${FUNCNAME}: takes exactly 1 argument (impl)."
-
- local impl=${1}
-
- # keep in sync with _PYTHON_ALL_IMPLS!
- # (not using that list because inline patterns shall be faster)
- case "${impl}" in
- python2_7|python3_[678]|pypy3)
- return 0
Re: [gentoo-dev] [PATCH 0/1] allow extra implementations of python
> On Thu, 26 Mar 2020, William Hubbs wrote: > If there's a way inside an eclass to check that the ebuild inheriting > it is in ::gentoo, I will use it to die if the ebuild is in ::gentoo > and this variable is set. Oh please, not this again. An ebuild or eclass is supposed to work the same everywhere, independent of the repo it is located in. Why don't you simply copy the eclass to your overlay and do the changes there? Ulrich signature.asc Description: PGP signature
[gentoo-dev] last rites: x11-terms/aterm, x11-terms/xvt
# Andreas K. Hüttel (2020-03-26) # Fail to build with glibc-2.30; no maintainer. Removal in 30days. # Bugs 691756, 691710 x11-terms/aterm x11-terms/xvt -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] last rites: x11-terms/aterm, x11-terms/xvt
Hi, On 2020/03/26 23:34, Andreas K. Huettel wrote: > # Andreas K. Hüttel (2020-03-26) > # Fail to build with glibc-2.30; no maintainer. Removal in 30days. > # Bugs 691756, 691710 > x11-terms/aterm I'll take this via proxy-maint. Kind Regards, Jaco
[gentoo-dev] [PATCH v2]
This patch splits the definition of _PYTHON_ALL_IMPLS and
_python_impl_supported to a separate eclass, this allows overlays
to easily support a different set of python implementations than
::gentoo without having to fork the entire suite of eclasses.
Changes from previous version (based on feedback on IRC):
- add a guard variable to make sure it's being inherited
python-utils-r1.eclass
diff --git a/eclass/python-impls-r1.eclass b/eclass/python-impls-r1.eclass
new file mode 100644
index 000..622cb1ccef3
--- /dev/null
+++ b/eclass/python-impls-r1.eclass
@@ -0,0 +1,93 @@
+# Copyright 1999-2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: python-impls-r1.eclass
+# @MAINTAINER:
+# Python team
+# @AUTHOR:
+# Author: MichaŠGórny
+# Split to separate eclass by: Patrick McLean
+# Based on work of: Krzysztof Pawlik
+# @SUPPORTED_EAPIS: 5 6 7
+# @BLURB: Definitions of supported eclasses for python-utils-r1
+# @DESCRIPTION:
+# A helper eclass defining the supported python implementations for
+# the python-r1 suite of eclasses.
+#
+# This eclass is meant to be inherited by python-utils-r1, inheriting
+# it separately is very unlikely to be useful.
+#
+# For more information, please see the Python Guide:
+# https://dev.gentoo.org/~mgorny/python-guide/
+
+case "${EAPI:-0}" in
+ [0-4]) die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}" ;;
+ [5-7]) ;;
+ *) die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}" ;;
+esac
+
+if [[ ${_PYTHON_ECLASS_INHERITED} ]]; then
+ die 'python-r1 suite eclasses can not be used with python.eclass.'
+
+elif [[ -z ${_PYTHON_ECLASS_CALLING} ]]; then
+ die 'python-impls-r1 can only be inherited from python-utils-r1'
+fi
+
+if [[ ! ${_PYTHON_IMPLS_R1} ]]; then
+
+# @ECLASS-VARIABLE: _PYTHON_ALL_IMPLS
+# @INTERNAL
+# @DESCRIPTION:
+# All supported Python implementations, most preferred last.
+_PYTHON_ALL_IMPLS=(
+ pypy3
+ python2_7
+ python3_6 python3_7 python3_8
+)
+readonly _PYTHON_ALL_IMPLS
+
+# @ECLASS-VARIABLE: PYTHON_COMPAT_NO_STRICT
+# @INTERNAL
+# @DESCRIPTION:
+# Set to a non-empty value in order to make eclass tolerate (ignore)
+# unknown implementations in PYTHON_COMPAT.
+#
+# This is intended to be set by the user when using ebuilds that may
+# have unknown (newer) implementations in PYTHON_COMPAT. The assumption
+# is that the ebuilds are intended to be used within multiple contexts
+# which can involve revisions of this eclass that support a different
+# set of Python implementations.
+
+# @FUNCTION: _python_impl_supported
+# @USAGE:
+# @INTERNAL
+# @DESCRIPTION:
+# Check whether the implementation (PYTHON_COMPAT-form)
+# is still supported.
+#
+# Returns 0 if the implementation is valid and supported. If it is
+# unsupported, returns 1 -- and the caller should ignore the entry.
+# If it is invalid, dies with an appopriate error messages.
+_python_impl_supported() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ [[ ${#} -eq 1 ]] || die "${FUNCNAME}: takes exactly 1 argument (impl)."
+
+ local impl=${1}
+
+ # keep in sync with _PYTHON_ALL_IMPLS!
+ # (not using that list because inline patterns shall be faster)
+ case "${impl}" in
+ python2_7|python3_[678]|pypy3)
+ return 0
+ ;;
+ jython2_7|pypy|pypy1_[89]|pypy2_0|python2_[56]|python3_[12345])
+ return 1
+ ;;
+ *)
+ [[ ${PYTHON_COMPAT_NO_STRICT} ]] && return 1
+ die "Invalid implementation in PYTHON_COMPAT: ${impl}"
+ esac
+}
+_PYTHON_IMPLS_R1=1
+fi
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index aacee5ac35a..96e1bbbebe6 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -32,62 +32,9 @@ fi
if [[ ! ${_PYTHON_UTILS_R1} ]]; then
[[ ${EAPI} == 5 ]] && inherit eutils multilib
-inherit toolchain-funcs
-
-# @ECLASS-VARIABLE: _PYTHON_ALL_IMPLS
-# @INTERNAL
-# @DESCRIPTION:
-# All supported Python implementations, most preferred last.
-_PYTHON_ALL_IMPLS=(
- pypy3
- python2_7
- python3_6 python3_7 python3_8
-)
-readonly _PYTHON_ALL_IMPLS
-
-# @ECLASS-VARIABLE: PYTHON_COMPAT_NO_STRICT
-# @INTERNAL
-# @DESCRIPTION:
-# Set to a non-empty value in order to make eclass tolerate (ignore)
-# unknown implementations in PYTHON_COMPAT.
-#
-# This is intended to be set by the user when using ebuilds that may
-# have unknown (newer) implementations in PYTHON_COMPAT. The assumption
-# is that the ebuilds are intended to be used within multiple contexts
-# which can involve revisions of this eclass that support a different
-# set of Python implementations.
-
-# @FUNCTION: _python_impl_supported
-# @USAGE:
-# @INTERNAL
-# @DESCRIPTION:
-# Check whether the implementation (PYTHON_COMPAT-form)
-# is still supported.
-#
-# Returns 0 if the implementation is valid and supported. If it is
-# unsupported, returns 1 -- and the caller should ignore the entry.
-# If it is invalid, dies with an appopriate error messages.
-_python_impl_supported() {
- debug-print-function ${FUNCNAME} "${@}"
-
- [[ ${#} -e
[gentoo-dev] network sandbox challenge
Dear all, Fulfilling the linting of ebuild code style design for software projects that loads their dependencies during build, such as go based projects or npm as an example, could be very nasty. Looking into source code of snapd or opennebula as two examples, I need to break network sandbox to get all dependencies for snapd go modules or opennebula sunstone npm code. 1) For opennebula I can use the full releases that brings already generated sunstone code, with the penalty to loose some patches or updates in the middle. 2) For snapd I need to load previously the remote repositories dependencies into a tar.gz that need to be stored in ebuild files. This is ugly, I know, but there is no distfiles trusted repository alternative where I can place them. As a workaround, I could create gitlab or github repository and use git lfs to upload the artifacts that need to be loaded (since I didn't know any free Artifactory or NexusOSS repositories community supported). Then use the provided url to download the files. What do think about this two cases and what are your suggestions? Thanks, Samuel signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] musl doesn't provide execinfo.h
On 3/23/2020 04:21, Jaco Kroon wrote: > Hi, > > https://bugs.gentoo.org/713668 relates. > > * Searching for /usr/include/execinfo.h ... > sys-libs/glibc-2.29-r7 (/usr/include/execinfo.h) > > As I see I can either add an explicit depend on glibc which I'd prefer > not to. Or someone from the musl team could possibly assist on how to > get the backtrace() set of calls on musl please? > > Alternatively I need to add a test and simply path debug.c to only > provide stub function for print_backtrace(FILE *fp) that just does > fprintf(fp, "No backtrace() available to print a backtrace.\n"); > > Suggestions? > > Kind Regards, > Jaco Some quick searching on google, it looks like the cleanest fix for that bug is dahdi-tools needs to be patched to only include execinfo.h or only use backtrace() on glibc-based systems, and that patch then sent to the dahdi-tools upstream developers for inclusion in a future release. That way, we're not dragging that patch around forever in the tree or in the musl overlay. It also doesn't look like musl itself will ever implement execinfo.h or backtrace(), per this message in 2015 from the lead musl developer: https://www.openwall.com/lists/musl/2015/04/09/3 -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] network sandbox challenge
[2020-03-27 01:16:43+] Samuel Bernardo:
> 2) For snapd I need to load previously the remote repositories
> dependencies into a tar.gz that need to be stored in ebuild files. This
> is ugly, I know, but there is no distfiles trusted repository
> alternative where I can place them.
> As a workaround, I could create gitlab or github repository and use git
> lfs to upload the artifacts that need to be loaded (since I didn't know
> any free Artifactory or NexusOSS repositories community supported). Then
> use the provided url to download the files.
Couldn't the snapd_${PV}.vendor.tar.xz available in
https://github.com/snapcore/snapd/releases
work in your case to avoid downloading tarballs?
And probably consider using go-modules.eclass, which can also allow
packaging when there is no vendoring done by the upstream by just
cut(1)'ing the content of go.sum
And I'm not so sure why you want to apparently host a tarball?
Maybe you're not aware that SRC_URI accepts multiple tarballs? And
btw you strongly should only use upstream URLs in it, they don't
need to be mirrored in distfiles.gentoo.org for the ebuild to work.
Re: [gentoo-dev] [PATCH v2]
On Thu, Mar 26, 2020 at 7:19 PM Patrick McLean wrote: > > This patch splits the definition of _PYTHON_ALL_IMPLS and > _python_impl_supported to a separate eclass, this allows overlays > to easily support a different set of python implementations than > ::gentoo without having to fork the entire suite of eclasses. > > Changes from previous version (based on feedback on IRC): > - add a guard variable to make sure it's being inherited > python-utils-r1.eclass In the future, please generate patches using git-format-patch, and mail them using git-send-email. That way we don't end up having to open an attachment, and we can also review the commit message.
Re: [gentoo-dev] network sandbox challenge
On Fri, Mar 27, 2020 at 01:16:43AM +, Samuel Bernardo wrote: > Dear all, > > Fulfilling the linting of ebuild code style design for software projects > that loads their dependencies during build, such as go based projects or > npm as an example, could be very nasty. > > Looking into source code of snapd or opennebula as two examples, I need > to break network sandbox to get all dependencies for snapd go modules or > opennebula sunstone npm code. Have you looked at the EGO_SUM in go-module? This already covers ANY go package that uses go.mod + go.sum, in a fully reproducible way that does not break network sandbox. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: PGP signature
Re: [gentoo-dev] musl doesn't provide execinfo.h
Hi, On 2020/03/27 03:25, Joshua Kinard wrote: > On 3/23/2020 04:21, Jaco Kroon wrote: >> Hi, >> >> https://bugs.gentoo.org/713668 relates. >> >> * Searching for /usr/include/execinfo.h ... >> sys-libs/glibc-2.29-r7 (/usr/include/execinfo.h) >> >> As I see I can either add an explicit depend on glibc which I'd prefer >> not to. Or someone from the musl team could possibly assist on how to >> get the backtrace() set of calls on musl please? >> >> Alternatively I need to add a test and simply path debug.c to only >> provide stub function for print_backtrace(FILE *fp) that just does >> fprintf(fp, "No backtrace() available to print a backtrace.\n"); >> >> Suggestions? >> >> Kind Regards, >> Jaco > Some quick searching on google, it looks like the cleanest fix for that bug > is dahdi-tools needs to be patched to only include execinfo.h or only use > backtrace() on glibc-based systems, and that patch then sent to the > dahdi-tools upstream developers for inclusion in a future release. That > way, we're not dragging that patch around forever in the tree or in the musl > overlay. Thanks. I'll see action accordingly. > > It also doesn't look like musl itself will ever implement execinfo.h or > backtrace(), per this message in 2015 from the lead musl developer: > https://www.openwall.com/lists/musl/2015/04/09/3 > Implementing libunwind is overkill for my needs, I'll be happy to help push things upstream if somebody else cares enough to implement. Kind Regards, Jaco
Re: [gentoo-dev] [PATCH] Split python implementations definition to separate eclass
On Thu, 2020-03-26 at 14:03 -0700, Patrick McLean wrote: > This patch splits the definition of _PYTHON_ALL_IMPLS and > _python_impl_supported to a separate eclass, this allows overlays > to easily support a different set of python implementations than > ::gentoo without having to fork the entire suite of eclasses. NAK. This increases the maintenance effort (even if it means having to open yet another file) for *zero* gain to Gentoo users. Your policy is entirely broken by design and I'm against supporting it officially. The existing number of eclasses is already causing confusion and added maintenance effort, and it has strong justification in *a lot of shared code*. To say it bluntly: if you want to do stupid things, do them yourselves and don't expect others to help. You get paid for that. We just waste our time. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 0/1] allow extra implementations of python
On Thu, 2020-03-26 at 22:12 +0100, Ulrich Mueller wrote: > > > > > > On Thu, 26 Mar 2020, William Hubbs wrote: > > If there's a way inside an eclass to check that the ebuild inheriting > > it is in ::gentoo, I will use it to die if the ebuild is in ::gentoo > > and this variable is set. > > Oh please, not this again. An ebuild or eclass is supposed to work the > same everywhere, independent of the repo it is located in. > > Why don't you simply copy the eclass to your overlay and do the changes > there? > They did, and then they complained that every few months they have to update it. See the big slander mail from William. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] network sandbox challenge
On Fri, 2020-03-27 at 01:16 +, Samuel Bernardo wrote: > Dear all, > > Fulfilling the linting of ebuild code style design for software projects > that loads their dependencies during build, such as go based projects or > npm as an example, could be very nasty. > > Looking into source code of snapd or opennebula as two examples, I need > to break network sandbox to get all dependencies for snapd go modules or > opennebula sunstone npm code. > Stop here. If you think that you need to 'break network sandbox', you already have the wrong attitude and shouldn't continue. Network sandbox is not your enemy. Using network is. Network sandbox protects users from paying extra because you've written a bad ebuild that unexpectedly downloads lot of data on their mobile connection. Network sandbox makes sure that we don't end up delivering stuff that doesn't work to people who are on isolated networks or simply have non-permanent connections. Network sandbox makes sure that these ebuilds will work three months from now when upstream randomly decides to remove old files or shuffle servers, or just get hits by a temporary issue. There's no 'breaking the network sandbox'. You must fix the ebuild not to require Internet. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
