[gentoo-dev] Last rites: dev-util/pkgconfig
# David Seifert (2021-08-04) # Last release over 4 years ago, upstream pretty much dead, the # ecosystem has switched to dev-util/pkgconf, which is alive. Testing # and prefix bugs, blocks WANT_AUTOMAKE=1.12 removal. # Bug #245228, #632124, #691268, #767853, removal in 30 days. dev-util/pkgconfig signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Python 3.10.0rc1
On Wed, 2021-08-04 at 20:27 +0100, Sergei Trofimovich wrote: > On Tue, 03 Aug 2021 11:15:13 +0200 > Michał Górny wrote: > > > Hi, everyone. > > > > Just a quick note: I've pushed Python 3.10.0rc1 today. It has many last > > minute changes that can break packages that were ported to previous > > 3.10.0 betas before. > > > > For practical reasons, we're going to support only >=3.10.0_rc1 going > > forward. If your package fails with >=3.10.0_rc1, feel free to apply > > fixes without caring for backwards compatibility with betas. If you see > > failures with 3.10.0_beta4, please try upgrading to _rc1 first. > > > > Notably, the newest releases of dev-python/django and dev-python/sphinx > > that I've pushed today were updated for _rc1 and will have failures with > > _beta4. > > Should we drop PYTHON_COMPAT=python3_10 for known to break package versions? > For example latest stable dev-python/sphinx-4.0.3 did not like today's ~arch > python: I suppose that's fine if it doesn't break depgraph. For completeness, the newer sphinx version is fixed for that. -- Best regards, Michał Górny
Re: [gentoo-dev] Python 3.10.0rc1
On Tue, 03 Aug 2021 11:15:13 +0200
Michał Górny wrote:
> Hi, everyone.
>
> Just a quick note: I've pushed Python 3.10.0rc1 today. It has many last
> minute changes that can break packages that were ported to previous
> 3.10.0 betas before.
>
> For practical reasons, we're going to support only >=3.10.0_rc1 going
> forward. If your package fails with >=3.10.0_rc1, feel free to apply
> fixes without caring for backwards compatibility with betas. If you see
> failures with 3.10.0_beta4, please try upgrading to _rc1 first.
>
> Notably, the newest releases of dev-python/django and dev-python/sphinx
> that I've pushed today were updated for _rc1 and will have failures with
> _beta4.
Should we drop PYTHON_COMPAT=python3_10 for known to break package versions?
For example latest stable dev-python/sphinx-4.0.3 did not like today's ~arch
python:
Traceback (most recent call last):
File "/usr/lib/python-exec/python3.10/sphinx-build", line 33, in
sys.exit(load_entry_point('Sphinx==4.0.3', 'console_scripts',
'sphinx-build')())
File "/usr/lib/python-exec/python3.10/sphinx-build", line 25, in
importlib_load_entry_point
return next(matches).load()
File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 162, in load
module = import_module(match.group('module'))
File "/usr/lib/python3.10/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1050, in _gcd_import
File "", line 1027, in _find_and_load
File "", line 1006, in _find_and_load_unlocked
File "", line 688, in _load_unlocked
File "", line 883, in exec_module
File "", line 241, in _call_with_frames_removed
File "/usr/lib/python3.10/site-packages/sphinx/cmd/build.py", line 25, in
from sphinx.application import Sphinx
File "/usr/lib/python3.10/site-packages/sphinx/application.py", line 31, in
from sphinx.config import Config
File "/usr/lib/python3.10/site-packages/sphinx/config.py", line 21, in
from sphinx.util import logging
File "/usr/lib/python3.10/site-packages/sphinx/util/__init__.py", line 41, in
from sphinx.util.typing import PathMatcher
File "/usr/lib/python3.10/site-packages/sphinx/util/typing.py", line 37, in
from types import Union as types_Union
ImportError: cannot import name 'Union' from 'types'
(/usr/lib/python3.10/types.py)
--
Sergei
[gentoo-dev] Last rites: media-libs/memphis
# David Seifert (2021-08-04) # Last release 11 years ago, XDG env issue, no revdeps, blocks # WANT_AUTOMAKE=1.11 removal, last major distro to package this. # Bug #586586, removal in 30 days. media-libs/memphis signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: app-i18n/libtabe and app-i18n/xcin
# David Seifert (2021-08-04) # Last release 16 years ago, multiple build failures, unmaintained, # upstream disappeared, last distro that still packages this. # Bug #722376, #742938, #742941, removal in 30 days. app-i18n/libtabe app-i18n/xcin signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
On Tue, Aug 3, 2021 at 7:56 PM Sam James wrote: > > > > > On 4 Aug 2021, at 03:39, Thomas Deutschmann wrote: > > > > On 2021-08-01 01:56, Sam James wrote: > >> 1) Verify packages don't install tmpfiles to /etc/tmpfiles.d, which > >> is a deprecated location; > > > > This location is _not_ deprecated. > > > > This is the location for the local system administrator to override > > tmpfiles.d specifications installed by packages which should install below > > /usr. > > > > > > Sure, thanks for the clarification. It's deprecated in the sense of ebuilds > installing to it though, right? What if I use ebuilds to configure my local system settings? ;) -A > > best, > sam
Re: [gentoo-dev] Packages up for grabs
On 04/08/2021 11:08, Sergei Trofimovich wrote: Last batch of packages in search of a dedicated maintainer: x11-misc/i3status I've taken it, thanks Sergei None of them should have any immediate problems.
[gentoo-dev] Last rites: dev-libs/hyperleveldb and dev-libs/replicant
# David Seifert (2021-08-04) # Last release 7 years ago, multiple test failures, unmaintained, # last distro that still packages this. # Bug #629610, #646690, removal in 30 days. dev-libs/hyperleveldb dev-libs/replicant signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
On 2021-08-04 04:56, Sam James wrote: Sure, thanks for the clarification. It's deprecated in the sense of ebuilds installing to it though, right? Well, it triggered me because saying it's deprecated implies two things for me: 1) It was OK for packages to do that in the past 2) Something has changed upstream Regarding 1) It was never OK for packages to install in that location. That will break the override mechanism systemd introduced. I.e. packages were and are still only allowed to install below /usr (/lib), to allow local system administrators to override installed unit/tmpfiles spec by placing a file with the same name in the corresponding directory in /etc. Regarding 2) Nothing has changed upstream regarding these locations. I personally hope that this QA check will never fire in hope we never added an ebuild doing something like that but in the end, that's the idea of having such a check: To notice something like that, just in case ;-) -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2 2/3] virtualx.eclass: Make VIRTUALX_DEPEND readonly in EAPI-8
On Mittwoch, 4. August 2021 12:29:40 CEST Ulrich Mueller wrote:
> > On Wed, 04 Aug 2021, Andreas Sturmlechner wrote:
> > +# Standard dependencies string that is automatically added to BDEPEND
> > +# (in EAPI-6: DEPEND) unless VIRTUALX_REQUIRED is set to "manual".
> > +# DEPRECATED: Pre-EAPI-8 you can specify the variable BEFORE inherit
> > +# to add more dependencies.
> > +[[ ${EAPI} == [67] ]] || VIRTUALX_DEPEND=""
> > +VIRTUALX_DEPEND+="
> >
> > x11-base/xorg-server[xvfb]
> > x11-apps/xhost
> >
> > "
> >
> > +[[ ${EAPI} == [67] ]] || readonly VIRTUALX_DEPEND
>
> I wonder about this one, because the *DEPEND variables are automatically
> accumulated across eclasses and ebuild. What is the advantage of the
> ebuild specifying VIRTUALX_DEPEND, instead of specifying BDEPEND
> directly?
>
The answer is in the updated description in this patch: ebuilds/eclasses
specifying VIRTUALX_REQUIRED=manual have (so far) been relying on the content
of VIRTUALX_DEPEND to add the standard dependencies from within the ebuild
instead of having virtualx.eclass do it for them, for whatever complex
dependency situation they might have.
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH v2 2/3] virtualx.eclass: Make VIRTUALX_DEPEND readonly in EAPI-8
> On Wed, 04 Aug 2021, Andreas Sturmlechner wrote:
> +# Standard dependencies string that is automatically added to BDEPEND
> +# (in EAPI-6: DEPEND) unless VIRTUALX_REQUIRED is set to "manual".
> +# DEPRECATED: Pre-EAPI-8 you can specify the variable BEFORE inherit
> +# to add more dependencies.
> +[[ ${EAPI} == [67] ]] || VIRTUALX_DEPEND=""
> +VIRTUALX_DEPEND+="
> x11-base/xorg-server[xvfb]
> x11-apps/xhost
> "
> +[[ ${EAPI} == [67] ]] || readonly VIRTUALX_DEPEND
I wonder about this one, because the *DEPEND variables are automatically
accumulated across eclasses and ebuild. What is the advantage of the
ebuild specifying VIRTUALX_DEPEND, instead of specifying BDEPEND
directly?
Ulrich
signature.asc
Description: PGP signature
[gentoo-dev] Tinderbox available for overlays
Hello, I would like to let you know that tinderbox is available for overlays. If you want tinderbox to run against your overlay, just send me an email and provide a valid Gentoo Bugzilla account for bug assignation. Agostino
[gentoo-dev] [PATCH v2 3/3] virtualx.eclass: Remove leftover variable VIRTUALX_COMMAND
Follow-up to commit 11fb990.
Signed-off-by: Andreas Sturmlechner
---
eclass/virtualx.eclass | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/eclass/virtualx.eclass b/eclass/virtualx.eclass
index ad376c497ac..9e2e9f00b78 100644
--- a/eclass/virtualx.eclass
+++ b/eclass/virtualx.eclass
@@ -42,11 +42,7 @@ VIRTUALX_DEPEND+="
"
[[ ${EAPI} == [67] ]] || readonly VIRTUALX_DEPEND
-# @ECLASS-VARIABLE: VIRTUALX_COMMAND
-# @DESCRIPTION:
-# Command (or eclass function call) to be run in the X11 environment
-# (within virtualmake function).
-: ${VIRTUALX_COMMAND:="emake"}
+[[ ${VIRTUALX_COMMAND} ]] && die "VIRTUALX_COMMAND has been removed and is a
no-op"
case ${VIRTUALX_REQUIRED} in
manual)
--
2.32.0
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] [PATCH v2 2/3] virtualx.eclass: Make VIRTUALX_DEPEND readonly in EAPI-8
Any additional dependencies shall be defined inside ebuilds instead.
Signed-off-by: Andreas Sturmlechner
---
eclass/virtualx.eclass | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/eclass/virtualx.eclass b/eclass/virtualx.eclass
index 155d611e66e..ad376c497ac 100644
--- a/eclass/virtualx.eclass
+++ b/eclass/virtualx.eclass
@@ -29,14 +29,18 @@ _VIRTUALX_ECLASS=1
: ${VIRTUALX_REQUIRED:=test}
# @ECLASS-VARIABLE: VIRTUALX_DEPEND
+# @DEFAULT_UNSET
# @DESCRIPTION:
-# Dep string available for use outside of eclass, in case a more
-# complicated dep is needed.
-# You can specify the variable BEFORE inherit to add more dependencies.
-VIRTUALX_DEPEND="${VIRTUALX_DEPEND}
+# Standard dependencies string that is automatically added to BDEPEND
+# (in EAPI-6: DEPEND) unless VIRTUALX_REQUIRED is set to "manual".
+# DEPRECATED: Pre-EAPI-8 you can specify the variable BEFORE inherit
+# to add more dependencies.
+[[ ${EAPI} == [67] ]] || VIRTUALX_DEPEND=""
+VIRTUALX_DEPEND+="
x11-base/xorg-server[xvfb]
x11-apps/xhost
"
+[[ ${EAPI} == [67] ]] || readonly VIRTUALX_DEPEND
# @ECLASS-VARIABLE: VIRTUALX_COMMAND
# @DESCRIPTION:
--
2.32.0
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] [PATCH v2 1/3] virtualx.eclass: Support EAPI-8
Standardise include guard, fix minor typo.
Signed-off-by: Andreas Sturmlechner
---
eclass/virtualx.eclass | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/eclass/virtualx.eclass b/eclass/virtualx.eclass
index ca52e8d2815..155d611e66e 100644
--- a/eclass/virtualx.eclass
+++ b/eclass/virtualx.eclass
@@ -6,17 +6,16 @@
# x...@gentoo.org
# @AUTHOR:
# Original author: Martin Schlemmer
-# @SUPPORTED_EAPIS: 6 7
-# @BLURB: This eclass can be used for packages that needs a working X
environment to build.
+# @SUPPORTED_EAPIS: 6 7 8
+# @BLURB: This eclass can be used for packages that need a working X
environment to build.
-case ${EAPI:-0} in
- [0-5]) die "virtualx.eclass: EAPI ${EAPI} is too old." ;;
- 6|7) ;;
- *) die "virtualx.eclass: EAPI ${EAPI} is not supported yet." ;;
+case ${EAPI} in
+ 6|7|8) ;;
+ *) die "${ECLASS}: EAPI ${EAPI:-0} is not supported." ;;
esac
-if [[ ! ${_VIRTUAL_X} ]]; then
-_VIRTUAL_X=1
+if [[ ! ${_VIRTUALX_ECLASS} ]]; then
+_VIRTUALX_ECLASS=1
# @ECLASS-VARIABLE: VIRTUALX_REQUIRED
# @PRE_INHERIT
--
2.32.0
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Packages up for grabs
Last batch of packages in search of a dedicated maintainer: app-emulation/ski app-misc/bb app-misc/golly dev-libs/editline dev-scheme/bytestructures dev-scheme/guile-gcrypt dev-scheme/guile-git dev-scheme/guile-sqlite3 dev-util/unifdef games-emulation/dolphin media-sound/xmms2 net-fs/curlftpfs sys-apps/prctl sys-boot/elilo sys-fs/libeatmydata www-client/lynx x11-misc/i3status x11-plugins/pidgin-window_merge x11-terms/cool-retro-term None of them should have any immediate problems. -- Sergei
Re: [gentoo-dev] coordination on JetBrains IDEs?
Hi, Op ma 10 mei 2021 om 17:32 schreef Jason A. Donenfeld : > These are all JetBrains IDEs that all basically follow the same format. > > I wonder if we can unify these somehow? Anyone interested in working > on that or have an idea of the feasibility? > I asked on IRC a few days ago but didn't get a reply so I'll ask here again: has anything been done towards this? I wanted to get Webstorm installed on my pc but the latest ebuild I can find is in the ssnb overlay and already quite old. I remembered seeing this email pass by and thought I'd check in first before I start cobbling together an updated ebuild for Webstorm. -- Met vriendelijke groeten, Best regards, Mathy Vanvoorden
